Hacker News 中文摘要

RSS订阅

自托管Kimi K3:硬件成本增加20%,任务解决能力提升20% -- Self-hosting Kimi K3: 20% more hardware cost, 20% better task resolution

文章摘要

这篇文章比较了在GPU上自托管不同AI编码代理的性能。GLM-5.2在8×B200节点上可支持24个并发会话,而Kimi K3因权重更大需用8×B300节点,仅支持16个会话。K3吞吐量低30%,任务时间长50%,但任务解决率达86.4%,远超GLM-5.2和Opus 4.8的62.5%。

文章总结

好的,这是根据您的要求,对原文进行中文重述和精简后的版本:

标题:一块GPU能容纳多少开发者?—— 自托管你的编程助手

更新说明: 我们使用SGLang对Kimi K3模型进行了测试。由于其1.4TB的权重无法装入8×B200节点的内存(1.5TB总HBM没有为KV缓存留出空间),我们改用8×B300节点(每GPU 288GB HBM,总计2.3TB)。这导致硬件成本比8×B200设置高出约20%。在我们的测试中,K3支持16个并发会话(GLM-5.2支持24个),总token吞吐量低约30%(16用户时为122 vs 170 tok/s),中位任务时间长约50%(38 vs 26分钟),使其速度约为Claude Code基线的8倍。然而,K3在质量上表现出色,解决了86.4%的任务,比GLM-5.2和Opus 4.8(均为62.5%)高出24个百分点。需要注意的是,我们的SWEBench Pro基准任务可能包含在K3的训练数据中,因此请谨慎看待这个解决率。

01 为什么你的Token账单今年暴涨

今年上半年,AI API使用成本飙升的迹象随处可见:GitHub Copilot转向基于token的计费,Uber在四个月内烧光了年度AI工具预算,开发者的月费从29美元涨到750美元。普通员工每年在AI API上的花费约140美元,但90分位用户接近7,300美元,99分位则高达90,000美元。账单波动如此之大,是因为AI代理的使用方式:目前,主要模型提供商超过70%的年化经常性收入来自编码用例。你交给代理的工作流程越多,token账单就越高。

许多组织最初通过API使用前沿模型提供商。几个月后,由于token定价模式变得更昂贵、用户升级到更新更贵的模型以及代理采用率激增,越来越多的组织开始考虑替代方案,如使用API路由器或为常规工作使用更便宜的模型层。然而,如果你的token消耗量很大或处理敏感数据,你可能希望放弃API方法,建立自己的推理栈。当考虑拥有硬件时,你需要了解租用或购买GPU能带来什么回报。何时进行这种转换才有意义?

02 你24/7支付硬件费用,但团队每天只用8小时

一旦你决定自托管,你将获得一个API端点,可以像使用Anthropic或OpenAI的API一样接入你的编码工具。与前沿API不同,你自己的端点有输出token的上限,但只有在系统满载时才能达到。一个开发者单独工作会留下大部分未使用的容量,但同一硬件服务于48个并行代理会话则完全不同。你的上限由模型、GPU和服务配置决定。

你为峰值负载配置硬件,但需要24/7为其付费。利用率,而非员工人数,是决定成本效益的关键。实际需求是波动的:编码任务的token使用在夜间接近零,上午攀升,午餐时下降,下午再次达到峰值。这意味着你为峰值负载购买硬件,但全天候付费。已发布的企业推理工作负载数据显示,GPU平均利用率为15-22%,即使运行良好的部署也很少超过25-35%。一个新兴趋势是,随着组织成熟,越来越多的会话来自自动化代理(如定时任务),这可以吸收你已经在支付的夜间容量。

现在我们来解决第二个问题:在系统变慢之前,有多少开发者可以共享这个池子?

03 当48个开发者共享一个盒子时会发生什么?

一个只由一个开发者使用的token池感觉很好——token的流入速度比阅读速度还快。问题是当有五个、十个或二十个并发开发者会话时会发生什么,因为AI编码代理是贪婪、突发的客户端,不仅消耗token,还会浏览网页、执行文件或编译代码。

衡量价值交付的更好单位是成功完成的任务。你需要了解任务从头到尾需要多长时间以及当代理等待模型时token流的速度。为了使任务完成可衡量,我们使用了SWEBench Pro中的一组任务。我们通过在不同用户并发级别下运行编码任务,评估模型和硬件组合的性能,并找出在任务时间变得过长之前,你的设置可以支持多少并发用户。

04 从桌面上的Spark到8×B200节点:该买哪个盒子

我们测试了四种流行的硬件选项,每种都搭配了最适合其内存预算的开源模型:

  • NVIDIA DGX Spark:最便宜的选择,适合想尝试自托管的团队。可运行Qwen3.6-35B-A3B模型。
  • NVIDIA H200:强大的单加速器,可提供更大的token池,从而在更高并发下提高吞吐量。同样运行Qwen3.6。
  • NVIDIA HGX H200 (4×H200):可托管更大的模型,如DeepSeek-V4-Flash,在速度、并发性和质量之间取得良好平衡。
  • HGX B200 (8×B200):强大的参考系统,可服务最接近前沿模型质量的开源模型,如GLM-5.2。

05 这些池子有多大?

DGX Spark的token池很小,在我们的测试中无法支持超过1-2个并发用户,并会出现超时错误。对于Qwen3.6,单个H200可以产生至少30倍于DGX Spark的token/秒。DeepSeek-V4-Flash在HGX H200上拥有更大的token池,但只有在高并发下才能发挥潜力。而GLM-5.2在HGX B200上,尽管硬件最强大,但token池较小,16个并发会话似乎就几乎饱和了GPU。更大、更强大的模型伴随着更小的token池。

06 开发者对速度满意吗?

以Claude Code为基准,GLM-5.2从8个并发会话开始就表现不佳。DGX Spark即使对一个用户来说也很慢,对多个用户则完全不可用。DeepSeek-V4-Flash和Qwen3.6可以支持到32个用户,之后性能下降。大致来说,在开发者抱怨速度之前,每个设置可以支持的并发用户数如下:

  • Qwen3.6 (DGX Spark): 仅1个,且速度慢
  • Qwen3.6 (H200): 轻松支持32个
  • DeepSeek-V4-Flash: 轻松支持32个
  • GLM-5.2: 8个已是极限

注意,Qwen3.6和DeepSeek-V4-Flash在更高并发下性能会崩溃,这与推理引擎(vLLM)的默认参数及其在预填充和解码请求之间平衡计算的方式有关。通过优化推理引擎,可以更好地处理这些问题。

07 这一切要花多少钱?

我们比较了购买、租用GPU和使用API的成本。对于购买,我们按5年折旧计算。结果如下(针对64个SWEBench Pro任务):

  • Qwen3.6 (1×H200):API成本$57.67,购买成本$0.43(30%利用率时为$1.43),租用成本$1.62。
  • DeepSeek-V4-Flash (4×H200):API成本$2.13,购买成本$1.90(30%利用率时为$6.33),租用成本$7.19。
  • GLM-5.2 (8×B200):API成本$92,购买成本$13.84(30%利用率时为$46.12),租用成本$71.23。
  • Anthropic API (Opus 4.8):API成本$98。

关键发现:4×H200需要保持89%的繁忙度才能让购买比DeepSeek的API更划算,而B200机架只需15%的利用率就能击败前沿API定价。在租用费率下,它已经以每个任务$1.11的价格提供接近前沿质量的任务,比任何API都便宜。对于Qwen3.6,租用GPU比使用API便宜35倍。但对于DeepSeek,租用反而比其API贵得多。没有单一的赢家,购买GPU只有在保持硬件忙碌时才划算。

08 但我喜欢封闭的前沿模型?

虽然开源模型总是落后前沿模型几个月,但到2026年,最好的开源模型已经非常实用,而且差距正在缩小。对于像GLM-5.2这样的模型,你至少需要一个HGX B200系统。在我们的测试中,各模型的解决率如下:Kimi K3为86.4%,GLM-5.2和Anthropic Opus 4.8均为62.5%,DeepSeek-V4-Flash为39.1%,Qwen3.6为35.4%。

09 那么一块GPU能容纳多少开发者?

答案在0到64之间,具体取决于配置。关键要点:

  • DGX Spark只适合单人使用,且模型较小。
  • 单个H200运行Qwen3.6可轻松服务32个并发会话,4×H200运行DeepSeek-V4-Flash也能以更高质量做到这一点。但8个B200运行GLM-5.2时,只能支持8个开发者。
  • 租用GPU可以节省成本,但高度依赖模型。我们看到了高达35倍的成本节省,但也看到了比API更高的成本。
  • 如果你的工作负载超过某个阈值,购买硬件可能变得划算。如果能让租用的B200机架保持15%的繁忙度,你就能以接近前沿API的价格获得接近前沿的质量。如果达不到,不要仅仅为了逃避token账单而自托管。

你的情况可能不同。因此,请衡量你自己的工作负载,了解你的峰值,并持续监控。随着你的组织在使用AI编码代理方面逐渐成熟,情况可能会发生变化。

评论总结

根据评论内容,总结如下:

主要观点与论据:

  1. 模型部署成本与性能权衡(评论1、7):作者团队指出,部署Kimi K3模型需从8×B200升级至8×B300,硬件成本增加约20%,并发用户数从24降至16。同时,SWEBench Pro测试集可能包含在Kimi训练集中,86%的解决率是上限。评论7进一步讨论1.4TB权重带来的加载/卸载时间问题,认为快速冷启动是关键产品特性,并质疑Kimi许可证对“模型即服务”的定义边界。

    • 关键引用:
      "fitting the 2.8T model means going from 8×B200 to 8×B300, ~20% more hardware cost"
      "our 64-task SWEBench Pro subset may be in Kimi's training set, so the 86% resolve rate is an upper bound"
  2. 价格信息缺失与量化需求(评论2、3):评论2批评文章缺乏实际价格,使“买什么”的分析失去意义。评论3呼吁加入量化版本对比,因为量化允许在较小硬件上运行模型,是购买GPU决策的重要维度。

    • 关键引用:
      "analysis of 'what to buy' without actual prices is borderline meaningless"
      "I would love to see benchmarks comparing different quantizations of several models, especially in quality"
  3. 本地模型体验与实用性(评论4):用户发现gemma-4-26b-a4b在本地运行表现良好,尤其适合代码指导、语言学习等任务,结果令人满意。

    • 关键引用:
      "gemma-4-26b-a4b is suprisingly capable"
      "the results are rather good (to the point that I use it mostly nowadays)"
  4. 资源利用与未来趋势(评论5):认为当前GPU利用率低是暂时现象,未来可通过自动化工作流和智能任务路由实现最大化利用,类似过去夜间运行MapReduce作业。

    • 关键引用:
      "Utilization maximization is a matter of switching to the software factory unattended flow"
      "A decade and a half ago we used to run massive map reduce jobs overnight. Code will be handled like this."
  5. 网站设计问题(评论6、8):多位用户批评网站背景动画干扰阅读,影响体验。

    • 关键引用:
      "I could not focus on the article with all the noise in the background"
      "Why does the website have to be so trippy when scrolling? It fucks with my eyes."
  6. 成本高昂与个人用户被排除(评论9):认为高昂成本将导致个人用户无法拥有计算机,自托管前沿模型成为企业专属。

    • 关键引用:
      "The costs are so staggering it's becoming clear we're going to be priced out of owning computers altogether"
      "Self-hosting frontier models is a corporation's choice, not an individual's."

平衡性总结:
评论对文章内容整体认可,但指出价格信息缺失、量化对比不足、网站设计干扰等缺陷。同时,对模型部署成本、许可证边界、未来资源利用趋势等提出深入讨论,反映了技术社区对本地化部署与商业化的复杂态度。