自托管 Kimi K3 和 GLM-5.2：GPU 硬件成本 vs 任务分辨率
执行摘要
为 AI 编码代理自托管像 Kimi K3 和 GLM-5.2 这样的前沿开放权重模型涉及硬件支出、并发性和任务分辨率质量之间的直接权衡。虽然 Kimi K3 所需的硬件投资大约比 GLM-5.2 多 20%——需要使用 8×B300 节点而不是 8×B200 节点——但在 SWEBench Pro 任务上它提供了 86.4% 的分辨率，优于 GLM-5.2 和 Anthropic Opus 4.8（两者均为 62.5%）。
Kimi K3 与 GLM-5.2：性能和硬件要求
Kimi K3 的巨大 1.4TB 权重占用导致其无法放入 8×B200 节点的内存预算（总 HBM 1.5TB），因为 KV 缓存的空间不足。因此，K3 需要一个 8×B300 节点，每个 GPU 提供 288GB HBM（每节点 2.3TB），导致硬件成本大约增加 20%。
吞吐量和延迟权衡
- 并发性： K3 支持 16 个并发会话，而 GLM-5.2 支持 24 个。
- 吞吐量： K3 的总令牌吞吐量大约比 GLM-5.2 低 30%（在 16 用户时为 122 vs 170 tok/s）。
- 任务完成时间： K3 的中位任务时间大约比 GLM-5.2 长 50%（38 vs 26 分钟），使得 K3 大约比 Claude Code 基线慢 8 倍。
尽管存在这些性能惩罚，K3 的卓越分辨率（86.4%）使其在组织能够容忍更高延迟的情况下成为处理复杂工程任务的更有效工具。
编码代理的 GPU 基础设施选项
选择合适的硬件取决于模型质量与系统必须支持的开发者数量之间的期望平衡。
硬件层级与模型适配
| 硬件配置 | 推荐模型 | 舒适并发数 | 性能备注 |
|---|---|---|---|
| DGX Spark | Qwen3.6-35B-A3B | 1 用户 | 慢；大约比 Claude Code 慢 3 倍 |
| 1× H200 | Qwen3.6-35B-A3B | 32 用户 | 高吞吐量；在 48 用户时大约比 Claude Code 慢 2 倍 |
| 4× H200 | DeepSeek-V4-Flash | 32 用户 | 质量与速度的良好平衡 |
| 8× B200 | GLM-5.2 | 8 用户 | 接近前沿质量；超过 8 用户后显著变慢 |
| 8× B300 | Kimi K3 | 16 用户 | 最高分辨率；硬件成本高 |
"崩溃" 现象
在使用 vLLM 进行高并发测试时，像 Qwen3.6 和 DeepSeek-V4-Flash 这样的模型在 48–64 用户后往往会出现崩溃而不是逐渐下降。这归因于推理引擎的默认参数以及 prefill 和 decode 请求之间的平衡，以及 KV 缓存大小的限制。
成本分析：购买 vs. 租用 vs. API
自托管的财务可行性由 GPU 利用率决定。由于硬件需要全天候付费（24/7），而开发者需求呈波峰波谷（通常平均利用率为 15–22%），因此不同模型的“盈亏平衡”点有所不同。
所有权的利用率阈值
- 高端机架 (B200)： B200 机架仅需 15% 的利用率即可在近前沿质量任务上比前沿 API 更具成本效益。
- 中端机架 (4× H200)： 4× H200 配置必须保持 89% 的繁忙度才能击败 DeepSeek-V4-Flash API 的定价，这主要是因为 DeepSeek 的 API 高度优化了缓存输入令牌（多达编码代理令牌的 98%）。
租赁作为中间方案
对于某些模型，租用 GPU 可能比 API 便宜很多（例如，Qwen3.6 的成本可降低 35 倍），但如果工作负载没有进行特定优化，租用 GPU 对于其他模型（例如 DeepSeek）可能比 API 更昂贵。
社区见解综合
围绕这些发现的技术讨论凸显了几项不可量化的优势和自托管的潜在优化：
- 隐私与主权： 自托管对具有严格数据驻留要求（例如欧洲或加拿大法律）的组织或处理敏感医疗数据的组织至关重要。
- 无限制实用性： 本地模型在执行红队渗透或信息安全任务时，可以避免前沿 API 带来的“拒绝”和账号封禁。
- 量化： 社区成员建议，使用量化版本（例如 int4）可以让前沿级模型在如 A6000 这样更小、更实惠的硬件上运行，尽管这需要进一步的基准测试以评估质量损失。
- 异步工作流： 有人认为，通过将非紧急的自动化任务（例如过夜错误修复）路由到自托管 GPU 的空闲容量，可以弥补“利用率差距”。