llama.cpp et llama-server

L'essentiel

• llama-server est le serveur HTTP de llama.cpp : API OpenAI, slots parallèles, continuous batching activé par défaut, KV cache quantifiable, métriques Prometheus ¹.
• Deux backends GPU sur gfx1151 : HIP (ROCm) et Vulkan (RADV). Aucun n'est systématiquement plus rapide : cela dépend du modèle, de la phase (prompt ou génération) et des flags de build.
• Limite structurelle : file d'attente FIFO sans priorité documentée.
• Toutes les options ci-dessous proviennent du README officiel ; les flags de build et variables d'environnement « Strix Halo » proviennent de la communauté et doivent être revalidés.

Options clés de llama-server

Source : README tools/server ¹. Les valeurs par défaut sont celles de la branche master au 16 septembre 2026.

Endpoints : /v1/chat/completions, /v1/embeddings (modèle avec pooling), /rerank, /health, /slots, /metrics.

Slots, contexte, KV unifié

Un slot est une séquence servie en parallèle. Avec -np 4 -c 32768 en mode non unifié, chaque slot disposerait d'environ 8 192 tokens (formulation du README à vérifier). Avec --kv-unified, le buffer est commun et se répartit selon l'usage réel : plus souple quand les requêtes sont de longueurs très différentes (question courte vs analyse de dossier). Dimensionnement détaillé dans KV cache.

KV cache quantifié

--cache-type-k q8_0 --cache-type-v q8_0 divise par deux la mémoire du KV cache par rapport à f16, pour une perte de précision faible ; q4_0 divise par quatre avec une perte plus marquée (formulation reprise de la FAQ Ollama, qui s'appuie sur llama.cpp). La quantification de V requiert généralement flash attention.

Métriques et supervision

--metrics expose notamment llamacpp:prompt_tokens_total, llamacpp:prompt_seconds_total, llamacpp:tokens_predicted_total, llamacpp:requests_processing, llamacpp:prompt_tokens_seconds, llamacpp:predicted_tokens_seconds ¹. /slots donne l'état de chaque slot (occupé, tokens traités). Il n'y a pas de métrique TTFT par requête : à mesurer côté client ou reverse proxy. Voir Monitoring.

File d'attente et priorité

Les requêtes au-delà des slots disponibles sont mises en file et servies dans l'ordre. Aucune option de priorité n'est documentée. Conséquence pour la Box : un traitement par lots (indexation, résumé nocturne) doit passer par une instance séparée ou être planifié hors heures ouvrées.

Images Docker officielles

ghcr.io/ggml-org/llama.cpp:server, :server-rocm, :server-vulkan ¹. Alternatives : binaires « AMD-validated » pour gfx1150/gfx1151 sous ROCm 7.1.1 et Ubuntu 24.04 (llama-server, llama-bench, llama-cli) ⁵ ; builds nightly ROCm 7 de Lemonade ⁶ ; conteneurs communautaires kyuz0 ⁷.

Exemple de lancement (documenté)

Le guide officiel gpt-oss recommande de lancer avec --jinja, -c et -np, et de régler l'effort de raisonnement via --chat-template-kwargs ². Une commande complète pour notre cas (4 slots, 32k de contexte total, KV q8_0, métriques) reste à écrire et à valider sur la machine ; elle n'est pas reproduite ici faute de source la donnant telle quelle.

Flags et réglages « Strix Halo » (communauté, à revalider)

Réglages récurrents dans les retours communautaires (aucun n'est une recommandation officielle) :

• Build HIP : GGML_HIP_NO_VMM=ON (gestionnaire de mémoire virtuelle HIP jugé bogué sur gfx1151), GPU_TARGETS=gfx1151, GGML_HIP_ROCWMMA_FATTN=ON ^{4 10}.
• Exécution HIP : -dio (direct I/O) requis pour les modèles au-delà d'environ 6 Go, sinon blocage au chargement ⁴ ; ROCBLAS_USE_HIPBLASLT=1 ⁸.
• Toujours : -fa 1 et --no-mmap pour éviter plantages et ralentissements ⁷.
• Multi-slots : peu de gain observé au-delà de -np 4 sur GPU NVIDIA, goulot d'échantillonnage CPU (PR --backend-sampling) ³ ; sur Strix Halo, hogeheer trouve -np 8 comme point d'équilibre sur un MoE 35B-A3B ¹².

Limites

• Pas de priorité de file ; pas de TTFT natif dans les métriques.
• Deux backends à maintenir et à re-mesurer à chaque mise à jour de ROCm ou Mesa.
• Le contexte total est fixé au lancement : changer -c ou -np impose un redémarrage.
• Un seul modèle par instance : embeddings et reranker demandent des instances séparées (ou un routeur).

Ce qu'il reste à tester

• Benchmark gpt-oss-120b à 1 utilisateur : Vulkan vs ROCm, contexte court et longSur le Framework Desktop, gpt-oss-120b MXFP4 atteint au moins 50 t/s en tg128 avec l'un des deux backends, et le prefill pp512 dépasse 500 t/s ; la génération baisse de moins de 20 % à 32k de profondeur.À tester
• Montée en charge de 1 à 10 utilisateurs : gpt-oss-120b et Qwen3-30B-A3BAvec llama-server -np 8 --kv-unified et KV q8_0, gpt-oss-120b sert 3 utilisateurs simultanés à plus de 25 t/s chacun avec un TTFT p95 inférieur à 3 s sur prompts courts ; à 10 utilisateurs, le débit par utilisateur reste au-dessus de 10 t/s. Le comportement suit la courbe publiée pour Qwen3.6-35B-A3B (59 → 20 t/s par utilisateur de 1 à 8 slots) décalée vers le bas.À tester
• Comparer Vulkan/RADV et ROCm/HIP dans llama.cppVulkan/RADV est plus rapide en génération (+15 à +30 %) et ROCm/HIP plus rapide en prompt processing au-delà de quelques milliers de tokens ; pour les prompts RAG de la Box (4k à 16k tokens), la différence de temps de réponse total est inférieure à 20 % et la stabilité départage les deux.À tester