Lindy 如何在 Atlas Cloud 上将 AI 智能体推理成本降低 90%

Lindy 构建了AI员工。它将整个AI员工队伍迁移到由 Atlas Cloud，将推理成本降低了约90%，而且没有交付更差的产品。_

~90%更低的推理成本 · 60%的输入token由缓存提供 · 持续每分钟3,000+请求 · 流量增长10倍以上，无需重新构建 · 一个密钥访问来自11个实验室的24个模型

Lindy在生产环境中运行着最具挑战性的智能体工作负载之一，而它运行在Atlas Cloud上。 以下是这一变化带来的影响：

因为Atlas以缓存费率对重复调用计费， Lindy运行的智能体会检查自己的工作而不是猜测。它发送的每十个输入token中有六个由缓存提供，因此智能体在单个任务中反复读取十几次的前缀几乎不花什么钱。
因为Atlas按工作负载进行资源调配， Lindy通过发送更多流量而非重新构建任何东西，实现了十倍以上的流量增长，而Atlas能够连续一小时保持每分钟3,000次以上的请求处理量。
因为Atlas用一个密钥承载整个目录， Lindy可以在一个下午内切换到新模型。它已通过单一集成运行过来自11个实验室的24个模型。
因为Atlas以具名的、经SOC 2认证的合约提供服务， Lindy可以用开放权重模型处理客户数据，并为运行方承担责任。

90%是Lindy的亮点。这个数字之所以能持续保持，而且下一次迁移会比这次更容易，原因在于底层的平台。

对Lindy而言，账单就是业务

Lindy构建AI员工。Lindy Teammate像新员工一样加入公司：它在Slack中接收请求，连接团队已经在使用的工具，参加会议，并保留学到的东西，使下一个请求比上一个更进一步。没有人编写自动化流程；他们进行委派，而智能体负责完成工作。

这种设计设定了一笔硬性的基础设施账单。一个AI员工在读取讨论串、查看日历、查找记录并起草回复的过程中，在任何人看到一个字之前就已经进行了十几次模型调用，而且由于Teammate服务整个团队，流量随员工人数增长。在这种形态下，产品背后模型的价格决定了业务的可行性。

[公开] "Lindy的定价只有在推理成本持续降低的情况下才能成立。"

— Bruno Škvorc，Lindy资深软件工程师

于是Lindy做了财务计算所要求的事情。它将大部分托管智能体流量从Claude、Sonnet和Gemini迁移到运行在Atlas Cloud上的DeepSeek v4 Flash，迁移路线上的推理成本下降了约90%。更换模型名称只花了一个下午。让这个改变在生产规模下持续生效、同时不使产品变差，这才是他们选择Atlas Cloud的原因。

为什么90%的成本节约能持续：第十一次调用几乎免费

按token计费时，智能体在每项任务中要为相同的前缀支付十几次全价，账单随着它思考的缜密程度而增长。这种税收正是让智能体产品流于浅层的原因：一次遍历而不是三次，因为第三次的成本和第一次一样高。这也是为什么简单的模型替换实际节省的钱比标价所暗示的少——重复的前缀会悄悄地把账单重新填满。

Atlas在最沉重的地方消除了这种税收。Lindy每十个输入token中有六个被识别而不是被重新处理， 以针对其实际流量签订的合约费率计费，因此每次智能体调用中占大头的前缀几乎免费。这就是为什么模型切换能变成持久的90%节省，而不是一个随着使用量上升而不断侵蚀的数字；这也是为什么在Atlas上的智能体可以运行三次遍历，而按token计费的同一智能体只能运行一次。

[建议稿 — 由您决定] "智能体工作负载在多次模型调用中会复用大量上下文。Atlas的缓存意味着我们不必每次都为此上下文支付全价，这是节省在规模化下得以保持的重要原因。."

— Ian McGregor，Lindy工程主管

在Lindy需要之前就已就位的容量

智能体流量没有安静的夜间窗口，也没有可以围绕规划的上线日。工作在团队工作期间到达，并且不会在你扩展时停止。重要的不是缓冲区能吸收的峰值，而是提供商能维持的速率。Lindy通过发送更多流量而非重新构建任何东西，实现了十倍以上的流量增长，而Atlas连续一小时保持每分钟3,000次以上的请求处理量。容量领先于工作负载，因此扩展是一个业务决策，从来不是基础设施项目。

支持：交付产品，而非工单

在这种规模下，提供商之间的区别与其说在于仪表盘，不如说在于当出现问题时有谁来响应。Lindy的工程师与Atlas的推理工程师共享一个沟通渠道，当天就能从能够采取行动的人那里得到回复。其中一些回复变成了产品改进：Lindy要求提供一种转移团队账户所有权的方式，Atlas当时并不支持，但它还是上线了，而且由Atlas的工程师亲自迁移了账户。

一个可以指名道姓的提供商

迁移到开放权重模型移除了过去负责解释模型运行方式的一方。实验室品牌过去能够解答的问题，现在指向了提供商：谁在提供这个服务，在什么管控之下，经过的数据会发生什么。Atlas以具名而非路由器的形式回答这些问题， 基于经SOC 2认证的合约，客户端数据既不会被存储也不会用于训练。这对AI员工来说比对聊天产品更重要，因为Teammate会读取其服务公司的Slack讨论串、日历和记录。基础设施问题直接位于客户信任问题之下，而Atlas同时回答了这两个问题。

没有锁定DeepSeek，也没有锁定任何东西

这次迁移让Lindy投入的是一个策略，而不是一个模型。DeepSeek v4 Flash在其接受测试的工作负载上胜出，只要它仍然是在质量达标前提下的最优价格，就会保持这个位置。下一个赢家将来自不同的实验室、采用不同的许可证，而且由于Atlas Cloud通过一个API提供对所有模型的访问，试用它只花一个下午而不是一个采购周期。在一天的测试中，Lindy仅凭已有的密钥，向来自七个实验室、覆盖三种模态的十二个此前从未用过的模型发送了47个请求。其中三个成为了生产工作负载。始终通过Atlas Cloud运行最佳模型的自由，赋予了Lindy真正的运营业务灵活性。

如果你在模型市场上运行智能体，请把它们迁移出来

Lindy走的正是这条路。它最初在OpenRouter上接触到DeepSeek，在那里用评估（evals）运行了模型，并证明了它值得迁移。在同样的测试中，它发现了决定生产环境去向的那个关键。

[公开] "我们还在不同的推理提供商上测试了同一个模型。令人烦恼的是，提供商确实很重要。同一个名义上的模型，根据谁来提供服务，得分可能不同。"

— Bruno Škvorc，Lindy资深软件工程师

模型市场的存在是为了方便你选购，而不是运行你的产品。将生产流量发送到路由器，它会被路由到任何有闲置容量的提供商那里，因此你无法选择谁来服务你的模型，也看不到是谁服务的。相同的权重在不同的机器上会返回不同的数字，原因可能是量化，也可能是某人服务栈中的捷径，而这些数字会在到达你的仪表盘之前先到达你的用户。每一次路由器跳转，都在悄悄重新掷骰你客户付费购买的产品质量。你无法调试它，因为你看不到是谁处理了调用。你无法修复它，因为你无法完全控制路由。那是你的声誉，由一个你永远没有机会掷的硬币决定。

因此Lindy没有在OpenRouter上运行生产环境。当流量上线时，它转向了与Atlas的直接合约：一个服务栈，每个请求都使用同一个，针对模型进行调优并受合约约束，具备活跃智能体工作负载所需的缓存和容量，以及同一个密钥下的完整目录。如果你的智能体已在生产中却仍然通过路由器运行，你就是在交付一个你无法保持稳定的产品，而且你只有在客户发现之后才会知道。像Lindy那样把它们迁移出来吧。

和我们聊聊你的工作负载 我们会告诉你它应该花多少钱，或者 浏览模型目录。

关于Lindy

Lindy构建AI员工。Lindy Teammate于2026年8月推出，与人类团队并肩工作：它在Slack中接收请求，连接公司已经在使用的工具，参加会议，并积累团队上下文，使每个请求都比上一个更进一步。Lindy不是要求人们构建和维护自动化，而是要求他们进行委派。Lindy由Flo Crivello创立，总部位于旧金山。