llama.cpp Releases2026-10-05 18:30 UTC+8

[Pré-version / build continu] b11412

[Pré-version / build continu] llama : correction d'une réallocation de graphe inattendue dans les modèles k-pool (#29958) * llama : correction d'une réallocation de graphe inattendue dans les modèles k-pool Les deux…

Pré-version / build continu : il s'agit d'un build expérimental, et non d'une version stable.

llama : correction d'une réallocation de graphe inattendue dans les modèles k-pool (#29958) * llama : correction d'une réallocation de graphe inattendue dans les modèles k-pool Les deux modèles k-pool construisaient une forme de graphe dépendant d'un état que la réserve full-context ne peut pas connaître : - qwen4exp se branchait sur inp->cache_safe, qui devient faux dès que llama_memory_seq_cp partage des cellules (par ex. batched-bench -pps) : les couches QSA remplaçaient scatter+gather par fill+concat et abandonnaient la feuille new_pool_rep, de sorte que le graphe de décode avait 12 nœuds de moins que celui réservé - glm5-next se branchait sur gather = n_tokens <= 16 && n_kv > n_sel, de sorte que le décode TG construisait la forme gather (7564 nœuds) alors que la dernière réserve, celle du PP, avait la forme dense (7762 nœuds) L'un ou l'autre écart force une re-réserve au moment du décode qui abandonne la taille du pire cas et fige l'état courant, si bien que la prochaine croissance d'état (n_pool, n_kv, n_new) nécessite plus d'espace à une taille de graphe inchangée et échoue sous GGML_SCHED_DEBUG_REALLOC=1. Reproduire avec, par ex. : GGML_SCHED_DEBUG_REALLOC=1 ./bin/llama-batched-bench \ -hf ggml-org/GLM-5.3-Flash-GGUF:Q2_K -npp 2500 -ntg 32 -npl 1,2 \ -c 32768 -pps -kvu Toujours faire scatter+gather des clés poolées, et choisir gather à partir des constantes du contexte uniquement : n_ubatch borne chaque ubatch, top_k + kpool - 1 borne n_sel. Chaque graphe d'un contexte partage alors une seule forme, que la réserve couvre, et le chemin dense s'est révélé plus rapide que le chemin gather à 2.5k et 16k de contexte. Assisted-by : pi:llama.cpp/MiMo-V2.6-Flash-MOPD * llama : suppression de l'API k-pool cache_safe inutilisée Les graphes k-pool ne se branchent plus sur cache_safe, donc plus rien ne lit get_kpool_cache_safe() ni le new_pool_rep conditionnel : les deux modèles passent toujours la cible de scatter, ce que set_input_kpool exige désormais au lieu de le simple- ment préférer. Suppression également de la copie cache_safe dans kpool_build_sizes(), un utilitaire ne traitant que les tailles. La disposition et le drapeau d'état lui-même restent, il décide toujours quels pools une disposition avec des cellules partagées doit re-pooler. Assisted-by : pi:llama.cpp/MiMo-V2.6-Flash-MOPD * tests : ajout d'un test de régression de réserve de graphe à séquences partagées Décoder un prompt dans la seq 0, partager ses cellules avec la seq 1 via llama_memory_seq_cp (ce que fait llama-batched-bench pour -pps), puis continuer à décoder les deux séquences. Pour les modèles k-pool, le partage efface cache_safe, ce qui change la topologie du graphe pendant que les pools continuent de croître, si bien qu'un ordonnanceur qui re-réserve avec l'état courant au lieu du pire cas échoue sous GGML_SCHED_DEBUG_REALLOC=1. L'enregistrement du test définit ce drapeau, et le test échouait sur les deux modèles k-pool avant 2220411ec1. kimi-linear et minimax-01 sont ignorés : ils réservent le graphe pp final avec n_seqs = 1 (voir [TAG_RESERVE_DIAG_DECAY] dans llama-context.cpp), donc tout graphe multi-séquences a une disposition différente et se re-réserve par conception. Assisted-by : pi:llama.cpp/MiMo-V2.6-Flash-MOPD * cont : ajout de TODO * cont : correction d'un commentaire * cuda : alignement de la réduction pondérée moe sur les ubatches vides ggml_cuda_match_moe_weighted_reduction rejetait les tenseurs avec zéro ligne. Un ubatch sans sorties réduit la dernière couche à zéro ligne via inp_out_ids, de sorte que graph_optimize supprimait sa dépendance d'allocation et que le graphe de l'ordonnanceur perdait un nœud par rapport à celui réservé. L'ordonnanceur se re-réservait alors à la taille de cet ubatch, et l'ubatch suivant, avec le même nombre de nœuds mais des tenseurs plus grands, échouait sous GGML_SCHED_DEBUG_REALLOC=1. La boucle de calcul ignorait déjà les nœuds vides avant toute tentative de fusion, donc la garde ne faisait dépendre les dépendances d'allocation que du nombre de lignes. * tests : construction du test de rollback uniquement là où les symboles internes se lient Le cas à séquences partagées appelle llm_arch_from_string, que libllama n'exporte pas via LLAMA_API, de sorte que l'édition de liens de test-recurrent-state-rollback échoue sur Windows avec les bibliothèques partagées. Sa construction se trouve désormais dans le bloc NOT WIN32 OR NOT BUILD_SHARED_LIBS, à côté de test-llama-archs et de l'enregistrement de test sous lequel il se trouve déjà. * tests : ignorer les archs par nom dans le test de réserve à séquences partagées L'ignorance de kimi-linear et minimax-01 passait par llm_arch_from_string, que libllama n'exporte pas via LLAMA_API, de sorte que le test ne pouvait pas se lier sur Windows avec les bibliothèques partagées. Il compare désormais directement la chaîne general.architecture, et le test se construit à nouveau sur toutes les plateformes. --------- Co-authored-by : Pascal

Site web : - https://llama.app

Attestations : - https://github.com/ggml-org/llama.cpp/attestations/52789660

macOS/iOS : - macOS Apple Silicon (arm64) - macOS Apple Silicon (arm64, KleidiAI activé) DÉSACTIVÉ - macOS Intel (x64) - XCFramework iOS

Linux : - Ubuntu x64 (CPU) - Ubuntu arm64 (CPU) - Ubuntu s390x (CPU) - Ubuntu x64 (Vulkan) - Ubuntu arm64 (Vulkan) - Ubuntu x64 (CUDA 12) - Bibliothèques CUDA 12.8 - Ubuntu x64 (CUDA 13) - Bibliothèques CUDA 13.4 - Ubuntu arm64 (CUDA 13) - Bibliothèques CUDA 13.4 - Ubuntu x64 (ROCm 10.0) - Ubuntu x64 (OpenVINO) - Ubuntu x64 (SYCL FP32) - Ubuntu x64 (SYCL FP16) - Linux arm64 (Snapdragon : CPU, GPU Adreno, NPU Hexagon) - guide d'installation