我在单卡 GB10/DGX Spark 上运行 Qwen3.8-Flash-Next 的方案：Intel AutoRound int4 量化 + vLLM，fp8 ngram 表卸载至本地 SSD 或外部 RDMA 服务器，mtp=3、c=1 时代码生成速度约 47.5 t/s

仓库：https://github.com/Saren-Arterius/qwen3.8-Flash-DGX-AutoRound 我从 blazux/qwen3.8-Flash-DGX fork 而来，借鉴了此前 qwen 3.5 122b 方案的所有思路，构建了一个混合模型，包含 lm_head 的 int8 量化（注意：未经校准），以及 GDN 输入/输出投影、QSA q/k/v/o、共享专家的 fp8 量化（注意：未经校准）。没有观察到明显的质量下降，目前已经实战测试了一两天，没有崩溃或模型失控的情况。vLLM 在 c=1、pp 模式下，按 API 调用中提示词 token 除以墙钟时间计算约为 2000 t/s，而 llama-benchy 的报告并不能很好地反映这一点。llama-benchy 在 mtp=3 时的峰值 tg（可视为下限）：c=1：41.33 t/s ± 1.89；c=8：152.67 t/s ± 7.32；c=16：239.33 t/s ± 3.30。在 d=32768 时，c=1：45.33 t/s ± 5.44；c=8：122.33 t/s ± 7.41；c=16：138.33 t/s ± 10.62。请注意，仓库中的技术信息可能是 AI 生成的垃圾内容，因为我并没有能力自己修改 vLLM，也不清楚其内部原理，模型质量方面也是如此。不过启动脚本已验证过，应该是可用的。另外，MTP 目前在并发场景下会引入大量额外的 TTFT，这可能对你造成问题。我很期待 DSpark/DFlash2 模型。如果你的 GB10 设备旁边放着一台带 100G+ 网络和 64GB+ 内存的 NAS，那么 "magi" 分支可能会让你感兴趣，因为它使用外部 RDMA 服务器，基本消除了 ngram/PLE 查找 IO 造成的额外延迟，在所有场景下均提升 3 t/s 的 tg。仓库：https://github.com/Saren-Arterius/qwen3.8-Flash-DGX-AutoRound