Day 07：LLM 原理速成——token 經濟與成本的真相

今天只聚焦在 Token 怎麼計價、生成怎麼進行、模型怎麼選這三件事，會直接影響你系統設計與帳單，也可能導致容易做出錯誤架構決策的部分。

本篇不會重講 Transformer 的數學（網路上已有太多好文章）。加上前兩天說明了「工程」與「ML」，今天說明「LLM」進行打底。

今天要解決的問題

一個假設但真實的對話：

主管：「我們的 AI 客服上個月花了多少？」 工程師：「大概……三萬多？」 主管：「為什麼比上個月多一倍，使用量只多了 20%？」 工程師：「……我查一下。」

查出來的原因通常是這幾個之一：有人把整份 FAQ 塞進系統提示、對話歷史沒有裁剪所以越滾越長、或是模型輸出沒有設上限，某些請求生成了兩千字的長篇大論。

這三個原因，都源自不理解 token 經濟。

📊 職缺訊號

「生成式 AI 部署與 LLMOps」出現在 38.7% 的生成式 AI 職缺中，而成本控制是其中最常被寫進 JD 的具體職責之一。原因很現實：LLM 應用的邊際成本不是零——這跟傳統軟體「寫完就幾乎免費複製」的直覺完全相反，也是最多團隊在 PoC 成功後、規模化時踩到的牆。

---

一、現象：帳單的兩個真相

圖 7-1：token 經濟的兩個真相（依常見計價結構與單 token 產生時間推算的示範值）。左圖：一次請求的 token 組成，最貴的常是固定前綴與輸出。右圖：延遲結構中 prefill 幾乎固定、decode 隨輸出長度線性成長。

真相一：輸出比輸入貴，通常是 4~5 倍左右。 所以一段 400 token 的回答，成本相當於 2,000 token 的輸入。這代表「請用三句話回答」不只是體驗優化，也是成本優化。

真相二：你以為免費的固定前綴，是最大的支出。 上圖中 5,000 token 的系統提示與 few-shot 範例，每一次請求都要付一次錢。每天 5 萬次請求，就是 2.5 億 token——這通常比使用者實際輸入的部分貴上幾十倍。

好消息是：這一段正好是最容易優化的（Day 26 會談 prompt caching，可省下約 55%）。

二、原理：三個你必須有感覺的概念

2.1 Token 不是字

Token 是模型的最小處理單位，透過 BPE（Byte Pair Encoding）之類的演算法切出來。粗略的直覺：

語言	大約換算	意義
英文	1 token ≈ 4 字元 ≈ 0.75 個單詞	最省
繁體中文	1 個字 ≈ 0.6–1.5 token（依模型而異）	中文通常比英文貴
程式碼	縮排、符號都吃 token	比想像中貴
JSON	大量括號與引號	結構化輸出的隱藏成本

這對台灣的實務有直接影響：同樣一份文件，中文版的 token 數常常比英文版多。做成本估算時，別直接套用英文的換算比例。

2.2 生成分兩個階段：prefill 與 decode

圖 7-2：LLM 推論的兩階段結構（示意流程）。Prefill 決定「等多久才看到第一個字」，Decode 決定「字出得快不快」。

這個區分很重要，因為它解釋了兩件事：

1. 為什麼串流（streaming）能大幅改善體驗：使用者在首字延遲時間 (TTFT) 之後就開始看到字，不用等整段生成完。實際總時間沒變，但感受完全不同（Day 17 會實作）。
2. 為什麼長輸入不太影響「速度」但影響「等待」：prefill 是平行的、算得快；decode 是序列的、慢。所以「輸入 8,000 token、輸出 100 token」比「輸入 500 token、輸出 1,000 token」快得多。

2.3 KV cache：為什麼併發上不去

Decode 時每產生一個 token 都要參考前面所有 token，為了不重算，模型把中間狀態存起來，這就是 KV cache。它的大小是：

KV cache = 2 × 層數 × KV head 數 × head_dim × 位元組數 × 序列長度 × 批次大小

以 8B 級模型（32 層、8 個 KV head、head_dim 128、fp16）計算，每個 token 每條序列約 128 KiB。看起來很小，但乘上長度與併發就很可觀：批次 16、序列 8,192，KV cache 就要約 17 GB——加上 16 GB 的權重，一張 80GB 的卡也只是剛好夠用。

這就是「為什麼我的 GPU 明明還有記憶體，併發卻上不去」的答案。Day 26 會完整處理。

三、動手：算出你自己的帳單結構

與其看別人的估算，不如算你自己的。這段程式碼不需要 GPU：

"""估算 LLM 應用的成本結構——把假設攤開來，才知道要優化哪裡。"""
# 以「每百萬 token」為單位的相對單價（用相對值，避免綁定特定供應商報價）
PRICE_IN, PRICE_OUT, PRICE_CACHED = 1.0, 5.0, 0.1

req = {
    "系統提示＋few-shot": 5000,   # 固定前綴，每次都送
    "檢索脈絡":            3000,   # RAG 取回的內容
    "對話歷史":            1500,
    "使用者輸入":           100,
}
output_tokens = 400
daily_requests = 50_000

in_tokens = sum(req.values())
cost_in = in_tokens * daily_requests / 1e6 * PRICE_IN
cost_out = output_tokens * daily_requests / 1e6 * PRICE_OUT
print(f"每日輸入成本：{cost_in:>8.1f}（{in_tokens} token/次）")
print(f"每日輸出成本：{cost_out:>8.1f}（{output_tokens} token/次）")

# 優化一：固定前綴命中 prompt caching
cached = req["系統提示＋few-shot"]
cost_in_cached = ((in_tokens - cached) * PRICE_IN + cached * PRICE_CACHED) \
                 * daily_requests / 1e6
print(f"啟用前綴快取後：{cost_in_cached:>6.1f}"
      f"（省 {(1 - cost_in_cached / cost_in):.1%}）")

# 優化二：輸出長度砍半
print(f"輸出減半後：{cost_out / 2:>10.1f}（省 {cost_out / 2:.1f}）")

執行結果會告訴你一件事：在多數 RAG 應用中，「固定前綴」與「輸出長度」這兩個旋鈕的效果，遠大於換一個便宜模型。 先轉這兩個旋鈕，再考慮換模型。

四、取捨：模型選型的四個維度

2026 年的模型地景大致分兩個陣營，選擇時看四個維度：

維度	閉源 API（如 Claude、GPT、Gemini）	開放權重自建（如 Llama、Qwen、Mistral）
起步成本	幾乎為零，當天就能上線	需要 GPU 與工程投入
邊際成本	隨用量線性成長	前期固定成本高，量大後單位成本低
資料主權	資料離開組織（需檢視供應商條款）	完全自控，適合金融、醫療、半導體內網
客製深度	受限於供應商提供的微調介面	可完整微調、量化、改推論引擎

4.1 順帶談談幻覺：它不是 Bug，是機制的一部分

既然要做應用，就必須理解為什麼 LLM 會一本正經地胡說。

原因藏在訓練目標裡：語言模型被訓練來預測「下一個最合理的 token」，而不是「說真話」。當模型對某個事實沒有足夠的訓練訊號時，它不會停下來說「我不知道」——它會產生一個在語言上最通順的答案。通順與正確是兩件事，而模型只被獎勵了前者。

這個認知會直接改變你的架構決策：

錯誤的期待	正確的做法
「換更強的模型就不會胡說了」	更強的模型幻覺較少，但不會歸零；架構上必須假設它會錯
「在提示裡寫『不要編造』就好」	有幫助但不可靠；要給它可依據的來源（RAG，Day 18–20）
「使用者自己會判斷」	流暢的錯誤答案最難被察覺；要強制引用來源讓使用者可驗證
「上線後再看看」	要先建評測集量化幻覺率，才知道能不能上線（Day 24）

換句話說：幻覺不是靠「調教」解決的，是靠系統設計解決的——給依據、要引用、能拒答、有評測。這四件事分別對應本系列的 Day 18、20、20、24。

💡 一個務實的起手式

先用 API 把產品做對，再談要不要自建。 理由是：多數專案在做對之前就死了，而自建的工程成本會拖慢你驗證產品的速度。等到用量穩定、且能算出「自建的損益平衡點」（Day 15、26 會給算法）再說。

唯一的例外是資料主權——如果法規或客戶合約明確不允許資料外流，那從第一天就要走自建路線，沒有折衷。

---

今日小結

• 從「軟體工程」到「系統資源邊際成本」的思維轉變： 傳統軟體開發的邊際成本趨近於零（Code 一寫好即可無限次免費執行）；但 LLM 應用的核心邏輯在於「每一次生成都是一次矩陣乘法與 VRAM 存取」。
• GenAI 工程師必須具備硬體感知（Hardware-Aware）與經濟成本感知，架構設計的本質是在「延遲、成本、準確度」三者間尋求最優解。
• 輸出 token 通常比輸入貴約 5 倍，控制輸出長度是最有效的省錢手段之一。
• 固定前綴是隱藏的最大支出，也是最容易用 prompt caching 優化的部分（可省約 55%）。
• 生成分 prefill（快、平行） 與 decode（慢、序列）：這解釋了串流為何有效、長輸入為何不太拖慢速度。
• KV cache 每 token 約 128 KiB（8B 級模型），乘上長度與併發就會吃光顯存——這是併發上不去的真正原因。
• 中文的 token 換算比英文貴，做成本估算時別直接套英文比例。
• 模型選型看四個維度；先用 API 做對產品，除非資料主權不允許。

文章限制

1. 簡化了 KV Cache 的優化演算法現況： 文中假設 KV Cache 會隨長度與頭數完全線性膨脹，但現代推論引擎早已廣泛採用 GQA（Grouped-Query Attention）、PagedAttention（vLLM）以及 KV Cache 量化（INT8/INT4），實際顯存佔用可獲得大幅舒緩，計算估算過於保守。
2. 忽略了不同 Tokenizer 對中文壓縮率的極大差異： 「中文通常比英文貴」在舊型 Tokenizer（如 early GPT-3.5）非常明顯；但較新的模型（如 Qwen2.5、Llama 3 擴充詞表後）對繁簡中文的壓縮率已顯著提升，不可一概而論，實作時應針對具體模型的 Tokenizer 進行測試。
3. 未納入 Speculative Decoding 與 FlashAttention 等推論加速變數： Prefill 與 Decode 的延遲估算忽略了投機解碼（Speculative Decoding）與 FlashAttention-2/3 對 TTFT 與 Decode 速度的優化影響，為了文章可讀性，僅將推論時間簡化為純粹的 Token 長度線性關係。

延伸閱讀

• 📄 Attention Is All You Need (Vaswani et al., 2017)：Transformer 架構的開山之作，理解 Self-Attention 機制的必讀論文。
• 📄 Scaling Laws for Neural Language Models (Kaplan et al., 2020)：研討模型參數、資料量與算力擴展規律的經典論文。

---

← Day 06 ｜ Day 08 →

本文同步發布於 iThome 鐵人賽；Blog 版本為站內閱讀與系列導覽的主要版本。