工具
实测 Kimi K3（2.8T 参数）自托管：B300 达 92 tok/s，每百万 token 成本 190 美元
社区用户在 8 张 B300 上以 vLLM 部署 Kimi K3 2.8T 参数模型，解码 92 tok/s；同时对比…
2026.08.23 · 周日约 2 分钟阅读
近日，一位社区开发者在 Reddit r/LocalLLaMA 分享了对 Kimi K3（2.8T 参数）模型的自托管实测结果。该模型在 8 张 B300 GPU 上通过 vLLM 运行，并同步对比了 Unsloth 推出的 1-bit 动态 GGUF 量化方案，提供了具体的吞吐、延迟与成本数据。
B300 + vLLM 部署表现
测试环境采用 8 张 B300，托管在 Modal 平台上，每小时 GPU 成本为 56.79 美元。推理框架使用 vLLM，开启张量并行 8 路，并采用原生 MXFP4 量化格式。
- 模型权重加载量约 1.56 TB，冷启动耗时约 27 分钟（含 JIT 编译与 51 个 CUDA graph 捕获）
- 首 token 时间（TTFT）稳定在 0.92–1.02 秒之间
- 解码速度稳定在 92 tok/s，4 条 prompt 平均为 83 tok/s
- 按输出 token 计费约为 190 美元/百万 token；单次干净运行的 GPU 成本约 36 美元；保持热启动状态下约为 1363 美元/天
1-bit GGUF 量化方案对比
测试同时运行了 Unsloth 的 Dynamic GGUF 1-bit 量化（UD-IQ1_S），模型文件约 594 GB，可装载至 8 张 A100-80GB，使用 llama.cpp。
- 硬件成本约 19.99 美元/小时，比 B300 方案便宜 2.8 倍
- TTFT 波动较大，介于 7–60 秒
- 解码速度约 9 tok/s
- 按 token 计费约 620 美元/百万 token，比 B300 方案贵 3.3 倍
- 1-bit 量化下模型质量「尚可」，算术运算正确，文本连贯
小结
从两组实测来看，B300 + vLLM 方案在吞吐和延迟上明显占优，但每小时硬件成本较高；1-bit GGUF 方案单卡成本低、显存占用小，但首 token 延迟和每 token 成本均显著高于 B300 方案。对于需要在自托管场景下运行超大参数 MoE 模型的团队，这两条路径在性能、成本与质量之间的取舍已十分清晰。完整的部署参数、Modal 部署文件与原始 benchmark JSON 可在作者提供的链接中查阅。