Pré-version / build continu : il s'agit d'un build expérimental, pas d'une version stable.
ggml-openvino : correction des tests CI ; correction des régressions GPU. (#30037) * ggml-openvino : ignorer les branches de graphe non sélectionnées et prendre en charge DUP L'amont #29622 ajoute une branche mixte token/embd à chaque graphe d'embedding d'entrée via ggml_build_forward_select(). Ses nœuds ne sont pas marqués pour le calcul, mais le backend les traduisait quand même, et le DUP de cette branche n'était pas pris en charge, si bien que le planificateur scindait le graphe et transmettait les embeddings à travers la scission avec un nombre de tokens fixe. Le premier décodage à token unique échouait alors (test-thread-safety sur CPU et GPU). Construire le modèle OV à partir des seuls nœuds de calcul, et traduire un DUP contigu de même type comme CONT afin que le graphe reste sur un seul backend. * ggml-openvino : rendre la dimension token de inp_scale_rows dynamique #29622 déplace également l'échelle d'embedding par token (gemma3, gemma3n, gemma4) vers une nouvelle entrée [1, n_tokens]. Lui donner une dimension token dynamique et la compléter par chunk sur le chemin statique (NPU). * ggml-openvino : ignorer les tests d'op GPU MUL_MAT avec des poids Q4_1/Q4_K non liés Les tests d'op construisent les poids Q4_1/Q4_K en u4 avec un point zéro f16. Le plugin GPU échoue à compiler cette forme pour certains nombres de lignes avec "clFinish, error code: -5 CL_OUT_OF_RESOURCES", ce qui interrompt test-backend-ops sur les cas MUL_MAT ajoutés dans #29869 (par ex. m=1000, n=2, k=1024). Les poids des modèles utilisent un point zéro u4 et ne sont pas concernés. Signaler ces cas comme non pris en charge sur GPU jusqu'à correction du plugin. Les tests d'op vérifient la prise en charge avant l'allocation, donc la vérification ne correspond qu'aux poids non liés ; le chargement de modèle sonde avec un tampon factice et conserve ses poids sur le GPU. * ggml-openvino : créer FILL dans le type de sortie translate_fill construisait toujours une constante f32, si bien qu'un FILL f16 produisait des données f32 et la copie en retour débordait du tampon de sortie f16. Utiliser le type de sortie pour la constante. * ggml-openvino : rejeter CONCAT avec un type quantisé Les entrées quantisées sont déquantisées lors de la traduction, donc le backend ne peut pas écrire une sortie CONCAT quantisée. Le signaler comme non pris en charge, comme pour CPY vers un type quantisé. * ggml-openvino : gérer le unique rassemblement d'état récurrent de build_rs #29856 a modifié build_rs pour rassembler tous les états récurrents avec un seul GET_ROWS sur la feuille s_copy et prendre l'ubatch et les états supplémentaires comme vues de celui-ci. Le chemin avec état ne correspondait qu'à la forme précédente, un GET_ROWS par vue de s_copy, si bien que Qwen3.5 échouait avec une exécution avec état sur CPU et GPU ("is_axis_valid(axis, r)" dans un Concat). Pour un cache à un seul slot, traiter le GET_ROWS sur la feuille s_copy comme le rassemblement d'état actif, conserver la disposition de rang 4 des reshapes qui lisent une vue de celui-ci, et mapper la copie de la vue vide d'état supplémentaire sur l'écriture différée du reste à un seul slot. Ne pas avertir de la dimension dynamique des vues vides. * openvino : aligner les rangs des opérandes eltwise pour contourner un défaut du plugin GPU * openvino : faire correspondre la fusion MoE sur le graphe avec état de rang 3 * ggml-openvino : ne pas unsqueeze une sortie de norme RMS dans AlignEltwiseOperandRanks La passe unsqueeze l'opérande de rang inférieur d'un Add/Multiply/Subtract dont les rangs des opérandes diffèrent. Dans gemma-3, l'opérande de rang inférieur de l'ajout résiduel post-attention est la sortie de la norme, et son unsqueeze fait que le plugin GPU calcule la couche incorrectement : gemma-3 renvoie des réponses vides sur GPU avec une exécution avec état. Ignorer la réécriture lorsque l'opérande de rang inférieur est une sortie de norme RMS. * docs : mise à jour des modèles OpenVINO validés --------- Co-authored-by: Mustafa CavusSite Web : - https://llama.app
Attestations : - https://github.com/ggml-org/llama.cpp/attestations/53122299
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
Android : - Android arm64 (CPU) - Android arm64 (Snapdragon : CPU, GPU Adreno, NPU Hexagon) - guide d'installation
Windows : - Windows x64 (CPU) - Windows arm64 (CPU) - Windows arm64 (OpenCL Adreno) - Windows x64 (CUDA 12) - DLL CUDA 12.4 - Windows x64 (CUDA 13) - DLL CUDA 13.4 - Windows arm64 (CUDA 13) - DLL CUDA 13.4 - Windows x64 (Vulkan) - Windows arm64 (Vulkan) - Windows x64 (OpenVINO) - Windows x64 (SYCL) - Windows x64 (ROCm 10.0)
openEuler : - DÉSACTIVÉ - openEuler x86 (310p) - openEuler x86 (910b, ACL Graph) - openEuler aarch64 (310p) - openEuler aarch64 (910b, ACL Graph)
UI : - UI