Phase 4 — 专家切片数据路径 (M1)
弱设备下载的是几个 6 MB 的专家，而非 1.4 GB 的层——且分片计算与整体一致到 3.6e-12。
验证 · 真实 Qwen3.5-122B-A10B
专家切片是字节拷贝——无反量化
256→8
专家维切片
~6.1
MB / 专家 (Q4+Q6)
206 MB
2 层 × 16 专家下载
200
HTTP，有效 GGUF
MoE 专家张量把所有专家沿最外层 ggml 维度堆叠，读取器因此暴露 (n_expert, rows, row_bytes) 的原始量化字节。专家 *e* 是量化块对齐的连续板块——切片字面上就是 data[a:b]，无反量化、无重打包。
write_expert_shard_gguf——已验证的往返。
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
数值 oracle
dispatch + combine == monolithic，精确成立
用真实 122B layer-0 专家（反量化参考），把专家拆成 4 个分片分别计算再合并，结果与整体 MoE FFN 一致：分片是同一加权和的精确重组，不是近似。
3.6e-12
max|mono − sharded|
1.2e-07
相对误差
True
allclose(1e-5)
28/256
涉及的专家
C++ worker，硬件验证
linkcpp-expert-worker 在 ROCm 上复现 oracle
- 纯 ggml/gguf（无 libllama）：把切片加载进 GPU 后端，运行
mul_mat_id(up/gate) → swiglu → mul_mat_id(down)。 - ROCm 构建 + 运行（MI250）：122B layer-0，专家 [0,8)，4 个 token。
- 对 oracle cosine 0.99995，allclose(1e-3) = True，max|Δ| = 7.9e-7——这个残差本身就是跨后端等价（ROCm vs numpy）的首个实测案例。
- 同一代码路径覆盖 CUDA/Metal/Vulkan/CPU（
mul_mat_id/swiglu是原版 ggml；CUDA 有专用 MoE 内核）。
最难、风险最高的部件——设备端 worker 内核——在此得到验证。剩下的是骨干↔worker 编排；worker 已是消费这些切片的、经过验证的纯函数。