企業自建 LLM 完整技術路徑：從基底選型到 LoRA 微調、量化部署的實戰指南

企業自建 LLM 的完整技術路徑是：選定基底模型（Llama 3.3、Qwen 2.5、Gemma 3 等開源權重）→ 用 LoRA 或 QLoRA 在自家資料上微調 → 用 AWQ 或 GPTQ 量化壓縮 → 用 vLLM 部署成 API 服務 → 跑 lm-eval-harness 驗證效果。一個 7B 模型完整 pipeline 跑下來，硬體可低到一張 RTX 4090，三人團隊大概 6 到 10 週能上線。

但「能做」不等於「該做」。

台灣的中小企業老闆很容易把「自建 AI」浪漫化，看到一些開源模型 demo 就想立刻投錢。實際數據沒那麼好看：Gartner 預測 2026 年超過 80% 的企業會部署生成式 AI，但其中真正自建的工作負載只佔 13%，雲端 API 仍是主流。剩下 87% 的企業選擇付費叫 OpenAI 或 Anthropic 的 API，是因為自建這條路很燒錢、技術門檻也高。

這篇是技術深入文，不是「五分鐘搞懂 AI」的入門懶人包。會講具體的 target_modules 設定、QLoRA 在 70B 模型上的顯存實算、AWQ 跟 GPTQ 的 throughput 差異。先擺好讀者定位：

• 如果你是 CTO 或技術主管，這篇是給你的施工圖，可以直接拿去評估方案
• 如果你是想評估外包價值的老闆，這篇能讓你知道對方「在做什麼」、「該花多久」、「報價合不合理」
• 如果你還在猶豫該不該做，建議先讀 Fine-tuning vs RAG 的決策指南，那篇是商業決策角度，這篇是純技術角度，互補閱讀

先說結論：什麼公司值得自建、什麼公司是在燒錢

自建 LLM 在 2026 年依然是少數人的遊戲。a16z 對 100 家企業 CIO 的訪談顯示，真正執行 model fine-tuning 的企業，幾乎都同時具備這三個條件：自家有獨特的、無法用 RAG 取代的領域資料；對推論延遲與資料外洩有合規或商業壓力；以及，內部至少有一位真的懂 ML training pipeline 的工程師。三個少一個，自建多半會失敗。

我們最近幾年看過幾個典型場景：

如果你是看完上表覺得「我家狀況其實沒那麼適合」，那這篇後半部就當作技術科普讀。如果是看完更想往下走，繼續往下讀，會給你具體的施工順序。

基底模型選型矩陣：Llama 3.3、Qwen 2.5、Gemma 3 該怎麼挑

選錯基底模型，後面整條 pipeline 都會白做。這一步要看四個維度：授權條款、中文表現、生態相容性、硬體門檻。台灣企業特別在意中文，這跟矽谷團隊的選擇邏輯不太一樣。

如果你的應用會碰繁體中文，Qwen 2.5 幾乎是 2026 年的唯一解。Qwen 2.5 14B 在 HumanEval 拿到 72.5%，Llama 3.3 8B 只有 68.1%，而且 Qwen 在 CJK 語料上下功夫遠比 Meta 多，繁體中文「腔調」自然得多。我們實測過：同樣是「請寫一封商業道歉信給合作的供應商」，Llama 3.3 8B 寫出來像翻譯腔，Qwen 2.5 14B 一開口就有台灣商業書信的味道。

Gemma 3 的優勢在「小」。它的 1B / 4B 版本能塞進 RTX 3090 甚至筆電，適合做邊緣部署——例如門市的離線語音助理、車載小模型。但要做企業級任務，27B 起跳才有競爭力，而 27B 的中文又輸 Qwen 2.5。

Mistral 我們很少在台灣案場用，原因是中文太弱。它在歐洲是好選擇，但繁體環境下幾乎沒有競爭力。除非你的應用本來就是英文為主（例如國際 SaaS 產品的後台），不然不建議。

顯存怎麼算：從參數量到實際吃幾 GB

顯存（VRAM）計算是新手最容易低估的一塊。光看模型參數量乘以位元組數，會差 4 到 6 倍。微調時的真實顯存佔用，要把這四塊全算進去：模型權重、梯度、優化器狀態、激活值。

以 Llama 3 7B 為例，FP16 全微調的實際 VRAM 需求是 60 到 80GB，不是天真乘出來的 14GB。差異全在優化器（Adam 每個參數要 8 bytes 存 momentum）和梯度。所以 RTX 4090（24GB）連 7B 的全微調都跑不動。

這就是為什麼QLoRA 是 2026 年的事實標準。它把基底模型量化成 4-bit、凍結權重不更新，只訓練極少量的 adapter 參數。實際吃多少：

70B 模型用 QLoRA 微調，在 2026 年已經能在一張 RTX PRO 6000 Blackwell（96GB VRAM）上單卡完成。這在兩年前還需要 4 張 A100。Unsloth 函式庫在 2026 年又把 QLoRA 效率推進了一截——同樣的工作量，速度快 2 倍、VRAM 再省 70%。

實際估算公式（給工程師收藏）：

# QLoRA 大略估算
# 模型權重（4-bit 量化）：params × 0.5 bytes
# LoRA adapter：params × 2 × rank × 16 × 2 bytes / hidden_size（通常 ~0.5%）
# Adam optimizer：adapter_params × 8 bytes
# 激活值（依 batch_size & seq_len）：通常 4-8 GB

# 範例：Llama 3 70B QLoRA, r=16
weight_4bit = 70e9 * 0.5 / 1e9        # = 35 GB
lora_adapter = 70e9 * 0.005 * 2 / 1e9 # ≈ 0.7 GB
optimizer = 0.7 * 8                    # ≈ 5.6 GB
activations = 6                        # 經驗值
total = 35 + 0.7 + 5.6 + 6            # ≈ 47 GB（單張 H100 80GB 綽綽有餘）

這個公式不精準，但抓量級夠用。實務上會多保留 20-30% 緩衝給 dataloader、CUDA context、checkpoint。

LoRA 與 QLoRA 超參實戰：rank、alpha、target_modules 的真實影響

LoRA 看似只有三個主要超參，但每個都會嚴重影響最終效果。先講target_modules這一塊——大多數開源教學沿用 LoRA 原論文的「只訓練 q_proj 和 v_proj」，這在 2026 年已經是過時做法。

2026 年的主流做法是把所有 linear layer 都拉進 LoRA 訓練，包含 attention 的 q/k/v/o 和 MLP 的 gate/up/down。實測下，全 linear LoRA 在 instruction-tuning 任務上比 q_proj+v_proj 平均高出 3-5 個百分點，VRAM 多吃也才 10% 左右，CP 值極高。

from peft import LoraConfig

# 2026 推薦設定（Llama 3 / Qwen 2.5 / Gemma 3 通用）
lora_config = LoraConfig(
    r=16,                           # rank：起手式 16
    lora_alpha=32,                  # alpha：建議 r 或 2r
    target_modules=[
        "q_proj", "k_proj", "v_proj", "o_proj",      # attention
        "gate_proj", "up_proj", "down_proj",          # MLP
    ],
    lora_dropout=0.05,
    bias="none",
    task_type="CAUSAL_LM",
    use_rslora=False,               # 只有 r>64 才需要
)

再來是rank（r）。這個值決定 adapter 的「容量」。太小學不會、太大過擬合且不穩定。實務經驗：

• r=4-8：適合簡單任務（風格轉換、二元分類、特定 persona）
• r=16：通用 instruction-tuning 的甜蜜點，95% 場景用這個
• r=32-64：複雜推理、code generation、需要學新知識的場景
• r=128+：必須開 use_rslora=True，不然 gradient 會不穩

alpha 是個容易誤解的參數。實際縮放比例是 alpha / r，所以很多人把 alpha 拉很高想增強效果，反而讓 adapter 主導太強、灰飛湮滅了基底模型的能力。一個穩妥的做法：alpha 設成等於 r，或最多 2r。Llama 4 和 Mistral Next 這類深層模型，alpha = r 的收斂最穩定。

初始設定建議跑 r=16 / alpha=32、訓練 3 個 epoch。如果 loss 下降太慢，再考慮加 alpha 或調 learning rate（QLoRA 預設 2e-4 算偏激進，可以從 1e-4 開始試）。

資料準備才是真正的工程：SFT 格式、清洗、token 預算

跟很多人的直覺相反，自建 LLM 真正花時間的是把資料整理成模型能學的樣子，GPU 跑訓練反而是其次。一個典型專案，訓練只佔 20% 的工時，剩下 80% 全在資料 pipeline 上。

SFT（Supervised Fine-tuning）的標準資料格式是 ChatML 或 Alpaca 格式。以 Qwen 2.5 為例，每一筆資料長這樣：

{
  "messages": [
    {"role": "system", "content": "你是恆遠的客服專員，回覆要禮貌、簡潔、有重點。"},
    {"role": "user", "content": "請問你們做網站架設的報價區間是多少？"},
    {"role": "assistant", "content": "您好，網站架設專案的報價會依需求複雜度而定，一般落在 NT$8 萬到 NT$30 萬之間。建議先填寫需求單，我們可以給您更精準的估算：https://foreverwebs.com/contact"}
  ]
}

資料筆數的經驗法則：

資料品質的影響遠大於數量。Apple、Microsoft 等公司的研究反覆證明，1,000 筆高品質資料的效果，往往勝過 10 萬筆抓網路抓來的雜訊資料。我們的內部規則：每一筆資料都要有人類審核過、輸出的事實性要驗證、不能讓模型學到自相矛盾的內容。

常見地雷：

• 資料外洩個資沒清乾淨，模型會把客戶電話「背」出來，違反個資法
• 回答長度極端不平衡（80% 都是兩三句、20% 是長段落），模型會學到「該短就長、該長就短」
• Token 長度沒控制，超出 context window 被截斷，學到一半的回答
• 沒有負面樣本（負樣本 / refusal），模型遇到不該答的問題會硬答

量化選型：GPTQ、AWQ、GGUF、bitsandbytes 該怎麼挑

微調完的模型若直接用 FP16 部署，70B 要吃 140GB VRAM，根本沒辦法塞進一張 H100。量化是把模型從 FP16 壓到 4-bit、8-bit 的技術，能在「保留 90% 以上效果」的前提下，把記憶體佔用減少 3-4 倍。

2026 年最常見的四種方案，效能與品質差異很大：

簡單的決策邏輯：

• 線上服務 / API：AWQ + vLLM + Marlin kernel，這個組合是 2026 年的事實標準
• Mac Studio / 個人本地：GGUF + llama.cpp 或 Ollama
• 還在實驗階段：bitsandbytes，方便調試但別上線
• 最在意精度：AWQ 或不量化（如果 VRAM 夠的話）

一個常見誤解：很多人聽到 GGUF 名氣大就以為它最強。事實是 GGUF 是檔案格式而非量化演算法本身，它在 llama.cpp 生態裡很方便（Ollama 就是用 GGUF），但放到 vLLM 上推論速度極差——Qwen 2.5 32B 在 vLLM 用 GGUF 只能跑到 93 tok/s，比同樣模型用 AWQ 慢了 8 倍。

推論部署：vLLM、Ollama、TGI、SGLang 各自的位置

模型微調完、量化好了，最後一步是把它變成能對外服務的 API。這一步決定你的線上成本和使用者體驗。2026 年 vLLM 已經是生產環境的絕對王者，但其他方案各有適用場景。

實測數據相當驚人：Llama 3.1 70B 在 vLLM 上比 TGI 吞吐高 1.8 倍、TTFT 快 5.1 倍。Llama 3.1 405B（8 張 MI300X）vLLM 比 TGI 吞吐高 1.5 倍。所以如果你準備上生產，請務必選 vLLM——除非你的 prompt 經常超過 200K tokens，那 TGI v3 在長 prompt 仍然快 13 倍。

一個能直接照抄的 vLLM + AWQ 啟動指令（Qwen 2.5 14B AWQ 為例）：

# 假設模型在 /models/qwen2.5-14b-awq
python -m vllm.entrypoints.openai.api_server \
    --model /models/qwen2.5-14b-awq \
    --quantization awq_marlin \
    --max-model-len 8192 \
    --gpu-memory-utilization 0.92 \
    --tensor-parallel-size 1 \
    --served-model-name qwen2.5-14b \
    --port 8000

# 這樣會起一個 OpenAI 相容的 API
# 直接用 openai-python 的 SDK 把 base_url 換成 http://localhost:8000/v1 就能呼叫

關鍵調優參數：

• gpu-memory-utilization：建議 0.90-0.92，留一點給 CUDA context
• max-model-len：設成業務實際需要的長度，越長 KV cache 越大、能服務的並發數越低
• tensor-parallel-size：多卡並行時用，70B 模型在兩張 H100 上設 2
• --enable-prefix-caching：相同 system prompt 的快取，能省 30% 以上延遲，強烈建議開

評測：怎麼證明你微調出來的模型真的有變強

沒做評測的微調等於沒做。我們看過太多團隊微調完只跑了三五個 prompt 覺得「感覺有變好」就上線，結果上線之後一堆 hallucination、客戶投訴。評測這一步至少要做兩層：自動化基準和業務情境。

自動化基準

業界標準工具是 EleutherAI 的 lm-evaluation-harness，它整合超過 60 個學術 benchmark，包含中文評測（CMMLU、C-Eval、TMMLU+ for 台灣）、英文（MMLU、GSM8K、HumanEval）、推理（ARC、HellaSwag）。一條指令就能跑：

lm_eval --model hf \
    --model_args pretrained=/models/qwen2.5-14b-finetuned \
    --tasks cmmlu,gsm8k,humaneval,arc_challenge \
    --batch_size 8 \
    --output_path ./eval_results/

微調前 vs 微調後跑同一組 benchmark，三件事必須驗證：

• 目標領域分數有提升（理所當然，但很多人沒驗）
• 通用能力沒崩盤——這是 catastrophic forgetting 的徵兆，最危險
• 有害輸出（toxic / bias）的比例沒上升

業務情境測試

自動化基準分數不能代表業務效果。下一步是建立一個「黃金測試集」，最少 100 題，涵蓋你真實業務中最常見和最棘手的場景。這 100 題請業務 PM 或客服主管出題，不要工程師自己出。評分用 GPT-4o 或 Claude 4.7 當 judge 就好（成本一次幾百塊台幣，比人類標註便宜 100 倍）。

MT-Bench 是一個常見的多輪對話 benchmark，用強模型當裁判給 1-10 分。MT-Bench 已經是業界事實標準，特別適合用來評估對話品質和指令跟隨能力。

一個 7B 自建專案的真實成本拆解

撇開大公司，看一個典型的中小企業案場：Qwen 2.5 7B 微調 + AWQ 量化 + vLLM 部署，做一個內部專屬的客服 / 知識問答系統。從 0 到 1 完整跑下來，台灣市場行情大致如下：

對照組——同樣場景用 GPT-4o API 做 RAG：

• 初期建置成本：5-15 萬（純工程，不需要硬體和訓練）
• 月 API 費用：以日均 1,000 次對話估算約 NT$ 6,000-15,000 / 月
• 首年總成本：約 12-35 萬

結論不意外——自建第一年通常貴 1.5-3 倍。但有兩個拐點會讓自建變划算：對話量持續成長到每月 5 萬次以上，API 費用會超過自建的伺服器月租；或是有合規 / 資料外洩的硬需求，那就無關 ROI。

詳細的 TCO 對照可以參考我們之前寫的自架 AI vs API vs SaaS 決策樹，那篇有把三條路徑的 3 年 TCO 攤開算給你看。

老闆視角：要不要養團隊？什麼時候該外包？

這一段給的是商業決策框架，不是技術內容。如果你正在評估報價或考慮要不要養一個 AI 團隊，請繼續看。

自建 LLM 對中小企業最大的隱性成本是「人」。一個能完整跑這條 pipeline 的工程師，台灣 2026 年的市場行情月薪是 18-35 萬，年薪兩百多萬。而且很難招，104 數據顯示 56% 的企業反映 AI 人才嚴重不足。要養兩三個這種人，光人事年支出就 600 萬起跳。

實務上比較常見的選擇有三條路：

我們做過很多次第三種——公司內部找一個懂業務的 PM，技術交給外部團隊執行。原因很單純：自建 LLM 一年裡真正需要「全力衝刺」的時間大概 3-6 個月，剩下時間是維運和小幅優化。養兩個工程師全年坐板凳並不合理；但完全外包又會讓知識在公司外、未來想 in-house 接手很痛。

如果你正在評估外包報價，有幾個訊號可以判斷對方是不是真懂：他會不會問你的資料樣態和量、會不會主動建議「先用 RAG 試一個月再決定要不要微調」、會不會提出明確的評測方案。會問會建議的，多半是內行；上來就賣你 70B 模型的，多半是把案子報大想多收錢。

恆遠的做法是先用兩週做 POC，跑通 RAG 跟 LoRA 兩條路的效果對比，再給客戶看數據決定要走哪條。如果你正在評估這類專案，可以直接聯絡我們做免費的技術需求釐清，至少讓你拿著對的問題去問廠商。

常見問題 FAQ

結語：技術選對了，剩下的是運營耐力

自建 LLM 在 2026 年技術上已經不是高牆。基底模型免費、QLoRA 把硬體門檻拉到一張消費級顯卡、vLLM 把部署複雜度大幅降低。三個人的小團隊，六到十週能把一條 pipeline 跑通。但「能跑通」不等於「能穩定服務」——後面 1 到 3 年的運營、重訓、評測、版本管理，才是 80% 的工程量。

給技術主管的建議：先別急著選模型，先把「我們的資料能做出什麼差異化」想清楚。如果你的資料 RAG 就能搞定，自建是浪費錢。但如果你有別人沒有的資料、有不能外送的合規要求、有想做的口吻或行業專屬能力，那這條路值得走。

給老闆的建議：別被「自建 AI = 高科技公司」這種行銷話術帶風向。OpenAI 跟 Anthropic 的模型已經夠強到讓多數企業靠 API 就能做出 80 分產品。自建是為了拿那 90 分以上，且願意為此付 10 倍時間和錢。如果你的競爭壓力沒到那個程度，先把錢花在資料治理和產品設計，比花在訓練上更有 ROI。

想評估這條技術路徑的可行性，或想找團隊執行 POC？我們提供 AI 顧問諮詢與客製化開發服務，從技術選型、POC 到正式上線一條龍。也可以直接聯絡我們聊聊，恆遠專注做 AI 與系統的客製化開發，能幫你判斷什麼該做、什麼不該做。

如果你正在評估「地端 agent vs 雲端 API」的硬體採購決策，可以延伸讀：Dell PowerRack 與 Deskside Agentic AI 完整解析，那篇針對金融、醫療、律師事務所這類資料敏感型中小企業，拆解 Dell 2026/5 在 Tech World 端出的 PowerRack 與 Deskside 兩款地端 AI 主機，含 24 個月 TCO 比較與外包合約紅線。