DGX-spark-GB10 120GB显存的机器，为什么部署Qwen3-14B生成速率才13tokens/s

为什么只有 ~13 tokens/s？这其实是正常的

部署的模型是：Qwen3-14B-Claude-4.5-Opus-Distill.q8_0.gguf

采用llama.cpp部署

https://modelscope.cn/models/TeichAI/Qwen3-14B-Claude-4.5-Opus-High-Reasoning-Distill-GGUF

Qwen3-32B/14B “Dense” 模型在 DGX Spark 上会遇到"带宽瓶颈"，速度约为 10.7 t/s。 你的 Qwen3-14B Q8_0 速度 13 t/s 实际上已经处于这个量级的合理范围内。

根本原因： GB10 的显存带宽（~273 GB/s）是瓶颈，不是算力。Dense 架构的大模型在推理（decode）阶段是严重的内存带宽受限场景，而不是算力受限。Qwen3-14B Q8_0 模型大小约 14GB，每生成一个 token 都要把权重全部读一遍，带宽决定上限。

与其模型的对比

MoE 架构是 DGX Spark 的"杀手级应用"，Qwen3 30B MoE 可以达到约 89 t/s，而同规模的 Dense 模型只有约 10.7 t/s。

如何提升速度？

方案一：换更低量化（最直接）

将 Q8_0 换成 Q4_K_M 或 Q4_K_XL，模型读取量减半，速度理论上提升近 1 倍（到约 25~30 t/s），质量损失可接受：

-m Qwen3-14B.q4_k_m.gguf

方案二：开启 Flash Attention

在启动参数中加上 -fa（Flash Attention），可以降低 KV Cache 的显存占用，在长上下文时效果明显：

-fa 1

方案三：减少 context 长度

你目前设置了 -c 40960，这会在启动时预分配 KV Cache，消耗大量显存。如果实际用不到这么长的上下文，缩短到 8192 或 16384 可以释放更多显存给模型本身：

-c 8192

方案四：调整 batch-size 和 ubatch-size

当前 --batch-size 1024 较小，可以尝试增大到 2048 甚至 4096 来提升 prefill 速度（对 decode 单流影响有限，但对并发场景有帮助）：

--batch-size 4096 --ubatch-size 512

方案五：换 MoE 架构模型（根本解法）

如果追求速度，MoE 模型才是 GB10 的最优解，可以考虑 Qwen3-30B-A3B（MoE）替代 Qwen3-14B Dense，速度有望提升到 60~89 t/s。

总结建议

你的 13 t/s 并不是配置问题，是 Dense 大模型在内存带宽受限设备上的物理上限。短期优化：换 Q4_K_M 量化 + 开启 -fa，速度约可翻倍到 25 t/s 左右。长期优化：换 MoE 架构模型。

另外：DGX-SPARK 测试速率

https://github.com/DandinPower/llama.cpp_bench/blob/main/dgx_spark/report.md

3.1 Prompt Processing (Prefill)

Measured in Tokens per Second (t/s).

3.2 Decoding (Generation)

Measured in Tokens per Second (t/s). Batch size = 1. Comparisons at shallow (512) vs deep (2048) context.