Phase 4 — La voie de données des tranches d'experts (M1)

Un appareil faible télécharge quelques experts de 6 MB, pas une couche de 1.4 GB — et le calcul shardé égale le monolithique à 3.6e-12 près.

Vérifié · vrai Qwen3.5-122B-A10B

Une tranche d'expert est une copie d'octets — sans déquantification

256→8
tranche en dim expert
~6.1
MB / expert (Q4+Q6)
206 MB
téléch. 2 couches × 16 exp.
200
HTTP, GGUF valide

Les tenseurs d'experts MoE empilent tous les experts le long de la dimension ggml la plus externe, le lecteur expose donc (n_expert, rows, row_bytes) d'octets quantifiés bruts. L'expert *e* est une dalle contiguë alignée sur les blocs de quantification — la tranche est littéralement data[a:b], sans déquantification ni ré-empaquetage.

write_expert_shard_gguf — l'aller-retour vérifié.

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
L'oracle numérique

dispatch + combine == monolithique, exactement

Avec de vrais experts de layer-0 du 122B (référence déquantifiée), scinder les experts en 4 shards, calculer chacun séparément puis combiner égale la FFN MoE monolithique : le sharding est un regroupement exact de la même somme pondérée, pas une approximation.

3.6e-12
max|mono − sharded|
1.2e-07
erreur relative
True
allclose(1e-5)
28/256
experts touchés
Worker C++, vérifié sur matériel

linkcpp-expert-worker reproduit l'oracle sur ROCm

  • ggml/gguf pur (sans libllama) : charge la tranche dans un backend GPU et exécute mul_mat_id(up/gate) → swiglu → mul_mat_id(down).
  • Compilation + exécution ROCm sur un MI250 : 122B layer-0, experts [0,8), 4 tokens.
  • Cosine 0.99995 vs l'oracle, allclose(1e-3) = True, max|Δ| = 7.9e-7 — ce résidu est en soi le premier cas mesuré d'équivalence inter-backends (ROCm vs numpy).
  • La même voie de code couvre CUDA/Metal/Vulkan/CPU (mul_mat_id/swiglu sont du ggml d'origine ; CUDA a un kernel MoE dédié).

La pièce la plus difficile et risquée — le kernel du worker sur l'appareil — a été vérifiée ici. Restait l'orchestration backbone↔worker ; le worker est une fonction pure prouvée qui consomme ces tranches.