Phase 4 — Het expertplak-datapad (M1)

Een zwak apparaat downloadt een paar experts van 6 MB, geen laag van 1.4 GB — en gesharde berekening evenaart monolithisch tot 3.6e-12.

Geverifieerd · echte Qwen3.5-122B-A10B

Een expertplak is een bytekopie — zonder dekwantisatie

256→8

plak in expertdim.

~6.1

MB / expert (Q4+Q6)

206 MB

download 2 lagen × 16 exp.

200

HTTP, geldige GGUF

MoE-experttensoren stapelen alle experts langs de buitenste ggml-dimensie, dus de reader stelt (n_expert, rows, row_bytes) rauwe gekwantiseerde bytes bloot. Expert *e* is een kwantblok-uitgelijnde aaneengesloten plaat — de plak is letterlijk data[a:b], zonder dekwantisatie en zonder herverpakking.

write_expert_shard_gguf — de geverifieerde rondreis.

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

Het numerieke orakel

dispatch + combine == monolithisch, exact

Met echte layer-0-experts van de 122B (gedekwantiseerde referentie) evenaart het splitsen van de experts in 4 shards, elk afzonderlijk berekenen en combineren de monolithische MoE-FFN: sharding is een exacte hergroepering van dezelfde gewogen som, geen benadering.

3.6e-12

max|mono − sharded|

1.2e-07

relatieve fout

True

allclose(1e-5)

28/256

aangeraakte experts

C++-worker, hardware-geverifieerd

linkcpp-expert-worker reproduceert het orakel op ROCm

Puur ggml/gguf (geen libllama): laadt de plak in een GPU-backend en draait mul_mat_id(up/gate) → swiglu → mul_mat_id(down).
ROCm-build + run op een MI250: 122B layer-0, experts [0,8), 4 tokens.
Cosine 0.99995 vs het orakel, allclose(1e-3) = True, max|Δ| = 7.9e-7 — dit residu is zelf het eerste gemeten geval van cross-backend-equivalentie (ROCm vs numpy).
Hetzelfde codepad dekt CUDA/Metal/Vulkan/CPU (mul_mat_id/swiglu zijn standaard ggml; CUDA heeft een speciale MoE-kernel).

Het moeilijkste, riskantste stuk — de worker-kernel op het apparaat — werd hier geverifieerd. Wat restte was backbone↔worker-orkestratie; de worker is een bewezen pure functie die deze plakken consumeert.