llama.cpp Releases

[Pre-Release / Continuous-Build] b11436

[Pre-Release / Continuous-Build] ggml-openvino: CI-Tests korrigiert; GPU-Regressionen behoben. (#30037) * ggml-openvino: nicht ausgewählte Graph-Zweige überspringen und DUP unterstützen Upstream #29622 fügt über…

Pre-Release / Continuous-Build: Dies ist ein experimenteller Build, keine stabile Veröffentlichung.

ggml-openvino: CI-Tests korrigiert; GPU-Regressionen behoben. (#30037) * ggml-openvino: nicht ausgewählte Graph-Zweige überspringen und DUP unterstützen Upstream #29622 fügt über ggml_build_forward_select() einen gemischten Token/embd-Zweig zu jedem Input-Embedding-Graphen hinzu. Seine Knoten sind nicht für die Berechnung markiert, aber das Backend hat sie dennoch übersetzt, und das DUP in diesem Zweig wurde nicht unterstützt, sodass der Scheduler den Graphen aufteilte und die Embeddings mit einer festen Token-Anzahl über die Teilung hinweg übergab. Der erste Single-Token-Decode schlug daraufhin fehl (test-thread-safety auf CPU und GPU). Das OV-Modell nur aus den Berechnungsknoten aufbauen und ein gleichartiges zusammenhängendes DUP wie CONT übersetzen, damit der Graph auf einem Backend bleibt. * ggml-openvino: Token-Dimension von inp_scale_rows dynamisch machen #29622 verlagert außerdem die Per-Token-Embedding-Skalierung (gemma3, gemma3n, gemma4) in einen neuen [1, n_tokens]-Input. Ihm eine dynamische Token-Dimension geben und ihn auf dem statischen (NPU)-Pfad pro Chunk auffüllen. * ggml-openvino: GPU-MUL_MAT-Op-Tests mit ungebundenen Q4_1/Q4_K-Gewichten überspringen Op-Tests bauen Q4_1/Q4_K-Gewichte als u4 mit einem f16-Nullpunkt. Das GPU-Plugin kann diese Form für einige Zeilenzahlen nicht kompilieren, mit der Meldung "clFinish, error code: -5 CL_OUT_OF_RESOURCES", wodurch test-backend-ops bei den in #29869 hinzugefügten MUL_MAT-Fällen abbricht (z. B. m=1000, n=2, k=1024). Modellgewichte verwenden einen u4-Nullpunkt und sind nicht betroffen. Diese Fälle auf der GPU als nicht unterstützt melden, bis das Plugin behoben ist. Op-Tests prüfen die Unterstützung vor der Allokation, daher trifft die Prüfung nur auf ungebundene Gewichte zu; das Modell-Laden testet mit einem Dummy-Buffer und behält seine Gewichte auf der GPU. * ggml-openvino: FILL im Ausgabetyp erzeugen translate_fill hat immer eine f32-Konstante gebaut, sodass ein f16-FILL f32-Daten erzeugte und das Zurückkopieren den f16-Ausgabepuffer überschritt. Den Ausgabetyp für die Konstante verwenden. * ggml-openvino: CONCAT mit quantisiertem Typ ablehnen Quantisierte Eingaben werden bei der Übersetzung dequantisiert, daher kann das Backend keine quantisierte CONCAT-Ausgabe schreiben. Dies als nicht unterstützt melden, wie bei CPY zu einem quantisierten Typ. * ggml-openvino: das einzelne rekurrente State-Gather von build_rs behandeln #29856 änderte build_rs so, dass alle rekurrenten States mit einem GET_ROWS auf dem s_copy-Blatt gesammelt werden und der ubatch sowie die zusätzlichen States als Views davon genommen werden. Der stateful-Pfad erkannte nur die vorherige Form, ein GET_ROWS pro View von s_copy, sodass Qwen3.5 bei stateful-Ausführung auf CPU und GPU fehlschlug ("is_axis_valid(axis, r)" in einem Concat). Bei einem Single-Slot-Cache den GET_ROWS auf dem s_copy-Blatt als das Gather des aktiven States behandeln, das Rank-4-Layout der Reshapes beibehalten, die eine View davon lesen, und die Kopie der leeren Extra-State-View auf das Single-Slot-Remainder-Writeback abbilden. Nicht über die dynamische Dimension leerer Views warnen. * openvino: Operanden-Ränge von eltwise-Operationen angleichen, um einen Defekt des GPU-Plugins zu umgehen * openvino: die MoE-Fusion im Rank-3-stateful-Graphen abgleichen * ggml-openvino: in AlignEltwiseOperandRanks keine RMS-Norm-Ausgabe unsqueezenn Der Pass unsqueezett den Operanden mit dem niedrigeren Rang bei einem Add/Multiply/Subtract, dessen Operanden-Ränge unterschiedlich sind. In gemma-3 ist der Operand mit dem niedrigeren Rang bei der Post-Attention-Residual-Addition die Norm-Ausgabe, und das Unsqueezing lässt das GPU-Plugin die Schicht falsch berechnen: gemma-3 liefert auf der GPU bei stateful-Ausführung leere Antworten. Die Umformung überspringen, wenn der Operand mit dem niedrigeren Rang eine RMS-Norm-Ausgabe ist. * docs : OpenVINO-validierte Modelle aktualisieren --------- Co-authored-by: Mustafa Cavus

Webseite: - https://llama.app

Attestierungen: - https://github.com/ggml-org/llama.cpp/attestations/53122299

macOS/iOS: - macOS Apple Silicon (arm64) - macOS Apple Silicon (arm64, KleidiAI aktiviert) DEAKTIVIERT - macOS Intel (x64) - iOS XCFramework

Linux: - Ubuntu x64 (CPU) - Ubuntu arm64 (CPU) - Ubuntu s390x (CPU) - Ubuntu x64 (Vulkan) - Ubuntu arm64 (Vulkan) - Ubuntu x64 (CUDA 12) - CUDA-12.8-Bibliotheken - Ubuntu x64 (CUDA 13) - CUDA-13.4-Bibliotheken - Ubuntu arm64 (CUDA 13) - CUDA-13.4-Bibliotheken - Ubuntu x64 (ROCm 10.0) - Ubuntu x64 (OpenVINO) - Ubuntu x64 (SYCL FP32) - Ubuntu x64 (SYCL FP16) - Linux arm64 (Snapdragon: CPU, Adreno GPU, Hexagon NPU) - Einrichtungsanleitung

Android: - Android arm64 (CPU) - Android arm64 (Snapdragon: CPU, Adreno GPU, Hexagon NPU) - Einrichtungsanleitung

Windows: - Windows x64 (CPU) - Windows arm64 (CPU) - Windows arm64 (OpenCL Adreno) - Windows x64 (CUDA 12) - CUDA 12.4 DLLs - Windows x64 (CUDA 13) - CUDA 13.4 DLLs - Windows arm64 (CUDA 13) - CUDA 13.4 DLLs - Windows x64 (Vulkan) - Windows arm64 (Vulkan) - Windows x64 (OpenVINO) - Windows x64 (SYCL) - Windows x64 (ROCm 10.0)

openEuler: - DEAKTIVIERT - openEuler x86 (310p) - openEuler x86 (910b, ACL Graph) - openEuler aarch64 (310p) - openEuler aarch64 (910b, ACL Graph)

UI: - UI

Originalquelle

llama.cpp Releases

Hinweise zum Inhalt

Originalveröffentlichung und Rechte liegen bei der Quelle.

Maschinelle Übersetzung · Original beachten