LLM 私有化部署完全指南：企業自建大型語言模型實戰

一、為何企業需要私有化部署 LLM

當 ChatGPT 在 2022 年底掀起全球 AI 浪潮後，企業導入大型語言模型（LLM）已從「要不要」變成「怎麼做」的問題。絕大多數企業的第一步是串接 OpenAI、Anthropic 或 Google 的雲端 API——這是最快的上手方式，但隨著使用量成長與場景深化，三個結構性問題逐漸浮現。

資料主權與合規風險：金融、醫療、政府等受監管行業的核心數據不能離開組織邊界。當你將客戶的病歷、交易紀錄或機密合約送入第三方 API 時，即便供應商承諾不儲存數據，你的資料仍然在傳輸過程中暴露於外部網路。在歐盟 GDPR、台灣個資法與中國數據安全法的框架下，許多場景根本無法使用雲端 API。私有化部署讓所有數據的處理與推論都在企業自己的基礎設施上完成，從根本上消除數據外洩的風險。

成本可預測性：雲端 API 的按 token 計費模式在小規模使用時極具成本優勢，但隨著使用量擴大，成本會呈線性甚至超線性成長。以 GPT-4 Turbo 為例，每百萬輸入 token 約 10 美元、輸出 token 約 30 美元。一個日處理 50 萬次請求的客服系統，每月 API 費用可能超過 15 萬美元。而一組 4 張 A100 80GB 的推論叢集（硬體成本約 6-8 萬美元），搭配量化後的開源 70B 模型，可以承載同等甚至更高的吞吐量——投資回收期通常在 3-6 個月。

延遲與可用性控制：雲端 API 的回應延遲受網路狀況、供應商負載與 rate limiting 影響，通常在 500ms-3s 之間波動。對於即時對話、程式碼補全、交易風控等延遲敏感場景，這種不可控的延遲是不可接受的。私有化部署讓你完全掌控推論基礎設施，可以透過硬體配置、模型優化和網路拓撲設計將延遲壓至 50-200ms，並確保 99.9% 以上的可用性。

模型客製化自由度：使用雲端 API 時，你只能在供應商提供的模型版本上做 prompt engineering。私有化部署則讓你完全自由地進行 LoRA 微調、知識蒸餾、模型合併（model merging）等深度客製化，打造真正適合特定業務場景的專屬模型。

二、開源模型選型：Llama vs Mistral vs Qwen

私有化部署的第一個決策點是選擇基礎模型。2024-2025 年，開源 LLM 生態已經形成三大陣營，各有明確的技術優勢與適用場景。

Meta Llama 系列：Llama 2^[1] 開創了開源大模型的先河，而 Llama 3（8B / 70B / 405B）進一步將開源模型的能力推至與 GPT-4 級別競爭的水準。Llama 的核心優勢在於龐大的社群生態——幾乎所有推論引擎、微調工具與量化方案都以 Llama 為第一優先支援對象。其 Grouped Query Attention（GQA）設計大幅降低了 KV cache 的記憶體需求，70B 模型的 KV cache 僅為同規模傳統 Multi-Head Attention 模型的 1/8。Llama 3 的 tokenizer 採用 128K 詞彙表，對多語言（包括繁體中文）的支援比 Llama 2 有顯著提升，但整體中文能力仍然落後於專門針對中文優化的模型。

Mistral AI 系列：Mistral 7B^[3] 是小模型高效推論的標竿。其核心技術創新是 Sliding Window Attention（SWA）——將注意力窗口限制在固定長度（如 4096 tokens），讓記憶體使用量不隨序列長度線性成長，極大地降低了長文本推論的資源需求。Mixtral 8x7B 則採用 Mixture of Experts 架構，總參數 46.7B 但每個 token 僅啟動 12.9B，在吞吐量與品質之間取得優秀平衡。Mistral 的模型授權相對寬鬆（Apache 2.0），對商業部署友好。然而 Mistral 的中文能力是三者中最弱的，若你的應用以中文為主，可能需要額外的中文語料微調。

阿里巴巴 Qwen 系列：Qwen 2.5^[4] 是中文場景的首選。從 0.5B 到 72B 的完整尺寸矩陣讓企業可以根據硬體預算靈活選擇。Qwen 在中文理解、繁體中文生成、中英混合場景上的表現顯著領先 Llama 和 Mistral——這對台灣企業而言是關鍵優勢。Qwen 2.5 支援最長 128K tokens 的上下文窗口，並提供專門的 Qwen-Coder（程式碼）和 Qwen-Math（數學推理）變體。不過 Qwen 的社群生態較 Llama 小，部分第三方工具的相容性需要額外驗證。

對台灣企業的實務建議：若應用場景以繁體中文為主（如客服、文件摘要、法律文書），優先選擇 Qwen 2.5；若需要最大的社群支援與工具相容性（如快速原型開發、多模態擴展），選擇 Llama 3；若硬體預算有限且需要處理長文本，Mistral / Mixtral 的 SWA 架構是記憶體效率最高的選擇。

三、推論引擎比較：vLLM、TGI 與 TensorRT-LLM

選定基礎模型後，下一個關鍵決策是推論引擎。推論引擎決定了模型如何在 GPU 上執行、如何管理記憶體、如何處理並行請求——它直接影響吞吐量、延遲和硬體利用率。目前主流的三個開源推論引擎各有鮮明的定位。

vLLM：由 UC Berkeley 開發，是目前開源社群最受歡迎的 LLM 推論引擎^[2]。vLLM 的核心技術突破是 PagedAttention——借鑑作業系統虛擬記憶體的分頁機制來管理 KV cache（詳見下一章節）。在實際基準測試中，vLLM 的吞吐量比 HuggingFace Transformers 原生推論高出 14-24 倍，比 HuggingFace TGI 高出約 2-4 倍。vLLM 提供 OpenAI 相容的 API 介面，讓遷移成本極低——你只需要將 API endpoint 從 OpenAI 指向你的 vLLM 服務，現有的程式碼幾乎不需要修改。vLLM 支援 continuous batching、tensor parallelism、speculative decoding^[9] 等進階功能，且社群活躍、更新頻繁。

HuggingFace Text Generation Inference（TGI）：TGI^[7] 是 HuggingFace 官方的推論伺服器，以 Rust 編寫，強調生產環境的穩定性與可觀測性。TGI 的優勢在於與 HuggingFace 生態系統的深度整合——你可以直接從 HuggingFace Hub 載入任何模型，無需額外的格式轉換。TGI 內建了量化支援（bitsandbytes、GPTQ、AWQ）、token streaming、health check endpoint 等生產級功能。其 gRPC 介面適合微服務架構的整合。吞吐量方面，TGI 通常介於 vLLM 與原生 Transformers 之間，但在小批次、低延遲場景下的表現接近 vLLM。TGI 的主要限制是對非 HuggingFace 格式模型的支援較弱，且部分進階優化（如 speculative decoding）的支援不如 vLLM 完整。

NVIDIA TensorRT-LLM：TensorRT-LLM^[8] 是 NVIDIA 官方的 LLM 推論優化引擎，代表了硬體廠商對推論加速的最深度介入。它將模型編譯為高度優化的 TensorRT 引擎，利用 NVIDIA GPU 的每一個硬體特性——FP8 Tensor Core、Multi-Instance GPU（MIG）、NVLink 多卡通訊等。在 NVIDIA GPU 上，TensorRT-LLM 通常能達到最高的絕對吞吐量，特別是在大批次推論場景下。代價是部署複雜度顯著更高：模型需要經過顯式的編譯步驟（可能耗時數十分鐘到數小時），對特定 GPU 架構和精度格式有嚴格要求，且除錯難度遠高於 vLLM。TensorRT-LLM 適合對吞吐量有極致要求、且有專業 GPU 工程團隊的企業。

我們的建議：對大多數企業而言，vLLM 是最佳起點。它的部署門檻最低、社群支援最廣、效能已足夠優秀。當你的推論需求成長到需要榨取最後 10-20% 的硬體效能時，再考慮遷移到 TensorRT-LLM。

四、PagedAttention 與 FlashAttention：記憶體優化核心

LLM 推論的記憶體瓶頸主要不在模型權重本身，而在 KV cache——Transformer 的自回歸解碼需要快取所有先前 token 的 Key 和 Value 向量。以 Llama-2-70B 為例，FP16 模型權重佔 140GB，但在並行處理 256 個請求、每個請求 2048 tokens 時，KV cache 可以佔據額外的 80-160GB。如何高效管理這片記憶體，直接決定了一台伺服器能同時服務多少用戶。

PagedAttention：vLLM 的核心創新^[2]直接借鑑了作業系統中虛擬記憶體的分頁（paging）機制。傳統的 KV cache 分配方式是為每個請求預先分配一塊連續的記憶體空間，大小等於最大可能的序列長度。但實際上大多數請求不會用滿這塊空間——如果你為 2048 tokens 預留了空間，而實際生成只有 200 tokens，那 90% 的記憶體就被浪費了。Kwon 等人的研究顯示，傳統方案的記憶體利用率通常只有 20-40%。

PagedAttention 將 KV cache 分割成固定大小的「頁」（通常每頁 16 個 token），並使用頁表（page table）來管理邏輯到物理的映射。新的 token 生成時，只分配一個新頁；請求結束時，頁被回收到全域記憶體池。這帶來了三個革命性的改進：（1）記憶體利用率從 20-40% 提升至接近 100%；（2）不同請求可以共享相同的 prompt 前綴頁（copy-on-write），在 system prompt 較長的 chatbot 場景下可節省 50% 以上的記憶體；（3）動態分配使得同一台伺服器可以同時處理更多的並行請求，直接提升吞吐量。

FlashAttention：如果 PagedAttention 解決的是 KV cache 的「空間效率」問題，那麼 FlashAttention^[6] 解決的是注意力計算的「時間效率」問題。標準的 self-attention 需要將完整的 N x N 注意力矩陣寫入 GPU 的 HBM（High Bandwidth Memory），這不僅消耗記憶體（O(N^2)），更造成嚴重的 I/O 瓶頸——GPU 的計算核心大部分時間在等待數據從 HBM 讀入。

Dao 等人提出的 FlashAttention 採用分塊計算（tiling）策略：將 Q、K、V 矩陣分成小塊，每次只在 SRAM（GPU 的片上快取，速度比 HBM 快 10-20 倍）中計算一個小塊的注意力，再用 online softmax 技術精確累加結果。這個方法在數學上完全等價於標準注意力——沒有任何近似——但 I/O 量從 O(N^2) 降至 O(N^2 d / M)（M 為 SRAM 大小），實際速度提升 2-4 倍，記憶體使用從 O(N^2) 降至 O(N)。FlashAttention-2 進一步優化了並行策略，速度再提升約 2 倍。

在實際部署中，PagedAttention 和 FlashAttention 是互補而非替代的關係——vLLM 同時使用兩者。PagedAttention 管理 KV cache 的記憶體分配，FlashAttention 加速每次注意力的實際計算。兩者疊加的效果是：同一張 GPU 可以同時服務的並行請求數量增加 3-5 倍，每個請求的回應延遲降低 2-3 倍。

五、GPU 硬體規劃：從單卡到叢集

GPU 的選型與叢集設計是私有化部署中成本佔比最高的決策。選擇正確的硬體配置需要同時考慮模型大小、並行請求量、延遲要求和預算限制。

單卡部署（7B-13B 模型）：對於 7B 參數的模型（如 Llama 3 8B、Mistral 7B、Qwen 2.5 7B），一張 NVIDIA A100 40GB 或 RTX 4090 24GB 即可在 FP16 精度下完成推論。若搭配 AWQ 4-bit 量化，7B 模型僅需約 4GB GPU 記憶體，甚至可以在 RTX 3060 12GB 上運行。單卡部署是最簡單的起步方式——安裝 vLLM、載入模型、啟動服務，整個過程不超過 30 分鐘。但單卡的並行處理能力有限，FP16 精度下 7B 模型在 A100 上的吞吐量約為每秒 40-80 個 token（取決於 batch size），適合日請求量在 1-5 萬的場景。

多卡推論（70B 模型）：70B 參數模型在 FP16 下需要 140GB GPU 記憶體，超過任何單張 GPU 的容量。此時需要使用 Tensor Parallelism（TP）——將模型的每一層切分到多張 GPU 上平行計算。以 2 張 A100 80GB 為例，每張 GPU 承載 70GB 的模型權重，剩餘空間用於 KV cache。vLLM 的 TP 實作高度優化，2 卡 TP 的吞吐量通常可達單卡（假設記憶體足夠）的 1.7-1.9 倍。4 張 A100 80GB 的配置可以為 70B 模型提供充裕的 KV cache 空間，支撐日均 10-30 萬次請求。關鍵考量：TP 要求 GPU 間有高速互聯——NVLink（900 GB/s）的效能遠優於 PCIe 4.0（64 GB/s）。如果你的伺服器只有 PCIe 連接，TP 的通訊開銷可能吞噬大部分平行化收益。

叢集部署（多節點）：當單台伺服器無法滿足吞吐量需求時，需要擴展到多節點叢集。此時有兩種策略：（1）數據平行（Data Parallelism）——在多台伺服器上各部署一份完整的模型副本，用負載均衡器分配請求，這是最簡單的水平擴展方式；（2）Pipeline Parallelism（PP）——將模型的不同層分配到不同節點，適合部署超大模型（如 Llama 3 405B，FP16 需要 810GB）。TensorRT-LLM^[8] 對 PP 的支援最為完善，而 vLLM 目前主要依賴 TP + 數據平行的組合。DeepSpeed-Inference^[5] 則在 TP + PP 的混合策略上有較成熟的實作。

H100 vs A100 的選擇：NVIDIA H100 相較 A100，在 LLM 推論場景下通常提供 1.5-2.5 倍的吞吐量提升，主要得益於 FP8 Tensor Core 和更高的記憶體頻寬（3.35 TB/s vs 2.0 TB/s）。但 H100 的單卡價格約為 A100 的 2-3 倍。若你的工作負載以長序列生成為主（memory-bound），H100 的優勢更明顯；若以短序列批次推論為主（compute-bound），A100 的性價比可能更高。

六、量化策略：在精度與速度之間取捨

量化是私有化部署中最立竿見影的優化手段——不需要改變模型架構或重新訓練，只需將權重從 FP16（16 bit）壓縮到更低的精度（通常是 INT4 或 INT8），就能大幅減少記憶體佔用和計算量。對於企業部署，量化不是可選項，而是幾乎必須的標準步驟。

Post-Training Quantization（PTQ）是目前最實用的量化路線。企業不需要重新訓練模型，只需準備少量的校準數據（通常 128-512 條樣本）即可完成量化。主流的 PTQ 方案包括：

• GPTQ：基於近似二階資訊的逐層量化，速度快（70B 模型約 4 小時），品質穩定。適合需要 GPU 加速推論的場景，vLLM 和 TGI 都有良好的 GPTQ 支援。
• AWQ（Activation-aware Weight Quantization）：核心洞察是只有約 1% 的「關鍵權重」對模型品質影響最大——AWQ 透過保護這些關鍵通道來最小化量化誤差。在 4-bit 量化下，AWQ 的品質通常略優於 GPTQ，且與 vLLM 的整合最為成熟。
• GGUF（llama.cpp 格式）：專為 CPU + GPU 混合推論設計，特別適合消費級硬體。GGUF 支援從 Q2_K（約 2.5 bit）到 Q8_0（8 bit）的多種量化級別，可以根據硬體記憶體靈活選擇。對於沒有企業級 GPU 的小型團隊，GGUF + llama.cpp 是最經濟的入門方案。

量化精度的品質影響：QLoRA^[10] 的研究表明，4-bit NormalFloat（NF4）量化在大多數任務上的品質損失低於 1%——這意味著 70B 模型從 140GB 壓縮到 35GB，推論速度提升 2-3 倍，但回答品質幾乎不變。INT8 量化的品質損失更小（通常可忽略不計），但壓縮比只有 2 倍。更激進的 2-3 bit 量化目前仍會導致可察覺的品質下降，建議僅在硬體資源極度受限時使用。

企業部署的量化策略建議：以 AWQ 4-bit 為標準配置。先在你的業務特定評測集上比較 FP16 和 AWQ-4bit 的輸出品質——如果差異在可接受範圍內（通常如此），就直接使用量化版本。這能讓你用更少的 GPU 承載更大的模型，或在相同硬體上服務更多的並行請求。只有在品質差異不可接受時，才考慮退回到 INT8 或 FP16。

七、API Gateway 與負載均衡設計

推論引擎只是後端的「發動機」，要讓它在生產環境中穩定服務，還需要一層完整的 API Gateway 和負載均衡架構。這一層的設計品質直接決定了系統的可用性、安全性和可觀測性。

API Gateway 層：API Gateway 是所有請求進入推論叢集的唯一入口，承擔四大職責。第一，認證與授權——透過 API Key、JWT Token 或 OAuth 2.0 驗證請求者身份，確保只有授權的內部系統或用戶可以存取模型。第二，Rate Limiting——按用戶、按部門或按 API Key 限制請求頻率，防止單一消費者耗盡叢集資源。常見的策略是 sliding window counter（例如每分鐘 60 次、每小時 1000 次）。第三，請求路由——根據模型名稱、請求參數或用戶優先級，將請求路由到不同的推論後端（例如高優先級請求路由到 FP16 模型，一般請求路由到量化模型）。第四，可觀測性——記錄每個請求的延遲、token 數量、模型版本等指標，為容量規劃和問題排查提供數據基礎。

負載均衡策略：LLM 推論的負載均衡比傳統 Web 服務更複雜，因為不同請求的計算量差異極大——一個生成 10 個 token 的請求和一個生成 2000 個 token 的請求，佔用 GPU 的時間可能相差 200 倍。簡單的 Round Robin 或 Least Connections 策略會導致部分 GPU 過載而其他 GPU 閒置。更適合 LLM 推論的策略包括：（1）基於佇列深度的路由——將請求發送到當前佇列最短的後端，這隱含地考慮了每個請求的處理時間；（2）基於 GPU 利用率的路由——透過 NVIDIA DCGM 即時監控每張 GPU 的利用率和記憶體佔用，將請求路由到最空閒的 GPU；（3）預估負載路由——根據請求的 max_tokens 參數預估計算量，將大請求和小請求均勻分配。

高可用設計：生產級部署需要考慮故障容錯。建議至少部署 N+1 個推論副本（N 為支撐正常負載所需的最少副本數），並配置健康檢查（health check）和自動故障轉移。vLLM 提供 /health endpoint，API Gateway 應每 10-30 秒輪詢一次，若連續失敗則自動將該節點從負載均衡池中移除。Kubernetes 環境下可以使用 Horizontal Pod Autoscaler（HPA）根據 GPU 利用率或請求佇列長度自動擴縮推論副本。

推薦技術棧：對大多數企業，我們建議使用 NGINX 或 Kong 作為 API Gateway，搭配 Prometheus + Grafana 做指標監控，Kubernetes + NVIDIA GPU Operator 做容器編排。這套組合的社群文件充足、企業案例豐富、運維成本可控。

八、成本分析：自建 vs 雲端 API

私有化部署的最終決策往往歸結為一個問題：在我的使用量下，自建的總擁有成本（TCO）是否低於持續使用雲端 API？這個問題的答案取決於三個變數：日均請求量、平均回應長度、以及你的時間範圍。

雲端 API 成本模型：以 GPT-4 Turbo 為基準，輸入 token 每百萬約 $10，輸出 token 每百萬約 $30。假設平均每次請求消耗 500 輸入 token + 300 輸出 token，每次請求成本約 $0.014。日均 10 萬次請求的月成本約 $42,000；日均 50 萬次請求的月成本約 $210,000。開源模型的雲端 API（如 together.ai、fireworks.ai）成本約為 GPT-4 的 1/5-1/10，但仍然存在數據離境和供應商鎖定的風險。

自建成本模型：假設部署 Llama 3 70B（AWQ 4-bit 量化），使用 4 張 A100 80GB。硬體成本方面，若自購伺服器（含 CPU、記憶體、NVLink、網路、機架）約 $80,000-120,000，攤提 3 年，月均硬體成本約 $2,800-3,300。若使用雲端 GPU（如 AWS p4d.24xlarge），月租約 $12,000-15,000。人力成本方面，需要 0.5-1 名 MLOps 工程師負責維運，月均人力成本約 $4,000-8,000（台灣市場）。電力與機房成本（若自建機房）月均約 $500-1,000。總計自建月均 TCO 約 $7,300-12,300（自購硬體）或 $16,500-24,000（雲端 GPU）。

損益平衡點：將兩種方案的成本曲線交叉比較，我們可以得到以下經驗法則：

• 日均請求量 < 1 萬次：雲端 API 明顯更經濟，且無需維運負擔
• 日均 1-10 萬次：取決於回應長度和模型選擇，需要具體計算
• 日均 > 10 萬次：自建通常更經濟，特別是使用自購硬體 + 開源模型的組合
• 日均 > 50 萬次：自建的成本優勢極為顯著，可能僅為雲端 API 的 1/5-1/10

隱性成本提醒：上述分析未包含幾項重要的隱性成本：（1）模型評測與選型的人力投入（通常 2-4 週）；（2）推論引擎的調優與除錯（初次部署可能需要 1-2 週）；（3）模型更新時的重新部署與回歸測試；（4）GPU 硬體的折舊與故障替換。這些隱性成本在小團隊中可能佔總成本的 30-50%，必須納入決策考量。

我們的建議：先用雲端 API 驗證業務可行性，確認需求穩定後再評估私有化部署。過早投入自建基礎設施是許多企業 AI 專案失敗的常見原因——在你還不確定需要什麼模型、什麼推論參數、什麼吞吐量的時候，雲端 API 的靈活性遠比成本節省更重要。

九、結語：企業 LLM 部署路線圖

私有化部署 LLM 不是一個單一的技術決策，而是一系列環環相扣的工程選擇——從模型選型、推論引擎、量化策略到硬體規劃、網路架構和成本模型，每一層都需要深入理解和反覆權衡。

基於我們在企業客戶專案中的實戰經驗，以下是一份分階段的部署路線圖：

第一階段：概念驗證（1-2 週）。選擇一個目標場景（如客服 FAQ 回覆、文件摘要、程式碼審查），使用雲端 API 快速搭建原型。這個階段的核心目標不是建設基礎設施，而是驗證 LLM 能否在你的業務場景中創造可量化的價值。同時收集真實的使用數據：每日請求量、平均 token 數、回應品質要求、延遲容忍度。

第二階段：推論引擎驗證（1-2 週）。在單張 GPU（A100 或 RTX 4090）上部署 vLLM + 量化模型（AWQ 4-bit），搭建一個最小可行的推論服務。將部分流量從雲端 API 切換到自建服務，在真實負載下驗證品質、延遲和穩定性。這個階段是「用最小成本試水溫」。

第三階段：生產級部署（2-4 週）。根據第二階段的數據設計正式的叢集架構——選擇合適的 GPU 數量和配置、搭建 API Gateway 和負載均衡、配置監控和告警、設計故障容錯機制。完成安全審計（資料加密、存取控制、日誌審計）後將全部流量遷移到自建服務。

第四階段：持續優化（持續進行）。基於生產數據持續調優——嘗試不同的量化方案、調整 batch size 和 max_tokens 參數、引入 speculative decoding^[9] 等進階加速技術、探索 LoRA 微調^[10]以提升特定任務的品質。定期評估新的開源模型版本，適時升級基礎模型。

LLM 的私有化部署是一個典型的「做對比做快更重要」的工程實踐。每一步都應該基於數據驅動的決策，而非直覺或跟風。我們見過太多企業在第一天就購買了 8 張 H100，卻在三個月後發現業務場景根本不需要這麼大的算力——或者更糟，發現 LLM 在他們的場景中根本不適用。

正確的順序是：先驗證價值，再建設基礎設施。這條路線看似保守，實則是通往成功的最短路徑。超智諮詢團隊在 LLM 部署架構設計、開源模型選型與企業級推論優化方面擁有豐富的實戰經驗——若你的企業正在評估 LLM 私有化部署方案，歡迎與我們聯繫，讓我們協助你設計最適合的技術路線。