Aller au contenu
Tag

#llama-cpp

72 entrée(s) portent ce tag.

Pages

12

Architecture Box v1Architecture · Composition candidate de la première Box : Framework Desktop sous Linux, Docker Compose, llama-server, Open WebUI, PostgreSQL, Caddy, restic et monitoring, avec un budget mémoire explicite.Architecture générale de la Box IAArchitecture · Vue simple et vue complète de la Box : couches, composants candidats, principes d'architecture et flux d'une requête, du navigateur à la réponse citée.Le laboratoire : lire et alimenter les benchmarksBenchmarks · Ce que la collection benchmarks enregistre, comment lire une fiche (TTFT, tok/s, pp, p50/p95), d'où viennent les données (nôtres ou publiées), comment en ajouter une et quelles séries de comparaison sont prévues.Méthodologie de benchmark reproductibleBenchmarks · Protocole du laboratoire : llama-bench, llama-batched-bench, vllm bench serve et autres outils de charge, métriques standard, prompts de référence, grille 1/2/3/5/10 utilisateurs, conditions à consigner et pièges.Inférence : panorama des moteursInférence · Comparaison des moteurs de serving (llama-server, Ollama, LM Studio, vLLM, SGLang, Lemonade) pour un Strix Halo sous Linux, et recommandation initiale prudente : llama-server d'abord, vLLM à évaluer.llama.cpp et llama-serverInférence · Le moteur de départ de la Box : slots, contexte partagé, KV cache quantifié, flash attention, métriques Prometheus, images Docker ROCm/Vulkan et flags connus pour gfx1151.Ollama, LM Studio, Lemonade : les moteurs « faciles »Inférence · Trois surcouches de llama.cpp orientées simplicité : variables de parallélisme d'Ollama, requêtes concurrentes de LM Studio, Lemonade porté par AMD ; limites pour un serveur multi-utilisateurs.ROCm et Vulkan sur gfx1151Linux · État du support ROCm pour le GPU Strix Halo (gfx1151), officiel depuis ROCm 7.13 preview et 10.0 stable, et comparaison Vulkan/RADV contre ROCm/HIP pour llama.cpp, avec des sources contradictoires.Monitoring : ce que l'on surveille et commentMonitoring · Métriques système, GPU, inférence et applicatives ; pile proposée (node_exporter, amd-smi, llama-server --metrics, Prometheus, Grafana, Uptime Kuma) et alternatives simples ; seuils d'alerte et tableau de bord type.Dimensionner la Box pour un cabinetMulti-utilisateurs · Méthode pour passer d'un profil d'usage (requêtes courtes, analyses de dossiers longs) à un choix de modèle, de slots et de contexte, avec trois scénarios et la liste de ce qu'il faudra mesurer.Multi-utilisateurs : servir 5 à 10 personnes sur une seule machineMulti-utilisateurs · Pourquoi une machine à 256 Go/s est bornée en génération, ce que le batching et les MoE y changent, ce que les mesures publiées disent, et ce qu'il reste à mesurer avant de promettre un nombre d'utilisateurs.KV cache : calcul et dimensionnementMulti-utilisateurs · Formule du KV cache, effet de GQA et MLA, quantification q8_0/q4_0, tableau d'estimations pour gpt-oss-120b, Qwen3-30B-A3B et Llama 70B à 8k/32k/128k, et impact du nombre de slots sur la mémoire.

Matériel

2

Framework Desktop (Ryzen AI Max+ 395, 128 Go)Matériel · Machine candidate de la Box IA : APU AMD Strix Halo avec 128 Go de mémoire unifiée, compacte et silencieuse, mais dont le support ROCm n'est officiel que depuis août 2026 et dont la stabilité sous forte charge GPU reste à démontrer.Mac Studio M5 Max (2026)Matériel · Alternative Apple à mémoire unifiée : jusqu'à 128 Go et 460 à 614 Go/s de bande passante, soit 2 à 2,5 fois le Framework Desktop, mais un écosystème macOS/Metal fermé et un prix des configurations 128 Go non confirmé.

Modèles

17

DeepSeek R1 (et distillations)Modèle · MoE de 671 Md sous MIT : impraticable sur 128 Go à taille complète ; seules les distillations 32B et 70B sont exécutables (11,2 t/s mesurés pour Distill-Qwen-32B).EuroLLM-22B (et 9B)Modèle · Dense européen de 22 Md (consortium UTTER, décembre 2025), Apache 2.0, 24 langues officielles de l'UE : candidat « souveraineté » à tester en français juridique.Gemma 3 27BModèle · Dense multimodal Google de 27 Md, plus de 140 langues, sous Gemma Terms of Use : bon multilingue, mais licence à conditions et lenteur d'un dense ; aucun chiffre Strix Halo trouvé.GLM-4.5 / 4.5-Air (et suite 4.6, 4.7, 5)Modèle · Famille MoE de Z.ai sous MIT : GLM-4.5-Air (106 Md, 12 Md actifs, environ 60 Go en Q4) est le seul gabarit praticable ; aucune mesure Strix Halo trouvée.gpt-oss-120bModèle · MoE OpenAI de 117 Md (5,1 Md actifs) sous Apache 2.0 : le candidat principal de la Box, mesuré entre 30 et 56 t/s sur Strix Halo selon le runtime.gpt-oss-20bModèle · Petit frère de gpt-oss-120b (21 Md, 3,6 Md actifs, 11,3 Go en GGUF) : modèle de repli rapide ou de tâches secondaires, non mesuré sur Strix Halo dans nos sources.Kimi K2 (Instruct, 0905, K2.6)Modèle · MoE de Moonshot AI à 1 000 Md (32 Md actifs) sous Modified MIT avec clause d'affichage : impraticable sur 128 Go, fiche de référence uniquement.Llama 3.3 70B InstructModèle · Dense Meta de 70 Md, français officiellement supporté, 42,5 Go en Q4 : la référence « gros modèle dense », bornée à environ 5 t/s par la bande passante de Strix Halo.Llama 4 Scout (109B-A17B)Modèle · MoE multimodal Meta de 109 Md (17 Md actifs), 19 à 20 t/s mesurés sur Strix Halo, mais licence excluant les entités domiciliées dans l'UE : écarté pour la Box.Lucie-7B (OpenLLM-France)Modèle · Modèle français de 6,7 Md (LINAGORA / OpenLLM-France), Apache 2.0, entraîné à 32 % sur du français : intéressant pour la souveraineté, trop petit pour l'assistant principal.Magistral Small 1.2 (24B, 2509)Modèle · Variante de raisonnement de Mistral Small (24 Md dense, Apache 2.0) : candidate pour l'analyse pas à pas de dossiers, sans mesure Strix Halo trouvée.Mistral Small 3.2 (24B, 2506)Modèle · Dense 24 Md de Mistral AI, Apache 2.0, vision et function calling : l'option « éditeur français » de taille moyenne, environ 10 à 12 t/s en Q6 selon Framework.Mistral Small 4 (119B-A6B, 2603)Modèle · MoE de Mistral AI (119 Md, 6 Md actifs), Apache 2.0, vision et raisonnement, contexte 256k : concurrent européen direct de gpt-oss-120b, sans mesure Strix Halo trouvée.Qwen3-235B-A22B (Instruct-2507)Modèle · Plus gros MoE Qwen3 (235 Md, 22 Md actifs) : trop grand pour 128 Go en Q4 ; praticable en Q3 avec 16 à 17 t/s mesurés, au prix d'une forte quantification.Qwen3-30B-A3B (Instruct-2507)Modèle · MoE Alibaba de 30,5 Md (3,3 Md actifs), Apache 2.0, 18,6 Go en Q4 : le candidat « rapide » de la Box, mesuré entre 72 et 98 t/s sur Strix Halo.Qwen3-32BModèle · Dense Alibaba de 32,8 Md, Apache 2.0, contexte 32k natif : référence dense de taille moyenne, plus lente qu'un MoE mais avec un mode raisonnement.Qwen3.5 et suivants (3.6, 3.8)Modèle · Famille Qwen la plus récente (février à août 2026) : hybrides Gated DeltaNet + MoE, 201 langues, Apache 2.0 ; le 35B-A3B est le modèle des seules mesures multi-slots publiées sur Strix Halo.

Benchmarks

15

Llama 3.3 70B (Shisa V2) Q4_K_M — llama.cpp b5863 — 5,0 t/s (lhl, Framework Desktop)Benchmark · Un dense de 70 Md en Q4 sur le Framework Desktop : 5,0 t/s en génération et 94,7 t/s en prompt, exactement au plafond de bande passante.Qwen3-30B-A3B Q4 — llama.cpp b5863 — 72,0 t/s (lhl, Framework Desktop)Benchmark · Premier point de la série Qwen3-30B-A3B sur le Framework Desktop : 72,0 t/s en génération et 604,8 t/s en prompt, mi-2025.gpt-oss-120b Q4_K_M — llama-server ROCm — 53,4 t/s (visorcraft)Benchmark · gpt-oss-120b sous llama-server avec backend ROCm sur un mini-PC Strix Halo : 53,4 t/s en génération.Qwen3-235B-A22B Q3_K_M — llama.cpp ROCm — 17,2 t/s, pp 101 t/s (visorcraft)Benchmark · Le plus gros MoE Qwen3 en 3 bits sur Strix Halo : 17,2 t/s en génération mais seulement 101 t/s en prompt.gpt-oss-120b MXFP4 — llama.cpp Vulkan RADV b9049 — 55,6 t/s (hogeheer)Benchmark · Meilleure mesure publiée de gpt-oss-120b sur Strix Halo : 55,57 t/s en génération et 727 t/s en prompt processing, Vulkan RADV, Beelink GTR9 Pro.Qwen3-Coder-30B-A3B Q4_K_S — llama.cpp ROCm — 73,7 t/s, pp 1 345 t/s (Soothill)Benchmark · Comparatif Vulkan vs ROCm de Soothill : côté ROCm, 73,7 t/s en génération mais 1 345 t/s en prompt, le meilleur prefill de la série.Qwen3-Coder-30B-A3B Q4_K_S — llama.cpp Vulkan — 97,7 t/s (Soothill)Benchmark · Comparatif Vulkan vs ROCm de Soothill : côté Vulkan, 97,7 t/s en génération et 1 115 t/s en prompt sur Qwen3-Coder-30B-A3B Q4_K_S.Qwen3.5-122B-A10B Q4_K_XL — llama.cpp b10333 ROCm 7.14 — 13,6 t/s, TTFT 1,78 s (Soothill)Benchmark · Côté llama.cpp du comparatif vLLM / SGLang / llama.cpp : 13,6 t/s à 1 client, 17,9 t/s agrégés à 2 clients, TTFT 1,775 s sur un MoE de 122 Md.Qwen3.6-35B-A3B UD-Q4_K_M — llama-server -np 1 — 59,2 t/s, TTFT 117 ms (hogeheer)Benchmark · Point de référence à 1 slot de la seule courbe de montée en charge publiée sur Strix Halo : 59,2 t/s et 117 ms de TTFT.Qwen3.6-35B-A3B UD-Q4_K_M — llama-server -np 16 — 10,4 t/s par utilisateur, 166 agrégés (hogeheer)Benchmark · À 16 slots, l'agrégé plafonne (166 t/s, +2,5 % par rapport à 8 slots) et chaque utilisateur tombe à 10,4 t/s avec 547 ms de TTFT.Qwen3.6-35B-A3B UD-Q4_K_M — llama-server -np 4 — 32,7 t/s par utilisateur, 130,8 agrégés (hogeheer)Benchmark · À 4 slots, chaque utilisateur reçoit 32,7 t/s (130,8 t/s agrégés, 2,2 fois le mono) avec un TTFT de 237 ms.Qwen3.6-35B-A3B UD-Q4_K_M — llama-server -np 8 — 20,3 t/s par utilisateur, 162 agrégés (hogeheer)Benchmark · À 8 slots, 20,3 t/s par utilisateur et 162 t/s agrégés (2,7 fois le mono), TTFT 307 ms : le point d'équilibre retenu par l'auteur.DeepSeek-R1-Distill-Qwen-32B Q4_K_M — llama.cpp HIP — 11,2 t/s (praveentechworld)Benchmark · Un dense de 32 Md en Q4 (19,8 Go) sur Strix Halo : 11,2 t/s, cohérent avec le plafond bande passante ÷ poids.Llama 3.3 70B Q4_K_M — llama.cpp HIP ROCm 6.3+ — 5,1 t/s, contexte 64k (praveentechworld)Benchmark · Llama 3.3 70B Q4_K_M (42,5 Go) sous ROCm avec un contexte de 64k : 5,1 t/s, confirmant le plafond de bande passante un an après la première mesure.gpt-oss-120b MXFP4 — llama.cpp ROCm 7.2.0 (fork Lychee b8182) — 51,1 t/s (Pellegrini)Benchmark · gpt-oss-120b sous ROCm 7.2.0 avec un fork llama.cpp : 51,1 t/s en génération, 174 t/s en prompt (charge applicative), environ 59 Go GPU, pic 140 W.

Expérimentations

3

Benchmark gpt-oss-120b à 1 utilisateur : Vulkan vs ROCm, contexte court et longExpérimentation · Reproduire sur le Framework Desktop les 51 à 56 t/s publiés pour gpt-oss-120b, comparer les deux backends et mesurer la dégradation à 4k et 32k de profondeur.Montée en charge de 1 à 10 utilisateurs : gpt-oss-120b et Qwen3-30B-A3BExpérimentation · Mesurer le débit par utilisateur, l'agrégé et le TTFT p95 à 1, 2, 3, 5 et 10 clients simultanés avec des prompts français courts, RAG et dossiers, pour remplir la matrice de capacité.Comparer Vulkan/RADV et ROCm/HIP dans llama.cppExpérimentation · Mesurer sur nos modèles cibles et nos longueurs de prompt RAG le débit de prompt processing et de génération des deux backends GPU de llama.cpp, pour trancher Q-008.

Décisions

1

Démarrer avec llama.cpp (llama-server) comme runtime d'inférenceDécision · Runtime initial du prototype : llama-server, API OpenAI-compatible, slots parallèles ; vLLM sera évalué ensuite.

Questions

2

Quel runtime d'inférence est le plus performant sur AMD Strix Halo ?Question · llama.cpp est le point de départ (ADR-004) ; vLLM et SGLang sur ROCm restent à évaluer pour le multi-utilisateur.Vulkan (RADV) ou ROCm (HIP) pour llama.cpp sur Strix Halo ?Question · Les sources se contredisent : Vulkan plus simple et parfois plus rapide en génération, ROCm meilleur en prompt processing selon certains ; à mesurer.

Recherches

1

Campagne de recherche : moteurs d'inférence, modèles et multi-utilisateursRecherche · Support gfx1151 des runtimes, options de parallélisme, théorie du KV cache, catalogue de modèles et benchmarks publiés.

Sources

9

AMD — binaires llama.cpp validés pour ROCm 7.1.1 (Radeon/Ryzen)Source · Binaires llama.cpp « AMD-validated » pour gfx1150/gfx1151, ROCm 7.1.1, Ubuntu 24.04, incluant llama-server, llama-bench et llama-cli.Discussion llama.cpp #18308 — paramètres optimaux pour l'inférence parallèleSource · Un utilisateur (GPU NVIDIA) observe peu de gain au-delà de -np 4 ; les mainteneurs attribuent la sous-utilisation GPU à l'échantillonnage CPU et renvo.Guide officiel llama.cpp : running gpt-oss (#15396)Source · Tailles GGUF : gpt-oss-20b 11,27 Go, gpt-oss-120b 59,02 Go ; mémoire d'environ 64 Go pour le 120b ; lancement avec --jinja, -c, -np et chat-template-k.llama.cpp — README de llama-benchSource · Options et valeurs par défaut de llama-bench : -p 512, -n 128, -d 0, -b 2048, -ub 512, -ctk/-ctv f16, -fa auto, -r 5, sorties csv/json/jsonl/md/sql. N.llama.cpp — README de llama-server (tools/server)Source · Documentation de référence de llama-server : options -np, -c, --kv-unified, -cb, --cache-type-k/v, -fa, --metrics, --slots ; endpoints /v1/chat/comple.Lemonade Server — options du backend llama.cppSource · Canal ROCm stable (lemonade-sdk/llama.cpp) ou nightly (lemonade-sdk/llamacpp-rocm) avec builds par architecture dont gfx1151 ; commande lemonade confi.lemonade-sdk/llamacpp-rocm — builds nightly llama.cpp + ROCm 7Source · Builds nightly de llama.cpp avec ROCm 7 pour gfx1151 (Windows et Ubuntu).LM Studio — Parallel RequestsSource · Requêtes parallèles via le continuous batching de llama.cpp ; « Max Concurrent Predictions » à 4 par défaut ; nécessite le runtime GGUF llama.cpp v2.0.Soothill — SGLang vs vLLM vs llama.cpp on Strix HaloSource · GMKtec EVO-X3, vLLM 0.26.0, SGLang 0.5.17, llama.cpp b10333, ROCm 7.14.0 : Qwen3.5-0.8B BF16 vLLM 86,6 (C=1), 246,5 (C=4), 311,6 t/s (C=8) ; llama.cpp.

Glossaire

10

Continuous batchingTerme · Technique de serveur d'inférence qui insère de nouvelles requêtes dans le lot en cours à chaque étape de génération, au lieu d'attendre que toutes les séquences du lot soient terminées.Flash attentionTerme · Implémentation optimisée du calcul d'attention qui évite de matérialiser la matrice complète des scores en mémoire, réduisant l'empreinte mémoire et accélérant le traitement des longs contextes.GGUFTerme · Format de fichier de llama.cpp contenant les poids quantifiés d'un modèle et ses métadonnées (tokenizer, architecture, gabarit de conversation) dans un seul fichier.llama.cppTerme · Bibliothèque et outils open source en C/C++ pour exécuter des modèles de langage quantifiés au format GGUF sur CPU et GPU, avec des backends CUDA, Vulkan, ROCm et Metal.llama-serverTerme · Serveur HTTP de llama.cpp qui charge un modèle GGUF et expose une API compatible OpenAI (chat, complétions, embeddings, reranking) avec traitement parallèle par slots.LLM (grand modèle de langage)Terme · Réseau de neurones entraîné sur de très grands volumes de texte pour prédire le token suivant, capable de comprendre et de produire du langage naturel.MXFP4Terme · Format numérique à 4 bits en virgule flottante avec facteurs d'échelle partagés par blocs, utilisé notamment par les modèles gpt-oss pour leurs couches d'experts.QuantificationTerme · Réduction de la précision numérique des poids d'un modèle (par exemple de 16 bits à 4 bits) pour diminuer sa taille en mémoire et accélérer l'inférence, au prix d'une perte de qualité généralement faible.Slot (llama-server)Terme · Dans llama-server, emplacement de traitement capable de servir une conversation à la fois ; le nombre de slots fixe le nombre de requêtes traitées en parallèle et partage la fenêtre de contexte totale entre elles.TokenTerme · Unité de texte manipulée par un modèle de langage, correspondant à un mot, un fragment de mot ou un signe de ponctuation.