Lindy 如何在 Atlas Cloud 上將 AI 代理推論成本降低 90%

Lindy 打造了 AI 員工。它將整個產品線遷移到由 Atlas Cloud，推論成本降低了約 90%，而且產品品質完全沒有下滑。_

推論成本降低約 90% · 60% 的輸入 token 由快取提供 · 每分鐘持續 3,000+ 個請求 · 流量成長 10 倍以上，無需重建 · 一個金鑰使用來自 11 個實驗室的 24 個模型

Lindy 在生產環境中運行最嚴苛的 agent 工作負載之一，而它運行在 Atlas Cloud 上。 以下是這帶來的改變：

因為 Atlas 以快取費率計價重複呼叫， Lindy 得以運行會檢查自身工作而非猜測的 agent。它所發送的輸入 token 中，每十個有六個由快取提供，因此 agent 在每個任務中重讀十幾次的前綴幾乎不花錢。
因為 Atlas 會針對工作負載進行配置， Lindy 僅透過增加流量就讓業務量成長超過十倍，無需重建任何東西；Atlas 並能連續一小時維持每分鐘 3,000 個以上的請求。
因為 Atlas 以單一金鑰提供完整模型目錄， Lindy 可以在一個下午內換用新模型。它已透過單一整合運行過來自 11 個實驗室的 24 個模型。
因為 Atlas 以具名且通過 SOC 2 認證的合約提供服務， Lindy 可以將開放權重模型放在客戶資料前，並為實際運行者的身分背書。

90% 是 Lindy 的標題數字。這個數字之所以能維持，以及下一次遷移之所以會比這次更簡單，關鍵都在底層平台。

對 Lindy 而言，帳單就是生意

Lindy 打造 AI 員工。Lindy Teammate 加入公司的方式就像新員工一樣：它在 Slack 中接收請求、連接團隊已在使用的工具、參與會議，並持續累積所學，讓每一次新請求都能從比上一次更進一步的地方開始。沒有人需要撰寫自動化流程；他們只需交付任務，agent 就會完成工作。

這種設計決定了高昂的基礎設施帳單。一個 AI 員工要閱讀討論串、檢查行事曆、查詢記錄並草擬回覆，在任何人看到一個字之前就已經發出了十幾次模型呼叫；而且因為 Teammate 服務的是整個團隊，用量會隨著員工人數成長。在這種型態下，產品背後的模型價格決定了業務的存亡。

[公開] “Lindy 的定價只有在推論成本持續降低時才可行。”

— Bruno Škvorc，Lindy 資深軟體工程師

於是 Lindy 做了財務數學要求的事。它將大部分受管 agent 流量從 Claude、Sonnet 和 Gemini 遷移到運行在 Atlas Cloud 上的 DeepSeek v4 Flash，遷移路線上的推論成本下降了約 90%。更改模型名稱只花了一個下午。而能在生產規模下維持這個成果、且產品品質不變，正是他們選擇 Atlas Cloud 的原因。

為什麼 90% 能維持：第十一次呼叫幾乎免費

若按 token 計價，agent 在每個任務中要為相同的前綴支付十幾次全額費用，而且帳單會隨著它思考的細緻程度而增加。這種稅負正是讓 agent 產品停留在淺層的原因：只跑一遍而不是三遍，因為第三遍的成本和第一遍一樣高。這也解釋了為什麼單純更換模型所節省的成本會比帳面上少——重複的前綴會悄悄把帳單重新填滿。

[提案 — 由您決定] “Agent 工作負載會在多次模型呼叫之間重用大量上下文。Atlas 的快取讓我們不必每次為相同上下文支付全額費用，這是節省效果能在規模化後持續維持的重要原因。”

— Ian McGregor，Lindy 工程主管

在 Lindy 需要之前就已備好的容量

Agent 流量沒有夜晚的安靜時段，也沒有可以規劃的上線日。工作在團隊工作時湧入，不會在你擴展時停止。重要的不是緩衝能吸收的突發尖峰，而是供應商能支撐的持續速率。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 帶來了真正的營運彈性。

如果你在 Marketplace 上運行 agent，請遷移它們

Lindy 走過這條一模一樣的路。它最初在 OpenRouter 上認識 DeepSeek，在那裡用評測跑過模型，證明了它值得遷移。也在同一輪測試中，找到了決定正式環境要在哪裡運行的那個因素。

[公開] “我們也在不同的推論供應商上測試了同一個模型。令人懊惱的是，供應商真的有影響。同一個名義上的模型，會因為由誰提供服務而得到不同的分數。”

— Bruno Škvorc，Lindy 資深軟體工程師

Marketplace 的存在是為了幫你購物，不是為了運行你的產品。把正式流量送到路由器，它會流向任何有剩餘容量的供應商，因此你無法選擇誰來提供你的模型，也無法看到究竟是誰提供了服務。相同的權重在不同的機器上會回傳不同的數字——無論是因為量化，還是某家服務堆疊中的捷徑——而這些數字會先到達你的使用者，然後才到達你的儀表板。每一次路由器跳轉都在悄悄重新決定你客戶付費購買的產品品質。你無法除錯，因為你看不到是誰處理了那次呼叫；你無法修復，因為你無法完全控制路由。那是你的聲譽，卻由一枚你從未擲出的硬幣決定。

因此 Lindy 沒有在 OpenRouter 上運行正式環境。流量上線時，是透過與 Atlas 的直接合約進行的：單一服務堆疊，每個請求都相同，針對模型調校並受合約約束，具備即時 agent 工作負載所需的快取和容量，而且完整目錄都在同一個金鑰上。如果你的 agent 已上線且仍透過路由器運行，那麼你正在交付一個無法維持穩定的產品，而且你會在客戶發現之前渾然不覺。像 Lindy 一樣，遷移它們。

與我們討論你的工作負載 我們會告訴你它應該花多少錢，或 瀏覽模型目錄.

關於 Lindy

Lindy 打造 AI 員工。Lindy Teammate 於 2026 年 8 月推出，與人類團隊並肩工作：它在 Slack 中接收請求、連接公司已使用的工具、參與會議，並累積團隊上下文，讓每個請求都能從比上一次更進一步的地方開始。Lindy 不是要求人們建立和維護自動化，而是要求他們交付任務。Lindy 由 Flo Crivello 創立，總部位於舊金山。