Je n'ai pas acheté le ZimaCube 2 pour l'IA. Je l'ai acheté pour être le backend de stockage de mon cluster Proxmox.
Mais ensuite, j'ai remarqué l'emplacement PCIe x16. Et le fait qu'il fonctionne entièrement avec l'alimentation de la carte mère — pas de 6 broches, pas de 8 broches, pas de câbles adaptateurs. Juste l'alimentation par l'emplacement. Ça a changé la donne.
Un Intel Arc Pro B50 plus tard, le ZimaCube 2 fait maintenant tourner llama.cpp et OpenClaw pour l'inférence locale — en plus de son rôle principal comme cerveau du stockage partagé du cluster. Voici toute l'histoire : pourquoi j'ai choisi le B50, comment s'est passée l'installation, ce que la version bêta de ZimaOS a apporté, et ce que cela signifie pour quiconque envisage une mise à niveau GPU sur le ZimaCube 2.
Pourquoi l'Intel Arc Pro B50
Choisir un GPU pour un NAS compact n'est pas comme choisir pour un PC de jeu. Vous avez trois contraintes strictes :
- Alimentation par emplacement uniquement. Les emplacements PCIe du ZimaCube 2 ne fournissent pas de câbles d'alimentation auxiliaires. Le GPU doit fonctionner uniquement avec ce que la carte mère fournit — 75W max.
- Profil bas ou emplacement simple. Le boîtier mesure 240 × 221 × 220 mm. Une carte double emplacement pleine hauteur ne rentrera pas physiquement.
- Silencieuse et fraîche. Cette carte fonctionne 24/7 dans un espace de vie. Pas de ventilateurs à soufflerie, pas de limitation thermique au repos.
L'Intel Arc Pro B50 coche toutes les cases :
|
Exigence
|
Arc Pro B50
|
|---|---|
|
Alimentation par emplacement uniquement
|
✅ 50W TDP — fonctionne entièrement via l'emplacement PCIe (pas de câbles)
|
|
Profil bas
|
✅ Emplacement simple, support demi-hauteur inclus
|
|
VRAM pour l'IA
|
✅ 16 Go GDDR6 — suffisant pour des modèles de 13B à 20B paramètres
|
|
Encodage AV1
|
✅ Encodage/décodage matériel AV1
|
|
Prix par VRAM
|
✅ Meilleur rapport VRAM-prix dans sa catégorie
|

L'installation : un seul emplacement, pas de câbles, terminé
L'installation physique a pris moins de dix minutes.
Ouvrez le panneau supérieur — les slots PCIe sont juste là, sans cages de disque à contourner. Le B50 s’insère dans le slot x16. Le support demi-hauteur s’aligne avec l’ouverture arrière. Vissez une vis. Refermez le panneau. C’est fait.
Pas de câbles d’alimentation. Pas d’adaptateurs. Pas de câbles coincés dans des espaces trop étroits. L’implémentation PCIe du ZimaCube 2 est vraiment propre — le slot est positionné avec assez de dégagement au-dessus des baies de stockage pour qu’une carte double slot ne gêne pas.
Ce n’est pas évident sur du matériel NAS compact. La plupart des appareils de ce format n’ont même pas de PCIe. Ceux qui en ont souvent placent le slot à des endroits limitant ce que l’on peut installer. IceWhale a bien conçu la disposition ici.
ZimaOS Beta : Support natif du pilote Arc
Je prévoyais d’effacer ZimaOS et d’installer Ubuntu Server. Puis IceWhale m’a contacté avec une version Beta de ZimaOS incluant le support natif du pilote Intel Arc GPU.
La version Beta gère automatiquement la détection du pilote. Au premier démarrage après l'installation du B50, ZimaOS a reconnu la carte, chargé le pilote Intel i915 avec extensions Arc, et l'a exposée au runtime Docker. Pas de compilation de module noyau. Pas de modification de GRUB. Ça a juste fonctionné.
Ce que je fais tourner : llama.cpp + OpenClaw
Avec le GPU reconnu, j'ai déployé deux conteneurs :
llama.cpp (inférence accélérée GPU)
- Modèle : Mistral 13B Q5_K_M (tient dans ~12 Go de VRAM avec contexte 8K)
- Backend : Intel SYCL (GPU Arc)
- Cas d'utilisation : Revue de code, résumé de documentation, chatbot local, traitement du langage naturel pour domotique

OpenClaw (passerelle IA locale)
- Point d'accès API unifié pour plusieurs modèles locaux
- Routage des requêtes entre llama.cpp et des modèles CPU plus petits
- Se connecte à Home Assistant pour des requêtes domotiques vocales
Les performances sont exactement ce à quoi on s’attend d’une carte simple slot de 50W : pas un GPU de centre de données, mais assez rapide pour être vraiment utile. Mistral 13B génère environ 25 à 35 tokens par seconde — plus rapide que la vitesse de lecture, ce qui est le seuil qui rend l’IA locale réactive plutôt que pénible.

Conserver le travail principal : backend de stockage + AI sur une seule machine
Voici ce que je n’ai pas fait : je n’ai pas sacrifié le but original du ZimaCube 2. Les pools de stockage qui servent le cluster Proxmox sont toujours là. Les snapshots ZFS s’exécutent toujours selon le planning. Les conteneurs Docker qui alimentent l’infrastructure n’ont pas bougé.
Ce qui a changé, c’est que le ZimaCube 2 fait maintenant deux choses à la fois :
Couche de stockage
- 4× HDD RAID-Z1 (données volumineuses)
- 2× NVMe RAID 1 (images VM)
- 1× NVMe SLOG/L2ARC (cache)
- Exports NFS vers 3 nœuds Proxmox
-
Automatisation des snapshots ZFS
Couche AI
- llama.cpp avec Mistral 13B
- Passerelle AI OpenClaw
- Assistant de revue de code
- Résumé de documents
- Intégration NLP Home Assistant
Les 40 Go de RAM (8 Go d’origine + 32 Go d’extension) sont répartis : environ 24 Go pour le cache ARC ZFS, 8 Go pour les conteneurs Docker et ZimaOS, et 8 Go pour la surcharge système. Les 16 Go de VRAM GPU gèrent les poids du modèle indépendamment — ils ne concurrencent pas la mémoire système.
La charge CPU pendant l’inférence est minimale puisque llama.cpp délègue au GPU. Les performances d’E/S du stockage ne sont pas affectées car les pools NVMe gèrent les données actives, et le GPU ne touche pas au contrôleur SATA.
Pourquoi pas une boîte AI séparée ?
J’ai envisagé de construire un nœud AI dédié. Il y a de bonnes raisons de séparer l’inférence du stockage — isolation, budget d’alimentation dédié, cycles de redémarrage indépendants. Mais il y a une raison convaincante de ne pas le faire :
Vous avez déjà un slot PCIe.
Le ZimaCube 2 a été conçu en pensant à l’extension. Si vous achetez un appareil qui inclut un slot PCIe x16 spécifiquement pour des mises à niveau futures, ne pas l’utiliser est la décision la plus coûteuse. Une boîte AI séparée signifie une autre alimentation, un autre boîtier, un autre lien réseau, une autre chose à gérer.
Une machine. Deux rôles. Le ZimaCube2 gère les deux.
Ajoutez une carte graphique à votre ZimaCube 2 et commencez à exécuter de l'IA locale →
Questions fréquemment posées
Le slot PCIe du ZimaCube 2 fournit-il assez de puissance pour une carte graphique ?
Oui — pour les cartes alimentées par slot jusqu'à 75W. L'Intel Arc Pro B50 (TDP 50W) et les GPU basse consommation similaires fonctionnent entièrement avec l'alimentation du slot PCIe. Les slots PCIe du ZimaCube 2 ne fournissent pas de câbles d'alimentation auxiliaires, vous devez donc choisir une carte qui n'en nécessite pas. La B50, la NVIDIA RTX A2000 et les Intel Arc A310/A380 sont toutes des options viables.
Quelle carte graphique recommanderiez-vous pour le ZimaCube 2 ?
Pour l'inférence IA spécifiquement, privilégiez la VRAM plutôt que la puissance de calcul. L'Intel Arc Pro B50 (16 Go) et la NVIDIA RTX A2000 (12 Go) sont les meilleures options alimentées uniquement par le slot PCIe actuellement disponibles. Pour le transcodage média uniquement, les Intel Arc A310 ou A380 sont moins chers et offrent toujours un encodage matériel AV1. Évitez toute carte graphique nécessitant un connecteur d'alimentation 6 broches ou 8 broches.
Puis-je faire fonctionner un ZimaCube 2 avec un GPU 24h/24 et 7j/7 sans problèmes thermiques ?
Oui. Le design thermique du ZimaCube 2 sépare la zone CPU/PCIe de la zone des disques. La Arc Pro B50 est une carte de 50W — elle ne génère pas assez de chaleur pour surcharger le châssis. Sous une charge d'inférence soutenue, les températures du GPU restent dans une plage de fonctionnement normale sans modifications supplémentaires de refroidissement.
Le ZimaCube 2 peut-il exécuter simultanément le stockage partagé et les charges de travail IA ?
Oui. La configuration originale décrite ici utilise le ZimaCube 2 à la fois comme backend de stockage NFS/ZFS pour le cluster Proxmox et comme serveur local d'inférence IA avec llama.cpp et OpenClaw. La VRAM du GPU gère les poids du modèle indépendamment de la mémoire système, et les pools de stockage NVMe garantissent que les E/S des machines virtuelles ne sont pas limitées par les charges d'inférence.
Quel est le plus grand modèle que je peux faire tourner sur une carte graphique 16 Go dans le ZimaCube 2 ?
Une carte graphique de 16 Go comme l'Intel Arc Pro B50 peut facilement faire tourner des modèles quantifiés de 13B à 14B paramètres (quantifications Q5_K_M ou Q4_K_M) avec des fenêtres contextuelles de 4K à 8K, ou des modèles de 20B à 34B à des niveaux de quantification plus faibles. Pour la plupart des cas d'utilisation d'IA auto-hébergée — assistance au codage, résumé de documents, NLP pour l'automatisation domestique — un modèle 13B bien optimisé avec une bonne quantification est l'idéal.
Centre de Campagne Zima
Plus à lire

J'ai transformé une étagère Ikea Kallax en un homelab rack 10 pouces avec le ZimaCube 2
Les homelabs montés en rack semblent parfaits jusqu'à ce que vous réalisiez que vous ne voulez pas d'un moteur à réaction d'entreprise envahissant votre...

Comment j'ai migré 14 000 photos vers le ZimaCube 2 sans aucune perte de données — Un guide de migration Immich
Déplacez votre bibliothèque Immich et votre base de données PostgreSQL en toute transparence. Découvrez le flux de transfert LAN 2,5 GbE exact pour passer...

Comment un seul appareil a remplacé tout mon cloud — Nextcloud + IA locale sur le ZimaCube 2
Cessez de payer pour le stockage en cloud. Découvrez comment un NAS auto-hébergé avec Nextcloud peut synchroniser vos fichiers en toute sécurité et faire...

