两台 DGX Spark 部署 MiMo-V2.6-Flash 全记录：309B MoE 双机 TP=2 环境准备、部署步骤、排错与性能测试

/* MD / 富文本中的 .toc（含博客园搬家等嵌套结构）；.toc-box 在侧栏，不受影响 */
#content_views .toc,
/* 编辑器常在目录前后插入空 p（:empty 仍占 20px），一并去掉避免顶空隙 */
#content_views.markdown_views > p:empty:has(+ .toc),
#content_views.markdown_views > .toc + p:empty,
/* 富文本旧版目录标记 */
#content_views.htmledit_views #main-toc,
#content_views.htmledit_views #hr-toc,
#content_views.htmledit_views p[id*=\”-toc\”] {
display: none !important;
}
/* 目录去掉后，紧跟的首个标题不再多出一块上边距 */
#content_views.markdown_views > .toc + h1,
#content_views.markdown_views > .toc + h2,
#content_views.markdown_views > .toc + h3,
#content_views.markdown_views > .toc + h4,
#content_views.markdown_views > .toc + p:empty + h1,
#content_views.markdown_views > .toc + p:empty + h2,
#content_views.markdown_views > .toc + p:empty + h3,
#content_views.markdown_views > .toc + p:empty + h4 {
margin-top: 0 !important;
}

文章目录

• • 1. 引言与结论速览
  • • 结论速览
  • 2. 部署环境准备
  • • 2.1 硬件配置要求
    • 2.2 操作系统与系统软件版本
    • 2.3 依赖软件安装清单
  • 3. 详细部署步骤
  • • 3.1 拓扑与节点分工
    • 3.2 节点基础配置
    • 3.3 高速网络（RoCE）设置与验证
    • 3.4 容器镜像与工具链准备
    • 3.5 模型权重准备（含内网受限环境的替代通道）
    • 3.6 启动服务（完整命令）
    • 3.7 就绪判定与功能验证
    • 3.8 停止、切换与回滚
  • 4. 常见问题排查与解决方案
  • • 4.1 排错总表（先查这张表）
    • 4.2 重点案例：服务能起、输出乱码——加载器静默丢掉 FP8 qkv 权重
    • 4.3 重点案例：加载期崩溃 `1856 vs 1792`——fused-QKV 几何
    • 4.4 其它实战坑（按出现频率排序）
  • 5. 性能测试建议
  • • 5.1 测试口径（保证数据可比、可复现）
    • 5.2 实测结果（调优后配置）
    • 5.3 两项单变量调优的取舍（每项先过质量探针再进基准）
    • 5.4 建议的测试流程
  • 6. 使用注意事项
  • 7. 小结与参考

关键词 / 建议标签：DGX Spark、GB10、MiMo-V2.6-Flash、vLLM、MoE、TP=2、Ray、MXFP4、FP8、RoCE、大模型部署、推理性能

说明：文中主机名、内网地址、用户名均已做脱敏处理（以 HEAD_IP / WORKER_IP 等占位符表示），命令与参数保持可直接参考的完整性。

1. 引言与结论速览

MiMo-V2.6-Flash（小米）是一个 309B 总参 / 15B 激活 的稀疏 MoE 模型：48 层、256 个路由专家（top-8）、专家权重 MXFP4 存储 + FP8 计算、原生 1M 上下文，官方推荐 SGLang、vLLM 次选，并明确提示 “Stable vLLM may lag the architecture”——这句话在本次部署中应验了。

我们的目标是在两台 DGX Spark GB10（单机 128GB 统一内存）上，用一个 vLLM（TP=2）实例把这个 178GB 的模型跑起来。过程并不顺利：服务能起、HTTP 200、但输出乱码这个问题卡了很久，最后定位到镜像自带加载器的一处静默丢键缺陷。本文把完整的环境准备、部署步骤、排错记录、性能数据与使用注意事项整理成可复现的文档，供同行参考。

结论速览

2. 部署环境准备

2.1 硬件配置要求

为什么必须双机：模型权重约 178 GB（91 个文件、65 个 safetensors 分片），单机 128 GB 统一内存（其中可供推理约 121 GB）装不下，且运行时还要为 KV Cache 留出空间。因此采用 TP=2 跨节点张量并行，两节点各持一份完整权重（每份按 TP rank 切分加载）。

2.2 操作系统与系统软件版本

以下为本机实测基线（DGX Spark 出厂系统 + 常规更新）：

2.3 依赖软件安装清单

镜像选型要点：该镜像已内置 MiMo-V2 的架构支持（含 MiMoV2FlashForCausalLM 注册）、triton_attn_diffkv 注意力后端（MiMo 在 sm_121a 上必需，因 FA3 不可用）、mimo 的 reasoning / tool-call 解析器与 deep_gemm MoE 后端。若你的镜像不含这些，需先升级镜像或对照社区方案打补丁。

3. 详细部署步骤

3.1 拓扑与节点分工

#mermaid-svg-TMnUtccuPds1KGNR{font-family:\”trebuchet ms\”,verdana,arial,sans-serif;font-size:16px;fill:#333;}@keyframes edge-animation-frame{from{stroke-dashoffset:0;}}@keyframes dash{to{stroke-dashoffset:0;}}#mermaid-svg-TMnUtccuPds1KGNR .edge-animation-slow{stroke-dasharray:9,5!important;stroke-dashoffset:900;animation:dash 50s linear infinite;stroke-linecap:round;}#mermaid-svg-TMnUtccuPds1KGNR .edge-animation-fast{stroke-dasharray:9,5!important;stroke-dashoffset:900;animation:dash 20s linear infinite;stroke-linecap:round;}#mermaid-svg-TMnUtccuPds1KGNR .error-icon{fill:#552222;}#mermaid-svg-TMnUtccuPds1KGNR .error-text{fill:#552222;stroke:#552222;}#mermaid-svg-TMnUtccuPds1KGNR .edge-thickness-normal{stroke-width:1px;}#mermaid-svg-TMnUtccuPds1KGNR .edge-thickness-thick{stroke-width:3.5px;}#mermaid-svg-TMnUtccuPds1KGNR .edge-pattern-solid{stroke-dasharray:0;}#mermaid-svg-TMnUtccuPds1KGNR .edge-thickness-invisible{stroke-width:0;fill:none;}#mermaid-svg-TMnUtccuPds1KGNR .edge-pattern-dashed{stroke-dasharray:3;}#mermaid-svg-TMnUtccuPds1KGNR .edge-pattern-dotted{stroke-dasharray:2;}#mermaid-svg-TMnUtccuPds1KGNR .marker{fill:#333333;stroke:#333333;}#mermaid-svg-TMnUtccuPds1KGNR .marker.cross{stroke:#333333;}#mermaid-svg-TMnUtccuPds1KGNR svg{font-family:\”trebuchet ms\”,verdana,arial,sans-serif;font-size:16px;}#mermaid-svg-TMnUtccuPds1KGNR p{margin:0;}#mermaid-svg-TMnUtccuPds1KGNR .label{font-family:\”trebuchet ms\”,verdana,arial,sans-serif;color:#333;}#mermaid-svg-TMnUtccuPds1KGNR .cluster-label text{fill:#333;}#mermaid-svg-TMnUtccuPds1KGNR .cluster-label span{color:#333;}#mermaid-svg-TMnUtccuPds1KGNR .cluster-label span p{background-color:transparent;}#mermaid-svg-TMnUtccuPds1KGNR .label text,#mermaid-svg-TMnUtccuPds1KGNR span{fill:#333;color:#333;}#mermaid-svg-TMnUtccuPds1KGNR .node rect,#mermaid-svg-TMnUtccuPds1KGNR .node circle,#mermaid-svg-TMnUtccuPds1KGNR .node ellipse,#mermaid-svg-TMnUtccuPds1KGNR .node polygon,#mermaid-svg-TMnUtccuPds1KGNR .node path{fill:#ECECFF;stroke:#9370DB;stroke-width:1px;}#mermaid-svg-TMnUtccuPds1KGNR .rough-node .label text,#mermaid-svg-TMnUtccuPds1KGNR .node .label text,#mermaid-svg-TMnUtccuPds1KGNR .image-shape .label,#mermaid-svg-TMnUtccuPds1KGNR .icon-shape .label{text-anchor:middle;}#mermaid-svg-TMnUtccuPds1KGNR .node .katex path{fill:#000;stroke:#000;stroke-width:1px;}#mermaid-svg-TMnUtccuPds1KGNR .rough-node .label,#mermaid-svg-TMnUtccuPds1KGNR .node .label,#mermaid-svg-TMnUtccuPds1KGNR .image-shape .label,#mermaid-svg-TMnUtccuPds1KGNR .icon-shape .label{text-align:center;}#mermaid-svg-TMnUtccuPds1KGNR .node.clickable{cursor:pointer;}#mermaid-svg-TMnUtccuPds1KGNR .root .anchor path{fill:#333333!important;stroke-width:0;stroke:#333333;}#mermaid-svg-TMnUtccuPds1KGNR .arrowheadPath{fill:#333333;}#mermaid-svg-TMnUtccuPds1KGNR .edgePath .path{stroke:#333333;stroke-width:2.0px;}#mermaid-svg-TMnUtccuPds1KGNR .flowchart-link{stroke:#333333;fill:none;}#mermaid-svg-TMnUtccuPds1KGNR .edgeLabel{background-color:rgba(232,232,232, 0.8);text-align:center;}#mermaid-svg-TMnUtccuPds1KGNR .edgeLabel p{background-color:rgba(232,232,232, 0.8);}#mermaid-svg-TMnUtccuPds1KGNR .edgeLabel rect{opacity:0.5;background-color:rgba(232,232,232, 0.8);fill:rgba(232,232,232, 0.8);}#mermaid-svg-TMnUtccuPds1KGNR .labelBkg{background-color:rgba(232, 232, 232, 0.5);}#mermaid-svg-TMnUtccuPds1KGNR .cluster rect{fill:#ffffde;stroke:#aaaa33;stroke-width:1px;}#mermaid-svg-TMnUtccuPds1KGNR .cluster text{fill:#333;}#mermaid-svg-TMnUtccuPds1KGNR .cluster span{color:#333;}#mermaid-svg-TMnUtccuPds1KGNR div.mermaidTooltip{position:absolute;text-align:center;max-width:200px;padding:2px;font-family:\”trebuchet ms\”,verdana,arial,sans-serif;font-size:12px;background:hsl(80, 100%, 96.2745098039%);border:1px solid #aaaa33;border-radius:2px;pointer-events:none;z-index:100;}#mermaid-svg-TMnUtccuPds1KGNR .flowchartTitleText{text-anchor:middle;font-size:18px;fill:#333;}#mermaid-svg-TMnUtccuPds1KGNR rect.text{fill:none;stroke-width:0;}#mermaid-svg-TMnUtccuPds1KGNR .icon-shape,#mermaid-svg-TMnUtccuPds1KGNR .image-shape{background-color:rgba(232,232,232, 0.8);text-align:center;}#mermaid-svg-TMnUtccuPds1KGNR .icon-shape p,#mermaid-svg-TMnUtccuPds1KGNR .image-shape p{background-color:rgba(232,232,232, 0.8);padding:2px;}#mermaid-svg-TMnUtccuPds1KGNR .icon-shape .label rect,#mermaid-svg-TMnUtccuPds1KGNR .image-shape .label rect{opacity:0.5;background-color:rgba(232,232,232, 0.8);fill:rgba(232,232,232, 0.8);}#mermaid-svg-TMnUtccuPds1KGNR .label-icon{display:inline-block;height:1em;overflow:visible;vertical-align:-0.125em;}#mermaid-svg-TMnUtccuPds1KGNR .node .label-icon path{fill:currentColor;stroke:revert;stroke-width:revert;}#mermaid-svg-TMnUtccuPds1KGNR :root{–mermaid-font-family:\”trebuchet ms\”,verdana,arial,sans-serif;}

Worker 节点 · 推理工作节点

Head 节点 · 主控 + 推理入口

HTTP :8000

CX7 直连 RoCENCCL/RAY 通信

SSH · 权重/补丁分发

vllm_node 容器 :8000ray head · TP rank0

vllm_node 容器ray worker · TP rank1

客户端 / 网关model 统一填 vllm

管理链路

• Head：执行所有部署/启动命令，运行 Ray head 与 API 服务；
• Worker：被 Head 通过 SSH 驱动拉起容器，运行 Ray worker；
• 两节点必须位于同一管理网络，并具备 免密 SSH。

3.2 节点基础配置

# 在 Head 与 Worker 各自执行：主机名与 hosts 解析（示例值）
sudo hostnamectl set-hostname head-node # Worker 侧改成 worker-node
# /etc/hosts 两机均写入（地址用实际值替换）
echo "HEAD_IP head-node" | sudo tee -a /etc/hosts
echo "WORKER_IP worker-node" | sudo tee -a /etc/hosts

# Head 侧配置到 Worker 的免密 SSH（启动器依赖）
ssh-keygen -t ed25519 -N '' -f ~/.ssh/id_ed25519
ssh-copy-id spark@WORKER_IP # 用户名按实际替换
ssh -o BatchMode=yes spark@WORKER_IP 'hostname' # 应免密返回 worker-node

3.3 高速网络（RoCE）设置与验证

双机 TP=2 的每一步通信都跑在这条链路上，因此先验网络，再起服务。

GID 自动探测（写入两端启动脚本，避免建链失败）：

for i in $(seq 0 15); do
t=$(cat /sys/class/infiniband/rocep1s0f1/ports/1/gid_attrs/types/$i 2>/dev/null || true)
g=$(cat /sys/class/infiniband/rocep1s0f1/ports/1/gids/$i 2>/dev/null || true)
if [ "$t" = "RoCE v2" ] && [ -n "$g" ]; then
case "$g" in *ffff:*) NCCL_GID_INDEX=$i; break;; esac
fi
done

链路验证四连（全部通过再继续）：

# 1) RoCE 设备状态：两端应为 ACTIVE
rdma link && ibdev2netdev
# 2) RDMA 带宽实测：单逻辑口应接近 100 Gb/s
ib_write_bw WORKER_IP -d rocep1s0f1 –report_gbits -q 4 -R –force-link IB
# 3) MTU 一致性
ip link show enp1s0f1np1 | head -1
ping -M do -s 8972 -c 3 WORKER_IP # 计划用 9000 MTU 时先验证大包不丢
# 4) 关键：容器内 NCCL 必须真的走 IB。启动后检查容器日志
# docker logs vllm_node 2>&1 | grep -i "NET/IB"
# 没有 NET/IB 字样 = NCCL 静默退化为 TCP（吞吐直接腰斩），检查容器是否透传 /dev/infiniband

3.4 容器镜像与工具链准备

# 1) 镜像（两节点均需，或由 Head 分发）
docker images | grep vllm-node-b12x # 期望存在 vllm-node-b12x:latest

# 2) 启动工具链（仅 Head 需要，供 launch-cluster.sh 驱动两端）
cd ~/github
git clone <spark-vllm-docker 上游仓库地址> spark-vllm-docker

# 3) fused-QKV 补丁就位（集群模式下 -v / mod 挂载在每个节点生效，
# 因此补丁文件必须在两节点的完全相同路径存在）
ls ~/github/spark-vllm-docker/mods/fix-mimo-v2-qkv-block/run.sh

3.5 模型权重准备（含内网受限环境的替代通道）

若 HuggingFace 不可达，走 ModelScope 下载，再限速同步到 Worker：

# 1) 宿主机安装下载器（容器内无需安装）
pip install –user modelscope

# 2) 下载到「容器已挂载的 HF 缓存目录」，容器内直接按路径加载
modelscope download –model XiaomiMiMo/MiMo-V2.6-Flash-RL \\
–local_dir ~/.cache/huggingface/hub/models–XiaomiMiMo–MiMo-V2.6-Flash-RL

# 3) 限速同步到 Worker 同路径（实测 530MB/s，占 200Gb 链路 <3%，不干扰在役服务）
rsync -a –bwlimit=530000 –info=progress2 \\
~/.cache/huggingface/hub/models–XiaomiMiMo–MiMo-V2.6-Flash-RL/ \\
spark@WORKER_IP:~/.cache/huggingface/hub/models–XiaomiMiMo–MiMo-V2.6-Flash-RL/

# 4) 两节点逐文件校验（大小/文件数一致），随后全程离线加载：HF_HUB_OFFLINE=1

要点：

• 权重约 178 GB / 91 个文件 / 65 个 safetensors 分片，下载与同步都是"长动作"，建议在低峰执行；
• 受限环境下给 Python 加 PYTHONDONTWRITEBYTECODE=1，避免写系统缓存被拦导致命令中断；
• 两节点各持一份完整权重（TP=2 时各取所需分片），漏同步 Worker 会直接启动失败。

3.6 启动服务（完整命令）

在 Head 节点执行（工具链根目录）：

cd ~/github/spark-vllm-docker
./launch-cluster.sh –ray \\
-t vllm-node-b12x:latest \\
-e HF_HUB_OFFLINE=1 \\
-e CUTE_DSL_ARCH=sm_121a \\
-e VLLM_USE_AOT_COMPILE=1 \\
-e VLLM_USE_BREAKABLE_CUDAGRAPH=0 \\
-e VLLM_USE_MEGA_AOT_ARTIFACT=1 \\
-e VLLM_USE_FLASHINFER_SAMPLER=1 \\
-e VLLM_USE_V2_MODEL_RUNNER=1 \\
-e NCCL_CUMEM_ENABLE=0 \\
-e NCCL_NVLS_ENABLE=0 \\
-e VLLM_USE_RAY_V2_EXECUTOR_BACKEND=1 \\
-d \\
–apply-mod mods/fix-mimo-v2-qkv-block \\
exec vllm serve /root/.cache/huggingface/hub/models–XiaomiMiMo–MiMo-V2.6-Flash-RL \\
–host 0.0.0.0 –port 8000 \\
–trust-remote-code \\
–tensor-parallel-size 2 \\
–load-format safetensors \\
–moe-backend deep_gemm \\
–attention-backend triton_attn_diffkv \\
–gpu-memory-utilization 0.88 \\
–max-model-len 262144 \\
–max-num-seqs 16 \\
–max-num-batched-tokens 8192 \\
–enable-prefix-caching \\
–reasoning-parser mimo \\
–tool-call-parser mimo \\
–enable-auto-tool-choice \\
–served-model-name vllm MiMo-V2.6-Flash

参数逐项说明（按重要性排序）：

若使用自建的切换脚本，注意两点：① 启动前必须 docker rm -f vllm_node（launcher 检测到同名容器会复用，改参数不生效，见 4.4 节）；② 就绪等待超时要放宽到 ≥1200s（标准加载器 + 首次编译约 10–12 分钟）。

3.7 就绪判定与功能验证

就绪判据：/v1/models 返回 HTTP 200（容器 Up ≠ 服务可用）。启动时间线参考：

# 1) 就绪判定
curl -s -o /dev/null -w '%{http_code}\\n' http://127.0.0.1:8000/v1/models # 期望 200

# 2) 功能验证：事实问答（本模型是推理型，reasoning 字段先出思维链，max_tokens 建议 ≥256）
curl -s http://127.0.0.1:8000/v1/chat/completions -H 'Content-Type: application/json' \\
-d '{"model":"vllm","messages":[{"role":"user","content":"中国的首都是哪里？"}],"max_tokens":256,"temperature":0}'
# 期望 content 含「北京」

# 3) 健康信号：关注这些加载期日志行
docker logs vllm_node 2>&1 | grep -E "Loading weights took|GPU KV cache size|Resolved architecture|TRITON_ATTN_DIFFKV|DEEPGEMM"
# 期望：Loading weights took 约 9–10 分钟、KV cache 约 739k tokens、attention 后端为 TRITON_ATTN_DIFFKV

验收清单（建议逐项打勾）：

3.8 停止、切换与回滚

# 停止（两节点都要执行，否则统一内存与 8000 端口不会释放）
docker rm -f vllm_node
ssh spark@WORKER_IP 'docker rm -f vllm_node'

# 回滚到其它模型栈（示例：切换到既有生产模型）
./switch-model.sh deepseek # 就绪约 3–4 分钟

若使用切换脚本，其流程为「停旧栈 → 起新栈 → 轮询就绪 → 质量探针 → 失败自动回滚原栈」。切换脚本有两个已知陷阱：① 改配置后必须停容器再启动（否则复用旧容器）；② “目标栈已在运行则直接退出”——改完参数要主动停一次。

4. 常见问题排查与解决方案

4.1 排错总表（先查这张表）

4.2 重点案例：服务能起、输出乱码——加载器静默丢掉 FP8 qkv 权重

现象（最迷惑人的一点：服务完全"正常"）：

• 权重加载正常完成、/v1/models 返回 200；
• 但生成的是固定吸引子（如 0,0,0,…），finish_reason=length、无 EOS；
• 两条同长度、不同内容的提示，生成 512 token 逐位完全相同；长度不同则是同一序列的后缀；
• 换 MoE 后端（b12x / marlin / deep_gemm）、关 lm_head 量化、改 QKV 行布局解释——输出逐位不变（只有 MoE 后端会换一个吸引子外观）。

定位路径（每步只引入一个变量的排查法，非常好用）：

根因：镜像的 instanttensor 加载器（快速加载：525s → 23.4s）不投递 FP8 的 qkv_proj.weight 键，只投递其 weight_scale_inv；而模型侧 _try_load_fp8_qkv_proj 是"权重与 scale 成对到达才写入"的语义，配对缺失时既不报错也不回退——这是本次故障最难定位的原因。

解法与验证：

# 修复：启动参数改一行
–load-format instanttensor → –load-format safetensors

# 复核（诊断模式下）
docker exec vllm_node grep -c PAIRED /tmp/attn-dbg.log # 期望 48（故障时 0）
docker exec vllm_node grep -m1 'qkv-load.*qkv_proj.weight ' /tmp/attn-dbg.log # 应有输出

普适教训：含"成对加载逻辑"的模型（融合 QKV + FP8）不宜使用 instanttensor 类快速加载器；同时，加载器/模型侧对"配对超时/缺键"应当显式报错而不是静默跳过——静默是这次排错耗时的大头。

4.3 重点案例：加载期崩溃 1856 vs 1792——fused-QKV 几何

现象：引擎初始化约 1 分钟后失败，死在权重加载首分片约 2% 处：

RuntimeError: The size of tensor a (1856) must match the size of tensor b (1792) at non-singleton dimension 0
File "…/vllm/model_executor/models/mimo_v2.py", line 525, in _shard_fp8_qkv_proj

根因：镜像处理 FP8 融合 QKV 反量化时，用 scale_rows_per_group = s_full.shape[0] // num_kv_heads 计算每组的 scale 行数，隐含假设"每组行数是 128（FP8 块大小）的整数倍"。而该模型检查点里：

两个恒等式（4×块行数 = 总行数、4×⌈块行/128⌉ = scale 行数）共同证明：融合 QKV 是"4 分块、块内 [Q|K|V]“，而不是全局 [Q|K|V]、也不是"num_kv_heads 个连续组”。滑窗层按原假设取 116 // 8 = 14 块 → 展开 1792 行 ≠ 真实 1856 行 → 直接抛错。

解法：使用 mods/fix-mimo-v2-qkv-block 补丁——按分块窗口反量化 → 重组全局 [Q|K|V] → 按 TP rank 取行 → 重新量化，并含布局自检与形状校验。修复后 PAIRED=48、输出正确。

4.4 其它实战坑（按出现频率排序）

5. 性能测试建议

5.1 测试口径（保证数据可比、可复现）

# 用例示例（容器内）
SEED=$(( RANDOM + 100000 )) # 关键：每轮唯一 seed
vllm bench serve –backend openai-chat –model vllm \\
–base-url http://127.0.0.1:8000 \\
–dataset-name random –random-input-len 2048 –random-output-len 256 \\
–num-prompts 16 –max-concurrency 16 –ignore-eos –seed $SEED \\
–percentile-metrics ttft,tpot,itl,e2el –metric-percentiles 50,95,99 \\
–save-result –result-dir /tmp/vllm-bench/mimo

5.2 实测结果（调优后配置）

读法：

• 单流/小并发：MiMo 的 TPOT 38.8ms（≈26 tok/s 等效）比对照栈慢，后者开了 n=3 投机解码；
• 突发并发：–max-num-seqs 16 后 MiMo 反超（87.6 vs 71.7 tok/s，TTFT 4.9s vs 10.5s）；
• 长上下文：48 层中 39 层是窗口 128 的滑窗注意力，32K 输入场景 MiMo 略优；
• "有效产出"打折：推理型模型同样 max_tokens 下先输出思维链，用户可见答案占比更低，选型时按"每千 token 可用答案"折算。

5.3 两项单变量调优的取舍（每项先过质量探针再进基准）

方法论提醒：这两项结论都建立在"改一个变量→先跑质量探针（事实问答+退化指标）→再跑冷启动基准"的流程上；跳过质量探针直接看吞吐，很可能把"坏掉的快"当成"优化成功"。

5.4 建议的测试流程

6. 使用注意事项

7. 小结与参考

一句话总结：在两台 DGX Spark 上跑 MiMo-V2.6-Flash，真正的门槛不在硬件也不在参数，而在**“版本边界”**——镜像（2026-09-13 的 dev 构建）与模型（2026-09-22 发布）之间存在两处不兼容：加载器丢 FP8 融合 QKV 权重（静默乱码）、fused-QKV 分组假设错误（加载崩溃）。两者分别用 –load-format safetensors 与 fused-QKV 补丁 规避后，模型双机 TP=2 稳定运行，突发并发与长上下文场景下吞吐已可用于生产。

参考来源：

• 模型主页（官方部署说明，SGLang cookbook + vLLM recipe）：https://huggingface.co/XiaomiMiMo/MiMo-V2.6-Flash-RL
• spark-vllm-docker（镜像与跨节点启动工具链）：https://github.com/eugr/spark-vllm-docker
• 社区 MiMo 系列双机 Spark 案例（MiMo-V2.5 配方，思路可参考）：
  • https://github.com/tonyd2wild/MiMo-V2.5-TP2-1M-NVFP4-KV-2xDGX-Spark
  • NVIDIA Developer Forum 长贴：https://forums.developer.nvidia.com/t/mimo-v2-5-new-model/368097
• vLLM Issue #35329（MXFP4 MoE 相关，用于对照排除）：https://github.com/vllm-project/vllm/issues/35329

本文基于 2026-09-22/23 的两次真实部署与一轮性能调优整理；文中版本号、参数与实测数据均为本机读数，模型与镜像更新后请重新验证。