🔹 前言

前 16 天，我們一路鋪陳了基礎觀念：
從 RAG 檢索架構、快取、觀測性、Prompt 設計 到 Workflow 工具（LangChain + Guidance）。
這些都是在回答同一個問題：怎麼讓 LLM 更聰明、更可靠地使用資料。

但光有好的 Prompt 以及資料流程還不夠。
進入下半場，我們要面對更根本的實務課題：

👉 這些 LLM 實際要部署在哪裡？

• 是直接用 雲端 API（例如 OpenAI、Anthropic、Google Gemini）？
• 還是要 自己架設本地模型（例如 Llama、Mistral、Qwen）？
• 或是採取 混合架構，依照場景動態切換？

不同策略不只影響成本，還會左右延遲、隱私、維運難度。

今天，我們就來比較這三種常見的 專案部署策略，看看它們的優缺點，以及什麼情境最適合哪種做法。

🔹 三種常見的部署策略

1. 雲端託管 (Cloud API)

代表：OpenAI API、Anthropic Claude、Google Gemini、AWS Bedrock
優點：

• 省去硬體管理，開箱即可用。
• 自動更新模型，不用自己維護。
• 高可用性、全球佈署。
  缺點：
• 成本高昂，隨 Token 用量線性增長。
• 資料隱私需謹慎，可能無法放內部機敏文件。
• 延遲（Latency）程度受制於雲端網路。

➡️ 適合 初期 MVP / 快速上線，以及 對隱私要求不高的應用。

2. 本地自建 (On-Premise / Self-hosted)

代表：Llama 2、Mistral、Falcon、RWKV，自行部署在 GPU Server 或 K8s Cluster
優點：

• 完全掌控資料隱私，不經過外部 API。
• 可以針對專案做 微調 (Fine-tune) 或 量化 (Quantization)[註1]。
• 長期成本較低（如果 GPU 已經購入）。
  缺點：
• 前期投入成本高（GPU 購置 / 租用、MLOps 基礎建設）。
• 模型更新要自己跟進。
• 維運複雜（需要監控 GPU 使用率、記憶體、推論速度）。

➡️ 適合 企業內部敏感應用（如醫療、金融、政府），或 長期高頻使用。

[註1] Quantization（量化，把浮點數權重轉成低精度，例如 FP16/INT8，降低運算成本）

3. 混合架構 (Hybrid)

做法：

• 預設走本地模型，處理大部分日常查詢。
• 特殊情境（例如需要高精度、推理能力的查詢）才轉發到雲端 API。
  優點：
• 成本可控 → 平常低成本跑自家模型，必要時才付費給雲端。
• 彈性高 → 可以根據查詢內容決定走哪個路徑。
  缺點：
• 架構較複雜，需要 Routing 策略。
• Debug 難度增加。

➡️ 適合 追求性價比 或 需要彈性 的團隊。

💡 Routing 策略實例

• 查詢字數 < 300 tokens → 本地模型 (Llama / Mistral)
• 查詢包含「建議 / 規劃 / 撰寫文件」 → 雲端模型 (Claude / GPT-4o / Gemini)

範例邏輯如下：

def route_query(query: str) -> str:
    """
    Routing 策略：
    1. 先檢查敏感資料
    2. 短文或 FAQ → 本地
    3. 其他 → 雲端
    """

    # 檢查是否含敏感資料（個資/機密）
    if contains_pii(query):        # PII: Personal Identifiable Information
        return "local"

    # 短文 or 常見 FAQ
    elif len(query) < 300 or is_faq_match(query):
        return "local"

    # 預設走雲端
    else:
        return "cloud"

這樣可以做到成本效益與精度的平衡。

模型部署策略決策樹

💀 常見決策陷阱

🔹 案例探討：公司內部 FAQ Chatbot

假設我們要做一個 公司內部 FAQ Chatbot，回答員工的常見問題（例如：請假流程、VPN 設定、HR 規章），應該選哪種部署策略呢？

• 成本試算：1,000 人公司，每天 1,000 次問答
• 假設：
  • 每次查詢平均 1,000 tokens（prompt + completion），輸入/輸出各半（500/500）
  • 一個月 30 天。
  • 模型以 GPT-4o mini 為例:
    • Input：$0.15 / 1M tokens，1,000 次/天 × 500 tokens × $0.15/1M = $0.075/天
    • Output：$0.60 / 1M tokens，1,000 次/天 × 500 tokens × $0.60/1M = $0.30/天

以下月費皆不包含人力和維護費，只單看硬體成本：

GPU 以 單張 A100 24/7 的「算力基礎成本」對齊不同平台（實際要看是否真的需要 24/7 滿載）。
NTD 以 1 USD ≈ NT$32 呈現（實際匯率每日波動）。

[註3] CapEx 全名是 Capital Expenditures（資本支出），中文一般翻作 資本性支出。
[註4] 光看 GPU 硬體成本（$330/月）可能覺得很便宜，但加上電費、人力後，實際月費可能超過 $1,600。

💰 隱藏成本拆解附錄（示範：自購 A100 80GB）

[註5] 台電工業用電採時間電價，依契約與時段而定。113/04/01 起之高壓電力價目參考：離峰 NT$2.49–2.62/kWh、半尖峰 NT$3.56–3.67/kWh、尖峰（夏月）約 NT$10.42–10.70/kWh。近年新聞口徑之工業平均約 NT$3.8–4.3/kWh；若要保守估算，可抓 NT$4.0/kWh。讀者可自行依實際合約與時段重算。
[註6] FTE 是 Full-Time Equivalent 的縮寫，中文常翻成 全職人力當量，泛指花了多少時間維護系統。

🤔 為什麼混合架構反而更貴？

混合架構需要同時維護兩套系統，本地與雲端的成本會疊加：

1. 本地模型基礎成本：~$1,519/月（硬體 + 電費 + 基本人力維護）。
2. 雲端 API 備援用量：~$500/月（假設 20% 查詢走雲端）。
3. Routing 層維運：~$800/月（API Gateway、Routing 策略判斷、雙邊監控）。

總計：約 $2,819/月，比單純本地成本高出許多。

方案一：雲端 API

• 做法：所有問題都丟給 雲端模型 (OpenAI / Claude / Gemini) 。
• 優點：開發最快，不需要管基礎設施。
• 缺點：
  - 成本：如果公司有上千名員工，每天數萬次查詢，Token 帳單可能會爆炸。
  - 小流量：每天 1,000 次 ≈ $8/月，很便宜。
  - 高流量：每天數萬次 ≈ $4,000+/月，就會爆炸。
  - 資料隱私：有些 HR 規章或內部文件不能丟到外部 API，需要做額外的加解密脫除敏感資料，然而仍無法完全符合 GDPR/CCPA 等規範

➡️ 適合 PoC、小規模試行 、無 IT 團隊的小型企業 或 非敏感資料的測試。

方案二：本地自建

• 做法：在公司 Kubernetes 叢集或是 Bare Metal Servers[註7] 裡部署 開源 LLM (Llama 3.1 - 8B/70B or Mixtral) 、自建模型 + 向量資料庫（如 Milvus / Pinecone）儲存 FAQ 文件提升效率。
• 優點：
  - 內部文件完全留在公司網路內，隱私安全。
  - 高頻查詢的長期成本較低。
• 缺點：
  - 初期要投入 GPU / MLOps 基礎建設。
  - 模型維護（更新、效能優化）需要專職 IT 團隊。

➡️ 適合 大型企業 / 金融 / 醫療 / 政府機構。

[註7] Bare Metal（實體機，不透過虛擬化層（Hyperisor），直接跑在硬體上）

方案三：混合架構

• 做法：
  - 員工問「常見 FAQ / 敏感資料 」時，走本地部署的模型（例：開源 LLM (Llama 3.1 - 8B/70B or Mixtral) 。
  - 員工問「複雜查詢 / 不敏感的需求」問題（例如：幫我規劃一份專案流程建議），再丟給 雲端模型 (OpenAI / Claude / Gemini)。
• 優點：
  - 成本可控，大部分查詢走便宜的本地模型。
  - 遇到複雜問題，還是能保有雲端模型的強大能力。
• 缺點：
  - 需要 Routing 策略，判斷「什麼問題要走哪邊」。

➡️ 適合有 IT 能力但預算有限的中型企業，追求 成本效益 + 彈性。

⚡ 實際流量並非每天固定，可能在日間尖峰時段衝高 5–10 倍。建議搭配 Auto-scaling（自動擴縮） 機制，例如雲端 GPU Spot Instance 或 Kubernetes HPA，才能避免資源閒置或突發 OOM。

混合型架構示意圖

✅ 最終推薦

在 1,000 人公司、每日 1,000 次查詢、且 高度重視隱私 的情境下，最合適的選擇是 方案二（本地自建）：

• 理由

  • 不含人力成本，按 A100 80GB 自購、3 年攤提試算：
    • 硬體攤提：NT$10,656／月
    • 電費（400W × 24 × 30 × NT$4/kWh）：NT$1,152／月
    • 其他（授權/基礎建設/雜支）：NT$200–3,200／月
    • 小計：NT$12,000–15,000／月
  • 含人力成本：-
    • 上述小計 + 維運人力（0.2 FTE = NT$35,200／月）
    • 總計：NT$47,200–50,200／月
  • 隱私與控制：資料完全留在內部網路，隱私可控。
  • 效能可行性：Llama 3.1（8B 量化）搭配 RAG 足以支撐 FAQ Chatbot 的需求，每日千次查詢對單張 A100 80GB 來說綽綽有餘。

• 實施步驟

  1. 部署 Llama 3.1（8B 量化） 至 A100 80GB（自購 ~US$10,000–15,000，3 年攤提）。
  2. 佈建 向量資料庫（如 Milvus），導入 FAQ 文件，串接 RAG 查詢流程。
  3. PoC 階段若想先上雲：可租 RunPod A100（80GB），公開價 ~US$1.64/hr；或 Lambda Cloud A100 80GB ~US$1.79/hr，僅在測試時段啟用以節省成本。

• 備選方案 ： 方案三（混合架構）

  成本：

  • 不含人力：硬體攤提 NT$10,656 + 電費 NT$1,152–1,728 + 少量路由/監控雜支（可抓 ~NT$1,000–5,000）= 合理範圍 NT$13k–18k（80% 查詢本地，20% 雲端 API）。
  • 含人力：
    • 基礎（0.3 FTE）：NT$63,000/月 -
    • 完整（0.4 FTE + 高可用監控）：NT$80,000/月
      特點：
  • 本地模型處理大部分 FAQ，雲端僅作故障切換備援。
  • 成本不一定比純本地便宜， 高可用性 更有保障，但維運較複雜（Routing、雙邊監控與安全）。

註：若功耗取 600W，電費變為 NT$1,728／月，則範圍分別上移 +NT$576。

📜 免責聲明

• 本文所涉及之成本試算、架構建議，均基於公開資訊（如雲端廠商定價頁、GPU 市場行情）與合理假設情境，僅供技術交流與學習參考。
• 實際部署成本將因 地區電價、供應商折扣、模型選型、維運模式 等因素而有顯著差異，另本文撰寫於 2025 年 10 月，雲端/GPU 市場價格變動快速，請以最新報價為準。
• 本文不代表任何特定企業之內部數據或商業決策，亦不構成投資建議或專案承諾。
• 若讀者需進行實際部署，建議以 自家需求與專案預算 為基準，並搭配專業顧問或雲端供應商提供之最新報價進行評估。

🔹 小結

LLM 可以有 三種典型部署策略：雲端 API、本地自建、混合架構：

1. 不同策略的取捨在於 成本 / 隱私 / 維運難度。
2. 可以在 API Gateway 層實作 Routing，動態決定要走本地或雲端模型。
3. 中小企業若需求單純，其實直接 Cloud API 就足夠；而 大型企業則多半會選本地或混合。

明天（Day 18），我們會開始介紹 LLM API Gateway 架構，示範如何用 FastAPI + LLM Proxy 搭建一個安全、可控的中介層，並且逐步審視 LLMOps 在維護 LLM 應用時需要留意的部分。

📚 引用 / 延伸閱讀

• OpenAI Pricing
• Amazon EC2 On-Demand Pricing
• Amazon EC2 P4 Pricing Book
• RunPod Pricing
• Lambda Cloud Pricing
• Vast.ai GPU Marketplace
• NVIDIA Blog – LLM Inference Benchmarking: How Much Does Your LLM Inference Cost?
• How much does an NVIDIA A100 GPU cost?
• Taiwan electricity rates increase more slowly than in other countries Taipower strives to improve finances but still needs billions in subsidies to cover residential electricity losses
• 台電 - 各類電價表及計算範例（113 年 4 月 1 日起實施）
• Llama 3.1（8B）模型卡（Hugging Face）
• Announcing up to 45% price reduction for Amazon EC2 NVIDIA GPU-accelerated instances