Lc0 0.33.0 rc0 Release

By Lothar Jung Date 2026-09-18 10:59 Upvotes 1

This release includes improvements across the cuda, onnx and demux backends, along with several search, benchmarking, and training-data fixes.

Several DAG search improvements: concurrent task workers, improved lock contention, garbage collection, more accurate draw score as well as better time keeping.
Added cuda backend graph support and cutlass fused multihead attention.
Refactored demux to reduce lock contention and improve batch handling.
Added support for preferred batch step selection in the cuda, onnx and xla backends.
Added support for network evaluations per second in uci info, enabled by the --show-eps command line switch or UCI_ShowEPS uci option.
Use cuda streams if possible in onnx, for more efficient memory transfers.
Switched onnx-trt to strongly typed graphs to avoid problematic type conversions in TensorRT, added quantization control through the optimize backend option and full bf16 support.
Added the onnx-coreml backend.
Also added the onnx-migraphx backend, with fixed batch sizes recommended for best performance.
Allowed the rescorer to process v7 training data.
Added tracing support.
Search avoids allocating extra computations for better backend buffer reuse.
Improved backendbench statistics and added thread support.
Added back a threads option to the blas backend.
The master version of net.proto is now hosted by lc0 and includes support for fp16 and fp32 weights encoding.
Notable bug fixes:
Restored the --history-fill naming.
Reverted ponder behavior changes.
Fixed castling move display for FRC.
Fixed multiplay issues.
Fixed a DAG n_in_flight underflow bug.
Defaulted cuda backend option fused_mha to false for networks with relu^2 activation.
Fixed a segfault in Python bindings for transformer networks when calling Weights.filters().
Fixed onnx locking.
Several build system updates.
Assorted small fixes and improvements.

By Max Siegfried Date 2026-09-18 17:33

Ja bei LC0 tut sich extrem viel.
Deutlich mehr als früher.
Also alle die immer behaupten, die Engine wird nicht mehr weiterentwickelt / ist quasi tot, irren sich gewaltig.

Beispiele:
Inquiry: Pure Swift (Apples Programmiersprache, also LC0 in Swift geschrieben) reimplementation under GPL-3.0 (macOS / MLX)
https://github.com/LeelaChessZero/lc0/issues/2438

MLX Swift
Das dürfte auch für die Stockfish Entwickler Gold wert sein.
https://github.com/ml-explore/mlx-swift

By Max Siegfried Date 2026-09-18 17:38

Nehmen wir zur Veranschaulichung einen fiktiven, aber realistischen Basiswert von 10.000 Knoten pro Sekunde für die reine GPU-Leistung des M1 Max.
Auf dem M1 Max brachte die NPU einen Zuwachs von 33 %. Sie lieferte also 3.300 nps zusätzlich, was eine Gesamtleistung von 13.300 nps ergab.
Überträgt man die Leistungssprünge (GPU 5x, NPU 12x) auf den M5 Max, ergibt sich folgendes Bild:
Chip-Generation GPU-Leistung (Basis) NPU-Leistung (Zusatz) Gesamtleistung (GPU + NPU) Leistungsplus durch NPU
M1 Max 10.000 nps 3.300 nps 13.300 nps + 33,0 %
M5 Max 50.000 nps 39.600 nps 89.600 nps + 79,2 %
Für den M5 Max bedeutet das: Die NPU hat extrem aufgeholt und liefert fast so viel Leistung wie die neue GPU. Wenn du die NPU beim M5 Max über das demux-Backend zuschaltest, steigt die Leistung nicht mehr nur um ein Drittel, sondern um fast 80 %.

M5 MAX x 2 = M5 ULTRA

By Max Siegfried Date 2026-09-18 17:43

Für LC0 auf Apple-Geräten ist die Version 0.33.0-rc0 ein massives Update, das die Hardware-Architektur der M-Chips deutlich effizienter ausnutzt.
Die Neuerungen zielen genau auf die Schwachstellen ab, die macOS-Nutzer bisher beim Einsatz von LC0 hatten.
Das bedeuten die wichtigsten Änderungen konkret:

Das neue onnx-coreml Backend:
CoreML ist Apples hauseigene Schnittstelle für maschinelles Lernen. Mit der direkten Integration in LC0 kann die Engine nun nativ, stabil und ohne experimentelle Workarounds auf die Apple Neural Engine (NPU) zugreifen.
Die Berechnungen werden von macOS direkt auf die KI-Kerne des Chips geleitet, was eine hohe Effizienz bei minimalem Stromverbrauch garantiert.

Die Überarbeitung von demux (Lock Contention & Batch Handling):
Das ist der Gamechanger für die rohe Leistung. demux ist das Backend, das die Last auf GPU (Metal) und NPU (CoreML) gleichzeitig verteilt.
In der alten Version haben sich diese Recheneinheiten beim parallelen Arbeiten oft gegenseitig ausgebremst, weil sie auf Datenfreigaben warten mussten ("Lock Contention").
Durch den Umbau des Codes fallen diese Software-Bremsen weg. GPU und NPU arbeiten nun wesentlich reibungsloser nebeneinander, was den Geschwindigkeitsverlust bei hybrider Nutzung drastisch minimiert.

DAG Search Improvements (Concurrent Task Workers):
Apple Silicon verfügt über extrem starke CPU-Kerne. Die Suchbaum-Logik (DAG) von LC0 läuft auf der CPU und entscheidet, welche Züge berechnet werden müssen, bevor sie diese an die GPU/NPU schickt.
Durch die neuen "Concurrent Task Workers" und reduzierten Blockaden arbeiten die CPU-Kerne des Macs jetzt viel besser zusammen.
Die CPU kann die Grafikkarte und die NPU dadurch deutlich schneller mit neuen Rechenaufträgen füttern.

Preferred Batch Steps im ONNX Backend:
CoreML und die Apple Neural Engine arbeiten am effizientesten mit bestimmten, festen Paketgrößen (Batches).
Die Möglichkeit, diese Batch-Größen jetzt bevorzugt anzusteuern, bedeutet, dass die NPU nicht mit für sie ineffizienten Datenpaketen "verschluckt" wird, sondern exakt die Happen bekommt, die sie am schnellsten verarbeiten kann.

Wie gut ist das?
Es löst die größten Flaschenhälse auf Apple-Geräten. In der Version 0.32.1 war die Kombination aus GPU und NPU oft durch Software-Overhead gebremst, sodass die Hardware ihr Potenzial nicht auf die Straße brachte.
Durch das native onnx-coreml-Backend in Kombination mit dem überarbeiteten, staufreien demux-Verteiler kann man erwarten, dass die Knoten pro Sekunde (NPS) bei hybrider Nutzung (GPU + NPU) deutlich ansteigen.
Man bekommt mehr Leistung aus derselben Hardware, weil die Software-Schnittstellen endlich exakt auf die Funktionsweise von Apples Unified Memory und der Neural Engine zugeschnitten sind.

By Lothar Jung Date 2026-09-18 18:47 Edited 2026-09-18 18:49 Upvotes 1

Ich nehme stark an, dass die macOS binarie den größten Sprung nach vorne macht.

By Lothar Jung Date 2026-09-19 12:12

Test: Stockfish-19 vs BT4 + BT5

Stockfish-19: 10,000,000 nodes per move, Threads=20, Hash=128.
BT4 + BT5: 50,000 npm, BT4 mbs=80, BT5 mbs=60, default.
Ratio= 200:1
BT4: lc0-v0.33.0-rc0-cuda12
BT5: lc0-v0.33.0-rc0-onnx + BT5-1024x15x32h-rpe-swa-3700000-leela2onnx-fp16.pb
Book Sufi-29 rd 1 to 25, cutechess-cli
RTX 4070 Ti + Ryzen 9 7900 (12c/24t)

```
# PLAYER    RATING PLAYED   W   L   D D(%) CFS(%)
1 Stockfish-19    : 0.0 200 72 37 91 46    81
2 BT5-3700_dag-preview    : -40.3    50   8 12 30 60    78
3 BT4-1740_dag-preview    : -90.9    50 10 19 21 42    50
4 BT4-tf13tune_dag-preview : -90.9    50   9 18 23 46    73
5 BT4-it332_dag-preview : -131.7    50 10 23 17 34 ---

White advantage = 217.56 +/- 25.08
Draw rate (equal opponents) = 79.81 % +/- 3.78
```

By Max Siegfried Date 2026-09-19 13:29

Ist das BT5 Netz nicht immer schlechter als das BT4 Netz gewesen?

By Lothar Jung Date 2026-09-19 13:41

Nein, BT5 braucht halt mehr Tiefe bei der Berechnung, da es größer als das BT4 Netz ist.
Also mit einer 5090 oder 2x4070 ti würde der Abstand zu Stockfish schrumpfen.
Jedoch ist der Hardwareeinsatz auf beiden Seiten beim Test ziemlich ausgeglichen.