隨著 AI Coding 工具大幅加速軟體開發的效率，企業的帳單也以驚人的速度膨脹中，甚至可能抵銷 AI 帶來的效率紅利。這也讓企業面臨兩難，一方面希望盡可能讓員工使用更強大的 AI 工具，另一方面又必須讓整體 AI 支出維持在可預測、可控制範圍內。
根據估值千億美元的數據與 AI 獨角獸 Databricks 近期發布的文章〈Managing AI Coding Costs at Scale〉（大規模部署下的 AI Coding 成本控管指南），Databricks 從自身經驗以及與 Stripe、Coinbase、Uber、Ramp 等企業的交流中，整理出一套 AI 成本管理方法。
雖然文中不免帶有 Databricks 自身的品牌溝通訴求，但其中仍有不少實用洞見。《創業小聚》從中整理 4 個 Token 最佳化與成本管理的核心策略。
策略一：不要只追求最強模型，而要找到「效率前沿」
談到 AI 模型，許多企業習慣追逐能力最強、智慧程度最高的模型。
但對大規模採用 AI Coding 的企業而言，真正重要的不是「最聰明」，而是在符合工作需求的前提下，哪個模型最划算。
Databricks 將這樣的概念稱為「Efficiency Frontier」，也就是在特定智慧程度下，能提供最佳價格效益的模型。
一些日常維運的工作，未必需要最頂尖的推理能力，例如修改變數名稱、尋找程式碼中的錯誤等任務。如果較便宜的模型已經能達到足夠好的品質，就應該把工作交給它。
Databricks 指出，新模型幾乎每週都在推出，而新模型帶來的不只是更高的智慧，也可能以更低的價格提供相近甚至更好的能力。因此，企業如果能快速評估、測試新模型，並依需求切換到更具成本效益的選擇，就能有效降低 AI 的支出。
而 Databricks 也提到，企業不能只依賴公開標準來判斷一個模型好不好，因為公開測試未必能反映企業實際的日常工作。更有效的方法，應該是要建立符合自身開發情境的自動化評測機制，定期比較新舊模型的實際表現與成本。
但另一個問題來了：既然模型一直更新，企業要怎麼快速切換？
策略二：不要讓開發工具，綁死模型的選擇
許多公司會使用 AI Coding Agent，這些 Agent 由「模型」與「執行框架」構成。通常模型和執行的框架之間會有整合，所以替換模型並不是在後台按一下按鈕這麽簡單。
簡單來說，「執行框架」可以理解為包裝、管理 AI Coding Agent 工作流程的工具，例如 Claude Code、Codex 或 Cursor。
企業如果希望更換模型，最直接的方法是要求開發者切換工具。但這種做法也會帶來很高的「切換成本」，開發者已經熟悉某一套工具，突然要求換另一套，不只影響使用體驗，也可能降低生產力。
因此，一種名為「Meta-Harness」的新框架因應而生，而由 Databricks 開源的 Omnigent 就是其中一種選擇。
Meta-Harness 讓開發者不需要直接面對底層不同的執行框架，而是在上層提供一套共同的操作介面，再根據需求將任務分派給不同的模型與工具。
這樣一來，企業就可以在不改變開發者使用習慣的情況下，持續調整底層模型，降低被單一模型或工具綁定的風險。
策略三：與其自己切換，不如讓 AI 選擇該用什麼模型
除了讓開發者可以自由切換模型，更有效率的做法也許是讓 AI 自己決定該用哪個模型。
目前業界主要有 3 種模式：
第一種，在開發者與底層模型之間加入一層「Proxy」(代理）。系統會針對每一次收到的指令（如：簡單的程式碼抓漏、摘要文件，或複雜的邏輯推理），判斷哪一個模型最適合處理，並參考市場上的即時性價比排名，使用「能完成任務且成本最低」的模型。
目前市場上已經出現多種採用這類模式的產品，包括 Databricks 自家的 Unity AI Gateway Smart Router、OpenRouter 的 AutoRouter、Ramp Router，以及 Cursor Router。
從 Databricks 的內部測試來看，Unity AI Gateway 的 Smart Router 能夠在維持與工作模型中最昂貴模型相近品質的同時，將平均任務成本降低超過 30%。而 Cursor 甚至提供「智慧、平衡、成本」三種模式，讓開發者有更多選擇。
第二種，使用任務層級判斷。與第一種只判斷「單次請求」不同，任務層級路由會從整個任務的角度出發，先分析一項工作的複雜程度，再決定應該交由哪一個執行框架與模型處理。
例如，「將元件名稱從 X 改成 Y」屬於相對簡單的結構化任務，可以交給較輕量的模型；但如果是「研究如何降低系統延遲」這類開放式問題，則可能需要能力更強的模型。
這類模式通常由 Meta-Harness 負責分派任務，其優勢在於企業不需要讓開發者自行判斷每項任務該使用哪一個模型，而是由系統在背後完成分流，同時降低開發者切換工具的成本。
第三種，是升級與委派模式（Escalation／Delegation Patterns）。
這種模式則是讓不同能力、不同成本的模型在同一個工作流程中協作，而不是從頭到尾都使用同一個模型。
其中「升級模式」代表的是由成本較低的模型負責主要工作，當它判斷任務需要更強的推理能力時，再將特定部分升級給高階模型。
例如 Claude 的 Advisor Tool，就是讓較便宜的模型在主要流程中工作，必要時再請更強大的模型提供協助。
另一種「委派模式」則是由高成本、高能力的模型負責主要決策與規劃，再將部分工作委派給成本較低的模型。
例如 Cognition 的 Devin Fusion，就是由尖端模型擔任主控（Main Agent），負責核心判斷與規劃，而將機械性的執行工作委派給低成本的「側翼模型」（sidekick）。
Devin Fusion 的測試顯示了，這種混合模式能在維持優良效能的同時，降低 35% 到 60% 的平均任務成本。
而這也說明，企業管理 AI 成本的重點，未必是限制員工使用 AI，而是讓每一項任務都用上「足夠好、但不必最貴」的模型。
策略四：AI 預算不能靠「超過額度就停用」，真正昂貴的是錯誤的使用方式
如果 AI 的使用量不斷增加，企業最直覺的想法可能是把每個員工設定一個月度預算，用完就不能再用。這或許也是台灣許多企業採用的方式。
但 Databricks 認為，這其實不是最好的方法。
原因之一是，真正高使用量的人，可能恰好是透過 AI 創造巨大生產力提升的員工。如果因為達到預算上限就直接切斷 AI 工具，反而會傷害企業最需要保護的生產力。
因此，比起硬性的預算上限，企業更適合建立一套漸進式管控的機制。
首先要讓成本透明化，提供即時的成本回饋，讓開發者了解個人用量，並清楚不同模型與工具間的費用差異。然後要有支出門檻的管控，設定分層警示機制，超出基礎門檻時發出提醒，額外高額支出則需經主管核准。
再來是讓模型降檔，當使用達到支出門檻後，系統自動將開發者切換至低成本模型，維持工作流不間斷，而非直接切斷存取。最後才是暫停權限，切斷其使用權限應視為極限情況下的最後手段。
而另一個容易被企業忽略的成本來源，是 Token 的額外開銷。
企業往往低估了 AI Agent 在背後產生的成本。當使用者輸入一句簡單的指令時，Agent 實際上會進行大量的程式碼搜尋、檔案讀取與工具調用，而累積大量的 Context（內容脈絡）。
為了應對 Context Bloat（內容膨脹）的問題，Databricks 也提出幾個優化方向，包括更頻繁地壓縮或整理 Context、使用 Token 效率更高的執行框架、降低工具輸出的冗長程度，以及將大型任務拆分成較小的工作單位。
此外，在處理大規模程式碼時，Prompt Caching（提示詞快取）也是降低成本的好工具。
雖然第一次將資料存進快取（Cache Writes）需要點費用，但之後每次重複讀取（Cached Reads）都能大幅省錢。企業只要依照實際需求彈性調整快取的保留時間，讓「快取命中率」（Cache Hit Rate）變高，整體 AI 費用就會明顯降低。
Databricks 表示，僅透過調整執行框架與快取設定，就能在不影響開發品質的前提下，讓每個對話階段（session）產生的 Token 數量降低近 50%。
AI Gateway 是企業接下來需要的新 AI 基礎建設？
當企業同時使用多個模型、AI Coding Agent 與開發工具後，上述問題其實會全部交織在一起。這也讓一種新的 AI 基礎建設開始浮現—— AI Gateway（AI 閘道器）。
Databricks 將 AI Gateway 定義為一個位於底層基礎模型與終端工具之間的集中管理層，用於統一掌控企業內部的 AI 資產。除了最基本的模型存取與流量代理（Proxy）外，也能進一步處理預算、權限、模型配置，以及 AI Coding Session 的紀錄與分析。
因此，從 Databricks 的經驗來看，AI Coding 成本快速增加並不是無法避免的結果，而是可以透過技術與管理層面的手段來解決的問題。
企業真正需要追求的，也不只是更強大的模型，而是整體的 AI 生產力以及成本效率。
（本文轉載自《創業小聚》）
