【2026 最新】本機 LLM 主機值得買嗎？API、租 GPU、自架成本損益表

你正在看一台價格足以買車的本機 LLM 主機：顯卡記憶體很大、機殼很帥，賣家也給了漂亮的 Token/s。另一個分頁則是 API 帳單，第三個分頁是每小時計費的雲端 GPU。到底哪個便宜？只拿「每百萬 Token」對「顯卡售價」，不足以得到可比較的總成本答案。

這篇專為第一次做容量與部署決策的人寫。你不必會財務建模，也不用先買任何硬體；我們會用一份 7 天工作 Trace，把 API、租 GPU、自架統一換成每個通過品質門檻的任務成本，再做 Break-even（損益兩平）與敏感度分析。最後你會得到可貼進試算表的欄位、公式，以及一套「先租後買」流程。

先說結論：先量 7 天，再談本機 LLM 主機

每個成功任務成本＝（首次執行＋後續重跑＋閒置／折舊＋能源＋人力＋失敗損失）÷ 通過品質門檻的任務數。

本文把這個教學指標稱為 quality-adjusted completion cost；它不是業界統一的會計準則。為了讓分母不可被挑數據，任務還必須在預先約定的正確性、端到端延遲、安全政策與人工介入上限內完成，才算通過。

每一筆費用只能出現一次：API 的 Retry 是後續 Attempt 執行費；租機的開機帳單時間已包含其中的 Warm-up 與閒置；自架的固定攤提也已涵蓋沒有工作的時段。最後用 COUNT(DISTINCT task_id)計算每個策略的最終通過任務，不能把同一任務的兩次合格 Attempt 算成兩個成果。

這就是全文的記憶把手。API、租 GPU、自架只是三條路；真正的分母不是 Token，也不是生成次數，而是讀者或系統願意接受的結果。資料依法或依內規不能外送時，先把不合格的路由刪掉；其餘情況可先用真實工作負載租機測 2–4 週，工作有更長週期就延長觀測。只有成本優勢在不同假設下都站得住，才把錢換成硬體。

為什麼只比 Token 或 GPU 單價會失真？

最近一位已有雙 RTX 3090 的社群使用者問：如果有約 15,000 美元，現在該不該再蓋家用伺服器？討論裡同時出現「硬體自由」、「雲端更省」與「再等等」等互相衝突的答案，發文者最後更新為先等待。這個 r/LocalLLaMA 案例不是購買證據，卻很好地暴露問題：缺少你的 Workload Trace，外部建議多半只能依假設估算。

LLM Cost Calculator已能輸入 Token、購買或租用、攤提期、每日時數和電價；CloudParity也把模型、量化、批次與雲端價格放進同一頁。不過後者在頁面上明列估算未含儲存、網路、人力等項目。它們適合做第一眼估算，不等於你的最終損益表。

本文優先檢查四個常見因素：便宜模型是否更常重跑、輸出是否需要更多人工修正、機器有多少時間只在待機，以及敏感資料能不能走外部服務。想先補齊顯存、量化與 Context 的概念，可先讀 本機 LLM 顯存選擇指南；本文則只處理「怎麼做出可稽核的錢包決策」。

第 0 步：隱私是路由閘門，不是任意加價

先替每種任務標記 sensitivity_class 與 allowed_route。可依法、依授權條款與組織政策外送的資料，才可能同時比較 API、租 GPU 與自架；含內部文件的任務可能只允許特定企業 API 或私有環境；法規、合約或組織政策明確禁止外送時，外部 API 與公有雲就直接淘汰。不要憑感覺替「隱私」加一個 20% 溢價，再假裝它能抵銷不合規。

也別把「API」一律寫成資料會被訓練，或把「自架」一律寫成安全。以 OpenAI 為例，截至 2026 年 9 月 8 日，官方資料控制文件說明 API 資料預設不拿來訓練；一般濫用監控日誌預設最多保留 30 天，但法律要求或保護服務與第三方所需時可能更久。Zero Data Retention 需事前核准，且端點的 Application State、第三方工具與功能限制要分開查。另一方面，自架仍要處理磁碟、備份、權限、漏洞與實體存取。白話說：先查你的實際方案與資料流，不要只看部署地點。

步驟 1：替本機 LLM 主機蒐集 7 天 Trace

先選一個真實、重複出現的工作，例如客服草稿、文件摘要、程式碼修補或研究報告。連續 7 天記錄每個邏輯任務，以及它展開的每一次 Attempt（實際嘗試）。逾時後重送、模型切換、格式不合而重跑，都要新增一列，不能只保留最後成功的那次。

task_id,strategy_id,route,model_revision,attempt_id,parent_attempt_id,input_uncached_tokens,cache_read_tokens,cache_write_tokens,output_inclusive_tokens,wall_seconds,billable_seconds,active_gpu_seconds,ttft_ms,tpot_ms,e2e_ms,attempt_passed,final_task_accepted,human_review_minutes,sensitivity_class,allowed_route,fallback_route,failure_reason,timestamp

把這行直接貼到 Google Sheets 或 Excel 當欄名。strategy_id代表 API-only、租機、自架或混合策略；同一任務發生 Fallback 時沿用 task_id，增加 Attempt，最後只用 final_task_accepted把任務算進分母一次。每次回應的 Usage 要保存並與工具、儲存及帳務用量對帳；本機與租機則分開記牆鐘時間、帳單時間與活躍 GPU 時間。model_revision要包含模型檔、量化、Serving Runtime 和重要參數，否則下週換了版本，數字會悄悄失去可比性。

延遲至少記 TTFT（首 Token 延遲）、TPOT（每個輸出 Token 時間）與端到端延遲的 P95（約 95% 觀測值不高於這個第 95 百分位數），不要只截最好看的一次。vLLM 官方 benchmark 文件列出成功請求、輸入與輸出 Token、吞吐、TTFT、TPOT、ITL 等指標，也提醒重複執行可能重用 Prefix Cache 而灌高吞吐。先跑 vllm bench serve --help確認你安裝版本的參數，再用同一任務集測各候選。

步驟 2：先凍結品質門檻，再看價格

品質門檻必須在看結果前寫好。客服草稿可以要求「事實欄位全對、語氣合格、無敏感資訊」；程式碼任務可以要求測試通過、靜態檢查通過、修改範圍沒有越界；摘要任務可以用抽樣人工評分加上必要欄位檢查。每一條路都跑同一組任務輸入、必要 Context、輸出要求、評分規則和延遲上限；若不同介面需要專屬 Chat Template，先凍結各路模板，不能看完結果才改 Prompt。

若品質是 0–100 分，別直接發明「每一分多少錢」。先訂最低可接受分數，把結果變成 attempt_passed = TRUE/FALSE，再依整條任務鏈是否在時限與政策內完成，設定 final_task_accepted；另外可畫品質與成本的 Pareto frontier（同時沒有別的方案更便宜又更好）。模型路由與小型 Eval 的做法，可接著看 AI Evals 新手教學。這樣一來，便宜但大量返工的方案不會被漂亮單價掩護。

步驟 3：把三條路的分子算完整

API：依實際 Usage 計價，不用 Prompt 字數猜

API 成本要逐 Attempt 加總互斥的一般輸入、Cache Read、Cache Write、Output-inclusive、工具、儲存與其他 Meter，再套用當時有效的 Pricebook；如果供應商的 Output 已包含 Reasoning，就不能再加一次。以 2026 年 9 月 8 日的官方頁面為快照，OpenAI GPT-5.6 Terra的標準文字費率為每百萬 Token：輸入 2 美元、Cached Input 0.20 美元、輸出 12 美元；該頁另列 Cache Write 與超過 272K 輸入的整筆 Request 費率規則。這只是示範欄位，發布後查價時應覆寫，不要把數字烤死在模型裡。

api_cost =
  uncached_input / 1_000_000 * input_rate
  + cache_read / 1_000_000 * cache_read_rate
  + cache_write / 1_000_000 * cache_write_rate
  + output_inclusive / 1_000_000 * output_rate
  + tool_cost + storage_cost + other_meter_cost

同一個 task_id若跑了三次，三筆都進分子；只把通過的一次放進分母。若你需要把 API 支出拆到客戶、功能與重試，LLM API 成本拆帳有完整 Ledger 做法。

租 GPU：用帳單秒數，不用純生成秒數

租機分子至少包含 GPU／CPU／RAM 的實際帳單時間、Container 與 Volume 儲存、網路／Egress（可能為零）和人工部署。模型下載、載入、Warm-up 與閒置若發生在已開機計費期間，已包含在同一筆資源帳單時間裡，不能再乘一次單價；另有獨立費用才另列。截至 2026 年 9 月 8 日，RunPod 官方即時價目列出的 Secure Cloud Pod 例子包括 RTX 4090 24GB 每小時 0.74 美元，執行中 Container Disk 每 GB／月 0.10 美元；Serverless、其他 GPU 與雲端層級是不同價格，區域與供應量也會影響可用性。換句話說，跑 40 分鐘的生成，不代表 Pod 只開了 40 分鐘。

在這套決策流程中，租機的一項主要價值，是用小錢驗證你想買的模型、量化與 Runtime。先讀 LLM Inference Engine 選擇指南，固定 vLLM、llama.cpp 或其他 Serving Stack 的版本，再比較吞吐與品質；Runtime 不同，硬體相同也可能得到不同的吞吐、延遲、記憶體占用與可用功能。

自架：折舊、牆上功率、維修與人力都入帳

自架每週固定成本可先寫成 （購入與建置－預估殘值）÷ 使用週數，再加 UPS、備份、網路、零件備品、維修與必要冷房。這是簡化攤提；資金占用重要時，還要加入資金成本。購買價請填你真正拿到的含稅報價，殘值則做低／中／高三個情境；不要把官方建議售價當成實際成交價。既有硬體的原始購入費是沉沒成本，但今天不賣掉它所放棄的二手價仍是機會成本；固定攤提已涵蓋未使用期間，不要再加一筆「閒置折舊」。

電費要量插座端的整機 AC kWh，不是拿 GPU 的 TGP 或電源供應器瓦數乘時間。舉例來說，NVIDIA RTX 5090 規格頁列出 575W Total Graphics Power；那是顯示卡規格，不是整台主機的牆上實測。MLCommons Inference v2.0 的 2022 功耗量測規則提供一個穩定的方法參考：量完整系統，並讓功耗與效能來自同一次 Run。

在台灣，住宅非時間電價採累進級距，夏月與非夏月也不同；正確做法是用同一計費期間比較「主機與必要冷房都開啟」和「兩者都不開啟」兩張分段帳單的差，而非拿全戶平均單價套上去。只有新增用電完全落在同一級距或同一時間帶時，才可用單一邊際電價近似。每次重算都可查看台電官方電費試算；別隨手套資料中心 PUE。

self_host_weekly =
  (purchase_price - residual_value) / useful_weeks
  + (bill_with_host_and_cooling - bill_without_host)
    / billing_period_weeks
  + maintenance + non_electric_cooling_cost
  + ops_hours * hourly_cost
  + fallback_cost + downtime_loss

maintenance只放零件與外部服務；若維修人力已在 ops_hours，不要再算一次。冷氣用電已進兩張帳單差，non_electric_cooling_cost只放未包含在電費裡的額外成本。fallback_cost是同一任務鏈已發生的外部執行費；downtime_loss只記沒有被 Retry、Fallback 或人力補回的額外商業損失。兩格若描述同一後果，只能留一筆。

合成算例：單看機器錢，會漏掉真正大項

下面是一組教學假資料，不是 AlphaLab 實測，也不是市場報價。假設每個候選策略各自跑相同的 1,000 個邏輯任務與評分規則；人力統一用每小時 NT$450。API 有 920 個通過，執行費 NT$1,350、審核與操作 20 小時；租 GPU 有 870 個通過，執行與儲存 NT$1,350、人力 23 小時；自架有 890 個最終通過，折舊、電力與維修 NT$1,800、人力 25 小時，另用 NT$450 雲端 Fallback。三個策略的貨幣與觀測週期一致。

試算結果是 API 每個通過任務 NT$11.25、租 GPU 約 NT$13.45、自架約 NT$15.17。重點不是 API 永遠便宜，而是人力與通過率能比基礎設施單價更大。若你的自架模型品質相同、審核更少、負載更高，排序完全可能翻轉；試算表的價值正是讓這些假設露在陽光下。

把損益兩平公式貼進試算表

先替每條路算三個數：每期固定成本 F、每個邏輯任務的變動成本 V、通過率 q。當一期有 N個任務時，單一通過任務成本是 F/(N×q)+V/q。拿自架 s與 API a相比，損益兩平量可寫成：

N_break_even =
  (F_s / q_s - F_a / q_a)
  / (V_a / q_a - V_s / q_s)

要直接貼進試算表，可把 B 欄設為自架、C 欄設為 API，Row 2 放 F、Row 3 放 V、Row 4 放 q、Row 5 放 N。三個公式如下；所有金額必須先換成同一幣別與同一期間：

B6: =B2/(B5*B4)+B3/B4
C6: =C2/(C5*C4)+C3/C4
B8: =IF(C3/C4-B3/B4=0,IF(B2/B4-C2/C4=0,"ALL N","NO FINITE CROSSOVER"),CEILING((B2/B4-C2/C4)/(C3/C4-B3/B4),1))

這個公式假設 F、V與 q不隨用量改變，並要求 N > 0且 0 < q ≤ 1；q = 0時，每個成功任務成本沒有有限值。若分母為 0，兩條變動成本平行：分子也為 0 就是所有用量都同價，否則沒有有限交叉點。試算表用 CEILING向上取整到下一個完整任務；算出的 N_break_even仍必須大於 0，並落在自架容量、品質與延遲都合格的區間。在常見的「自架固定成本較高、但每個合格任務的變動成本較低」情境，公式的分子與分母都應為正；若後半條不成立，就不會出現用量愈大、自架愈划算的交叉點。遇到階梯式擴卡、分段電價或大量 Fallback，直接畫逐月累積成本曲線，不要硬套直線公式。

接著做敏感度分析：每次只改一格，至少掃過任務量、輸出長度、Cache 命中、尖峰併發、通過率、人工複核分鐘、殘值、維修、電價與額外冷房。最後再做「差情境同時發生」壓力測試。若自架只在最佳情境勝出，它不是省錢方案，而是一張對未來很挑剔的賭注。

先租後買：兩到四週的最小實驗

1. 第 1 天，凍結基準。定義任務集、品質 Rubric、延遲 SLO、資料路由、人工時薪與 Pricebook 日期；輸出一份不可事後改題的設定快照。
2. 第 2–4 天，跑合規候選。Allowed Route 允許時，API 保存實際 Usage，租 GPU 則用接近購機候選的顯存與 Runtime；不能外送就改在合規私有環境或現有本機測，不能跑也不要為了文章先買。
3. 第 5 天，故意測失敗。加入逾時、冷啟動、模型重載、滿併發、網路中斷與合規 Fallback；確認 Retry 沒被成本資料吞掉。
4. 第 6–7 天，核對分子與分母。比對租機帳單、API 用量、牆上電表與人工工時，逐條人工抽查 final_task_accepted。
5. 本文建議再跑 2–4 週才談購買。這是篩選節奏，不是統計保證；工作若有月末或季節尖峰，就延長到覆蓋完整週期。只有不同週、不同尖峰與保守殘值下仍跨過 Break-even，才向供應商詢最終報價。

資料政策允許外送時，可保留雲端 Fallback 與成本上限：自架負責穩定基載，API 承接尖峰、高難度或故障任務，混合策略可能是合理候選。若政策不允許外送，Fallback 就應改成合規的第二台本機、私有環境或排隊後 Fail-closed，而不是繞過 Allowed Route。這和 本機、雲端與 API 混合使用的思路一致，但本文把它變成可量測的容量政策。

24GB、多 GPU、高記憶體主機怎麼選？

24GB 顯存：先把實際量化模型載入，再跑你最長的 Context 與最大併發。模型權重裝得下，不代表 KV Cache（生成時保存注意力狀態的工作記憶）也裝得下；Hugging Face 文件說明一般全注意力模型的 Dynamic KV Cache 會隨已快取序列長度線性增加，Static、Sliding Window 或特殊注意力架構則可能預留固定容量或設上限。只要一到尖峰就記憶體不足，24GB 就不是你的合格候選。

多 GPU：適合單卡裝不下，或有足夠併發讓多卡吞吐產生價值的情況。不要把兩張 24GB 想成毫無代價的 48GB；切分方式、PCIe／NVLink 與 Runtime 都會影響結果。llama.cpp 多 GPU 文件把 layer與仍屬 Experimental 的 tensor切分模式分開，後者更仰賴卡間互連。你的 Trace 必須用實際拓撲重跑。

高記憶體單機或統一記憶體：當首要問題是模型容量、長 Context 與安靜省事，而非最高 Token/s，可把它列入候選。先看 Apple 高記憶體本機 AI 分析理解容量與頻寬取捨，再用同一品質與延遲門檻實測。測試資料、參數、品質門檻或量測定義不同的 Benchmark 不宜直接互比；硬體、量化或軟體版本不同時，先確認其餘條件與指標一致。

讓本機 LLM 主機損益表翻車的 7 個常見坑

1. 只保存成功結果：失敗 Attempt 與 Retry 的 Token、GPU 秒數、人力全被歸零。解法是每次實際嘗試一列。
2. 拿平均負載買尖峰：平均吞吐過關，P95 仍可能塞車。解法是把延遲 SLO 與最大併發寫進品質門檻。
3. 暖 Cache 重跑 Benchmark：第二輪看似突然變快。解法是分開記 Cold／Warm，並保存 Cache 命中。
4. 用 TGP 當整機電力：漏掉 CPU、記憶體、機殼／CPU 風扇、轉換損失與冷房。解法是插座端量 kWh。
5. 把閒置當免費：執行中的 Pod 仍有運算費、停止後的持久 Volume 可能仍有儲存費，主機也持續折舊。解法是讓資源狀態、帳單時間與生成時間同時進 Trace。
6. 把隱私換成想像中的金額：不允許的路由本來就不該入圍。解法是先做 Allowed Route Gate，再算剩下選項。
7. 用最好情境說服自己：高殘值、零維修、滿載與零 Fallback 是高度樂觀的聯合假設，不應預設會同時成立。解法是至少跑低／中／高三組敏感度。

2026 年 9 月查價時，哪些欄位需要更新？

API 模型、Cache、Batch、長 Context 與工具費會改；GPU 報價依 GPU、產品與雲端層級不同，區域與供應量則會影響可用性；硬體成交價與殘值也會變。請在試算表保留 price_checked_at、source_url、currency、tax_included與 fx_rate，每次決策重新拉價。

台灣電價則要更新季節、級距與時間電價設定。本文的合成算例故意不把某個匯率或電價宣稱成普遍現況；你應輸入自己的帳單差額。只要有一個價格仍是舊截圖或搜尋摘要，就把該格標黃，先不要簽採購單。

常見問題 FAQ

1. 有 15,000 美元，就該買本機 LLM 主機嗎？

不一定。預算只告訴你買得起，沒有證明用得完。先跑 7 天 Trace；Allowed Route 允許時租接近的 GPU，不允許外送就用合規私有環境或現有硬體，再看保守情境下是否仍跨過 Break-even。

2. 某候選 API 的 Token 單價較高，為什麼仍可能勝出？

因為你買的是成功任務。若你的 Trace 顯示 API 通過率較高、人工複核較少，且省下自有硬體的待機與維修、降低分攤到這個工作的人力，即使該案例的 Token 單價較高，仍可能換到較低的完成成本。

3. 自架一定比較有隱私嗎？

不能一概而論。自架能縮短外部資料路徑，但仍要管磁碟、備份、帳號、漏洞與實體安全；API 也有不同保留與企業控制。依實際資料流和合約做判斷。

4. 一週資料真的夠嗎？

本文只把它當第一輪篩選。它能找出明顯不合格的容量或品質；本文建議購機前再跑 2–4 週，並依任務量與季節性延長，直到覆蓋尖峰、週末、版本變動與故障情境。

5. 24GB 顯卡能跑多大的模型？

不能只靠參數量得到固定答案。模型檔格式、量化、Context、KV Cache、Batch、GPU Offload 與 Runtime 都會改變需求；用實際 Artifact 載入並跑最大情境才算數。

6. 兩張顯卡的顯存可以直接相加嗎？

容量上可能切分，效能上不能直接相加。模型如何分片、卡間互連與 Serving Stack 都會產生成本；先租相同拓撲測過，再決定多卡。

7. 電費用 GPU 的 575W 乘時數可以嗎？

不可以當整機成本。575W 是特定 GPU 的板卡規格，不含其餘系統與必要冷房。用插座電表量同一次工作負載的整機 kWh，再套帳單的增量電價。

8. 最後可以混用 API 與自架嗎？

資料路由允許時，可以列為候選。自架承接穩定、允許的基載；API 或租 GPU 承接尖峰、高難度與故障 Fallback。禁止外送的資料則使用合規的本機或私有備援。關鍵是把整條策略的 Trace 與成本留下來。

給新手的 7 個重點

1. 先用 Allowed Route 排除不能承載資料的路，隱私不是隨手加價。
2. 每個 Retry 都是成本；失敗 Attempt 留在分子。
3. 三條路共用同一任務集、品質 Rubric 與延遲門檻。
4. 租 GPU 看帳單時間，自架看牆上 kWh，API 看實際 Usage。
5. 常見的高用量 Break-even，要先滿足自架固定成本較高、合格任務變動成本較低。
6. 路由允許時先租 2–4 週；若工作週期更長，就延長到覆蓋尖峰、重載、故障與 Fallback。
7. 政策允許時可以混用；買的是已量測的穩定基載，不是對需求的想像。