100 兆 tokens 告訴你：為什麼降價 10% 也救不了你的 LLM 產品

你以為 AI 模型競爭就是打價格戰？

OpenRouter 剛發布的報告分析了 100 兆 tokens 的真實使用數據，發現一個驚人事實：**降價 10%，使用量只增加 0.5-0.7%**。

更扯的是，Claude 價格最貴，卻占了編程市場 60%。

到底發生什麼事？

為什麼這份報告值得關注？

這不是又一份「AI 趨勢預測」報告。

OpenRouter 是全球最大的 LLM API 聚合平台：

• 支援 300+ 模型
• 60+ 供應商（OpenAI、Anthropic、Google、DeepSeek...）
• 100 兆 tokens 真實使用數據（2024/11 - 2025/11）

這份報告揭露了三個開發者必須知道的反直覺發現。

發現 1：價格戰是假議題

數據打臉時刻

報告原話：

"需求缺乏價格彈性，用戶優先考慮品質和可靠性而非價格。"

為什麼會這樣？

工程師選模型的真實決策流程：

1. 能不能解決問題？（品質）
2. 會不會突然掛掉？（可靠性）
3. 貴多少？（成本排最後）

如果你的產品靠降價搶市場，代表你已經輸了。

這就像你不會因為便宜 10 塊就選擇會當機的 IDE。工程師時間成本遠高於 API 費用，穩定性和輸出品質才是關鍵。

發現 2：玻璃鞋效應（新概念警報）

什麼是玻璃鞋效應？

報告提出全新概念：如果模型首次解決了用戶未滿足的需求，會產生極強的鎖定效應。

就像灰姑娘的玻璃鞋，一旦找到完美契合的那雙，別人再好也不換。

數據證明

核心洞察：

• 早期用戶形成「基礎群體」（base cohort）
• 一旦找到「完美契合」的模型，很難被搶走
• 後來者即使更好，也難撬動這群人

對開發者的啟示

如果你在做 LLM 產品：

1. 專注解決一個痛點
   別想通吃所有場景，找到你的「玻璃鞋用戶」。

2. 搶早期用戶
   他們會變成鐵粉，留存率是後期用戶的 2 倍。

3. 別妄想用「更好」搶別人的用戶
   玻璃鞋效應會擋住你。與其正面硬剛，不如找未被滿足的需求。

真實案例：DeepSeek 回旋效應

報告觀察到有趣現象：某些流失用戶後來返回 DeepSeek。

為什麼？

1
2
3
4
5

用戶心路歷程：
1. 用 DeepSeek（便宜但可能品質有疑慮）
2. 流失去試 Claude / Gemini（貴但品質好）
3. 發現品質差異不值得多付的錢
4. 回流 DeepSeek（成本效能最佳解）

這證明了：用戶不是不在乎價格，而是會在品質和成本間找平衡點。

發現 3：推理 tokens 突破 50%

遊戲規則改變了

1
2

2024/11: 推理 tokens < 30%
2025/11: 推理 tokens > 50%

這意味著什麼？

AI 使用模式正在從：

• ❌ 單次文本生成（「幫我寫一封信」）
• ✅ 多步驟推理（「分析這份合約 → 找出風險 → 提出修改建議」）

領先者

開發者該做什麼？

如果你的產品還停留在「文字接龍」階段：

1
2
3
4
5
6
7
8
9
10
11

# ❌ 舊思維：單次生成
response = llm.generate("寫一個排序函數")

# ✅ 新思維：多步驟推理
response = llm.reason([
    "分析需求：需要什麼排序演算法？",
    "設計方案：時間複雜度權衡",
    "實作代碼：包含邊界處理",
    "生成測試：涵蓋極端情況",
    "效能優化：找出瓶頸"
])

優先支援工具調用（tool calling），這是報告觀察到的明確趨勢。

代理式推理模式（agentic reasoning）正成為標準，你的架構如果不支援，就會被淘汰。

其他值得關注的數據

開源 vs 閉源：三足鼎立

關鍵洞察：

• 開源陣營達到 30% 市場份額
• 中國模型一年內從可忽略不計增至 13%
• DeepSeek 仍領先開源，但市場已分散化

開源模型的真實用途：

驚人發現：開源模型在角色扮演類別反超閉源。

這打破了「開源只能做低階任務」的迷思。創意內容、對話生成等領域，開源已經夠用。

編程主導一切

關鍵數據：

• 編程請求平均 20K+ tokens（其他類別 3-4 倍）
• 序列長度從 2K → 5.4K+ tokens（增長近 3 倍）
• 完成 tokens 從 150 → **400+**（增長近 3 倍）

這代表什麼？

如果你的產品主打編程場景：

1. 長上下文必備（32K 起跳，建議 128K）
2. 輸出品質 > 速度（工程師會等，但不接受爛代碼）
3. Claude 是標竿（60% 市場占有率不是假的）

對開發者的三個行動建議

1. 多模型策略（別 All-in 單一模型）

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38

// ✅ 正確做法：任務導向的模型路由
const modelRouter = {
  // 編程：品質優先，成本其次
  coding: {
    primary: 'claude-sonnet-4',
    fallback: 'deepseek-coder-v3'
  },

  // 推理：多步驟任務
  reasoning: {
    primary: 'gemini-2.5-pro',
    fallback: 'grok-code-fast-1'
  },

  // 批量處理：成本優先
  bulk: {
    primary: 'deepseek-v3',
    fallback: 'qwen-2.5'
  },

  // 創意內容：開源夠用
  creative: {
    primary: 'llama-3.3-70b',
    fallback: 'mistral-large'
  }
}

// 根據任務類型選擇模型
function selectModel(taskType, contextLength) {
  const config = modelRouter[taskType];

  // 長上下文任務優先使用支援度高的模型
  if (contextLength > 32000) {
    return config.primary;
  }

  return config.fallback;
}

為什麼？

報告明確指出：

"生態系統缺乏單一主導者，開發者應維持靈活性，根據特定任務選擇最佳模型。"

實戰經驗：

• Claude：編程場景無可取代（60% 市場證明）
• Gemini：推理任務和長上下文表現好
• DeepSeek：成本效能最佳，批量任務首選
• 開源模型：創意內容、角色扮演夠用

2. 優先支援長上下文

編程工作負載真實數據：

• 平均輸入：20K+ tokens
• 平均輸出：400+ tokens（成長 3 倍）
• 序列長度：從 2K → 5.4K+ tokens

實作建議：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24

# ❌ 舊思維：4K 上下文窗口
MAX_CONTEXT = 4096
PROMPT_BUFFER = 500

# ✅ 新思維：至少 32K，建議 128K
MAX_CONTEXT = 128000
PROMPT_BUFFER = 2000

# 動態調整策略
def prepare_context(code_files, docs, history):
    """
    編程任務平均需要 20K+ tokens：
    - 代碼檔案：5-10K
    - 相關文件：3-5K
    - 對話歷史：2-5K
    - 輸出緩衝：2K
    """
    total_tokens = estimate_tokens(code_files + docs + history)

    if total_tokens > MAX_CONTEXT - PROMPT_BUFFER:
        # 優先保留代碼，壓縮文件和歷史
        return smart_truncate(code_files, docs, history)

    return code_files + docs + history

檢查清單：

• 你的模型支援多長的上下文？（<32K 會吃虧）
• 編程任務是否常遇到上下文不足？
• 是否有智能截斷策略？（別傻傻從頭砍）

3. 投資工具調用能力

報告觀察：

"工具調用請求份額穩步上升，代理式推理模式正成為標準。"

什麼是工具調用？

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30

# 傳統方式：單次生成
prompt = "幫我查詢天氣並發送郵件通知"
response = llm.generate(prompt)
# 問題：LLM 不能真的查天氣或發郵件

# 工具調用方式：代理式推理
tools = [
    {
        "name": "get_weather",
        "description": "查詢指定城市的天氣",
        "parameters": {"city": "string"}
    },
    {
        "name": "send_email",
        "description": "發送郵件",
        "parameters": {"to": "string", "subject": "string", "body": "string"}
    }
]

# LLM 會自動決定調用哪些工具、傳什麼參數
response = llm.chat(
    prompt="幫我查詢台北天氣並發送郵件通知",
    tools=tools
)

# 執行流程：
# 1. LLM 決定調用 get_weather(city="台北")
# 2. 執行真實 API，取得天氣數據
# 3. LLM 根據結果決定調用 send_email(...)
# 4. 完成任務

支援工具調用的模型（2025 現況）：

實作檢查清單：

• 你的模型 API 支援 function calling / tool use？
• 是否設計了清晰的工具描述？（LLM 靠這個決策）
• 錯誤處理機制？（工具調用可能失敗）
• 成本控制？（多步驟推理會增加 token 消耗）

給產品經理和創業者的警告

如果你正在做 LLM 產品，這三個數據會影響你的策略：

1. 別打價格戰

1

降價 10% → 使用量增長 0.5-0.7%

這代表什麼？

假設你的 API 定價從 $0.01/1K tokens 降到 $0.009：

• 成本下降：10%
• 使用量增長：0.5-0.7%
• 淨收入下降：~9.5%

正確策略：

• ✅ 提升品質和可靠性
• ✅ 找到「玻璃鞋用戶」（未被滿足的需求）
• ✅ 針對特定場景優化
• ❌ 瘋狂降價搶市場

2. 早期用戶 = 你的護城河

玻璃鞋效應數據：

• 早期用戶 5 個月留存：40%
• 後期用戶 5 個月留存：**<20%**

策略意義：

1. 專注 Product-Market Fit
   找到第一批「這就是我要的！」的用戶，遠比廣撒網重要。

2. 優化早期體驗
   第一次互動決定了用戶會不會變鐵粉。

3. 別急著擴張
   深耕早期用戶群，讓他們成為佈道者。

3. 推理能力 = 未來門票

推理 tokens 占比：

1
2

2024/11: <30%
2025/11: >50%

市場正在淘汰單次生成產品。

如果你的產品還是：

• 「輸入 prompt → 輸出結果」
• 沒有多步驟推理
• 不支援工具調用

你可能活不過 2026。

總結：五個關鍵洞察

1. 價格戰沒用
   降價 10% 只增加 0.5% 使用量，品質和可靠性才是關鍵。

2. 玻璃鞋效應
   早期用戶一旦找到契合模型，留存率是後期用戶 2 倍。搶早期用戶，不是搶市場份額。

3. 推理 > 生成
   多步驟推理已占 50%+ tokens，單次生成模式正在被淘汰。

4. 多模型策略
   沒有單一最佳模型，針對任務選擇（編程用 Claude，成本敏感用 DeepSeek，創意用開源）。

5. 長上下文必備
   編程任務平均 20K+ tokens，你的產品還在用 4K 窗口就落伍了。

下一步行動

如果你是開發者

• 檢視模型選擇策略
  是否過度依賴單一模型？考慮實作任務導向的模型路由。

• 評估長上下文支援
  你的主要場景需要多長上下文？是否有智能截斷機制？

• 驗證工具調用能力
  你的模型是否支援 function calling？是否有完整的錯誤處理？

如果你是產品經理

• 停止價格戰思維
  把資源投入品質優化，而非無意義的降價。

• 找到你的玻璃鞋用戶
  誰是第一批說「這就是我要的！」的人？深耕他們。

• 規劃推理能力
  你的產品路線圖是否包含多步驟推理？現在開始還不晚。

如果你是創業者

• 重新思考競爭策略
  別想正面硬剛 Claude/GPT，找未被滿足的需求（垂直場景、特定語言、區域市場）。

• 評估技術債
  你的架構是否支援多模型切換？是否支援長上下文和工具調用？

• 關注開源趨勢
  中國開源模型一年內從 0% 增至 13%，這個趨勢會繼續。

完整報告

這篇文章只涵蓋了報告的核心發現。如果你想深入了解：

OpenRouter State of AI 2025 完整報告：
https://openrouter.ai/state-of-ai

報告包含更多數據：

• 全球使用分布（亞洲增長超過 2 倍）
• 各模型詳細排名和市場份額
• 不同類別的成本分析
• 用戶留存曲線和流失模式

100 兆 tokens 的數據不會騙人。市場已經告訴你答案，就看你聽不聽。

如果這篇文章對你有幫助，歡迎分享給同樣在做 LLM 產品的朋友。