Kimi K2.6，月之暗面 的一万亿参数混合专家模型，于 2026 年 5 月在 DigitalOcean 无服务器推理 上线：将前沿级别的智能编码能力带到一个兼容 OpenAI 的端点，并与 DigitalOcean 现有云资源同一账单计费。
那张终结按 Token 计费时代的发票
你在提示框中键入了一句话：“将这个仓库重构为微服务，并为每个服务开一个 PR。”你按下回车，起身离开，回来时看到一个可运行的分支和一份合理的提交历史，有那么一瞬间，感觉自己活在未来。
然后发票到了。
那一次调用悄然变成了一个漫长的循环——智能体读取文件、调用工具、对结果进行推理、规划下一步，并再次循环。几十次推理调用。每次调用都带着不断增长的上下文窗口，每次调用都按完整的 token 价格计费。你预测这项任务大约会花费四十美分，账单上那栏却写着十四美元。再乘以每天运行数千次的产品功能，你的财务团队上个季度批准的那本账，就悄然崩盘了。
这不是计费错误。这是我们大多数人已经用了两年的定价模型，再也无法适配当前工作负载的那个时刻。按 token 定价是为聊天设计的：一个人，一条提示，一次补全，token 数量你可以在合理误差范围内估算。长周期智能体工作流不是聊天，它们是循环——自行决定一个任务值得多少次模型调用，而像 Kimi K2.6 这样的前沿模型，现在有能力判定答案是“很多次”。
好消息是，这是一个可以解决的问题。坏消息是，要解决它需要抛弃一些自 2023 年以来感觉像是常识的习惯。这篇文章发布的时间，正好是 Kimi K2.6 在 DigitalOcean 无服务器推理上线的同一周，这并非巧合。让我们来看看究竟发生了什么变化，为什么按 token 的计算在智能体负载下会失效，以及取而代之该用什么来做预算。
Kimi K2.6 正是那个让旧预算数学再也无法继续使用的模型。
本文关键要点
- 按 token 定价是为聊天工作负载设计的，而非智能体工作负载。长周期智能体每个任务会进行几十次推理调用，支出是非确定性的。
- 解决方法是按任务边界做预算，而不是按调用。追踪任务成本中位数、P95 任务成本、每次成功结果的成本，以及余量比率。
- Kimi K2.6 于 2026 年 5 月在 DigitalOcean 无服务器推理上线。它通过
inference.do-ai.run/v1/chat/completions上的 OpenAI 兼容端点提供。
认识 Kimi K2.6
在我们深入探讨为什么你的成本模型即将崩溃之前，有必要先了解一下是哪个具体的模型造成了这种局面。
Kimi K2.6 是月之暗面最新的旗舰模型，专为那种聊天时代模型从未被要求做的那种长周期、自主性工作而构建。有几个规格参数对接下来的经济性讨论很重要：
- 一万亿总参数，320 亿活跃参数。一种稀疏的混合专家架构，意味着以同类稠密模型几分之一的推理成本，提供前沿级别的推理能力。
- 256K token 上下文窗口。足够宽，可以一次性摄入整个代码库或文档集：这也意味着单次调用可能比典型的聊天回合要“重”得多。
- 最先进的编码性能。在 SWE-Bench Pro 上超越了主要的前沿模型，尤其在 Rust、Go 和 Python 上表现强劲。
- 原生多模态。通过 MoonViT 编码器 在同一架构中处理文本、图像和 UI 布局。
- 基于修改后的 MIT 许可证的开源权重。可移植、可审计，目前在 DigitalOcean 的基础设施上全托管运行。
以下是它在通用智能体、编码和视觉任务方面，于独立基准测试中的表现：
上图是一个柱状图，将 Kimi K2.6 与 GPT-5.4、Claude Opus 4.6 和 Gemini 3.1 Pro 在十个智能体基准测试中进行了比较，分为三类：通用智能体（Humanity’s Last Exam, BrowseComp, DeepSearchQA, Toolathlon, OSWorld-Verified），编码（Terminal-Bench 2.0, SWE-Bench Pro, SWE-Multilingual），以及视觉智能体（MathVision, V）。Kimi K2.6 在 SWE-Bench Pro (58.6%)、DeepSearchQA (92.5%)、BrowseComp (83.2%) 和带有工具的 Humanity’s Last Exam (54.0%) 上领先，同时在其余基准测试中保持竞争力。* （上述资料来源与Kimi官网）
简而言之：Kimi K2.6 不是那种你从表单字段调用的聊天机器人，它是一个被构建为长周期智能体内部引擎的模型——你的编排层在处理多步骤任务时，会一次又一次地调用它。这种转变——从每次意图一次调用，到每次意图多次调用——正是余下这篇文章存在的全部原因。
旧的思维模型（以及它为何曾站得住脚）
大约有两年时间，AI 成本预测是一个电子表格问题。
你选一个模型，查一下它的每 token 费率，估算一个请求平均消耗多少 token：几百个输入，几百个输出，如果你的用户比较健谈，也许一千个。然后乘以你预期的请求量，加上增长余量，把数字交给财务。他们问一两个澄清问题，然后签字。
这个方法之所以有效，是因为每个请求的形状大致相同。用户输入一些内容，模型响应，交互结束。token 数量会有变化，但变化幅度有限，因为整个系统的限制因素是人类决定接下来要输入什么。人们每分钟只能问那么多问题，他们会累，会去吃午饭。使用的自然上限就是人类注意力的自然上限。
这使得成本单位（token）和工作单位（请求）能够清晰地对应起来。一次请求，一个有限的 token 数量，一个可预测的账单项目。你可以在此基础上构建仪表盘，可以针对它给功能定价，也可以向 CFO 承诺一个数字并实现它。
这个思维模型之所以成立，是因为它所描述的工作负载从根本上讲是聊天工作负载。而对于聊天，按 token 定价不仅合理，而且优雅。麻烦在于，聊天已不再是我们大多数人部署的工作负载了。
长周期智能体工作流带来了哪些变化
“一个面向用户的‘任务’变成了推理支出的概率分布，而不是一个数字。”
一个长周期智能体不会只发一次请求，它会进行一个循环。
其形态如今已很熟悉：智能体制定计划，调用工具，读取结果，推理下一步做什么，然后再次循环。循环中的每一次遍历都是一次独立的推理调用，一次到模型的完整往返，并且整个累积的上下文都一同被携带。一个在用户看来只是一次请求的任务，在底层可能是十次、二十次或五十次调用。
当你从聊天转向这种循环时，三件事会同时出问题。
每个任务的调用次数不再是固定的。一个聊天回合是一次调用。一个 ReAct 循环会一直运行，直到智能体决定任务完成：简单任务可能三次迭代就结束，困难任务可能需要三十次。你事先不知道，智能体自己也不知道。
随着任务的推进，每次调用都会变得更重。每一个工具结果、每一个中间计划、每一个观察，都会被折叠回下一次迭代的上下文中。到第十五步时，你发送的已经不是 500 token 的提示，而是一段 40000 token 的对话历史。在像 Kimi K2.6 这样拥有 256K 上下文的模型上，这个上限足够高，以至于“上下文膨胀”不再只是理论上的担忧，而开始成为一个账单项目。
扇出是非确定性的。同一个任务运行两次，会得到两张不同的 token 账单。智能体解决问题的路径取决于工具返回了什么、模型决定调查什么，以及它是否自我怀疑。这里的差异不是 bug，而是关键所在。一个总是走同一条路径的智能体，算不上一个真正的智能体。
将这三个因素相乘，一个面向用户的“任务”就变成了推理支出的一个概率分布，而不是一个数字。这就带来了问题，因为大多数团队正在使用的预算工具是为处理数字而构建的，而不是分布。
上图展示了一个示意性的智能体成本分布：同一个长周期任务进行了 1000 次模拟运行，大多数运行成本较低，聚集在 0.40 美元的中位数附近，而一个长长的右尾则延伸到 30 美元以上。中位数是你在会议上会引用的数字。平均值，被右尾向右拉动，落在 4.13 美元，已经高了一个数量级。而 P95，即你实际需要为之做资源规划的数字，是 14 美元：大约是中位数的 35 倍，这也是当流量激增时，你的财务团队会在账单上看到的项目。同一个提示产生了所有这些结果。智能体在每次运行中自行决定了这项任务值得做多少工作。
为什么按 token 做预算会悄然失效
一旦一个任务变成一个分布而非一个数字，三件事会同时出错，而且是悄然出错的，这更糟糕。方差变成了首要指标。同一个提示在周二下午花费 0.40 美元，到周三早上可能花费 14 美元，因为智能体在解决问题时走了一条更长的路径。中位数看起来不错，平均值感觉可以忍受。但当流量激增时，真正体现在发票上的是 P95，而几乎没有人会针对它进行预测。
你无法给不可限定范围的东西定价。如果一个功能的底层成本横跨 30 倍的波动范围，你就无法给它设定一个固定价格，要么在昂贵任务上赔掉利润，要么在廉价任务上向客户多收钱。基于用量的定价只是把问题踢到了后面。你的客户现在有了和你一样的预测问题，而他们把这个问题交给你，对你的信任就减少了。
团队会出于防御而进行限制，导致能力流失。当工程师无法预测一项任务的成本时，理性的反应就是加以钳制：降低最大迭代次数，收紧上下文限制，设置五分钟的硬性超时。智能体变得更蠢，产品变得更糟。你购买前沿模型所看重的那个能力——长周期部分——恰恰是你现在不敢让它去用的部分。
失败模式很少是单一的一张令人震惊的发票。它是一种缓慢的偏离：预测悄然不再与现实匹配，功能悄然变得不那么有雄心，工程团队悄然对现有成本模型失去信任。这些都不是以火灾的形式出现，而是以天花板的形式出现。
解决之道不是找到一个更便宜的模型或更好的折扣，而是改变你用来做预算的单位。
单位的转变：从每 token 价格到每完成任务的成本
如果工作的单位不再是一次请求，那么成本的单位就不能再是一个 token。
解决方法是按照工作负载的真实行为来做预算。用户付钱不是让你去调用一个模型，他们付钱是让你去完成一项任务：重构仓库、草拟简报、核对账目。这才是对他们来说重要的单位，也应该是对你来说重要的单位。其余一切都只是实现细节。
三个转变能让这一点具备可操作性。
定义任务边界，而非 token 预算。在智能体运行之前，决定好“完成”是什么样子，以及“太远”是什么样子。最大迭代次数，挂钟时间上限，以及一个触发优雅退出而非失控循环的硬性 token 上限。这个边界不是限制智能体“能”做什么，而是限制它在必须回来汇报之前“被允许”做什么。这就是预算和紧急按钮之间的区别。
按边界做预算，而不是按调用。一旦定义了边界，你的单位成本就是该边界内的最坏情况支出，而不是单次推理调用的平均支出。这才是你用来做预测的数字。它比你旧的每次调用估算要高，这没问题。同时，它也显著地更加稳定，因为边界是你可控的。你用“较低但不稳定”的数字换来了一个“较高但可预测”的数字，而这正是财务团队真正想要的权衡。
将部分失败视为一个账单项目，而非例外。有些任务不会完成。智能体会触及边界、转错弯，或者卡住。按 token 预算往往会隐藏这些成本，因为推理已经发生且已被计费。而按完成任务成本计价，迫使你诚实地将它们计入成本：每一次失败的运行都是只产生支出而没有产出的结果，这个比率是你应该追踪的真实数字，而不是一个你应该去优化回避的难堪。
这个转变听起来很小，但它具有承重意义。一旦你的成本单位变成完成的任务，你的预测就会变得稳定，你的定价就站得住脚，你的工程师就再也不必为了保护那个一开始就量错了东西的预算，而把智能体限制到平庸的水平。
以上就是重新定义框架。下一节将把它转化四个你可以真正放在仪表盘上的数字。
一个实用的预算框架（每位 CTO 都应追踪的四个数字）
这个边界的重新定义，只有在你产生出一组可以真正摆在团队面前的指标时才是有用的。有四个指标能完成大部分工作。
1、预期任务成本（中位数）。你真实世界任务支出的中点：一半的运行成本更低，一半更高。当有人问“运行一个智能体需要多少钱？”时，这是你在内部引用的数字。这不是你用来做预测的数字。中位数支出是一个有用的参考值；但仅凭它自己，是个陷阱，因为它隐藏了最终会出现在发票上的昂贵运行的长尾。
2、P95 任务成本（规划数字）。95% 的运行成本都处于或低于这个数值。这是你实际用来做预算的数字，因为它是你的基础设施在正常繁忙的一天中必须承受的成本形态。一个健康的 P95 与中位数比率大约在 2-3 倍。如果你看到 10 倍或更高，你的边界太松，或者你的智能体探索的比执行的多。两者都是可修复的，但前提是你在进行度量。
3、每次成功结果的成本。总推理支出除以实际完成并产生可用结果的任务数量。这个指标能抓住那些失败的运行、被放弃的循环和静默超时——这些是发生了却没有产生价值的支出。如果这个数字比你的原始每任务成本高出很多，那说明你的智能体的失败次数比你想象的要多，并且你为此支付了全额费用。
4、余量比率。你当前的峰值并发任务量，除以你的供应商在触发限流或排队之前能承受的量。长周期智能体本质上是突发性的；“智能体响应敏捷”和“智能体感觉坏了”之间的差别，往往在于余量，而非原始容量。追踪这个指标，你就能在问题影响到用户之前几周，预见到容量问题。
将这四个数字放在一起，能告诉你一些按 token 计费的仪表盘永远做不到的事：不仅是你花了多少钱，还有你花得值不值。
大多数团队已经有了计算这四个指标所需的原始数据。通常缺少的，是将它们作为一个整体来看待的自律性：因为每个指标孤立来看都可能描绘出一幅美好的图景，而只有将它们结合起来才能揭示真相。
为什么 Kimi K2.6 是值得为此做预算的模型
一个预算框架只有在它所支撑的工作负载值得运行时才有意义。大多数智能体功能的失败，并非因为预算不对，而是因为底层模型实际上无法完成任务，最终你为产生不了任何结果的长循环支付了费用。
Kimi K2.6 在三个对长周期工作至关重要的维度上改变了这个局面。
推理能力不会随着步骤增加而退化。Kimi K2.6 在 SWE-Bench Pro 上取得了 58.6% 的分数，是所有开源权重模型中最高的，在目前使用的最困难的真实世界编码基准测试之一上，领先于 GPT-5.4 (57.7%) 和 Claude Opus 4.6 (53.4%)。在一个 20 步的重构任务中，每次额外迭代的边际成本只有在模型于第 18 步时仍能做出精准决策的情况下，才是值得的。这正是大多数模型会悄然失败的地方，而 SWE-Bench Pro 上的领先优势，是目前可获得的关于 Kimi K2.6 在长周期中保持质量的最强信号。
具备前沿能力的混合专家效率。一万亿总参数，320 亿活跃参数。在实践中，这意味着你正在以更接近 300 亿稠密模型的推理经济性，获得可与 10-20 倍于其活跃参数规模的前沿稠密模型相竞争的推理质量。对于上一节提到的每次成功结果成本指标，这个比率正是让计算能够成立的关键。
一个物有所值的 256K 上下文窗口。对于聊天工作负载，256K 是杀鸡用牛刀。对于一个在三十次迭代中不断积累工具结果、文件内容和中间计划的长周期智能体来说，这就是完成任务和因超时而失败之间的区别。这里的上下文大小不是一个营销数字，而是工作负载本身的一个结构性使能因素。
再加上原生多模态（通过 MoonViT，在同一架构中处理文本、图像和 UI 布局）以及基于修改后 MIT 许可证的开源权重，你所拥有的是一个规格参数与本文所描述的工作负载形态相匹配的模型。预算框架是纪律，而 Kimi K2.6 则是让这种纪律值得践行的理由。
为什么无服务器推理适合这种支出模式
一旦你开始按任务边界而不是 token 数量做预算，那么你在哪里运行推理，就变成了一个关于方差的问题。
长周期智能体的调用量不是平滑的。一个用户启动一个任务；智能体在两分钟内进行三十次推理调用；然后一个小时内毫无动静；接着因为三个客户同时开早会，六个任务同时触发。这不是一条你可以优雅地进行容量规划的工作负载曲线。它是突发性的、多尖峰的，并且根本不在乎你的容量规划电子表格。
你有两个选项来消化这种形态。
你可以为峰值进行预留。为你最糟糕那天最糟糕那小时搭建自己的 GPU 集群，承受它大部分时间闲置的成本，并接受“大部分时间闲置”是“永不受限”的代价。这在规模上是有理由的，但盈亏平衡点一直在变。而且，要保持 INT4 量化、批处理和冷启动行为的调优，所需的工程时间也不是免费的。
或者，你可以让其他人来承担这个方差。无服务器推理就是为这种支出形态而构建的：容量可以随你的任务量在两个方向上伸缩，而供应、量化和调优都由那个本职工作就是做这个的团队处理。突发流量由他们来消解，闲置时长不计费。你的方差存在于它唯一应该存在的地方：在你任务边界的计算中，在这里你才能真正对它做些什么。
还有第二个更安静的优势，它比看起来更重要。当推理只是你同一张发票上的一个账单项目，与你的 Droplet、数据库 和 Kubernetes 集群并列时，上一节中的预算框架才是真正可操作的。你不需要对照一个单独的 AI 供应商的计费门户来核对云支出；你是在一个地方，看一个数字，对应一个预测。对于一位试图向 CFO 捍卫某个智能体功能的单元经济性的 CTO 来说，这种整合不是便利，而是一个可信的预测和一个含糊其辞之间的区别。
（其实还有第三个选项：使用一个独立的推理 API，供应商的业务只围绕模型。那也行得通，但你会被留下一张单独的发票、一个单独的仪表盘和一个单独的采购关系需要处理：这正是上述预算框架被设计来消除的那种开销。）
适合某个工作负载的基础设施，不仅仅要匹配它的平均形态，还要匹配它的方差。
DigitalOcean 无服务器推理上的 K2.6：一个具体示例
到目前为止，这篇文章都还挺抽象的。让我们把它变具体。
论点可以归结为两部分：模型创造了调用量，而基础设施必须承接它。DigitalOcean 无服务器推理上的 Kimi K2.6 模型，是当前生产环境中这种配对比较清晰的例子之一。
基础设施为这个等式带来了什么。无服务器推理就是为我们一直在描述的那种支出形态而构建的：突发性、不可预测，任务之间有安静的间隔，如果换成自托管集群，这段时间就会闲置着并向你收费。H100 的供应、量化、冷启动工程：这些全都不在你的团队需要操心的范围内。你的方差存在于你的任务边界计算中，而非你的运维轮值表中。
实践中是什么样子。端点是兼容 OpenAI 的，所以集成就是你现有工具已经做的那些事情：
curl -X POST 'https://inference.do-ai.run/v1/chat/completions' \
-H "Authorization: Bearer $MODEL_ACCESS_KEY" \
-H 'Content-Type: application/json' \
-d '{
"model": "kimi-k2.6",
"messages": [
{
"role": "user",
"content": "分析这个仓库并建议一个微服务迁移计划。"
}
]
}'
这就是完整的集成界面。在无服务器推理控制台中找到你的访问密钥，你就从现有项目里调用着一个前沿模型，使用量会汇总到你同一张发票上，与你的 Droplet、托管数据库和 Kubernetes 集群一样。
目前在 DigitalOcean 无服务器推理上可用：
- Kimi K2.6，通过
inference.do-ai.run/v1/chat/completions上的 OpenAI 兼容端点提供 - 每次调用 256K 上下文，无需单独供应
- 使用量计入你现有的 DigitalOcean 账户
- 可与 LangGraph、LlamaIndex、OpenAI SDK 或任何能使用 OpenAI API 的编排层配合使用
你的编排层插在哪里。这里值得明确一点：上面的端点只负责提供模型。长周期智能体——也就是 ReAct 循环、规划步骤、工具调用调度器、重试逻辑——这些存在于你的代码中，或者存在于你在其上运行的框架里，比如 LangGraph 或 LlamaIndex。把端点 URL 放进你偏好的任何编排层，你就拥有了我们一直在做预算的完整设置：一个按需的前沿模型，一个由你控制的编排层，以及一个你定义好的任务边界。
这个组合对于经济性讨论之所以有趣，并非因为它有多神奇，而是因为分层足够清晰。模型是一个账单项目，一张发票，一个密钥。你的编排是你自己的代码，待在它本该在的地方。而本文前面给出的预算框架，能够清晰地应用于这两者之上，因为在它们之间没有任何隐藏的东西。
而这，说到底，正是你想从基础设施那里得到的东西：一个方差由你管理，而枯燥的部分不归你管的地方。
结语：为边界做预算，交付智能体
按 token 思维是 2023 年的习惯。工作负载已经向前发展了，预算模型也需要随之发展。为边界做预算，追踪那四个数字，你的智能体就会从成本风险变为一个效能倍增器。
将这个框架投入实践的最快方式，就是把它指向一个值得为此运行的模型。Kimi K2.6 现在已经在 DigitalOcean 无服务器推理上线——前沿智能，OpenAI 兼容端点，你这边无需任何运维，与你的 DigitalOcean 技术栈其他部分合并计费。
开始在无服务器推理上使用 Kimi K2.6 进行构建 →
生成一个密钥，把端点放进你的编排层，然后交付你一直在为之做预算的那个智能体。
常见问题
什么是 Kimi K2.6？
Kimi K2.6 是月之暗面于 2026 年 4 月发布的旗舰级开源权重语言模型。它是一个一万亿参数的混合专家模型，拥有 3200 亿活跃参数、256K 上下文窗口，以及最先进的编码性能：在 SWE-Bench Pro 上取得 58.6% 的分数。
如何在 DigitalOcean 上使用 Kimi K2.6？
Kimi K2.6 通过 DigitalOcean 无服务器推理在 inference.do-ai.run/v1/chat/completions 上提供。该端点兼容 OpenAI。你需要从无服务器推理控制台获取一个模型访问密钥。
DigitalOcean 无服务器推理上 Kimi K2.6 的定价模式是什么？
使用量与你现有的 DigitalOcean 资源（Droplet、Kubernetes、托管数据库等）合并计费，而非作为单独的供应商发票。有关当前的每 token 定价，请参见卓普云官网的无服务器推理模型计费表。
Kimi K2.6 与 GPT-5.4 和 Claude Opus 4.6 相比如何？
在 SWE-Bench Pro 上，Kimi K2.6 取得 58.6% 的分数，领先于 GPT-5.4 的 57.7% 和 Claude Opus 4.6 的 53.4%。它是该基准测试上得分最高的开源权重模型。
什么是“任务边界”预算？
| 预算单位 | 适用于聊天？ | 适用于智能体？ | 原因 |
|---|---|---|---|
| 每 token 估算 | 是 | 较弱 | 忽略了循环次数和方差 |
| 每请求估算 | 是 | 否 | 一个用户任务可能触发多次调用 |
| 每完成任务边界 | 是 | 是 | 能捕捉中位数、P95、失败和上限 |
任务边界预算将基于 token 的成本预测，替换为基于每次完成任务的预算——为每次智能体运行定义最大迭代次数、挂钟时间和 token 上限，然后针对该边界内的最坏情况支出进行预测，而非针对单次调用成本。
为什么智能体 AI 比聊天成本更高？
智能体 AI 通常比聊天成本更高，因为一个面向用户的任务会在幕后触发许多模型调用。一个聊天请求通常是一次提示和一次响应；而一个长周期智能体可能会进行规划、调用工具、检查结果、修改计划、再调用更多工具，并重复这个循环几十次。
随着上下文的增长，每个循环也可能变得更贵。工具输出、中间推理、文件内容和先前的观察都可能被带入后续调用中，因此智能体不仅仅是在发出更多的请求，在任务推进过程中，它往往是在发出更“重”的请求。这就将一个“任务”变成了一个可能花费的成本分布，而不是一个可预测的每次请求账单。
什么是 P95 任务成本？
P95 任务成本是指 95% 的智能体运行成本都处于或低于这个成本水平。例如，如果你的 P95 任务成本是 14 美元，意味着 95% 的已完成运行成本为 14 美元或更少，而最贵的 5% 成本更高。
对于长周期智能体，P95 通常比平均值或中位数更有用，因为它展示了在正常的高方差使用中你需要为之做规划的是什么。这是帮助团队避免被昂贵但属于预期的智能体运行所惊到的预算数字。
为什么中位数 AI 任务成本有误导性？
中位数任务成本有误导性，因为它隐藏了长尾。如果大多数运行都很便宜，即使有相当一部分运行成本要昂贵得多，中位数看起来也会令人安心。
在本文的例子中，中位数运行成本为 0.40 美元，但 P95 运行成本为 14 美元——大约是前者的 35 倍。如果团队围绕中位数做预算，在生产环境中运行智能体时，尤其是在流量激增或任务变得更复杂时，可能会严重低估真实成本。
CTO 应该如何为长周期 AI 智能体做预算？
CTO 应该以任务级别为长周期智能体做预算，而非单独的 token 或 API 调用级别。核心单位应该是完成的任务：仓库重构、支持调查、财务对账、研究简报，或是智能体预期要交付的任何结果。
一个实用的预算框架应追踪四个数字：任务成本中位数、P95 任务成本、每次成功结果的成本，以及余量比率。团队还应该在智能体运行之前定义任务边界，包括最大迭代次数、挂钟时间限制、token 上限以及优雅退出行为。这为财务和工程提供了一个共同的方式来预测成本，而无需对智能体施加过于激进的限制，导致其丧失能力。
我应该在什么时候使用无服务器推理，而非专用 GPU？
当你的智能体工作负载是突发性的、不可预测的，或者在全天内分布不均时，无服务器推理非常适合。长周期智能体可能在短时间内发出许多调用，然后闲置，然后在多个用户同时启动任务时再次激增。这种形态很难用专用 GPU 高效地进行预留，除非你有足够稳定的量来保持硬件忙碌。
专用 GPU 在持续的规模化下是有意义的，尤其当你可以保持高利用率，并且有团队能管理供应、量化、批处理、冷启动和容量规划时。无服务器推理通常在你想要吸收可变需求，而又不想自己运维 GPU 基础设施时，是更好的选择。
DigitalOcean 无服务器推理是否支持 OpenAI 兼容 API？
是的。本文描述了 DigitalOcean 无服务器推理上的 Kimi K2.6，可通过一个 OpenAI 兼容的端点访问：
https://inference.do-ai.run/v1/chat/completions
这意味着团队可以使用现有的 OpenAI 兼容工具、SDK 模式以及编排框架，如 LangGraph 或 LlamaIndex，同时通过 DigitalOcean 无服务器推理运行模型。
