Lucebox sur Olares One — Épisode 5 : Le runtime nous claque la porte avec un device id négatif

Épisode 4 — après 6h de compile cumulées, l’image aamsellem/lucebox-qwen36-blackwell:1.0.0 est sur Docker Hub. Ça compile, ça link, ça push. Logique.

Sauf que le pod ne boote pas.

Le crash

Logs du pod, après que le download du target Q4_K_M (~17 Go) et du drafter z-lab (~3.5 Go) soit terminé :

==> Starting Lucebox llama-server: /opt/lucebox/.../llama-server
[HAMI-core Msg(...)]: Initializing.....
[HAMI-core Warn(...)]: invalid device memory limit CUDA_DEVICE_MEMORY_LIMIT_0=0m
[HAMI-core Msg(...)]: get_nvml_device_memory_total 0
[HAMI-core Msg(...)]: get_nvml_device_memory_total 1
... (jusqu'à 15)
[HAMI-core Msg(...)]: Initialized
[HAMI-core Msg(...)]: SCHEDULER_WEBSOCKET_URL ws://gpu-scheduler.os-gpu:6000

ggml_cuda_init: found 1 CUDA devices (Total VRAM: 24463 MiB):
  Device 0: NVIDIA GeForce RTX 5090 Laptop GPU, compute capability 12.0,
            VMM: yes, VRAM: 24463 MiB

[HAMI-core ERROR (...)]: Illegal device id: -644371744

Et puis exit. Pod en CrashLoopBackOff. Je restart, et :

[HAMI-core ERROR (...)]: Illegal device id: -39296272

Puis :

[HAMI-core ERROR (...)]: Illegal device id: 1816936528

Le device id change à chaque run, et il est random.

Premier réflexe

Quand un programme C ou C++ vous balance un entier “random” qui change à chaque run, neuf fois sur dix c’est une uninitialized stack variable. Vous déclarez int dev; sans initialiser, et dev prend la valeur de ce qui se trouvait sur la stack à ce moment-là — c’est-à-dire ce que les fonctions précédentes y ont laissé. Random.

Mais d’où vient l’erreur ? Pas de ggml. Pas de Lucebox. Pas de llama-server. C’est [HAMI-core ERROR ...] — c’est HAMi vGPU, la couche d’isolation GPU qui tourne sur Olares Kubernetes.

C’est quoi HAMi exactement

HAMi (Heterogeneous AI computing Virtualization Middleware) est un device plugin Kubernetes qui virtualise les GPUs. Sur Olares, il vit dans le namespace kube-system :

$ kubectl get ds -n kube-system | grep hami
hami-device-plugin          1/1  ...   gpu.bytetrade.io/cuda-supported=true
hami-nvidia-dcgm-exporter   1/1  ...

Comment ça marche ? Au démarrage, l’init script de HAMi copie une lib custom (libvgpu.so) sur le host dans /usr/local/vgpu/. Quand un pod demande nvidia.com/gpu dans ses resources, HAMi le mount via hostPath dans le container, et libvgpu.so est LD_PRELOAD sur tous les binaires du pod. Cette lib intercepte les appels CUDA pour faire du tracking memory, du scheduling, du quota.

Donc quand llama-server appelle une fonction CUDA, il passe d’abord par HAMi. Et c’est HAMi qui crashe avec Illegal device id: <random>.

Premier diag : c’est VMM ?

Le log dit VMM: yes. Lucebox utilise le CUDA Driver API VMM (cuMemCreate, cuMemAddressReserve, cuMemMap) pour ses allocations. C’est ce qu’on a vu aux épisodes 2-4 — toutes les undefined references étaient des fonctions VMM. C’est plus efficace que cudaMalloc pour gérer les pools dynamiques.

Hypothèse : HAMi n’intercepte peut-être pas correctement le path VMM. Si je désactive VMM côté ggml-cuda, le bug pourrait disparaître.

ggml a un flag CMake pour ça : -DGGML_CUDA_NO_VMM=ON. Ça force cudaMalloc (Runtime API) au lieu de cuMemCreate (Driver API). HAMi sait normalement intercepter Runtime API.

Donc je rebuild. Build #5. Encore 2h de compile parce que le flag invalide tout le cache CUDA.

docker.io/aamsellem/lucebox-qwen36-blackwell:1.1.0

Push, swap l’image dans le chart Olares (v1.0.0 → v1.1.0), redémarre le pod. Ça boot, ça download les modèles, ça démarre llama-server.

ggml_cuda_init: found 1 CUDA devices (Total VRAM: 24463 MiB):
  Device 0: NVIDIA GeForce RTX 5090 Laptop GPU, compute capability 12.0,
            VMM: yes, VRAM: 24463 MiB
[HAMI-core ERROR (...)]: Illegal device id: -1967326112

Toujours pareil.

Wait, le log dit VMM: yes. Pourquoi ? J’ai désactivé NO_VMM dans le build…

Oh. C’est la capability du device qui s’affiche, pas l’usage par ggml. Le device peut faire du VMM, ggml a juste choisi de ne pas l’utiliser. Mais Illegal device id est toujours là.

Ce qui veut dire : le bug n’est pas dans le path VMM. Il est ailleurs. Et NO_VMM ne sert à rien.

À ce stade, je suis 7h dans la saga, j’ai brûlé 8h de CPU sur des compiles, et je ne sais toujours pas pourquoi mon pod crashe. Time to read the HAMi source code.

Épisode 6 — On va lire le code de HAMi-core. À très vite !

Disclosure — Tous les benchmarks de ce post tournent sur mon propre Olares One. Si le contenu vous a été utile et que vous envisagez d’en acheter un, commander via ce lien de parrainage vous donne 400 $ de réduction (3 599 $ au lieu de 3 999 $) et me rapporte 200 $. Je le mentionne par transparence — et oui, accessoirement, ça aide à faire vivre le blog (hébergement, domaine, et le temps que je passe à écrire ici). Lien valable jusqu’à fin juin 2026 environ.