GiGaRuN Solutions
Vos métiers, nos solutions Excellence IT — La Réunion
+262 692 31 11 91
← Retour à l’accueil des guides

Workstation IA locale —
architecture complète

Guide technique de configuration d'un poste de travail haute performance pour l'inférence IA locale, l'infogérance multi-clients et la stratégie de dispatch LLM hybride.

OS Ubuntu 26.04 LTS
CPU Ryzen 9 7900 · 12C/24T
GPU Arc Pro B70 · 32 Go VRAM
RAM 192 Go DDR5
Stockage 8 To RAID0 + 14,25 To bruts

01 · Architecture matérielle

Une config taillée pour
l'inférence sans compromis

Chaque composant a été choisi pour servir un rôle précis dans une architecture IA locale — de la capacité VRAM pour faire tourner des modèles 30B+ jusqu'au volume de RAM système qui permet de faire coexister inférence GPU, machines virtuelles clientes et services d'infogérance.

Processeur · AM5
AMD Ryzen 9 7900
12 cœurs / 24 threads · Zen 4 · jusqu'à 5,4 GHz · 65W TDP · cache L3 64 Mo
Multi-thread
~24 000 pts
Single-thread
~2 050 pts

Le 65W TDP est un avantage réel sur cette carte B650M — VRM adaptés, thermique maîtrisée, idéal pour un usage continu 24/7.

GPU IA · PCIe 4.0 x16
Intel Arc Pro B70
32 Xe2 cores · 256 moteurs XMX · 32 Go GDDR6 ECC · Battlemage G31 · TSMC 5nm
Bande passante
608 Go/s
TOPS INT8
367 TOPS
FP32
22,9 TFLOPS

La bande passante mémoire est le facteur clé pour la vitesse de génération de tokens en LLM. 608 Go/s = 5× le Mac mini M4.

Mémoire système · DDR5
192 Go DDR5 (4×48 Go)
Dual channel · Ryzen 9 7900 · B650M DS3H · 4 slots DIMM · jusqu'à 256 Go supportés
Capacité GPU
32 Go VRAM
RAM système
192 Go DDR5

192 Go = VMs clientes isolées + Wazuh + services + modèles LLM CPU-side en parallèle, sans jamais swapper.

Carte mère · Micro-ATX
Gigabyte B650M DS3H
AM5 · B650 chipset · 2× M.2 PCIe 4.0 CPU-direct · 4× SATA III · 2,5 GbE · USB 3.2 Gen2×2
Slots M.2
2× PCIe 4.0
Ports SATA
4× SATA III
✓
Topologie optimale pour le RAID0 : les deux slots M2A_CPU et M2B_CPU sont CPU-direct PCIe 4.0 x4 — aucun uplink chipset, aucun goulot. Le RAID0 atteint ses vitesses théoriques sur cette carte.

Capacité LLM par mode d'inférence

Modèle Quantisation Taille mémoire Mode Tokens/s estimés
Llama 3.1 8B Q4_K_M ~5 Go GPU pur ~80–120 t/s
Qwen3 14B Q4_K_M ~9 Go GPU pur ~50–80 t/s
Qwen3 30B Q4_K_M ~18 Go GPU pur ~25–40 t/s
Llama 3.3 70B Q4_K_M ~43 Go GPU+CPU hybride ~8–15 t/s
Qwen3 72B Q3_K_M ~31 Go GPU pur ~12–20 t/s
DeepSeek R1 70B Q2_K ~28 Go GPU pur ~10–18 t/s (qualité dégradée)

* Mode hybride via llama.cpp --n-gpu-layers : couches critiques en VRAM, reste en RAM DDR5. Vitesse réduite mais modèles >32 Go accessibles.

02 · Stratégie de stockage

Quatre niveaux de stockage,
un rôle précis chacun

L'architecture retenue sépare clairement le système (SATA, fiable, isolé), les données chaudes (RAID0 NVMe, performance maximale), et l'archivage/backup (HDD, haute capacité, endurance 24/7). Chaque niveau répond à une contrainte spécifique de la workstation IA + infogérance.

SATA
Kingston A400 256 Go SATA III 6Gb/s · 2,5" · 7mm
SYSTÈME / OS

Disque dédié à Ubuntu 26.04. Isoler le système sur un disque SATA séparé est une décision d'architecture volontaire : si le RAID0 NVMe subit une défaillance, l'OS reste intact et opérationnel. Aucun service critique ne dépend de ce disque sauf le boot.

LECTURE SÉQ.~500 Mo/s
ÉCRITURE SÉQ.~450 Mo/s
INTERFACESATA 6Gb/s
PORT CARTE MÈRESATA 0
HDD
Toshiba N300 14 To 7200 rpm · 512 Mo cache · 3,5" · NAS grade
BACKUP + ARCHIVE FROIDE

Le N300 est un disque NAS 24/7 avec 180 To/an de workload rating et vibration compensation — conçu exactement pour cet usage. Destination de backup du RAID0, bibliothèque de modèles froids, stockage DPO longue durée, et snapshots VM. C'est le filet de sécurité de toute la config.

LECTURE SÉQ.~250 Mo/s
CACHE512 Mo
ROTATION7200 rpm
PORT CARTE MÈRESATA 1
RAID
/dev/md0 — RAID0 NVMe · 8 To bruts mdadm software RAID · CPU-direct PCIe 4.0 x4 × 2 · Aucun goulot chipset
DONNÉES CHAUDES · IA · VMs

Les deux slots M2A_CPU et M2B_CPU de la B650M DS3H sont CPU-direct — aucun uplink chipset entre les drives et le processeur. Cette topologie est exactement ce qu'il faut pour que le RAID0 atteigne ses vitesses théoriques. Le striping double la bande passante effective pour les lectures/écritures larges : modèles LLM (gros fichiers séquentiels), images de VMs, datasets de training. C'est le cœur de performance de la machine.

LECTURE THÉORIQUE~14 750 Mo/s
ÉCRITURE THÉORIQUE~13 900 Mo/s
CAPACITÉ UTILE8 To (2×4 To)
OUTILmdadm level=0
⚠
RAID0 = zéro redondance. Un NVMe qui lâche = perte totale des 8 To. Le backup nocturne vers le Toshiba N300 est obligatoire, pas optionnel. Configurer restic ou rsync en cron dès la mise en route.
M2A_CPU · DRIVE 1
Samsung 990 Pro 4 To
7 450 Mo/s R · 6 900 Mo/s W · Samsung Pascal · V-NAND TLC · 1 600K IOPS
M2B_CPU · DRIVE 2
Kingston FURY Renegade 4 To
7 300 Mo/s R · 7 000 Mo/s W · Phison E18 · 3D TLC · 1 000K IOPS

03 · Partitionnement

Schéma de partitionnement
Ubuntu 26.04

L'objectif est de protéger le système (A400) des données chaudes (RAID0), tout en évitant que des services comme Ollama ou Docker saturent le disque OS en écrivant dans /var par défaut.

Kingston A400 — /dev/sda

Point de montage Taille Système de fichiers Rôle
/boot/efi 512 Mo FAT32 Partition EFI — boot UEFI Ubuntu
/boot 2 Go ext4 Noyaux Linux, initramfs, grub
/ ~253 Go ext4 Système Ubuntu, binaires, packages apt — pas de /home ni /var

/dev/md0 — RAID0 NVMe (8 To)

Point de montage Taille Système de fichiers Rôle
/home 2 To ext4 Profil utilisateur, projets GiGaRuN, configurations, dépôts git
/var 1 To ext4 Docker layers, Ollama /var/lib/ollama, logs applicatifs, bases de données
/data/models 2 To ext4 Modèles LLM actifs (GGUF, safetensors) — bibliothèque chaude
/data/vms 2 To ext4 Images libvirt/QEMU-KVM — VMs clientes isolées (Wazuh, Dolibarr, Windows)
/data/workspace ~1 To ext4 Données de travail chaudes, cache inference, datasets temporaires

/dev/sdb — Toshiba N300 14 To

Point de montage Taille Système de fichiers Rôle
/backup/raid0 8 To ext4 Sauvegarde nocturne du RAID0 — restic ou rsync incrémental
/backup/models-cold 3 To ext4 Bibliothèque froide de modèles LLM — chargés sur demande vers /data/models
/backup/dpo 1 To ext4 Logs, documents DPO longue durée, archives RGPD
/backup/snapshots ~2 To ext4 Snapshots VM froids, images disque clientes, exports Dolibarr

04 · Inférence IA locale

Pourquoi cette config est
une vraie plateforme IA

La combinaison Arc Pro B70 (32 Go VRAM / 608 Go/s) + 192 Go DDR5 + RAID0 14 750 Mo/s place cette machine dans une catégorie rare : capable de faire tourner des modèles 30B en temps réel et des 70B en mode hybride, sans aucun service cloud, sans latence réseau, sans données qui sortent du périmètre.

💡
La bande passante mémoire GPU est le facteur numéro 1 en inférence LLM. Pas les TFLOPS, pas les TOPS — la quantité de données que le GPU peut lire par seconde depuis sa mémoire. À 608 Go/s, le B70 charge et traite les poids du modèle 5× plus vite qu'un Mac mini M4 (120 Go/s), ce qui se traduit directement en tokens par seconde.

Stack logiciel recommandé

Composant Rôle Raison du choix
Ollama Serveur LLM local · API OpenAI-compatible Interface unifiée, support llama.cpp backend, gestion automatique du VRAM, API REST localhost:11434
llama.cpp Backend inférence bas niveau Support SYCL/OpenCL pour Arc B70 sous Linux, mode hybride GPU+CPU via --n-gpu-layers
OpenVINO Optimisation Intel hardware Runtime Intel optimisé pour Xe2 — INT8/INT4 quantization nativement sur B70, meilleure efficacité que PyTorch générique
Open WebUI Interface utilisateur LLM Frontend Ollama-compatible, multi-modèles, gestion de contexte, RAG intégré
AnythingLLM RAG local sur documents clients Indexation de documents clients sensibles en local, vecteurs stockés sur RAID0, zéro cloud
QEMU-KVM + libvirt Virtualisation clientes 192 Go DDR5 permettent 8–12 VMs clientes isolées simultanées avec resources dédiées
Wazuh SIEM/XDR infogérance Déployé en conteneur Docker sur /var, collecte agents clients via VPN

Montage du RAID0 — commandes Ubuntu 26.04

# ── Vérifier que les deux NVMe sont détectés ────────────────────────── lsblk # → nvme0n1, nvme1n1 attendus nvme list # ── Créer l'array RAID0 ─────────────────────────────────────────────── sudo mdadm --create /dev/md0 \ --level=0 \ --raid-devices=2 \ --chunk=512 \ /dev/nvme0n1 /dev/nvme1n1 # ── Formater et partitionner l'array ───────────────────────────────── sudo parted /dev/md0 mklabel gpt sudo parted /dev/md0 mkpart primary ext4 0% 25% # /home ~2To sudo parted /dev/md0 mkpart primary ext4 25% 37% # /var ~1To sudo parted /dev/md0 mkpart primary ext4 37% 62% # models ~2To sudo parted /dev/md0 mkpart primary ext4 62% 87% # vms ~2To sudo parted /dev/md0 mkpart primary ext4 87% 100% # workspace sudo mkfs.ext4 -L home /dev/md0p1 sudo mkfs.ext4 -L var_data /dev/md0p2 sudo mkfs.ext4 -L ai_models /dev/md0p3 sudo mkfs.ext4 -L vms /dev/md0p4 sudo mkfs.ext4 -L workspace /dev/md0p5 # ── Déplacer /var sur le RAID (AVANT Docker/Ollama) ───────────────── sudo mkdir -p /mnt/var_new sudo mount /dev/md0p2 /mnt/var_new sudo rsync -aAXv /var/ /mnt/var_new/ # ── Persistance mdadm ──────────────────────────────────────────────── sudo mdadm --detail --scan | sudo tee -a /etc/mdadm/mdadm.conf sudo update-initramfs -u # ── fstab — ajouter les montages ───────────────────────────────────── sudo blkid /dev/md0p1 # récupérer les UUID # Ajouter dans /etc/fstab : # UUID=XXXX /home ext4 defaults,nofail 0 2 # UUID=XXXX /var ext4 defaults,nofail 0 2 # UUID=XXXX /data/models ext4 defaults,nofail 0 2 # UUID=XXXX /data/vms ext4 defaults,nofail 0 2 # UUID=XXXX /data/workspace ext4 defaults,nofail 0 2 # ── Backup RAID0 → N300 (cron quotidien) ───────────────────────────── sudo apt install restic restic init --repo /backup/raid0 # Ajouter dans crontab -e : # 0 2 * * * restic backup /data /home /var --repo /backup/raid0

Configurer Ollama pour l'Arc Pro B70

# ── Driver Intel Xe / compute runtime ──────────────────────────────── sudo apt install -y intel-opencl-icd intel-level-zero-gpu level-zero sudo apt install -y intel-oneapi-runtime-opencl intel-oneapi-runtime-level-zero # ── Vérifier que le B70 est vu ─────────────────────────────────────── clinfo | grep "Device Name" # → Intel(R) Arc(TM) Pro B70 Graphics # ── Installer Ollama ───────────────────────────────────────────────── curl -fsSL https://ollama.ai/install.sh | sh # ── Variables d'environnement pour forcer le GPU Intel ─────────────── sudo systemctl edit ollama.service # Ajouter : # [Service] # Environment="OLLAMA_GPU=true" # Environment="ZES_ENABLE_SYSMAN=1" # Environment="SYCL_DEVICE_FILTER=level_zero:gpu" # ── Mode hybride pour les grands modèles ───────────────────────────── # Dans Modelfile ou via llama.cpp direct : llama-server \ --model /data/models/llama-3.3-70b.Q4_K_M.gguf \ --n-gpu-layers 48 \ # couches en VRAM (ajuster selon le modèle) --ctx-size 8192 \ --threads 12 \ # 12 cœurs Ryzen 9 7900 --port 8080

05 · Stratégie de dispatch IA

Local vs cloud — politique
de dispatch LLM

En tant que DSI/RSSI externalisé et DPO, la question du dispatch n'est pas que technique — c'est une obligation légale et contractuelle. Toute donnée client, élément de configuration sensible, ou information à caractère personnel doit rester dans le périmètre local. Claude Code ou Codex ne reçoivent que ce qui est explicitement classé non-sensible.

Inférence locale — modèles on-prem
  • Données personnelles clients (RGPD art. 28 — sous-traitance)
  • Configurations réseau, credentials, secrets d'infrastructure
  • Logs Wazuh, alertes SIEM, incidents de sécurité
  • Documents contractuels clients, devis, factures Dolibarr
  • Code source propriétaire clients (Dolibarr custom, API internes)
  • Données de supervision (inventaires, topologie réseau)
  • Analyses forensiques et rapports de pentest
  • Données DPO : registre des traitements, violations, DPIA
  • Communications sensibles (messagerie chiffrée, contrats NDA)
  • Mots de passe, clés API, certificats TLS/SSL
Dispatch cloud — Claude Code / Codex
  • Génération de code générique non lié à un client (scripts utilitaires, boilerplate)
  • Refactoring de code public ou open source anonymisé
  • Documentation technique générale, README, wikis publics
  • Rédaction de contenu marketing GiGaRuN (site, plaquettes)
  • Brainstorming commercial, argumentation offres, pricing
  • Génération de rapports à partir de données anonymisées
  • Templates de contrats avec placeholders (sans données réelles)
  • Formation et veille technologique (résumés, synthèses)
  • Problèmes de dev génériques non contextualisés client
  • Tests unitaires sur code anonymisé sans logique métier sensible
REQUÊTE ENTRANTE │ ▼ ┌─────────────────────────────────────┐ │ Contient des données client ? │ │ PII / config / secrets / logs ? │ └────────────┬────────────────────────┘ │ OUI ──────────────────────────── NON │ │ ▼ ▼ INFÉRENCE LOCALE ┌─────────────────────┐ Ollama · Arc Pro B70 │ Requis une capacité │ Qwen3 30B / Llama 70B │ > modèle local ? │ Zéro donnée sortante └────────┬────────────┘ │ OUI ──── NON │ │ ▼ ▼ Claude Code Ollama local OpenAI Codex (suffisant) (non-sensible uniquement)

Configurer Claude Code en mode hybride local/cloud

# ── Installer Claude Code (Node.js requis) ─────────────────────────── npm install -g @anthropic-ai/claude-code # ── Configurer un proxy local (LiteLLM) pour router local vs cloud ─── pip install litellm cat > litellm_config.yaml <<EOF model_list: - model_name: local-30b litellm_params: model: ollama/qwen3:30b api_base: http://localhost:11434 - model_name: claude-cloud litellm_params: model: claude-sonnet-4-6 api_key: os.environ/ANTHROPIC_API_KEY EOF litellm --config litellm_config.yaml --port 4000 # ── Claude Code pointe vers le proxy local par défaut ──────────────── export ANTHROPIC_BASE_URL=http://localhost:4000 claude # → route vers local-30b par défaut, cloud sur demande explicite # ── Règle .claudeignore pour protéger les données sensibles ────────── cat > ~/.claude/.claudeignore <<EOF **/client_data/** **/wazuh_logs/** **/*.env **/*.pem **/*.key **/dolibarr/conf/conf.php **/backup/** EOF

06 · Mise en route

Séquence d'installation
complète

Ordre des opérations recommandé pour un déploiement propre. L'isolation des services dès le début évite les migrations douloureuses plus tard.

Étape Action Notes critiques
01 Installer Ubuntu 26.04 sur A400 (SATA) Partitionnement manuel — ne pas toucher aux NVMe pendant l'install. Boot UEFI sur A400.
02 Créer le RAID0 NVMe avec mdadm APRÈS premier boot. Vérifier que nvme0n1 et nvme1n1 sont vierges. Ne pas activer BIOS RAID mode.
03 Partitionner md0, formater, migrer /var Migrer /var AVANT d'installer Docker ou Ollama — sinon migration post-installation complexe.
04 Installer drivers Intel Xe (compute runtime) intel-opencl-icd + level-zero. Vérifier avec clinfo que le B70 est visible.
05 Installer Ollama, tester avec un modèle 8B ollama run llama3.1:8b — vérifier GPU offload dans les logs (n_gpu_layers > 0).
06 Configurer restic → /backup/raid0 (N300) Cron 2h du matin. Premier backup complet avant tout usage production. Tester la restauration.
07 Installer Docker, déployer Wazuh + Open WebUI /var/lib/docker est sur le RAID0 — OK. Wazuh consomme beaucoup de RAM, allouer 8-16 Go.
08 Configurer QEMU-KVM + libvirt Images VM dans /data/vms. Activer nested virtualization si besoin (AMD-V).
09 Déployer LiteLLM proxy + Claude Code Configurer .claudeignore immédiatement. Tester que les fichiers sensibles sont exclus.
10 Charger les modèles LLM dans /data/models Démarrer par Qwen3 14B (9 Go) et Llama 3.1 8B. Tester les débits avec llama-bench.
🔑
Point de vigilance RSSI : avec 192 Go de RAM et un GPU 32 Go, cette machine peut stocker et inférer sur des données très sensibles. Documenter le traitement dans le registre DPO de GiGaRuN (en tant que responsable de traitement pour l'usage interne) et dans les registres des clients si leurs données sont traitées localement.

Comparatif · Choix d'OS

Ubuntu, Proxmox ou Windows ?

Trois architectures possibles pour cette machine — chacune répond à un profil d'usage différent. Les onglets ci-dessous détaillent les avantages, inconvénients et verdict pour chaque option.

Recommandé · usage actuel
Ubuntu 26.04 LTS
Poste de travail IA direct, sans couche de virtualisation. Simplicité maximale, performances GPU natives.
Avantages
  • Drivers Intel Xe natifs — GPU accessible directement à Ollama sans passthrough
  • Installation simple — pas de configuration IOMMU/VFIO nécessaire
  • Performances GPU maximales — pas d'overhead virtualisation
  • Claude Code, Docker, QEMU-KVM cohabitent sans friction
  • Support Arc Pro B70 en pleine maturité sous Linux kernel 6.8+
  • Débogage direct — pas de couche intermédiaire à traverser
Inconvénients
  • Pas d'isolation native entre services clients — tout tourne sur le même OS
  • Snapshots système limités — btrfs/LVM requis, moins ergonomique que Proxmox
  • Scalabilité cluster impossible nativement — pas prévu pour évoluer vers du multi-nœud
  • Gestion des VMs Windows clients plus artisanale (virt-manager vs interface web Proxmox)
🎯
Verdict : meilleur choix pour démarrer vite et maximiser les performances IA. Idéal si la machine est principalement un poste de travail IA personnel avec quelques services annexes. C'est l'architecture documentée dans ce guide.
Recommandé · usage DSI multi-clients
Proxmox VE 9
Hyperviseur professionnel basé Debian 13 trixie, kernel 6.14+. Héberge VMs et LXC, gestion web centralisée, ZFS natif. La réponse longue durée pour un DSI externalisé — et le kernel 6.14 améliore significativement le support Intel Arc vs VE 8.
Avantages
  • Isolation réelle par client — chaque client dans son propre LXC/VM, réseau cloisonné
  • Snapshots natifs instantanés — VM entière + données en un clic, restauration testable
  • ZFS natif dans l'installeur — ARC cache RAM, checksums, snapshots incrémentaux
  • Interface web centralisée — Wazuh, Dolibarr, VMs Windows, tout dans un seul panel
  • Arc Pro B70 supporte SR-IOV — conçu pour la virtualisation GPU, meilleur que les Arc grand public
  • Kernel 6.14+ (PVE 9) — support Intel Xe/Arc nettement amélioré vs kernel 6.8 de PVE 8 : meilleure stabilité passthrough, GuC/HuC firmware chargés automatiquement
  • Scalabilité cluster — ajout d'un nœud natif si l'activité grandit
  • 192 Go RAM → allocation généreuse sans manque : ia-node 64 Go, Windows 16 Go, LXC 8 Go chacun
Inconvénients
  • GPU passthrough Arc Pro B70 — 1 à 2h de setup VFIO/IOMMU, à valider sur ta machine spécifique
  • SR-IOV Arc sur Linux encore en maturation — moins stable qu'un passthrough complet (amélioré sur kernel 6.14 de PVE 9, mais pas encore au niveau NVIDIA)
  • Host headless — pas d'interface graphique sur Proxmox lui-même, tout passe par SSH ou web
  • Légère perte de performances GPU vs bare metal (overhead hyperviseur)
  • Complexité initiale supérieure — groupes IOMMU à vérifier, configuration BIOS spécifique
Proxmox VE 9 (Debian trixie) │ ├── ZFS stripe — 990 Pro + FURY Renegade (8 To) │ ├── /rpool/data/vm-disks → images VM │ └── /rpool/data/ct-volumes → volumes LXC │ ├── VM : Ubuntu Server 24.04 — "ia-node" │ ├── GPU passthrough : Arc Pro B70 (VFIO) │ ├── RAM : 64 Go · vCPU : 8 cores │ └── Ollama + Open WebUI + AnythingLLM │ ├── VM : Windows 11 (tests clients) │ └── 16 Go RAM · pas de GPU │ ├── LXC : wazuh-stack │ └── 16 Go RAM · Docker inside LXC │ ├── LXC : dolibarr │ └── 8 Go RAM · MariaDB + PHP │ └── LXC : services └── Nginx reverse proxy · Vaultwarden · etc.
🏗️
Verdict : meilleur choix à long terme pour GiGaRuN en tant que DSI externalisé. L'isolation clients, les snapshots et la gestion centralisée justifient la complexité initiale. PVE 9 / kernel 6.14 lève une partie des réserves sur le support Arc — c'est le bon moment pour s'y mettre. Point bloquant à valider en premier : vérifier que le B70 est seul dans son groupe IOMMU sur ce B650M avant de migrer.
Non recommandé · usage IA locale
Windows 11 Pro
Option de dernier recours si contrainte logicielle forte. Support Ollama existant mais performances et flexibilité très en deçà des alternatives Linux.
Avantages
  • Pas de friction pour les outils Microsoft (Office, Teams, RDP)
  • Ollama disponible sur Windows — installation simple via .exe
  • WSL2 permet de faire tourner des outils Linux sans dual-boot
  • Familiarité — courbe d'apprentissage nulle si déjà sur Windows
Inconvénients
  • Support Intel Arc sur Windows instable pour le compute — drivers OneAPI moins matures que Linux
  • Performances GPU Ollama inférieures à Linux native (tests réels : -20 à -40% tokens/s)
  • Docker Desktop sous Windows — overhead significatif, moins fiable qu'un Docker Linux natif
  • Pas de ZFS natif — storage pools et snapshots absents ou limités (Storage Spaces)
  • Licences Windows Server requises pour vraie isolation clients
  • Mises à jour forcées — risque de redémarrage non planifié en production
  • Télémétrie et surface d'attaque supérieure — problématique pour des données clients sensibles
⚠️
Verdict : à éviter pour une workstation IA principale. Le support Intel Arc pour le compute ML est significativement moins bon sous Windows. Acceptable uniquement comme VM cliente dans Proxmox ou si une contrainte logicielle spécifique l'impose.
⚡
vLLM sur Arc Pro B70 : vLLM dispose d'un backend Intel XPU via --device xpu et OpenVINO. Moins mature que CUDA mais fonctionnel sur B70 — avantage principal vs Ollama : batching continu multi-utilisateurs, indispensable pour un service SaaS avec plusieurs clients simultanés. Voir la section Architecture LLM Service ci-dessous.
Synthèse · tableau comparatif
Critère Ubuntu Desktop Proxmox VE Windows 11 Pro
Simplicité de démarrage✓✓ Excellent∼ Moyen✓ Bon
Performances GPU Ollama✓✓ Natives∼ -5 à -10%✗ -20 à -40%
Isolation services clients✗ Faible✓✓ Forte✗ Faible
Snapshots infra∼ Manuel✓✓ Natifs✗ Limités
Stack Docker/Linux✓✓ Native✓✓ Native (VM)∼ WSL2
Scalabilité cluster✗ Non✓✓ Oui✗ Non
Gestion multi-VMs clients∼ virt-manager✓✓ Interface web∼ Hyper-V
Adapté DSI externalisé∼ Moyen✓✓ Très bien✗ Non
Complexité setup GPU IA✓✓ Simple∼ VFIO/IOMMU✗ Drivers instables
Sécurité données clients∼ Correcte✓✓ Isolation forte✗ Télémétrie
vLLM (batching multi-clients)✓✓ Natif XPU✓✓ Via VM Ubuntu✗ Non supporté
LiteLLM billing abonnements✓✓ Docker natif✓✓ LXC/VM∼ WSL2 instable

Architecture commerciale · LLM as a Service

Offrir des abonnements LLM
à vos clients PME

La stack ci-dessous transforme la workstation en un service LLM facturable — modèles locaux sur le B70 pour la confidentialité, fallback cloud pour les surcharges, LiteLLM comme couche d'orchestration et de billing.

Internet │ ▼ [ Cloudflare Tunnel ] ← HTTPS automatique · DDoS · aucun port ouvert sur le firewall │ ▼ [ Nginx reverse proxy :443 ] ← rate limiting · logs · WAF basique │ ▼ [ LiteLLM Proxy :4000 ] ← auth API keys · routing · budget par client · logs billing │ ├──────────────────────────────────────────────────┐ ▼ ▼ [ vLLM :8000 ] ← local, privé [ API Cloud ] ← fallback Gemma 3 27B / Qwen3 32B Claude Sonnet / GPT-4o --device xpu · batching continu DeepSeek V4-Flash / V4-Pro (si quota local dépassé) │ ▼ [ Arc Pro B70 · 32 Go VRAM ] ~25-40 tokens/s sur Qwen3 14B · ~15 tok/s sur 32B
Composants stack
  • Cloudflare Tunnel Expose le service sans ouvrir de port. HTTPS automatique. Protection DDoS incluse. Gratuit jusqu'à usage raisonnable.
  • Nginx Rate limiting par IP, logs structurés, terminaison TLS locale. Filtre avant que la requête atteigne LiteLLM.
  • LiteLLM Proxy Une API key par client, budget mensuel en tokens configurable, dashboard usage, routage local/cloud automatique selon disponibilité.
  • vLLM --device xpu Batching continu — 5 clients simultanés sans dégradation notable. Ollama ne fait qu'une requête à la fois. Indispensable pour un SaaS.
Modèles recommandés B70
Modèle VRAM Usage
Qwen3 14B~9 GoStandard · rapide · multilingue
Qwen3 32B~20 GoPremium · raisonnement
Gemma 3 27B~17 GoRédaction · instruction
Llama 3.1 8B~5 GoFree tier · réponses rapides
DeepSeek-R1 14B~9 GoAnalyse · code
Fallback cloud — via API DeepSeek (trop grands pour le B70)
DeepSeek V4-FlashAPIRapide · code · $0.14/M tokens · quasi-égal à Pro sur le code
DeepSeek V4-ProAPIAgents · raisonnement · factual · $1.74/M tokens · 1M ctx
Avec 32 Go VRAM : deux modèles locaux simultanés — ex. Qwen3 14B + Llama 8B. DeepSeek V4 = fallback cloud via LiteLLM, jamais en local.
Installation vLLM Intel XPU
# Prérequis — drivers Intel compute runtime (déjà installés si Ubuntu guide suivi) sudo apt install intel-opencl-icd level-zero intel-level-zero-gpu # Environnement Python isolé python3 -m venv /opt/vllm-xpu source /opt/vllm-xpu/bin/activate # vLLM avec support Intel XPU (via ipex) pip install vllm --extra-index-url https://download.pytorch.org/whl/xpu # Lancer vLLM sur le B70 avec batching continu vllm serve Qwen/Qwen3-14B-Instruct \ --device xpu \ --dtype float16 \ --max-model-len 8192 \ --port 8000 \ --host 127.0.0.1 ← jamais exposé directement # Vérifier que le B70 est utilisé vllm serve ... --device xpu --gpu-memory-utilization 0.85
Configuration LiteLLM — billing par client
# /opt/litellm/config.yaml model_list: - model_name: "local/qwen3-14b" litellm_params: model: "openai/qwen3-14b" api_base: "http://127.0.0.1:8000/v1" api_key: "none" - model_name: "cloud/claude-sonnet" litellm_params: model: "claude-sonnet-4-5" api_key: "os.environ/ANTHROPIC_API_KEY" - model_name: "cloud/deepseek-flash" litellm_params: model: "deepseek/deepseek-v4-flash" api_key: "os.environ/DEEPSEEK_API_KEY" - model_name: "cloud/deepseek-pro" litellm_params: model: "deepseek/deepseek-v4-pro" api_key: "os.environ/DEEPSEEK_API_KEY" router_settings: routing_strategy: "least-busy" fallbacks: - "local/qwen3-14b": ["cloud/deepseek-flash", "cloud/claude-sonnet"] litellm_settings: success_callback: ["langfuse"] ← logs billing failure_callback: ["langfuse"] # Créer une clé API par client avec budget mensuel curl -X POST http://localhost:4000/key/generate \ -H "Authorization: Bearer $MASTER_KEY" \ -d '{"key_alias":"client-acme","max_budget":50,"budget_duration":"monthly","models":["local/qwen3-14b"]}'
⚠️
Maturité Intel XPU sur vLLM : le backend --device xpu est fonctionnel mais moins stable que CUDA. Tester impérativement en bench avant mise en production. Alternative plus stable à court terme : Ollama + LiteLLM proxy (pas de batching continu, mais zéro friction driver). Migrer vers vLLM quand le support XPU sera consolidé (fin 2025 estimé).
💡
Modèle commercial suggéré : Free tier (Llama 8B, 50k tokens/mois) · Standard 29€/mois (Qwen3 14B local, 2M tokens) · Premium 79€/mois (Qwen3 32B local illimité + fallback DeepSeek V4-Flash) · Enterprise sur devis (DeepSeek V4-Pro + Claude Sonnet pour les agents complexes). LiteLLM gère les budgets automatiquement — clé suspendue quand le quota est atteint.