---當開放權重的前沿模型遇上真實的 agentic 用量，企業算力的採購邏輯正在改變
最近一位做開發的朋友，把他的 AI 訂閱從每月 20 美元升級到 200 美元。成本漲了 10 倍，聽起來很誇張，但他算得很清楚：換來的產能，保守估計成長了 20 倍---每單位產出的成本其實砍半了。他不是捨得花錢，是精算過的划算。
這件事點出一個多數企業還沒意識到的落差：很多人對「AI 要花多少錢」的直覺，還停留在生成式 LLM 與 RAG 的年代---問一句、答一句，單次幾千個 token，一個月算下來也就一杯咖啡的錢。但真正把 AI agent 用進生產流程的人，面對的是完全不同的量級。
一個具體的參照：在真實的程式開發場景裡，用 agentic 工具修一個 bug，單一任務就可能燒掉 120 萬個 token---這是實測數字，不是估算，已經是過去「聊天式」用法的上百倍。當 AI 從「問答工具」變成「會自己讀檔、規劃、呼叫工具、反覆驗證的工作夥伴」，token 的消耗是階梯式跳升的。
這個落差，就是這篇文章要處理的核心：當你的 AI 用量即將(或已經)跳升一個數量級，雲端還是自建，答案可能和你的直覺不一樣。而 K3 的出現，讓「自建」這個選項第一次真正被擺上桌。我們就來把這筆帳算清楚。
先說一個反直覺的觀察：當 agentic 用量認真起來，雲端最先讓你撞上的，往往不是帳單，而是額度。
一位重度使用者分享，他用某個頂級模型做開發，實測十分鐘就燒完了五小時的使用額度，然後被迫停工。這不是被多收錢，是產能被直接掐斷。而這類情況並非個案：近期開發者社群裡，「額度焦慮」幾乎每天上演---有人手上還有一個中等難度的除錯任務想當晚完成，卻發現額度已滿、要等到凌晨兩點才恢復，週額度也只剩 6%，只能上社群問大家該不該把最後一次重置額度用掉。
更值得注意的是供給側的訊號：連頂級 AI 供應商都不得不頻繁地為付費用戶「重置使用額度」，好讓自家基礎設施「喘口氣」。當服務成長快過機房擴充，額度限制就成了供應商管理自身資源稀缺的手段---但供應商的資源問題，最後變成了你的停工。
還有一層更隱性的成本：最厲害的使用者，已經被迫把大量工程精力，花在「如何少燒 token 才不會撞牆」上，有人專門去研究 agent 的迴圈如何導致 token 一圈圈飆升、再自行開發工具壓低消耗。這些才華本該用在產出，現在卻耗在規避額度的內耗裡。
把這些現象串起來，結論很清楚：雲端 agentic 的瓶頸，已經從「貴不貴」轉移到「你的產能節奏，掌握在別人手裡」。而這件事，多付錢未必能解決---因為問題出在供給側的容量與政策，不在你的預算。
要理解 K3 的意義，得先破除一個省錢的迷思：搭配夠強的模型，對高生產力的 agent 使用者不是選項，是剛需。
原因在於，agentic 工作流是把模型的每一步決策，沿著幾十次工具呼叫複利放大的過程。模型差一點，不是慢一點，而是整個任務走歪---然後你要花更多時間 debug、更多來回、更多架構返工。這些下游成本，遠超過模型本身的價差。能用更強的模型就不用次一級的，不是奢侈，是精算過的效率。那些死盯訂閱費省小錢的，往往是還沒真正把 agent 用進生產流程的人。
這一點，我們用自己的地端部署踏踏實實驗證過(參考另一篇專欄文章：Hermes Agent 地端部署實戰 )。在一次地端 AI agent 的實作裡，我們先用一張消費級顯示卡搭配一個中小型的開源模型跑 agent---結果很快撞牆：模型只要遇到稍微複雜的任務就開始「鬼打牆」，反覆兜圈、給不出可用的結果。唯一有效的解法，就是換上更大的模型；但更大的模型，地端的硬體又塞不下。最後只能改接雲端的大模型 API 才讓 agent 真正可用。這個過程精確地暴露了問題的本質：agent 要能幹活，底層模型的能力是硬門檻；而過去，搆得上這個門檻的模型，幾乎只有雲端租得到。
於是企業陷入一個死局：你想要一個能真正幹活的 agent，就得把資料和工作流交給別人的雲。這不是「要不要自主」的選擇題，而是「要能力，就沒有自主」。
K3 打破的正是這個死局。第三方評測給了它明確定位：綜合能力指數排名第 4、與 Claude Opus 4.8 同級，在前端程式的人類盲測中甚至登上第 1。
綜合能力:AA Intelligence Index v4.1(K3 = 57,第 4 名)
人類偏好(前端單項):Arena Frontend Code(K3 第 1,Elo 1,679)
這是史上第一次，一個夠得上前沿第一梯隊的模型，可以下載、可以部署進自己機房。頂級能力與完全自主，第一次不再互斥。K3 的震撼不在於它開源，而在於它開源的同時還夠強---強到讓「自建」從堪用的備案，變成值得認真算帳的選項。
而且它的可行性，比多數人以為的更近。市場流傳一種說法：「自建 K3?那要六十幾張 H100 才跑得動，太不切實際。」這個算術其實沒有錯---錯的是拿 H100 來評估一個 2026 年的模型。關鍵不在精度，而在單卡的顯存密度：H100 每張 80GB，而最新 Blackwell 世代的 DGX B300 每張達 288GB，密度是前者的 3.6 倍。以同樣保守的 FP8 精度、約 30 並發的企業級負載試算，整套系統約需 4，400GB 顯存---放在 H100 上要 55 張卡、將近七台伺服器；換到 B300，16 張卡、兩台伺服器就夠了。
我這裡設計了一個「 GPU 算力量表」。只要輸入相關的參數，就可得到大致的算力推薦，同時也附上計算邏輯與公式的說明。如有需要可以下載回去填入參數取得推薦結果。
提示：因為是 Google 表單的關係，如果下載到本機電腦無法正常顯示公式結果，請找一個 Google Drive 空間上傳後再使用。
值得一提的是，上述試算刻意採用 FP8 這個保守口徑。K3 本身是以更低精度的量化感知訓練(MXFP4)產出的模型，而 Blackwell 原生支援 FP4 運算---等 7 月底官方權重與推論框架的支援到位，同樣的硬體還會有額外的餘裕。我們寧可用保守的數字報一個站得住的規模，也不拿尚未驗證的最佳情況去壓低報價。
能力到位了、可行性也到位了。剩下的，就是算帳。
我們選一個有代表性的標的：500 名 AI 使用者的企業。這個規模通常捨得投資，幾千萬到上億的算力預算不是障礙，真正在意的是這筆錢看不看得到回報。
用量假設(公開，方便你代入自己的數字)：其中約 160 位是真正跑 agentic 開發的工程師，每人每日約 5 個任務；其餘 340 位為中輕度使用者。全公司每日約 10.6 億 token，每年約 388 億。硬體端，依實際的顯存與吞吐量表推算，在約 30 並發(CCU)的尖峰負載下，兩台 DGX B300(16 張 GPU)可支撐這個規模。
雲端 K3 純租，三年成本：
agentic 編碼的每 token 成本落在很寬的區間---大量讀取程式碼(輸入為主)、快取命中率高時，單價可以壓很低；偏生成、偏輸出的任務則高上數倍。我們用每百萬 token 0.8 到 3.2 美元的區間，涵蓋兩種負載：
|
雲端單價假設 |
三年成本(萬 TWD) |
適用負載 |
|---|---|---|
|
樂觀 $0.8 |
約 2,930 |
高快取、輸入為主的編碼任務 |
|
中間 $2.0 |
約 7,326 |
混合負載 |
|
保守 $3.2 |
約 11,722 |
偏生成、輸出為主 |
自建 2 台 DGX B300，三年 TCO：
|
項目 |
金額(萬 TWD) |
|---|---|
|
DGX B300 × 2(含三年 AI Enterprise 授權與建置費) |
5,800 |
|
高速交換機(Compute & Data) |
300 |
|
電力與空調(約 5.46 萬/月 × 2 台 × 36 月) |
393 |
|
核心運算平台三年小計 |
約 6,493 |
|
企業儲存(300T，另述，見第五節) |
1,000 |
|
含儲存總計 |
約 7,493 |
這一次，帳翻過來了。以核心運算平台約 6,293 萬對比雲端三年：
|
對比(三年) |
結果 |
|---|---|
|
雲端 $0.8 vs 自建 6,493 萬 |
雲端省約 3,563 萬 |
|
雲端 $2.0 vs 自建 6,493 萬 |
自建省約 833 萬 |
|
雲端 $3.2 vs 自建 6,493 萬 |
自建省約 5,229 萬 |
在中間與保守的單價假設下，自建三年反而比雲端便宜 800 萬到 5,200 萬。關鍵在於利用率：同樣兩台 B300，先前若只服務 250 人，產能利用率僅約一半、怎麼算都虧；但服務到 500 人這個規模，硬體被有效負載填滿，固定成本被充分攤提，自建的單位成本就壓了下來。硬體是固定成本，你塞越多有效負載，每個 token 越便宜---這就是規模的力量。
倘若 K3 公布的規格可以支援 FP4 精度的話，很有機會只需要一台 B300 就夠了，如此可更進一步將三年自建成本壓縮到 3,300 萬上下的水平。自建的優勢更具吸引力了！
但這裡必須誠實標註前提：上述「自建勝出」成立於高 agentic 用量的假設(每日約 10.6 億 token，即 160 位開發者認真使用)。若實際開發者比例較低、用量未達這個水位，交叉點就會往回移---存在一個明確的用量門檻，過了門檻自建才在成本上勝出。所以正確的問法不是「500 人就該自建嗎」，而是「你的真實用量，過了那道門檻沒有」。這也是為什麼任何人都不該拿別人的結論當自己的答案，而該用自己的數字重算一次。
而且---單看 token 成本是遠遠不夠的，這筆帳還漏算了三件雲端給不了的事。
回到第二節那些撞牆的故事：雲端的 reset、週額度、session 上限，是供應商管理自身資源稀缺的工具，代價卻是你的停工。自建的機器沒有這些---你的算力、你的節奏、你的產能天花板，由你自己決定。對靠 agentic 產能吃飯的團隊，停工是按小時計損失的；「不會被掐住」值多少，取決於你的工程師一小時產出多少價值。這一項，雲端再便宜也給不了。
近期有一個真實案例很能說明問題：全球最大的 AI 模型平台 Hugging Face 遭遇一起全自動 AI agent 的入侵 (見: Security incident disclosure — July 2026 )。
Hugging Face Security incident disclosure — July 2026
一週內在其基礎設施上執行了超過 17，000 次自動操作。事後鑑識時，該團隊原想用某個頂級的閉源模型 API 來分析攻擊日誌，卻發現真實的攻擊指令與惡意 payload 觸發了模型的安全護欄，模型直接拒絕執行；最後，他們只能在自家伺服器上部署一個開源模型，才完成了這次分析。
這個案例的啟示不是「開源比較好用」，而是掌控權的歸屬：當你的 AI 能力租自別人的雲，你就繼承了對方的所有限制---包括在你最需要的時候，因為它的安全政策或對齊判斷，而拒絕為你的正當工作服務。資安鑑識、逆向工程、事件處理這類正當卻「敏感」的任務，最容易撞上這道外加的閘門。自主部署，讓「模型聽誰的」重新回到你自己手上。當然，伴隨這個自主權的，是你必須自己承擔的治理責任---存取控制、稽核、沙箱隔離---而這恰恰是企業級地端部署需要專業設計的地方，不是把模型下載下來就了事。
雲端成本隨用量線性成長，單價又掌握在供應商手裡---今天便宜，不代表明天便宜。
而這種失控不是小團隊的窘境,連科技巨頭都栽了跟頭。根據 The Information 報導、並經 Forbes 等多家media 轉述:Uber 在 2025 年 12 月對旗下約 5,000 人的工程團隊開放 Claude Code，採用率從 2 月的 63% 一路飆到 3 月的 84%，擴散速度超過近年任何一套軟體；結果才進入 2026 年短短幾個月，原訂的年度 AI 預算就被用光，技術長 Praveen Neppalli Naga 坦言得「回到白板重新規劃」。平均每位工程師每月花費落在 150 到 250 美元，重度使用者高達 500 到 2,000 美元，CTO 本人甚至在一次兩小時的示範中就花掉 1,200 美元。
2026 年才過幾個月,就把整個年度 AI 預算用光了 https://www.theinformation.com/newsletters/applied-ai/uber-cto-shows-claude-code-can-blow-ai-budgets
值得注意的是,這不是工具出錯或濫用---工程師正是拿它來做並行 agent 執行、大規模重構、自動化測試這些「該做的事」。從生產力看是成功,從財務看卻是失控。問題的根源,是 token 用量型計價，不像 CFO 熟悉的軟體授權那樣可預測。連 Uber 這種等級的工程與財務團隊都會誤判，說明多數企業此刻編列的 AI 預算,恐怕都還停留在「試點時代」的假設上。
自建則是一次性資本支出加上趨近於零的邊際成本：機器買了，用越多、每單位越便宜。對用量正在指數成長的組織，自建鎖定的是未來的成本天花板---如果兩年後用量翻三倍，雲端帳單跟著翻三倍，自建的成本卻幾乎不動。這是財務上真實的避險，不是話術。
還有一個關鍵的框定：那筆 1，000 萬的企業儲存。NetApp 300T 這類儲存，不該被算成「跑 K3 的成本」---它是企業 AI 資料平台的基礎資產，服務整條資料管線：RAG 知識庫、訓練與微調資料、向量資料庫。這些用途長期存在、被多個 AI 應用共同攤提，不是為單一模型而買。把它從 K3 的帳裡拆出來、放回「企業 AI 基礎設施」的正確位置，整筆投資的樣貌就完全不同。這種 TCO 的重新框定本身就是專業評估的價值---算錯帳的人，會因為把基礎設施誤記成單一專案成本，而錯過本該做的投資。
現實中，不是每家企業都能一次撥出七千萬的資本支出。如果你認同自建的方向，但當下預算有限、未來有機會逐步增撥，不必勉強一步到位---混合架構是一條漸進的過渡路。
具體做法是：初期以雲端 K3 API 為主力，同時用一小規模的地端配置(例如單台或蒸餾模型的工作站)承接一部分穩定、重複、對資料敏感的負載；隨著用量成長、預算到位，再把地端的比重逐步擴大，最終過渡到以自建為主體、雲端為尖峰彈性的架構。
這條路的好處是把一次性的大額資本支出，拆解成跟著用量與預算節奏走的分階段投資，同時讓團隊在過程中累積地端維運與治理的經驗---等到真正要擴大自建規模時，你已經踩過坑、有了能接住的能力，而不是從零開始賭一把大的。
把帳算完、也把帳外的三件事補上，答案不是一個「該」或「不該」，而是看你是誰：
四種情境的共同點是：結論從來不是「買不買機器」，而是「怎麼配」---本體、蒸餾版、雲端 API 各承擔什麼、比例怎麼切、儲存怎麼規劃、合規怎麼隔離、預算怎麼分階段。而「怎麼配」不是買一台伺服器就會自動發生，它是一個需要盤點用量、試算成本、設計架構的過程。
要，先算帳---但別只算 token 的帳。
只算 token，你可能得到「規模不夠就別自建」這個一半正確、卻危險的結論。因為它漏掉了產能主權(你的工程師會不會十分鐘撞牆停工)、漏掉了能力主權(你的模型會不會在關鍵時刻因別人的政策而拒絕工作)、也漏掉了成本的確定性(你賭雲端單價三年後還這麼便宜嗎)。把這些一起算進去，答案會因企業而異，但每一家都值得用新的前提重算一次。
過去，自建的門檻是能力---機房裡跑不出夠強的模型。K3 之後，門檻變成了判斷力：你有沒有把自己的帳，連同帳外的那幾件事，一起算清楚。
真正會贏的企業，不是把所有東西都自建的，也不是完全不碰地端的，而是把工作負載切對的那一群。K3 讓這個選擇第一次成立；而做對這個選擇，需要的不是更貴的硬體，是更清楚的帳。
本文所有試算之硬體與雲端價格、用量假設均為特定情境下的參數，實務決策應以實際報價與實測用量重新計算。資料來源：Moonshot AI 官方(kimi.com/blog/kimi-k3)；Artificial Analysis Intelligence Index v4.1；Arena.ai Frontend Code Leaderboard；NVIDIA DGX B300 官方資料表；硬體報價為 2026 年台灣市場行情；地端部署實測為團隊實作經驗；資安事件案例引自公開新聞報導；開發者使用案例引自公開社群分享。