企業 LLM 該地端自建還是用雲端 API？2026 決策框架與 TCO 損益兩平試算

「我們的資料不能外流，所以 AI 一定要地端自建。」

這句話我在製造業、金融業與醫療機構的會議室裡聽過太多次。它聽起來嚴謹，實際上卻常常是一個未經檢驗的假設——而這個假設一旦寫進預算書，就會變成一筆七位數、綁三年、而且很難退場的資本支出。

地端 LLM 部署不是一個資安問題，而是一個同時牽動合規、成本結構與組織能力的架構決策。Gartner 預測超過 40% 的 agentic AI 專案將在 2027 年底前被取消，主因正是成本失控與商業價值不清；部署架構選錯，是把這兩個風險一次買齊的最快方式。

這篇文章不會告訴你「地端比較安全」或「雲端比較划算」。它會給你一套可以帶進財務會議的判斷方法：什麼條件下地端才成立、成本結構差在哪、損益兩平點怎麼算、以及開源模型那道多數人只看了一半的門檻。

什麼情況下，企業才真的需要地端自建 LLM？

原子答案： 地端自建只在四種情況下具備正當性——法規明文禁止資料跨境、稽核要求對推論管線有完整控制權、用量大到雲端 API 帳單超過自建 TCO、或延遲要求低到必須貼著資料所在地運算。不符合任一條，地端通常是昂貴的過度設計。

先把「資料不能外流」這句話拆開。它在實務上至少有三種完全不同的意思，而只有第三種真的指向地端：

1. 不希望資料被拿去訓練模型——主流雲端供應商的企業方案本來就提供不用於訓練的合約承諾與零留存選項，這一層用採購條款就能解決。
2. 不希望資料離開特定地理區域——用區域資料落地加上私有連線即可滿足，仍然是雲端架構。
3. 法規明文要求資料不得離開自有機房，或稽核必須能檢視完整推論管線——這一層雲端解不了，地端是唯一選項。

我看過太多團隊在第一層的需求上，買了第三層的解法。

在動用任何預算之前，請先要求法務與資安把「不能外流」寫成一條可驗證的條文：誰不能看到什麼資料、依據哪一條法規或客戶合約、以什麼方式稽核。寫得出來，架構自然浮現；寫不出來，那就不是合規需求，而是焦慮。

除了合規，另外三個成立條件是：用量（每月 token 消耗大到雲端帳單超過自建持有成本）、延遲（產線或交易場景要求推論貼著資料所在地）、可控性（需要凍結模型版本以確保輸出行為長期一致，而非跟著供應商更新漂移）。

地端與雲端 API 的成本結構差在哪裡？

原子答案： 地端是「高固定成本、低邊際成本」，雲端 API 是「零固定成本、線性邊際成本」。前者先付一大筆，之後每次推論幾乎只付電費；後者不用先付錢，但用多少付多少。兩條成本曲線必然相交，交點就是決策點。

把兩種模式的成本項目攤開對照，會發現它們的風險型態完全不同：

成本面向	地端自建	雲端 API
初期投入	高（硬體、機房、網路，六至七位數）	近乎零
邊際成本	極低（電力為主）	線性（依 token 計價）
維運人力	0.3–0.5 FTE 起跳，長期存在	接近零
成本可預測性	高（折舊固定）	低（用量暴衝即帳單暴衝）
模型升級	需自行評估、重新部署與調校	供應商推送，幾乎無成本
閒置損失	有（GPU 沒跑也在折舊）	無（不用不付費）
退場成本	高（硬體殘值低、已沉沒）	低（停用即止血）
擴充彈性	低（受限實體機器，採購前置期以月計）	高（分鐘級）

這張表最容易被忽略的一列是閒置損失。企業內部應用的用量幾乎都有明顯的日夜與週末落差，一台全天折舊的 GPU 伺服器，實際利用率若只有兩成，等於你用四倍的單位成本在買推論。雲端 API 在這種鋸齒狀用量下的效率優勢，遠比帳面單價看起來的大。

關於雲端這一側的支出如何壓縮，我在企業 AI 成本失控怎麼救？LLM Token 成本控管的 5 個實戰槓桿裡整理過五個槓桿——實務上，多數企業在認真做完快取、路由與 prompt 瘦身之後，帳單會下降到讓地端方案徹底失去財務正當性的水準。先優化，再談自建，順序反了會買下一台你其實不需要的機器。

自建 LLM 要花多少錢？三種硬體量級的實際配置

原子答案： 地端硬體大致分三級：單機入門約 NT$16-24 萬起，可跑 7B-14B 量化模型；多卡工作站約 NT$60-120 萬，是企業級 RAG 與內部助理的實務起點；機房級 8 卡 HGX H200 系統國際報價約 US$320,000-420,000。硬體只是起點，不是總額。

量級	典型配置	價格帶	可跑模型	適用場景
入門單機	單張消費級／專業卡，量化推論	NT$16–24 萬起	7B–14B（量化）	PoC、單部門試點、開發測試
多卡工作站	RTX PRO 6000 級 ×1–2	NT$60–120 萬	最高約 70B	企業 RAG、內部助理、正式內部服務
機房級	8 卡 HGX H200 / B200	US$320K–500K	百B 級、高併發	全公司級服務、對外產品

對絕大多數台灣企業而言，多卡工作站這一級才是真實的討論起點。單機入門跑得動 demo，但併發一上來就會露餡；機房級的價格則已經進入需要董事會決議的區間，而那個量級的用量，多數企業三年內都到不了。

必須強調的是，硬體採購價只佔總持有成本的一部分。完整的 TCO 至少還要加上：機房空間與空調、電力（GPU 滿載功耗相當可觀）、網路與備援、以及最容易被漏算的維運人力。以一台多卡工作站攤提三年計算，硬體折舊約每月 NT$1.7–2.5 萬，但加上 0.3 名維運人力（約 NT$3–4.5 萬／月）與電力機房後，每月實際持有成本落在 NT$5–7 萬——人力那一項，通常比機器還貴。

為什麼「開源模型」不等於「可以隨便用」？

原子答案： 開源權重模型要過兩道獨立的門：授權條款允不允許你的商業用途，以及模型來源能不能通過你所屬產業的資安與採購審查。兩道門是分開的，過了一道不代表過了另一道——這是台灣企業最常踩的認知盲區。

先看第一道門，授權。2026 年主流開源權重模型的授權條件差異相當大：

模型家族	授權	商用注意事項
Mistral（7B / Nemo / Large 3）	Apache 2.0	無使用量上限，限制最少
DeepSeek V4	MIT	授權極寬鬆，但受第二道門限制
Microsoft Phi-4	MIT	小模型，適合邊緣與特定任務
Qwen 開源線	Apache 2.0	授權寬鬆，但受第二道門限制
Google Gemma 4	Apache 2.0	條件已較早期版本放寬
Meta Llama 4	社群授權	超過 7 億 MAU 需另行取得授權

好消息是效能落差已經不是主要顧慮：2026 年開源權重模型在 MMLU-Pro 等通用基準上與商用 API 的差距已收斂到約 3-5 個百分點。壞消息是，授權寬鬆的模型不一定用得了。

多數中文討論把「地端部署」直接等同於「資料安全」，然後從授權清單裡挑一個最寬鬆的就開始下載權重。但對台灣的政府機關、公部門標案承包商與受規管產業（金融、醫療、關鍵基礎設施）而言，政府採購規範、供應鏈資安要求與地緣政治考量，通常使 Qwen、DeepSeek 等中國開發的模型無法通過資安審查——即使你把它關在自己的機房裡，完全不連外網，也一樣過不了。

這是「地端＝安全」這個直覺最大的破口。資安審查看的不只是資料流向，還有模型來源與供應鏈信任。我看過團隊花了兩個月把 DeepSeek 調校到內部評估集表現最好，最後在資安審查會議上被一句話擋下來，整個專案重來。

實務建議：在投入任何調校工時之前，先把候選模型清單送法務與資安會簽。這件事花不到一週，卻能省下兩個月。相關的治理框架，可以參考2026 企業 AI 治理與資安實戰指南。

如何算出你的損益兩平點？TCO 試算的 5 個變數

原子答案： 損益兩平點由五個變數決定：每月 token 用量、混合單價、硬體攤提年限、維運人力比例、以及 GPU 實際利用率。以多卡工作站估算，交點大約落在每月十億 token 的量級——低於這個數字，地端在財務上就站不住腳。

實際跑一次數字。假設一台多卡工作站方案：

• 硬體 NT$90 萬，攤提 3 年 → 每月折舊約 NT$2.5 萬
• 電力、機房、網路 → 每月約 NT$1 萬
• 維運人力 0.3 FTE → 每月約 NT$3.5 萬
• 地端每月總持有成本 ≈ NT$7 萬

反推雲端側：若以中階模型混合單價約 US$1.5／百萬 token 計算，NT$7 萬（約 US$2,200）換算下來，相當於每月約十四億 token。也就是說，你的用量必須穩定超過每月十億 token 這個量級，地端才開始划算。

十億 token 是什麼概念？以一次帶檢索脈絡的問答約消耗 8,000 token 估算，這代表每月約十二萬次問答、每個工作日約六千次。對一家兩百人的公司來說，等於每人每天要用三十次——這個數字，多數企業在導入的頭兩年都達不到。

同樣的邏輯也適用於周邊元件的選型，例如向量資料庫的自架與託管取捨，同樣是固定成本與邊際成本的權衡。

部署選型決策樹：依序回答四個問題，架構自然浮現

flowchart TD
    Start["需要導入 LLM"] --> Legal{"法規明文禁止<br/>資料離開自有機房？"}
    Legal -->|是| OnPrem["地端自建<br/>（合規驅動，不論成本）"]
    Legal -->|否| Vendor{"雲端企業方案的<br/>零留存 + 區域落地<br/>能否滿足稽核？"}
    Vendor -->|否| OnPrem
    Vendor -->|是| Volume{"每月 token 用量<br/>是否穩定 > 10 億？"}
    Volume -->|否| Cloud["雲端 API<br/>（先做成本優化）"]
    Volume -->|是| Skill{"是否具備 0.3 FTE<br/>以上的 GPU 維運能力？"}
    Skill -->|否| Cloud
    Skill -->|是| Hybrid["混合架構<br/>敏感／高頻走地端<br/>其餘走雲端"]

    style OnPrem fill:#a8c4a2,stroke:#3d5a36,color:#14210f
    style Cloud fill:#9db8d2,stroke:#33536e,color:#0f1a24
    style Hybrid fill:#e8c89a,stroke:#7a5b2e,color:#2a1f10

圖 2：四個問題的順序不能顛倒——合規是門檻條件，用量是財務條件，能力是執行條件。多數企業會在「用量」這一關被導向雲端，而這正是正確答案。

混合架構為什麼是多數企業的真實解答？

原子答案： 混合架構讓你按資料敏感度與任務複雜度分流：敏感資料與高頻簡單任務走地端小模型，複雜推理與低頻任務走雲端旗艦模型。它同時吃到地端的合規性與雲端的能力上限，代價是需要一層路由治理。

現實中很少有企業是「全部地端」或「全部雲端」。真正在生產環境跑得穩的，多半是依請求特性分流的混合架構：

混合架構的模型路由分流邏輯

graph TD
    Req["應用請求"] --> GW["LLM Gateway<br/>統一入口・稽核・成本歸屬"]
    GW --> Class{"資料分級<br/>＋任務複雜度"}
    Class -->|"機敏資料<br/>（個資／病歷／合約）"| Local["地端開源模型<br/>資料不出機房"]
    Class -->|"高頻簡單任務<br/>（分類／摘要／抽取）"| Local
    Class -->|"複雜推理<br/>（多步驟／長脈絡）"| Cloud["雲端旗艦 API<br/>能力上限最高"]
    Class -->|"低頻長尾任務"| Cloud
    Local --> Eval["共用評估集<br/>供應商無關的品質基準"]
    Cloud --> Eval

    style Local fill:#a8c4a2,stroke:#3d5a36,color:#14210f
    style Cloud fill:#9db8d2,stroke:#33536e,color:#0f1a24
    style GW fill:#e8c89a,stroke:#7a5b2e,color:#2a1f10
    style Eval fill:#e8a598,stroke:#7a3b2e,color:#2a1410

圖 3：混合架構的關鍵不是兩套模型，而是中間那層 Gateway 與底下那份共用評估集——前者讓路由規則可被治理，後者讓「換模型」變成一次可量測的回歸測試，而不是一場重寫。

這層抽象是遷移成本的保險。只要應用不直接綁死特定供應商的 SDK，日後不論是把工作負載搬回地端、或是換掉表現變差的模型，都是設定檔層級的調整。這也呼應了RAG 自建還是買現成的 Build vs Buy 決策框架裡的核心主張：在還沒確定答案之前，先讓自己保有改變答案的權利。

台灣企業最常踩的 5 個地端部署錯誤

1. 把採購問題誤判成架構問題。 「資料不能外流」有八成的情況可以用合約條款與區域落地解決，卻被直接翻譯成七位數的硬體採購。
2. 只算硬體，不算人力。 維運人力經常是 TCO 中僅次於折舊的第二大項，卻幾乎不出現在初版預算書裡。
3. 忽略利用率。 內部應用的用量有明顯鋸齒，全天折舊卻只有兩成利用率的 GPU，等於用四倍單位成本買推論。
4. 先選模型才送資安審查。 花兩個月調校一個過不了供應鏈審查的模型，是最昂貴也最常見的順序錯誤。
5. 沒有評估集就換模型。 沒有供應商無關的評估基準，「地端模型夠不夠好」永遠只能靠感覺爭論，無法收斂成決策。

這幾個錯誤的共通點，是把「買設備」當成專案的起點。真正的起點應該是需求定義與用量量測——這一點在中小企業第一筆 AI 預算該花在哪裡也是同樣的結論：先買判斷力，再買工具。

90 天評估路線圖：從資料盤點到 TCO 決策

原子答案： 用 90 天把假設換成數據：前 30 天釐清合規要求的真實邊界與盤點資料分級，中間 30 天在雲端量測真實 token 用量並建立評估集，最後 30 天用實測數字跑 TCO 試算，再做採購決策。

90 天地端 LLM 評估路線圖

gantt
    title 90 天地端 vs 雲端評估路線圖
    dateFormat YYYY-MM-DD
    axisFormat %m/%d
    section 第一階段：釐清邊界
    法務與資安定義可驗證合規條文    :a1, 2026-08-11, 14d
    資料分級盤點與敏感度標記        :a2, 2026-08-18, 14d
    候選模型清單送審（授權＋供應鏈）:a3, 2026-08-25, 7d
    section 第二階段：量測事實
    雲端 API 試點並埋設用量追蹤     :b1, 2026-09-08, 21d
    建立供應商無關評估集            :b2, 2026-09-15, 14d
    先執行成本優化再量測基線        :b3, 2026-09-22, 14d
    section 第三階段：決策
    以實測用量跑 TCO 試算           :c1, 2026-10-06, 10d
    地端 PoC 效能驗證（如仍成立）   :c2, 2026-10-13, 14d
    架構決議與採購或續用            :c3, 2026-10-27, 7d

圖 4：這條路線圖刻意把「地端 PoC」放在最後——因為只有在合規邊界釐清、用量實測完成、且成本優化做過之後，地端方案是否成立才有意義。順序顛倒，你會為了證明一個已經買下的決定而找理由。

第二階段的「先執行成本優化再量測基線」是整條路線圖最關鍵、也最常被跳過的一步。沒做過快取與路由優化就量到的用量基線，會系統性地高估你的真實需求，進而把 TCO 試算推向一個錯誤的結論。

結論：這是一個財務決策，不是一個資安決策

回到開頭那句話。「資料不能外流，所以要地端自建」之所以危險，不是因為它錯，而是因為它把一個需要五個變數才能回答的問題，壓縮成一句不容討論的立場。

三個帶得走的判準：

• 合規是門檻條件，不是理由。 先讓法務把要求寫成可驗證的條文，寫不出來就不是合規需求。
• 用量決定財務答案。 損益兩平大約在每月十億 token 的量級，低於此，雲端 API 幾乎必然更划算。
• 能力決定執行答案。 沒有 0.3 FTE 的 GPU 維運能力，地端方案的真實成本會比試算表高得多。

我的建議始終一致：先上雲端、埋好量測、做完成本優化，再回頭檢視地端是否成立。 這個順序讓你用最低的沉沒成本取得最完整的決策資訊。反過來做，你買到的不是資料主權，而是一台需要三年才能折舊完的焦慮。

如果你正在評估地端與雲端的取捨，卻卡在無法把合規要求轉譯成架構決策、或是缺乏可信的 TCO 試算基礎，歡迎與我聊聊。我協助企業把這類決策拆解成可量測、可被財務驗證的判斷，而不是靠直覺押注一筆難以退場的資本支出。想從整體投資報酬的角度檢視，也可以參考AI ROI 衡量框架。

FAQ 常見問題

自建地端 LLM 大概要準備多少預算？

台灣市場的地端 LLM 主機大致分三個量級：單機入門約 NT$16-24 萬起，可跑 7B-14B 量化模型；多卡工作站（如 RTX PRO 6000 級）約 NT$60-120 萬，是多數企業 RAG 與內部助理的實務起點；機房級 8 卡 HGX H200 系統國際報價約 US$320,000-420,000（典型 US$370,000）。但硬體只佔總持有成本的一部分，還要加上機房、電力、維運人力與模型更新的持續投入。

地端部署一定比雲端 API 便宜嗎？

不一定，取決於用量。地端是「高固定成本、低邊際成本」，雲端 API 是「零固定成本、線性邊際成本」，兩者存在一個損益兩平點。以一台多卡工作站攤提三年、加計電力與 0.3 名維運人力估算，每月總持有成本約 NT$5-7 萬，換算需要每月穩定消耗約十億 token 以上，地端才會開始便宜。多數企業實際用量遠低於此，此時雲端 API 反而是理性選擇。

資料不能外流，就一定只能地端部署嗎？

不一定。「資料不能外流」通常是合規語言，先確認它的實際定義。如果指的是不得離開公司控制範圍，主流雲端供應商的企業方案多半提供不用於訓練的承諾、區域資料落地、私有連線與零留存選項，往往就能滿足。只有當法規明確要求資料不得離開特定司法管轄區、或稽核要求對推論管線有完整控制權時，自架開源模型才是唯一合規解。先讓法務與資安把要求寫成可驗證的條文，再決定架構。

開源模型的效能跟 GPT、Claude 差多少？

在通用基準上差距已明顯收斂。2026 年主流開源權重模型在 MMLU-Pro 等指標上與商用 API 的差距約在 3-5 個百分點。但基準分數不等於你的業務表現，真正的落差通常出現在長脈絡推理、多步驟工具呼叫與非英語的專業領域用語。決策依據應該是你自己的評估集，而不是排行榜。

地端 LLM 需要幾個人維運？

以單一多卡工作站的內部應用估算，穩定期約需 0.3 至 0.5 名全職人力，涵蓋推論服務維護、模型與框架版本升級、GPU 監控與故障排除、以及量化與效能調校。這筆人力成本經常被漏算，卻往往是地端 TCO 中僅次於硬體折舊的第二大項。導入前必須先確認團隊有沒有這個能力，而不是假設可以邊做邊學。

已經上雲端 API 了，之後要搬回地端會很痛嗎？

只要一開始就在應用與模型之間放一層抽象（自建或既有的 LLM Gateway），遷移成本可以控制得很低。真正的痛點不在換模型，而在於 prompt 與評估集綁死了特定供應商的行為特性。建議從第一天就維護一份與供應商無關的評估集，讓換模型變成一次可量測的回歸測試，而不是一場重寫。