他本來要幫老闆比價「買顯卡」跟「付 Claude 月費」，算到最後卻發現自己在算一整座機房
（以下情境為示意性虛構案例，主角「溫子軒」為說明用示意人物，非真實客戶）
老闆在群組丟了一句話
「隔壁那家公司都自己買顯卡跑 AI 了，我們幹嘛還在付 Claude 的月費？」
溫子軒是一間十幾人新創的技術負責人，盯著老闆丟進群組的這句話，一時說不出反駁的理由。他們公司每個月的 Claude API 帳單確實一直在漲，而網路上「用一台 Mac Studio 就能跑贏 Claude」的說法，這陣子也到處都是。老闆丟下一句「下週預算會議，你算一份『自己買硬體』跟『繼續用 API』的比較給我」，就把這個問題整個甩到他頭上。
先找一個算得出來的替身
溫子軒動手查資料時，第一個卡關的地方是：Claude Fable 5 到底要多少顆 GPU 才跑得動，根本沒人知道——因為 Anthropic 從沒公開過 Fable 5 的參數量、架構或權重。Reddit 上有一串討論在猜「跑得動 Fable 級模型要幾張 H100」，有人猜 4 張，有人猜 8 張 B200，還有人直接說「你需要一整個機櫃」，答案亂七八糟，沒有人真的算過。
他後來看到一支拿 Kimi K3 當替身做計算的影片，才發現這才是唯一算得出來的方法：Kimi K3 官方公布了 2.8 兆參數、100 萬 token 的上下文窗口，發布資料裡也直接拿自己跟 Fable 5 對比程式碼與 Agent 基準測試——雖然 Kimi 自己的部落格也承認整體仍落後最強的閉源模型，基準分數不等於實際做得好。這不是要證明 Kimi K3 能取代 Fable 5，而是它是唯一一個規模夠大、參數量又公開透明的替身，可以拿來做真正的算術。
算式一攤開，答案立刻現形
Kimi K3 用 4-bit 格式（MXFP4）儲存權重，2.8 兆參數乘上半位元組，光是原始權重就要 1.4 TB——這還沒算進推論軟體、對話上下文、安全餘量，是地板值，不是總成本。
溫子軒照著這條算式，一項一項對照公司能負擔的選項，答案卻一路碰壁。他先查了公司內部最頂規的 Mac Studio——512 GB 統一記憶體，連地板值的三分之一都不到，直接出局。他想起有同事提過「4 張 H100 應該夠了吧」，一算，每張 80 GB、四張加起來也才 320 GB，比 Mac Studio 還少，一樣不夠。再往上，8 張 B200 組成的 DGX B200 有 1.44 TB GPU 記憶體，帳面上總算卡在地板值之上——但扣掉權重後只剩不到 40 GB 可用，上下文視窗、對話快取、推論軟體全部要擠進這 40 GB 裡，根本沒有喘息空間。他繼續往上加碼查到 DGX B300，8 張卡有 2.3 TB，扣掉權重後還有近 900 GB 餘裕，理論上總算勉強能跑；可是 Kimi 官方自己建議的「高效推論」規格，寫的是 64 顆以上加速器——換算下來是 8 台伺服器，不是 1 台。
單一台 DGX B300 一路開下去，官方公布的功耗是 14.5 kW，8 台跑起來不含散熱就逼近 116 kW；他還看到有人在討論串裡說自己公司養了好幾十張 B200，開機的聲音「像坐在空中巴士 A380 後面」。他用今天公開的租賃報價粗估了一下，8 台這樣的節點一個月要價落在 31 萬到 57.7 萬美元之間——他知道這只是量級參考，不是報價單，但已經足夠說明規模跟他原本想的完全是兩回事。
他以為在算一次性採購，其實在算一座機房
看到這裡，溫子軒才意識到自己一開始的假設整個錯了。他以為老闆要的是「買幾張顯卡、一次付清、以後不用再付 API 月費」——一筆資本支出。但算式攤開後才發現，要跑得動 Fable 級模型的自架方案，根本不是「買一次就好」的硬體採購，而是一整座資料中心的長期營運：電力、散熱、機房網路、還要有人 24 小時顧著這批機器。而這個月成本，比他們現在付的 Claude 帳單高出一個數量級。
更關鍵的是，影片裡有人糾正了 Reddit 討論串一開始問錯的問題：「100 個使用者」不等於「100 個並發請求」。如果 100 名員工平均每 10 分鐘各發一次請求、每次回應占用系統 30 秒，攤開來平均同時在跑的請求可能只有 5 個左右——AI Agent 會讓這個數字快速膨脹沒錯，但溫子軒回頭一查自家團隊實際的並發使用量，發現遠遠沒有想像中那麼誇張。
他帶進會議室的不是報價單，是一個問題
隔週的預算會議，溫子軒沒有帶著「買 8 台 DGX B300」的採購清單進去，那太快了。影片裡有個曾經幫幾千個使用者跑過 LLM 服務的人講的一句話，他抄了下來：「一個夠好、能撐得住規模的模型，勝過只能服務兩三個人的超強模型。」也呼應了他查到的另一個模式——真正自己養過本地模型的團隊，幾乎沒有人是「完全自架」的：私密或重複性高的工作留給本地小模型，最難的任務還是交給 Claude 或 GPT。
溫子軒帶進會議室的，是一個反問：「我們真的知道自己每天實際用了多少 token、多少並發請求嗎？」他建議先別急著決定要不要自架，而是先把團隊實際的用量攤開來看——哪些任務量大但簡單、哪些任務少但吃重——再決定值不值得為了省 API 費，換來一整座機房的營運責任。
常見問題（FAQ）
Q1：這篇提到的「Kimi K3」是什麼？跟 Claude Fable 5 有什麼關係？
Kimi K3 是一個公開參數規模的大型語言模型（2.8 兆參數、混合專家架構、100 萬 token 上下文），其發布資料曾直接拿自己與 Claude Fable 5 做基準測試比較。由於 Anthropic 從未公開 Fable 5 的參數量或架構，本文（與其改寫來源影片）選用 Kimi K3 作為「規模相近、但參數公開透明」的替身，來做本地部署所需硬體的估算，並非宣稱兩者能力相同。
Q2：一般公司真的需要自己買 GPU 在本地跑頂級 AI 模型嗎？
多數情況不需要。來源影片的結論是：真正跑過本地模型的團隊，幾乎沒有人是「完全自架」——本地小模型適合處理私密或重複性高的工作（如文件搜尋、分類、例行性編碼），最困難的任務仍交給 Claude 或 GPT 等雲端服務。是否值得自架，取決於實際的並發使用量與工作型態，而不是單純的頭痛醫頭式省錢念頭。
Q3：文中的採購與電費金額（如每月 31 萬至 57.7 萬美元）是精確報價嗎？
不是。這些數字是來源影片作者依公開的硬體租賃價格與規格做的量級推估（rough scale math），用來說明規模有多大，並非正式報價單，也不是 Anthropic、Nvidia 或任何雲端服務商的官方定價。實際成本會因地區、供應商、合約條件而有大幅差異，讀者評估自身情境時應以實際詢價為準。
Q4：「100 個使用者」跟「100 個並發請求」有什麼不同？為什麼這個差別很重要？
「使用者數」是總共有多少人「有可能」使用系統，「並發請求數」是同一時間點系統實際要處理的請求量——兩者可能差距很大。文中舉例：100 名員工若平均分散發送請求，同一時間可能只有約 5 個請求在跑，遠低於「100」這個直覺數字。這個差別直接決定了需要採購的硬體規模，是本文最容易被誤解、也最容易導致採購過度估計的一點。
Q5：不想猜測硬體規格，那該怎麼決定要不要把 AI 工作搬到本地端？
來源影片提出的建議是：先別急著下採購單，用租賃硬體實測幾週，看真實使用者的實際反應，比任何規格表或跑分都更有參考價值。而在租測之前，更根本的第一步是先看清楚自己團隊實際的 token 用量與並發請求模式——知道自己真正用了多少、用在哪裡，才有資格談要不要為了省下這筆錢去換一整座機房的營運責任。
延伸閱讀
資料來源聲明：本文改寫自 YouTube 頻道 Kai 發布之影片《What Would It Cost to Run Claude Fable 5 Locally?》，以敘事方式重新編排，非逐字翻譯。文中主角「溫子軒」為說明用示意人物，非真實客戶案例，其公司背景與情境為示意性重建。文中所有具體數字（記憶體換算、GPU 規格、功耗、租賃成本估計）均為來源影片作者依公開規格資料所做之量級推估，非本站或第三方獨立查核、審計之數據，亦非官方定價，讀者評估自身情境時應以實際硬體規格與供應商報價為準。
現在就開始行動
不管是續用 API 還是考慮自架，真正該先搞清楚的不是「該買幾張顯卡」，而是「我們現在到底用了多少」。與其憑頭痛醫頭的直覺猜測，不如先把每個模型、每個任務的實際 Token 用量攤開來看。立即免費試用 AI Token King，讓我們幫你的團隊把真實用量攤開來看，用數據決定要不要換一整座機房，而不是憑一句「隔壁公司都在用」。
留言