更新（2026年7月29日）：我们已通过与SGLang相同的设置运行Kimi K3。在1.4TB的权重下，K3不符合为GLM-5.2使用的8×B200节点的内存预算（1.5TB的总HBM没有KV缓存的余地）。因此，这次运行使用了8×B300节点，每个GPU提供288GB的HBM，而不是192GB，或者说每个节点为2.3TB。这使得硬件成本平均比8×B200配置高出约20%，具体取决于您的租赁提供商。在我们的测试中，K3支持16个并发会话（GLM-5.2管理24个会话）。总的token吞吐量约低30%（16个用户时分别为122与170 tok/s），而中位数任务时间约长50%（38分钟对26分钟）。这使得K3的速度大约比我们的Claude Code基线慢8倍。然而，K3在任务解析质量上弥补了这点，解析率为86.4%，比GLM-5.2和Opus 4.8高24个百分点（后两者均为62.5%）。需要注意的是，我们从SWEBench Pro获取的基准任务可能已在K3的训练数据中，因此对这一解析率应持谨慎态度。本文中仅更新了图表以包含新的K3数据。01 今年你的token账单为何暴涨 今年上半年的预警信号随处可见：GitHub Copilot切换到基于token的计费[1]，Uber在短短四个月内耗尽了年度AI工具预算[2][3]，开发者报告预计成本从每月29美元跃升至750美元[4]。我们甚至为此创造了词汇："tokenmaxxing"、"token panic"、"token budgets"。目前中位数员工每年在AI API使用上的花费约为140美元。听起来似乎无害，直到你看到尾部数据：第90百分位数接近7300美元每年，而第99百分位数接近90000美元。对许多组织而言，代理AI的采用才刚刚开始，因此预计这些数字将在未来一年内发生变化。账单为何如此波动？因为我们使用AI代理的方式：目前，主要模型提供商中超过70%的年经常收入来自编码用例[4]。你将工作流程的更多部分交给代理，token账单就会变得更高。许多组织通过API访问，采用OpenAI或Anthropic等主要前沿模型提供商的AI编码代理。几个月后，越来越多的组织开始考虑多元化的选择，原因有很多：token定价模型变得更昂贵，用户升级到更新且更昂贵的AI模型，而组织内部的代理采用开始迅速增长。有些合理的替代方案值得更仔细地研究：切换到API路由器；在日常工作中使用更便宜的模型层，而将艰难的20%任务升至前沿模型等。然而，如果你的token消耗变得显著，或者你在处理敏感数据，你可能会想要完全放弃API方法并建立自己的推理堆栈。当硬件的所有权成为讨论话题时，你需要明白租用或拥有GPU实际上给你带来了什么回报。何时切换是合理的？继续阅读，我们将给你提供自行决策的工具。02 你支付的池子24/7，你的团队每天使用8小时 所以你决定调查买入或租赁自己的GPU是否合理。一旦配置正确，它将为你提供一个可以接入你编码工具的API端点，就像Anthropic、OpenAI或其他模型提供商所提供的那样。与前沿API相比，自己的端点对每秒输出token有一个上限，但只有在系统完全负载时你才会达到这个上限。一个独自工作的开发者，大部分时间未能使用到这个上限，但是同样的硬件支持四十八个代理会话并行运行则是另一种情况。你的上限将由模型、GPU以及服务配置决定。020k40k60k124816243264总tokens/s与并发用户 → 图01 并发用户与每秒总token数的示例模型A在硬件设置B上运行的说明性示例。与按token消费收费的API使用模型不同，运行自己的设置意味着你支付的是基础设施的费用，以及维持其运作的成本。在大多数情况下，这意味着即使当你没有生成token时，你也在为其支付。这个权衡对你是否可行，由两个问题决定。第一个是你使用了池子的多少。让我们首先解决这个问题。你为高峰负载进行配置，并为其支付费用24/7。利用率，而不是员工人数，决定了成本的合理性。实际需求不是恒定的，而是有波动的。对于许多组织而言，编码任务的token消耗在夜间几乎为零，早晨逐渐上升，中午明显下降，而在下午中段再次达到峰值。这意味着你为高峰负载购买硬件，但要为其支付24/7（除非你租用“GPU现货实例”，但在这种情况下更难以依赖）。你的使用高峰的形状与数量同样重要：一个单一时区的团队将token需求集中到更狭窄的波动中，而同样的员工人数