DGX Spark 上的模型选型与生产力实践
- URL: https://mp.weixin.qq.com/s/4iFhcdocdMeBSMUP70nRZA
- Date Saved: 2026-08-12
- Source: WeChat (你起来我讲两句)
- Tags: local-llm
Summary
DGX Spark（GB10, 128GB统一内存, 273GB/s带宽）的模型选型实战经验。实测十几个模型后的选型铁律和三个主力模型推荐。
选型铁律
- 必须 NVFP4 — Blackwell原生FP4算力，llama.cpp的GGUF Q4不走FP4核心，是浪费
- 小激活MoE优于Dense — 解码看每字激活参数量，激活3B的MoE比27B Dense还快
- 4-bit权重压到100GB以内 — 留空间给KV缓存和系统（排除400B+巨无霸）
- MTP投机解码免费加速40% — 但要引擎支持
三个主力模型（互斥，一次跑一个）
| 模型 | 类型 | 速度 | 用途 |
|---|---|---|---|
| Nex-N2-mini | MoE 35B-A3B | 57 tok/s | 日常对话、多模态、批量评测（64并发564 tok/s） |
| Qwen3.6-27B | Dense 27B 视觉 | 15-20 tok/s | 代码质量天花板（77.2% SWE-bench，平Terminal-Bench Claude 4.5 Opus） |
| Coder-Next | 80B-A3B MoE | 35 tok/s | 编码Agent，原生工具格式 |
实测踩坑
- Qwen3.5-122B：13 tok/s独占整机，交互差
- GRM-2.6-Opus：自量化时不能动GDN线性注意力层，否则输出全空格（量化自检还看不出）
- Nemotron-3：120B-A12B，MTP在实测引擎跑不起来，无MTP反而不如27B
- GGUF Q4：不走FP4核心，浪费算力
多模态服务栈
- ASR: Qwen3-ASR-1.7B（中英+22方言）
- TTS: Kokoro（CosyVoice2因torchaudio在aarch64装不上而放弃）
- 视觉检测: LocateAnything-3B
- ComfyUI: docker-compose部署，跑通Hunyuan文生视频
aarch64 踩坑通用解法
- 保留NGC的GPU torch
- 单独修x86/CUDA12的依赖
- 音频模型避开torchaudio
- functorch用shim转发，transformers钉4.50.3
性能关键数字
- 273GB/s带宽 → 55GB bf16模型约5 tok/s，14GB 4-bit模型约19 tok/s
- 量化不是可选，是必选
- SGLang在sm_121上开箱即用，支持NVFP4 MoE