Uber 的 AI 使用量增 9.4 倍，為何帳單沒有同步飆升？

Uber 的 AI 支出一度超出 2026 年預算，但公司的應對方式並不是簡單限制員工使用。相反地，Uber 把 AI 視為一項工程成本最佳化問題：讓不同工作負載使用合適的模型、避免上下文無限制膨脹、重用已快取的提示內容，並讓工程師直接看到每次工作階段的成本。1

這套做法讓 Uber 自 4 月起維持大致穩定的 AI 總支出；同期每週 AI 代理請求量較 2 月增加 9.4 倍。以相同 AI 模型計算，每 1,000 次請求的成本較 4 月高峰下降近 34%，單次工作階段成本則較 6 月高點下降 52%。1

AI 使用量沒有放慢，反而持續增加

成本改善並不是因為員工減少使用 AI。Uber 的 AI 代理目前已負責超過 70% 的程式碼變更提交，工程師每天執行超過 30,000 個代理任務，使用 AI 工具的員工人數也增加至四倍以上。1

「使用量大幅增加、支出大致持平」代表每項工作的單位成本下降。這不表示 AI 工作負載變成免費，而是 Uber 改變了 Token 與模型算力的使用方式。

1. 依工作類型分配合適模型

Uber 不再預設所有任務都使用能力最強、價格最高的模型，而是根據工作需求，把任務分配給成本與能力較匹配的模型。較簡單的工作可交由低成本模型處理，複雜任務才使用更高的模型能力；公司也在評估包括開放權重模型在內的替代方案，應用於特定場景。1

這讓模型選擇從「一套設定套用全部」變成工作負載決策。對大型工程團隊而言，即使每次例行請求只節省少量成本，累積後也可能顯著降低平均每項任務的費用。

2. 限制長時間代理工作階段的上下文

即使模型支援最高 100 萬個 Token 的上下文視窗，Uber 仍將互動式工作階段上限設為 400,000 個 Token。1

這項限制針對的是程式碼代理常見的成本風險：一個工作階段可能不斷累積檔案、工具結果、指令與重複的互動紀錄。如果沒有邊界，探索性操作或控制不佳的工作階段就可能持續處理越來越龐大的上下文。

設定 Token 上限並不等於停止使用代理，而是為最消耗上下文的工作階段設下一個可預測的成本上限，也讓工程團隊多了一個管理用量的控制點。

3. 將提示快取有效期延長至一小時

Uber 將提示快取（prompt cache）的有效時間從 5 分鐘延長至 1 小時，以配合工程師的實際工作節奏：AI 工作階段可能閒置超過 5 分鐘，之後才繼續工作。1

延長快取時間能避免系統反覆處理相同上下文。對代理式程式碼工作流程而言，同一個程式碼儲存庫或同一組指令可能在一個工作階段中多次被引用，重用快取就能減少不必要的 Token 處理，而不必改變任務本身。

4. 讓工程師即時看見運行成本

Uber 在工程師的終端機中提供 AI 工作階段的即時成本資訊。1

這把使用量轉化為即時的工程回饋。工程師不必等到財務報告出爐，才發現某個工作流程成本過高；在進行實驗時，他們就能看到支出，並視需要調整工作階段、模型或上下文。

更重要的是，成本意識被放進真正做決策的產品流程中。提示內容、重試次數、上下文大小與模型選擇，都是在這個工作流程裡發生，而不是在事後的預算檢討中才被發現。

Uber 的做法對企業 AI 有何啟示？

Uber 的經驗顯示，控制企業 AI 支出不只是編列預算的問題，同時也是系統設計問題。

這個案例中最值得注意的控制措施包括：

• 依工作負載進行模型路由： 在能力足夠的前提下，讓較簡單的工作使用成本較低的模型。
• 上下文治理： 為可能累積大量 Token 歷史的工作階段設定限制。
• 提示快取： 重用重複出現的上下文，避免每次都從頭處理。
• 單位成本監測： 讓執行 AI 工作流程的人看見每次操作的邊際成本。
• 維持模型競爭： 評估包括開放權重模型在內的替代方案，而不是讓所有任務依賴單一預設模型。1

這些措施對 AI 代理尤其重要，因為代理式工作通常是反覆進行的。一個使用者請求可能觸發多輪規劃、工具呼叫、結果驗證與修改，Token 總消耗因此比一次性的聊天互動更難預測。

因此，Uber 的成果應被視為營運效率案例，而不是「AI 使用量快速成長也不會帶來財務風險」的證明。Uber 能讓支出大致穩定，是因為它重新設計了每次請求與每個工作階段的成本結構。

對其他企業而言，重點相當直接：AI 採用與成本治理應同步擴張，而且從一開始就要把用量與成本衡量功能整合進工具本身。只有如此，企業才有機會在擴大 AI 代理規模的同時，避免 Token 消耗失去控制。