Phase 4 — Der Experten-Scheiben-Datenpfad (M1)

Ein schwaches Gerät lädt ein paar 6-MB-Experten, keine 1.4-GB-Layer — und die geshardete Rechnung gleicht der monolithischen bis auf 3.6e-12.

Verifiziert · echtes Qwen3.5-122B-A10B

Eine Expertenscheibe ist eine Bytekopie — ohne Dequantisierung

256→8

Scheibe in Expertendim.

~6.1

MB / Experte (Q4+Q6)

206 MB

Download 2 Layer × 16 Exp.

200

HTTP, gültiges GGUF

MoE-Expertentensoren stapeln alle Experten entlang der äußersten ggml-Dimension, der Reader exponiert also (n_expert, rows, row_bytes) roher quantisierter Bytes. Experte *e* ist eine quantblock-ausgerichtete zusammenhängende Platte — die Scheibe ist buchstäblich data[a:b], ohne Dequantisierung und ohne Umpacken.

write_expert_shard_gguf — der verifizierte Roundtrip.

sliced = tensor.data[a:b]              # outermost axis = expert
writer.add_tensor(name, sliced, raw_dtype=tensor.tensor_type)
# router (ffn_gate_inp) & shared expert stay on the backbone → excluded
GET /api/proxy/models/{m}/expert-shard?layers=0:2&experts=0:16  # node-token authed

A laser slicing one expert slab into a mini-GGUF beside a perfectly level balance scale

Das numerische Orakel

dispatch + combine == monolithisch, exakt

Mit echten Layer-0-Experten des 122B (dequantisierte Referenz) gleicht das Aufteilen der Experten in 4 Shards, separates Berechnen und Kombinieren der monolithischen MoE-FFN: Sharding ist eine exakte Umgruppierung derselben gewichteten Summe, keine Näherung.

3.6e-12

max|mono − sharded|

1.2e-07

relativer Fehler

True

allclose(1e-5)

28/256

berührte Experten

C++-Worker, hardwareverifiziert

linkcpp-expert-worker reproduziert das Orakel auf ROCm

Reines ggml/gguf (kein libllama): lädt die Scheibe in ein GPU-Backend und führt mul_mat_id(up/gate) → swiglu → mul_mat_id(down) aus.
ROCm-Build + Lauf auf einem MI250: 122B Layer-0, Experten [0,8), 4 Tokens.
Cosine 0.99995 vs. das Orakel, allclose(1e-3) = True, max|Δ| = 7.9e-7 — dieses Residuum ist selbst der erste gemessene Fall von Cross-Backend-Äquivalenz (ROCm vs. numpy).
Derselbe Codepfad deckt CUDA/Metal/Vulkan/CPU ab (mul_mat_id/swiglu sind Standard-ggml; CUDA hat einen dedizierten MoE-Kernel).

Das schwerste, riskanteste Stück — der Worker-Kernel auf dem Gerät — wurde hier verifiziert. Was blieb, war die Backbone↔Worker-Orchestrierung; der Worker ist eine bewiesene reine Funktion, die diese Scheiben konsumiert.