輸入 token
3 秒看懂
輸入 token 是大語言模型（LLM）接收並理解的最小語義單元——可以把它們想像成模型“閱讀”時的基本單詞或子詞。你給模型多少輸入 token，就直接決定它一次能“看見”多少上下文，也直接影響每次呼叫的計算開銷與延遲。
一句話輔助記憶：輸入 token 是大型模型與物理世界互動的“計量量子”——既是模型目光所及的單位，也是計算成本與產品體驗必須精密平衡的支點。
3 分鐘產業解釋
在大型模型 API（如 GPT‑4、Claude、Gemini）的商業化中，“輸入 token”是定價和效能的核心維度。
計費模型的底層邏輯
API 通常按“每百萬輸入 token”收費，輸入價格一般遠低於輸出價格（約為輸出的 1/5 到 1/10）。這一價差根源於推論中預填充階段的高並行度帶來的計算效率優勢。然而，實際應用中長文件、多輪對話場景往往導致輸入 token 總量遠超輸出，成為成本主體。以客戶支援類 Agent 為例，每次請求可能攜帶完整產品手冊（數萬 token）作為上下文，而輸出僅為數十字的簡短回答，此時輸入成本可佔總 API 費用的 85% 以上。
上下文視窗的競爭地位
模型訓練和推論時能容納的最大輸入 token 數（如 128K、1M tokens）已成為產品競爭力的硬指標。截至 2025 年初，主流旗艦模型的視窗引數如下（資料來源：各公司官方技術文件與公開定價頁）：
| 模型/系列 | 上下文視窗 | 輸入價格（$ / 1M tokens） | 釋出/更新時間 |
|---|---|---|---|
| GPT‑4 Turbo | 128K | 10.00 | 2024 年 |
| Claude 3.5 Sonnet | 200K | 3.00 | 2024 年 Q3 |
| Gemini 1.5 Pro | 1M（正式） / 2M（實驗） | 1.25（≤128K tokens 部分） | 2024 年 |
| LLaMA 3.1 (70B) | 128K | 開源，推論價格視部署方案 | 2024 年 7 月 |
| Qwen 2.5 | 128K | 開源 | 2024 年 9 月 |
注：具體價格可能隨促銷與套餐調整，以上為各平台官網公佈的標準費率。
系統層面的連鎖反應
輸入 token 數量上升會引發 Transformer 注意力機制的二次方複雜度問題，推高推論延遲、GPU 視訊記憶體（尤其 KV cache）和能耗，倒逼硬體（HBM 容量、高頻寬互聯）與演算法（稀疏注意力、長上下文外推）協同進化。
15 分鐘專家深入：技術原理
從技術鏈路看，輸入 token 連線了“文本 → 嵌入 → 計算”三步。以下按資料處理流展開，並逐層揭示關鍵設計取捨。
階段一：分詞——由文本到 Token ID
分詞器將原始文本切分為 token ID 序列。這一步驟是所有後續計算的入口，其質量直接影響模型對語言的理解效率與單次請求的經濟性。
核心演算法族：
- BPE（Byte Pair Encoding）：自 Sennrich 等（2016）引入神經機器翻譯後，被 GPT 系列廣泛採用。訓練時從字元開始，反覆合併最高頻的相鄰符號對，最終形成合並規則集。編碼時貪婪應用規則，將文本拆分為子詞單元。現代變體多為 byte‑level BPE，確保任何 Unicode 輸入均可編碼，徹底消除“集外詞（OOV）”問題。
- WordPiece：Google 用於 BERT，基於似然最大化選擇合併對——每次合併選擇能最大提升訓練語料語言模型機率的符號對。計算成本高於 BPE，但理論上在相同詞表大小下資訊密度更優。
- Unigram LM / SentencePiece：先訓練一個較大的種子詞表，再通過機率化刪除字元逐步剪枝，保留最可能的分詞方案。T5、XLNet、LLaMA 等模型採用。SentencePiece 直接處理原始文本（不依賴預分詞），對多語言尤其友好。
分詞示例（以 GPT‑4 風格 BPE 為例，英文）：
原始文本："The transformer revolutionized NLP"
可能切分："The" | " transform" | "er" | " revolutionized" | " NLP"
Token IDs: [576, 43264, 298, 78532, 4633]同一單詞“transformer”被拆為“transform”和“er”，說明 token 並非字面意義上的“單詞”。
階段二：嵌入與位置編碼
分詞器輸出的 [1, n] 維 token ID 序列，經過嵌入層（Embedding）對映為 [n, d_model] 的稠密向量矩陣。嵌入層本質是一個可訓練的查詢表，引數規模為 V × d_model（V 為詞表大小），通常在數十億到數百億量級。
位置編碼隨後注入序列順序資訊。主流方案：
- RoPE（Rotary Position Embedding）：在注意力計算中對 Q、K 施加旋轉變換，使內積僅依賴相對位置差。LLaMA 系列、Qwen 等採用。天然支援通過插值等方式擴充套件上下文。
- ALiBi（Attention with Linear Biases）：不學習位置嵌入，直接在注意力分數上疊加線性偏置（距離越遠偏置越負），賦予模型天然的長度外推能力。
- 絕對位置編碼：原始 Transformer 使用 sine/cosine 固定編碼，GPT‑3 使用可學習位置嵌入。隨著上下文視窗擴張，這些方案逐漸在被 RoPE 及其變體替代。
嵌入與位置編碼的輸出矩陣 X ∈ R^{n×d} 構成後續所有 Transformer 層的輸入。
階段三：Transformer 計算
給定 n 個輸入 token，每層自注意力的核心運算：
Q = X·W_Q, K = X·W_K, V = X·W_V # X: [n, d_model]
Attention(Q, K, V) = softmax(Q·K^T / √d_k)·V計算複雜度：Q·K^T 產生 [n, n] 注意力矩陣，FLOPs ≈ 2·n²·d_k·num_heads（不含 softmax 和 V 的乘法）。前饋網路（FFN）對每個 token 獨立計算，複雜度為 O(n·d_model·d_ff)。因此，當輸入 token 數 n 較大時，注意力部分迅速成為主導——這是經典的“二次方瓶頸”。
KV Cache 與視訊記憶體壓力：在自迴歸解碼中，每次僅輸入新 token，但需訪問歷史上所有 token 的 K、V 以避免重算。快取大小：
KV_cache_bytes = 2 · batch_size · n · num_layers · d_head · num_heads · precision_bytes以 FP16 精度、n=128K、batch_size=1、典型 70B 引數模型（如 LLaMA 3 70B，80 層、64 頭、d_head=128）為例：
KV_cache ≈ 2 × 1 × 128000 × 80 × 128 × 64 × 2 bytes
= 2 × 128000 × 80 × 16384 bytes
≈ 335 GB這一數字已遠超單張 H100（80GB HBM3）的視訊記憶體容量，實際部署中需依賴多卡張量並行或減少可用上下文。
階段四：預填充與解碼的工程分離
推論過程在工程上分為兩個性質迥異的階段：
- 預填充（Prefill）：一次性攝入全部輸入 token，平行計算所有層的注意力，生成首 token 並快取每層 K/V 狀態。計算是 GPU 高度友好的矩陣乘法，但
O(n²)特性使延遲隨輸入長度非線性增長。以 128K 輸入為例，預填充延遲可達數十秒（未最佳化時）。 - 解碼（Decode）：每次僅輸入新生成的一個 token，利用快取 KV 計算當前 token 的注意力與 FFN。此時計算量變為
O(n·d)，但需反覆讀取完整 KV cache，瓶頸由算力變為視訊記憶體頻寬。輸入 token 越多→KV cache 越大→解碼速度越慢（token/s 下降）。
效能資料示例（基於 vLLM v0.4.0 推斷，H100，LLaMA 3 70B FP16）：
| 輸入長度 | 預填充延遲（s） | 解碼吞吐（tokens/s） | KV Cache 佔用（GB） |
|---|---|---|---|
| 4K | ~0.02 | ~45 | ~10.5 |
| 32K | ~0.8 | ~38 | ~84 |
| 128K | ~12 | ~25 | ~335 |
注：以上為基於公開系統引數的理論推估值，具體值取決於架構最佳化程度與並行策略，僅供參考量級。實際 Benchmark 資料建議查閱 vLLM 與 TensorRT‑LLM 官方技術報告。
計算圖簡化示意
輸入文本（Unicode 字串）
│
▼
分詞器 ──► token IDs [1, n]
│
▼
嵌入層 + 位置編碼 ──► X [n, d]
│
▼
┌─────────────────────────────────┐
│ Layer 1..L │
│ ┌─ Multi-Head Self-Attention ─┐│
│ │ Q·K^T [n,n] → Softmax → ·V ││ ← O(n²·d)
│ └────────────────────────────┘│
│ ┌─ Feed Forward (per token) ─┐│ ← O(n·d²)
│ └────────────────────────────┘│
└─────────────────────────────────┘
│
▼
語言模型頭 ──► 預測下一個 token 機率（[V] 分佈）關鍵引數
評估輸入 token 相關的模型效能與部署成本時，以下引數構成核心決策架構：
| 引數名稱 | 定義 | 典型值/範圍 | 重要性說明 |
|---|---|---|---|
| 上下文視窗（Max Context Length） | 模型單次可接收的最大輸入 token 數 | 8K ~ 1M+（2025 年初） | 直接決定可用輸入長度上限，是產品選型首要指標 |
| 分詞效率（Chars per Token） | 平均每個 token 編碼的字元數 | 英語：3.5 | 相同字元數下，該值越高 token 消耗越少、成本越低 |
| 詞表大小（Vocabulary Size） | 分詞器可識別的唯一 token 數量 | 32K ~ 256K | 越大則平均每個 token 編碼字元越多，但嵌入層引數隨之膨脹 |
| 預填充吞吐（Prefill Throughput） | 每秒可處理的輸入 token 數 | H100 上約 1K~10K tokens/s（依賴長度和目標模型） | 影響首 token 延遲，長輸入場景的關鍵體驗指標 |
| KV Cache 記憶體佔用 | 每增加 1K 輸入 token 所需額外視訊記憶體 | 典型 70B 模型約 2.6 GB/1K tokens（FP16） | 直接制約併發數與最大序列長度 |
| 首 token 延遲（Time to First Token, TTFT） | 從請求傳送到第一個生成 token 返回的時間 | 4K 輸入 <1s，128K 輸入可達 10~30s | 使用者體驗的直接感知維度，長輸入下為核心痛點 |
| 有效上下文利用率 | 模型對長文本不同位置資訊的實際關注度 | 中段位置通常衰減 20%~50%（Lost in the Middle 效應） | 僅視窗“夠大”不等於模型能“讀全”，需輔助評測 |
| 輸入價格 | API 呼叫中每百萬輸入 token 的收費 | $0.15 ~ $10 / 1M tokens（2025Q1） | 直接影響總成本，應結合預計請求長度與頻次計算 |
其中 KV Cache 記憶體佔用 =
2 × n × num_layers × d_head × num_heads × precision_bytes，具體推導見“技術原理”章節。建議使用者在選型時根據目標最大序列長度預估算視訊記憶體需求。
技術路線與對比
輸入 token 的處理方案可從“分詞演算法”與“長上下文擴充套件”兩個維度展開對比。
路線一：分詞演算法對比
| 維度 | BPE（GPT 風格） | WordPiece（BERT 風格） | Unigram（T5/LLaMA 等） |
|---|---|---|---|
| 核心原理 | 貪心合併最高頻位元組對 | 似然最大化選擇合併對 | 機率化詞表剪枝 |
| 常見詞表大小 | 32K~100K（LLaMA2 32K, GPT‑4 ~100K） | 28K~32K（BERT 30K） | 32K~256K |
| 平均字元/Token 比（英） | 約 4.0 | 約 4.5 | 約 3.5~4.0 |
| OOV 處理 | 位元組級回退，徹底無 OOV | 拆為字元，基本無 OOV | 支援字元回退 |
| 訓練速度 | 快（貪心合併） | 較慢（需多輪似然評估） | 慢（需訓練 LM 並剪枝） |
| 多語言友好度 | byte‑level BPE 較好 | 需特殊預處理 | SentencePiece 原生支援多語言 |
| 代表模型 | GPT‑2/3/4、Claude 系列 | BERT、ALBERT | T5、XLNet、LLaMA、Gemma |
趨勢研判：BPE 系因訓練簡便、OOV 處理魯棒，已成為當前大型模型（尤其 GPT/Claude 系）的主流選擇。Unigram/SentencePiece 在開源社群有廣泛應用（LLaMA 系列），二者在分詞效率上的差距正逐漸縮小。字元/Token 比受語種影響顯著——中文使用者在選擇模型時應特別關注自身應用的主要語言，可比對同文本在不同分詞器下的 token 消耗實測資料。
路線二：長上下文擴充套件技術對比
| 技術 | 原理 | 優點 | 缺點 | 代表工作/模型 |
|---|---|---|---|---|
| RoPE 線性插值 | 將位置索引等比縮放至原訓練範圍 | 實現簡潔，零額外訓練 | 高頻資訊丟失，遠距離分辨力下降 | 早期 LLaMA 擴充套件方案 |
| NTK‑aware 插值 | 低維高頻區少縮放，高維低頻區多縮放 | 保留更多區域性資訊，擴充套件效果更好 | 實現略複雜 | LLaMA‑2‑7B‑32K 等 |
| YaRN | NTK‑aware + 溫度係數控制注意力熵 | 進一步穩定超長上下文注意力 | 需微調適配溫度引數 | LLaMA 2 128K 微調 |
| ALiBi | 不學習位置嵌入，線上性衰減偏置 | 天然外推，不依賴位置嵌入訓練 | 固定偏置形式犧牲部分靈活性 | BLOOM、早期 Anthropic 模型 |
| 稀疏注意力 | 限制 token 僅關注區域性或特定模式的遠距離 token | 降低 O(n²) 複雜度至 O(n log n) 或 O(n√n) | 資訊丟失風險，工程實現複雜 | Longformer、BigBird |
| 狀態空間模型（SSM） | 用線性時不變系統替代注意力（如 Mamba） | 複雜度降為 O(n)，理論上無限長度 | 在部分密集檢索任務上精度落後於注意力 | Mamba、Mamba‑2、Jamba |
趨勢研判：2024~2025 年，RoPE + NTK‑aware 插值/YaRN 已成為開源社群擴充套件上下文的主流範式，讓 8K 基礎模型通過輕度微調就具備 128K 甚至 1M 視窗。狀態空間模型作為“注意力替代”的方案正在快速追趕，但在需要精確長程依賴的複雜推論任務上仍有差距。混合架構（如 Jamba 交錯注意力層和 Mamba 層）可能是中期方向。
上下游產業鏈分析
輸入 token 的技術生態可以沿“上游資料與演算法 → 中游模型與引擎 → 下游應用與硬體”展開，以下按鏈條逐層梳理：
上游：資料、分詞器與訓練基礎設施
- 多語言語料庫建設：分詞器訓練需要大規模、多領域、高質量語料，覆蓋目標應用涉及的主要語種。資料清洗（去重、去噪、格式規範化、敏感資訊過濾）是生產級分詞器的關鍵前置工序。公開未見統一的語料質量標準，主流模型公司通常自建資料集且不對外開放。
- 分詞器訓練工具鏈：以 Hugging Face
tokenizers庫（Rust 實現）為代表，支援 BPE、WordPiece、Unigram 等多種演算法的高效訓練。部分團隊使用 Google 開源的 SentencePiece 獨立訓練。訓練速度：在典型伺服器上，從數十 GB 語料訓練一個 100K 詞表的 BPE 分詞器通常在數小時內完成。 - 位置編碼設計：RoPE 及其擴充套件方案正成為事實標準。理論上，位置編碼的選擇直接決定後續能否以輕量方式擴充套件上下文，是上游基礎研究的重要課題。
- 長序列資料處理管線：針對超長文件的切分、語義分段、overlap 視窗設計、後設資料注入等，是讓模型有效理解長輸入的“預處理軟工程”。
中游：模型架構與推論引擎
- 模型架構：自注意力機制仍是主流，但稀疏注意力、SSM、混合模型正在分流。模型架構選擇直接決定了輸入 token 數量的邊際成本曲線——是
O(n²)還是O(n log n)或O(n)。 - 訓練架構最佳化：長序列訓練依賴序列並行（如 Megatron‑LM 的序列並行）、啟用檢查點與重計算策略，以在有限視訊記憶體內完成數千 token 長序列的反向傳播。ZeRO 系列最佳化（DeepSpeed）被廣泛使用。
- 推論引擎：vLLM（PagedAttention 技術，將 KV Cache 以非連續頁式管理，提升視訊記憶體利用率）、TensorRT‑LLM（支援 FP8、多頭注意力融合）、llama.cpp（追求在消費級硬體上執行長上下文模型，支援 mmap 載入）構成了當前三大主流推論架構。各架構對長上下文的支援程度成為差異化競爭要點。
下游：API 服務、產品形態與硬體需求
- API 服務定價：按輸入/輸出 token 分別計費已成行業慣例。部分廠商（如 Anthropic）對超長輸入給予特定折扣或採用階梯定價（前 128K 一個價，超量部分優惠）。快取命中（相同字首多次請求僅計費一次）是重要成本最佳化手段，截至 2025 年初，OpenAI 與 Anthropic 均支援自動/手動快取。
- 產品功能：超長文件 QA、法律文書分析、全量程式碼庫理解、Agent 長會話記憶等場景直接受益於大視窗。部分企業將“上下文視窗大小”作為市場宣傳的核心賣點，向非技術客戶溝通“一次能處理的檔案頁數”。
- 硬體需求牽引：長序列推論對視訊記憶體需求顯著提升。HBM 容量（H100 80GB、H200 141GB）和視訊記憶體頻寬（HBM3/HBM3e）成為推論卡選型的硬約束。B200（預計 2025 年量產，搭載 192GB HBM3e）正是對這一需求的回應。ADVANCED PACKAGING（CoWoS）產能直接制約高階 GPU 供給，截至 2024 年底，台積電 CoWoS 產能仍偏緊但正在擴張中。
受益公司與市場格局
以下從模型廠商、硬體供應商、工具鏈平台三個層次梳理主要受益方。所有資訊基於公開財報、官方公告及產業報告，截至 2025 年初。
模型廠商
| 公司 | 核心模型/系列 | 最大上下文視窗 | 輸入 Token 定價策略 | 競爭優勢 |
|---|---|---|---|---|
| OpenAI | GPT‑4 Turbo / GPT‑4o | 128K | $10/1M tokens（GPT‑4 Turbo） | 率先量產 128K，生態完整，市場份額領先 |
| Anthropic | Claude 3.5 系列 | 200K | $3/1M tokens（Sonnet） | 上下文更長，價格更低，企業文件場景滲透快 |
| Google DeepMind | Gemini 1.5 Pro | 1M（正式）/2M（實驗） | $1.25/1M tokens（≤128K） | 最大標稱視窗，MoE 降本，與 GCP 生態深度整合 |
| Meta | LLaMA 3.1 (8B/70B/405B) | 128K | 開源，按部署成本 | 社群生態活躍，開源模型中標杆位置 |
| 阿里雲端 | Qwen 2.5 系列 | 128K | 開源 + 雲端 API | 中國市場份額突出，多語言適配 |
| Mistral AI | Mistral Large / Small | 128K / 32K | $4~8/1M tokens（2024Q4） | 歐洲合規需求獨特定位，多語種覆蓋 |
| xAI | Grok 系列 | 公開資料未見明確上限 | 隨 X Premium 捆綁 | 與社交平台深度整合，差異化分發渠道 |
定價為公開標準費率，實際企業採購可能存在定製合約價。
硬體供應商
- 輝達（NVIDIA）：其 GPU（H100/H200/B200）佔據長上下文推論訓練市場的主導份額。HBM 容量是推論卡 ASP 提升的關鍵驅動力。2024 財年（截至 2024 年 1 月）資料中心營收超 475 億美元（來源：NVIDIA FY2024 財報）。
- AMD：Instinct MI300X 搭載 192GB HBM3，容量超過 H100，正試圖在推論負載中替代輝達。出貨量資料公開資料未見細分到長上下文推論場景。
- SK 海力士 / 三星 / 美光：HBM 的三大供應商。SK 海力士為 HBM3/HBM3e 主要供應商，三星與美光積極擴產。2025 年 HBM 產能仍被視為高階 AI 晶片供給的瓶頸環節。
推論服務與工具鏈
- Anyscale / Modal / Together AI：提供基於 vLLM 等架構的 LLM 推論即服務，間接受益於企業自部署長上下文模型的需求增長。具體營收與份額資料公開資料未見。
- Hugging Face：tokenizers 庫、transformers 生態系統為全球最大比例的模型提供了分詞與推論基礎設施，間接設定行業部分標準。
- vLLM（UC Berkeley 開源）：PagedAttention 技術成為長上下文推論的事實標準記憶體管理方案之一，被多家商業推論服務採用。
市場規模與增長趨勢
輸入 token 本身不構成獨立市場，但作為 LLM API 呼叫量與推論硬體開銷的核心計量單位，其規模可從 API 市場、推論晶片市場、以及長序列專用需求三個口徑側面度量。以下資料基於公開研究機構報告與企業財報中的關聯揭露。
API 推論市場
- 全球 LLM API 推論市場規模：據 Grand View Research 與 Statista 資料交叉參考，2024 年約在 60
90 億美元區間，預計 2030 年達 400600 億美元水平（CAGR 約 35%~40%）。該市場規模直接由 token 處理量（輸入+輸出）驅動。 - 輸入 token 佔比：據多家推論服務商非正式揭露（Semianalysis、Anthropic 技術部落格），企業級應用中輸入 token 佔總 token 量的比例通常在 70%~85%，在 RAG（檢索增強生成）、長文件分析、Agent 長會話等場景佔比更高。因此，可以粗略推斷輸入 token 相關營收佔 API 推論市場的 70% 以上。
推論硬體市場
- AI 加速器市場：據 IDC 與 Mercury Research 估計，2024 年全球 AI 晶片銷售額約 900~1100 億美元（含訓練與推論）。其中推論所佔份額持續上升，預計到 2027 年推論佔比將超過訓練。
- HBM 市場：據 TrendForce，2024 年全球 HBM 市場規模約 180
220 億美元，預計 2025 年達 280350 億美元。大視窗推論對 HBM 容量需求是增量驅動之一，具體精細化測算公開資料未見。
長上下文專項需求（定性）
- RAG 系統：儘管 RAG 理論上可降低對模型原生長上下文的依賴，但實踐中企業越來越傾向於“RAG + 大視窗”組合——用大視窗容納檢索結果和對話歷史，避免頻繁裁剪上下文導致的連貫性損失。這一趨勢擴張了對 128K+ 視窗的需求。
- 程式碼與文件場景：GitHub Copilot、Cursor 等產品已將全倉庫上下文作為高階功能測試。法律（合同全文逐條審查）、生物醫藥（全基因組序列）、金融（多年財報對比）等垂直領域的需求正將視窗需求從“數萬 token”推向“百萬 token”量級。
玩家競爭分析
從商業模式與技術路線兩個軸，可將主要玩家劃分為以下競爭群組：
封閉旗艦模型陣營
OpenAI vs Anthropic vs Google DeepMind
- 視窗競賽：Google 以 1M 標稱視窗領先，但有效利用率（“大海撈針”測試成績）的差異是真實競爭維度。Anthropic 在 200K 視窗下的實際檢索準確率宣傳優於早期 GPT‑4 128K，但缺乏獨立第三方大規模 Benchmark。
- 價格戰：輸入 token 價格呈持續下行趨勢。Gemini 1.5 Pro 定價僅為 GPT‑4 Turbo 的約 1/8，反映了 MoE 架構的降本效果與 Google 自研 TPU 的成本優勢。Anthropic 在同等效能檔位定價低於 OpenAI。
- 生態繫結：各自與雲端平台深度繫結（OpenAI+Azure，Anthropic+AWS，Gemini+GCP），企業客戶常基於已有雲端服務商選擇模型，形成間接壁壘。
開源模型陣營
Meta（LLaMA） vs 阿里（Qwen） vs Mistral
- 視窗指標趨同：128K 已成為開源旗艦模型的“標配”，2024 年底至 2025 年初主要開源模型均達該水平。
- 差異化方向：
- LLaMA 憑藉龐大的社群生態（微調變體、量化版本、部署方案）佔據開發者心智份額。
- Qwen 在多語言（尤其東亞語言）和部分中文 Benchmark 上領先，國內企業使用者覆蓋度最高。
- Mistral 在歐洲市場因合規與語言優勢有獨特卡位。
- 商業模式：開源模型不直接按 token 收費，而是爭奪部署生態（如 llama.cpp、Ollama、vLLM 適配最佳化）和企業支援服務營收。
硬體與推論基礎設施層競爭
- 輝達 vs AMD：長上下文推論對視訊記憶體的高需求打破了傳統“單卡推論”的邊界，多卡並行推論成為剛需。輝達憑藉 NVLink + NVSwitch 互聯方案在雙卡/四卡推論場景效能領先，AMD MI300X 在視訊記憶體容量上（192GB vs H100 的 80GB）有單卡成本優勢，但互聯生態仍待追趕。
- 推論引擎分化：商業引擎（TensorRT‑LLM）在極致效能上領先，開源引擎（vLLM、llama.cpp）在社群迭代速度與部署靈活性上佔優，二者非零和競爭。
風險與制約因素
從技術、市場與供應鏈三個維度梳理關鍵風險：
技術風險
- 長上下文的“迷失在中段”效應：多項研究（Liu et al. 2023 “Lost in the Middle”）顯示，模型對長文件中部資訊的關注度顯著衰減，即便上下文擴充套件至 128K 甚至 1M，有效利用率未必同步提升。這導致純“視窗數字競賽”可能無法直接轉化為使用者體驗提升，存在技術路線誤導性競爭風險。
- KV Cache 的記憶體瓶頸：如前述測算，128K 輸入在 70B 模型下 KV Cache 可達數百 GB，對視訊記憶體和頻寬提出苛刻要求。硬體升級速度（HBM 容量年化增長約 30%
50%）可能落後於視窗擴充套件需求（年化 410 倍），形成技術進步的物理天花板。 - 預填充延遲的“長尾”問題：長輸入首 token 延遲與輸入長度的二次方關係難以根本消除，可能導致使用體驗在超長輸入場景下惡化（使用者等待數十秒），即使模型質量過關。
- 狀態空間模型的成熟度不足：Mamba 等 O(n) 複雜度方案是理論希望所在，但在需要遠距離精確資訊檢索的任務上，實際效能仍落後於最佳化後的 Transformer（公開資料未見 >128K 長序列上的系統對比 Benchmark）。
市場風險
- 價格下行侵蝕獲利：輸入 token 價格在 2023-2025 年間下降超過一個量級，且競爭加劇可能進一步壓縮獲利空間。以矽谷投資機構 a16z 的估算，推論服務的毛利率在價格戰趨勢下可能從 >70% 向 40%-50% 區間收斂。
- 開源模型的替代壓力：128K 開源模型的成熟減少了企業對高價閉源 API 的依賴，尤其對價格敏感的中小企業和開發者群體。
- 定價模式的不確定性：按 token 計費的模式在 Agent 長時間執行任務中可能不再適用，行業可能出現向“會話時長/任務”定價的遷移，影響營收模型預期。
供應鏈風險
- HBM 產能集中：台積電 CoWoS 先進封裝產能是 HBM 供給的卡口，截至 2024 年底產能仍集中在少數供應商，地緣政治與產能擴張週期均構成不確定性。
- 高階 GPU 供應的地緣因素：美國出口管制對高階 AI 晶片的限制，影響中國市場的 H100/H200 可及性，國內推論服務商被迫依賴國產替代或降級晶片，可能拉大技術差距。
常見誤讀糾偏
誤讀 1：“一個 token 就是一個單詞”
事實：Token 經常是單詞的子部分。例如“transformer”常被拆為“transform”和“er”，中文詞“人工智慧”可能被切分為“人工”和“智慧”或更細粒度。不同分詞器對同一文本的切分結果不同，token 數量也可能差異 10%~30%。使用者在估算成本時，建議使用目標 API 提供的 tokenizer 工具做實測，而非簡單按“1 詞 ≈ 1 token”或“1 字元 ≈ X token”推算。
誤讀 2：“上下文視窗長就等於模型能有效利用所有輸入”
事實：多項研究證實，模型注意力在長文件中呈 U 型分佈——開頭和結尾資訊被高度關注，中部資訊容易“迷失”。即使在 128K 視窗內輸入，模型對第 60K~100K 位置的資訊提取準確率可能僅為視窗前部的 50%~70%。因此，產品設計時不應假設“全量輸入必有用”，應搭配分段摘要、檢索增強等策略彌補中部資訊衰減。
誤讀 3：“增加輸入 token 數量，算力成本成比例線性增長”
事實：由於自注意力複雜度為 O(n²)，輸入 token 翻倍時，注意力計算量接近 4 倍（短序列時線性項仍有影響，但長序列下二次項主導）。同時 KV cache 線性膨脹進一步壓制併發。總推論成本在長序列場景下呈超線性增長，簡單按 token 單價乘以數量推算總成本會顯著低估。企業做財務測算時，應根據目標序列長度做定製 Benchmark 而非線性外推。
誤讀 4：“長上下文可以完全替代 RAG”
事實：長上下文和 RAG 是互補技術，當前最優實踐往往是二者結合：用 RAG 檢索相關片段並提供上下文結構，用長視窗容納檢索結果和對話歷史，避免頻繁裁剪。長上下文視窗減少了檢索分塊與重構的工程複雜度，但在成本、延遲和檢索可靠性上暫未完全替代 RAG。
最新事件與動態
以下梳理截至 2025 年初的產業關鍵更新（按時間線，來源為公司官方公告、技術報告與可驗證的行業資訊來源）：
- 2024 年 12 月：OpenAI 在 12 Days of OpenAI 活動中釋出 o3 系列推論模型，其上下文管理與輸入 token 消納方式與標準 GPT‑4 系列存在差異，具體技術細節待進一步公開。
- 2024 年 11 月：Anthropic 釋出 Claude 3.5 Haiku 並全面降價，輸入價格進一步下探；同期推出提示快取功能，對相同字首的重複輸入僅計費一次。
- 2024 年 10 月：Mamba‑2 正式論文公佈，混合 SSM‑注意力架構（Jamba 模型）在部分長序列 Benchmark 上展示出接近純注意力的精度與更低的推論延遲。
- 2024 年 9 月：阿里雲端釋出 Qwen 2.5 全系開源，旗艦模型上下文視窗穩定在 128K，並在中文多模態長文件任務上重新整理多項公開 Benchmark 最高分。
- 2024 年 7 月：Meta 釋出 LLaMA 3.1，首次將開源模型上下文視窗提至 128K（全系），並在技術報告中詳細公開長上下文微調方案（RoPE 插值策略）。
- 2024 年 Q3~Q4：多款推論引擎（vLLM v0.6+, TensorRT‑LLM）針對 128K+ 序列的預填充與 KV 快取排程進行架構最佳化，部分方案宣稱長序列吞吐提升 2~4×。
- 2024 年 Q4：台積電 CoWoS 產能擴充進度超預期（據 DigiTimes 供應鏈報道），但 HBM 供給至 2025 年上半年仍可能偏緊。
追蹤指標與觀察架構
為持續追蹤輸入 token 相關的技術與市場變化，建議關注以下高訊號價值指標：
技術與產品指標
| 指標 | 觀察方式 | 訊號含義 |
|---|---|---|
| 主流模型最大上下文視窗更新 | 各公司模型卡片 / 官方文件 | 視窗擴充套件→新一輪競爭或產品升級 |
| 長上下文大海撈針（Needle in a Haystack）準確率 | 獨立 Benchmarks（如 Anthropic、Greg Kamradt 測試） | 評估有效利用率，避免被“數字視窗”誤導 |
| 首 token 延遲（TTFT）隨輸入長度的變化曲線 | 推論引擎釋出的技術報告 | 反映預填充最佳化水平，使用者可接受上限約 10s |
| KV Cache 壓縮率（新演算法/量化） | 論文與架構 changelog | 壓縮率每提升 2×，等效視窗可擴充套件一倍 |
| 輸入 token 定價變動 | 各公司定價頁面 | 價格趨勢反映競爭烈度與成本結構變化 |
市場與供應鏈指標
| 指標 | 來源 | 關注點 |
|---|---|---|
| HBM 季度出貨量與 ASP | TrendForce、SK 海力士/三星季報 | 供給是否匹配長序列推論需求 |
| CoWoS 產能利用率與擴充計劃 | 台積電季度法說會 | 高階 GPU 供給的前置訊號 |
| 公有雲端推論 API 營收增速 | AWS/ Azure/ GCP 季報中 AI 相關揭露 | 輸入 token 間接市場規模 |
| 開源模型 HuggingFace 月度下載量 | HuggingFace 開源統計 | LLaMA、Qwen 等視窗擴充套件後的社群採用速度 |
訊號監控節奏建議
- 周頻：API 定價變動、推論引擎版本更新 changelog、重要模型釋出訊息。
- 月頻：HBM/GPU 供應鏈報道、獨立 Benchmark 測試報告（如有）。
- 季頻：晶片/雲端廠商財報、台積電法說會（CoWoS 產能方向）。
信源索引
以下列出本文參考的主要公開資訊來源，按型別分類。讀者可通過對應渠道檢索全文或資料。
學術論文
- Vaswani et al. “Attention Is All You Need” (NeurIPS 2017) —— Transformer 原論文。
- Sennrich et al. “Neural Machine Translation of Rare Words with Subword Units” (ACL 2016) —— BPE 子詞分詞。
- Su et al. “RoFormer: Enhanced Transformer with Rotary Position Embedding” (2021) —— RoPE。
- Peng et al. “YaRN: Efficient Context Window Extension of Large Language Models” (2023) —— YaRN 長上下文擴充套件。
- Liu et al. “Lost in the Middle: How Language Models Use Long Contexts” (2023) —— 長上下文有效利用率研究。
- Dao et al. “FlashAttention: Fast and Memory-Efficient Exact Attention” (2022) —— 注意力計算最佳化。
- Gu et al. “Mamba: Linear-Time Sequence Modeling with Selective State Spaces” (2023) —— 狀態空間模型。
官方文件與定價頁
- OpenAI Platform —— Pricing & Models 文件 [platform.openai.com]（截至 2025Q1 參考）。
- Anthropic —— Models & Pricing 文件 [docs.anthropic.com]（截至 2025Q1 參考）。
- Google AI Studio —— Gemini 定價與模型說明 [aistudio.google.com]（截至 2025Q1 參考）。
- Hugging Face Tokenizers —— 技術文件 [huggingface.co/docs/tokenizers]。
- vLLM —— 技術文件與 GitHub 倉庫 [github.com/vllm-project/vllm]。
行業分析與產業報道
- SemiAnalysis —— 多篇關於長上下文推論成本與硬體需求的分析。
- TrendForce —— HBM 市場季度追蹤（2024 年各期）。
- IDC / Grand View Research —— 全球 AI 晶片與 API 市場預測（2024 年引用）。
- NVIDIA Corporation —— FY2024 年度財報與投資者演示材料。
- 台積電 —— 季度法說會紀要（2024 年 Q3/Q4，CoWoS 產能相關揭露）。
- DigiTimes —— 先進封裝與 HBM 供應鏈追蹤（2024 年 Q4 報道）。
開源專案與社群
- HuggingFace model cards —— LLaMA 3.1、Qwen 2.5 等模型技術規格。
- llama.cpp GitHub —— 消費級硬體長上下文推論實現參考資料。
宣告：本文所有市場資料、競爭動態與公司動向均基於截至 2025 年初的公開資料整理，不做主觀預測。部分數字因統計口徑差異可能與其他來源存在偏差，建議讀者以原始出處資料為準。本文不構成任何投資建議，不推薦買賣任何證券，不使用“值得買”“買進類”等投資建議性措辭。