長上下文定價最高差 6.7x，閘道頁面卻不顯示

提示一長，閘道模型頁上的價格就不再等於帳單上的價格。我們透過一家大型多供應商聚合商，針對 9 個採分級定價的模型，在每個已公開的長度門檻前後分別送出請求。5 個模型跨過第一個門檻後，實際費率正好是頁面價格的 2x；Alibaba 的 3 個模型在最高級距分別升至 3x、3x 與 6.7x；另有一個由 Azure 提供的模型，在門檻前後都先按頁面所列端點費率的 1.25x 計費，跨過門檻後再翻倍。頁面完全沒有揭露這些差異。供應商自己的文件則清楚記載這套機制：Google、OpenAI、xAI、Alibaba、ByteDance 與 MiniMax 都會在輸入超過 32K、128K、200k、256K、272K 或 512k token 的門檻後，對整個請求重新計價，連輸出也算在內。本文先看實際帳單，再整理背後的級距表，最後說明如何設定，讓請求維持在門檻以下。

TL;DR

• 透過一家頁面只顯示單一價格的聚合商，9 個分級定價模型超過供應商門檻後，實際費率是頁面價格的 1.8x 到 6.7x；透過 Azure 提供的 GPT-5.6 Luna 則按標示價格的 1.25x 計費。
• qwen3.7-flash 在 32K 與 256K 兩個門檻，輸入價格依序從每百萬 $0.03 升至 $0.10，再升至 $0.20；qwen3-coder-plus 則停在 3x，沒有套用供應商列出的 6x 級距。
• 一旦輸入跨過 32K 到 512k token 之間的門檻，供應商會對整個請求重新計價，包含輸出。
• 要限制的是輸入，不是輸出：可使用 Claude Code /autocompact、Codex model_context_window，以及 API 壓縮觸發條件。

閘道真的會按頁面價格收費嗎？

提示一長就不會。若要查出實際差多少，每個中介層都要比對兩項資料：閘道公開的定價中繼資料，以及請求在門檻前後實際回報的成本。

一家大型多供應商聚合商在模型目錄中公開 pricing.overrides 陣列，內容包含基本價格，以及 min_prompt_tokens: 200000 搭配較高費率之類的條件規則。DeepSeek 與 Tencent 模型另有 utc_start / utc_end 時段，用於離峰定價。我們在 2026-09-01 擷取的目錄中，有 60 個項目帶有 overrides，包括 Gemini Pro 系列、Grok 4.x、qwen3.7-plus、qwen3.7-flash、qwen3-coder-plus、Seed 2.0 系列，以及在 272,000 token 設有門檻的整個 GPT-5.6 系列。模型頁只顯示基本價格，級距藏在中繼資料裡。而且這份中繼資料不一定完整反映供應商的級距表：qwen3-coder-plus 在 32,000 與 128,000 有規則，但沒有供應商第 4 級 256K 的規則。

因此，我們在 2026-09-02 與 2026-09-03 透過該聚合商，針對每個已公開門檻的前後分別送出請求。每個點執行兩次，開啟用量計費資訊（聚合商會在回應中附上實際收取金額），並記錄實際提供服務的端點。同一個聚合商模型 ID 可能對應多個上游主機，各自有不同價格，聚合商稱它們為端點：

這些頁面與帳單擷取於同一天。每頁只有一個醒目的價格、一張端點價格表，兩者都沒有長度級距。上述每筆費用都精確符合中繼資料中的 token 規則。9 個模型在供應商的第一個門檻都按供應商倍率跳級；3 個 Alibaba 模型的帳單更沿著頁面完全沒提到的階梯上升。qwen3.7-flash 在 32K 時從 $0.03 升至 $0.10，256K 時再升至 $0.20，達到頁面價格的 6.7x，但頁面仍只標示 $0.03。GPT-5.6 Luna 同樣在門檻處跳級，而且還多一層價差：所有由 Azure 提供的執行，不論門檻前後，都按所列 Azure 端點價格的 1.25x 計費（$0.275 對 $0.22，$0.50 與 $0.55 對 $0.40 與 $0.44）。這筆加價既沒有出現在頁面，也沒有寫進端點中繼資料。

聚合商的級距也可能比供應商少。qwen3-coder-plus 在 32K 時升至 1.8x，128K 時升至 3x，接著一路到 276k token 都維持每百萬 $1.95。Alibaba 自己的價格表在 256K 後，輸入升至 $6、輸出升至 $60，分別是基本價格的 6 倍與 12 倍。聚合商的中繼資料沒有 256K 規則，所以實際費用沒有變。外部無法判斷聚合商是自行吸收價差，還是採用不同合約。能確定的是，帳單遵循中繼資料，而中繼資料與頁面是兩份不同的文件。

資訊落差不在中繼資料與帳單之間，而在頁面與這兩者之間。頁面最醒目的數字，是下方表格中最便宜端點的費率，不是實際為你提供服務的端點費率；兩個數字也都沒有附帶長度條件。只列一個價格的模型卡，不會告訴你是否有級距、下一個請求會由哪個端點處理，也不會說明你的帳戶是否真的能使用你正在查看價格的端點。

做法很簡單。讀取實際使用模型的機器可讀定價資料，細到端點層級，並檢查是否有長度條件；接著開啟用量計費資訊，在門檻前後各送一個請求，比對回報成本。若閘道的費用在頁面未揭露的位置跳升，代表它直接套用了供應商規則，卻沒有告知使用者。若供應商價格會跳級，但閘道費用維持不變，原因不是改由不同價格的主機提供服務，就是閘道自行吸收價差，而只有前者可能是穩定狀態。

門檻在哪裡，級距如何套用？

6 家供應商公開了長度門檻。凡是明確說明規則的模型，跨過門檻後都會對請求中的所有 token 套用較高費率，包含輸出。多數第一個門檻是 2x，但多級階梯會繼續上升：qwen3.7-plus 的唯一門檻是 3x；qwen3.7-flash 到第 3 級時，輸入價格是 6.7x；qwen3-coder-plus 到第 4 級時，輸入是 6x，輸出是 12x。以下價格皆為每百萬 token，擷取自供應商在 2026-09-01 的定價頁面。

計費程式碼還要處理兩個邊界細節。Google 的兩個頁面差了 1 個 token：Vertex 註記寫的是「大於或等於 200K」，Gemini API 定價表則寫「提示 > 200k token」。Alibaba 對 K 也有明確定義：128K 等於 128,000 token，256K 等於 256,000，不是 2 的次方。

級距只由輸入長度決定，但會套用到整個請求，包括所有輸出 token。跨過門檻的那 1 個 token，其邊際成本因此包含前面所有 token 的價差。以 Gemini 2.5 Pro 為例：199,999-token 的提示，輸入費用是 $0.25；到了 200,001 token，輸入費用變成 $0.50，而 4,000-token 的回答則從 $0.04 升至 $0.06。只多 1 個 token，總費用卻多 $0.27。

qwen3.7-plus 的跳級是 3x：按官方費率，255,029-token 提示的費用是 $0.102，257,332-token 提示則是 $0.309。qwen3-coder-plus 的同一套機制跨越 4 個級距後會持續疊加，因此 260k-token 提示的每 token 費率是 30k-token 提示的 6 倍，輸出則是 12 倍。

這項規則不只存在於供應商價格表，實際帳單也看得出來。qwen3.5-plus 的官方輸入級距，在 256K 前後分別是每百萬 $0.40 與 $0.50。我們比較閘道帳單後發現，門檻以下的 10 次執行（243k token）與門檻以上的 24 次執行（256k 到 321k），每個輸入 token 的費用正好相差 1.25x，輸出價格則不變。259k 的請求不是只有最後 3k 個 token 付 1.25x，而是所有 token 都付 1.25x。

對會持續累積歷史紀錄的 agent 而言，門檻會在工作階段中途無聲跨過。剛好超過門檻的那一輪，會為它攜帶的所有先前內容支付溢價；之後每一輪也會持續支付，直到上下文被縮短。

模型能力也會在同一門檻跳變嗎？

不會。我們特別測量這一點，因為價格級距很容易被誤認為能力邊界，但兩者並不是同一回事。我們在兩個門檻為 256K 的分級 Qwen 模型上，將帶有每次執行隨機碼的單行事實，放在 5 個不同深度，再測試是否能找回。在關閉 thinking 的情況下，兩個模型於 243k、269k 與 320k token 都是 30 次中成功 30 次。延遲隨長度線性增加，沒有在門檻處跳升（qwen3.7-plus 的中位數分別為 15.2 秒、17.0 秒、20.5 秒）。較難的任務是統計整份日誌中植入的 K 個罕見事件，這項表現確實會隨長度下降：qwen3.7-plus 找到的比例，從 128k 的 74% 降至 192k 的 60%、243k 的 58%，再降至 320k 的 45%。下降在價格門檻前很早就開始，門檻兩側的結果也落在同一條趨勢線上。

Anthropic 的文件也為這種漸進效應命名：隨 token 數增加，準確率與回想率會下降，這種現象稱為「上下文腐化」。這個效應確實存在，而且是連續發生，不會配合價格門檻跳變。

如何讓請求維持在門檻以下？

限制輸入，不要限制輸出。級距由請求的輸入長度決定，因此 max_tokens 這種輸出上限沒有幫助；真正有效的是限制用戶端送出內容的設定。這類控制點分布在 4 個層級。

以下按層級列出可限制提示長度的設定。「可壓在級距下」表示能指定絕對 token 數，因此可設在價格門檻稍下方。相對於視窗的設定，只能避免超出模型的上下文視窗，而上下文視窗與價格門檻是不同的數字。

這張表帶出兩個重點。程式設計 agent 若使用分級定價模型，壓縮視窗是把價格斷崖變成摘要的關鍵設定。它必須用絕對 token 數設在門檻稍下方，不能只設定為 1M 視窗的某個比例。另一點是，最常見的兩種「安全」設定，也就是 Responses truncation: "auto" 與聚合商的 middle-out，都只是視窗防護。它們在模型的上下文視窗才會生效，而分級定價的 Gemini 與 GPT-5.6 模型視窗是 1M，不是價格跳升的 200,000 或 272,000 token。因此，它們可以避免請求失敗，卻無法阻止請求跨過價格門檻。

不要指望快取能讓請求維持在門檻以下。 提示快取可以降低帳單，但不會避開 Google 模型的價格級距，因為快取讀取也採用相同長度級距。150k 的快取前綴加上 60k 的新上下文，仍是一個 210k 提示，會合併計價。預留容量則直接繞過這個問題，因為佈建輸送量單位（PTU）按小時計費，與 token 數無關。若額外上下文確實值得跨越門檻，就應明確做出這個選擇。上述測量顯示，模型不會在門檻處突然變差，因此決策只取決於新增上下文，是否值得讓整個請求的費用乘上 2x、3x，或最高級距的 6.7x。

Synthorai 的處理方式

長度級距本質上是費率條件，因此閘道也按費率條件處理。模型價格卡可以包含一組以輸入 token 邊界為條件的級距清單。每個請求都依自身提示長度選擇級距，並將該級距套用到所有 token，與供應商的計價方式相同。上文 qwen3.5-plus 的帳單就是透過這套機制產生。用量紀錄會把提示 token 數與價格版本連同計價後的成本一起保存，因此可以把帳單還原成「這個請求跨過了門檻」。請求採用的計價級距可以從用量紀錄中查到，不只存在價格表中。

常見問題

較高的長上下文費率，只會套用在超過門檻的 token 嗎？

不會。所有有公開說明規則的供應商，都會對整個請求重新計價：Google 表示「所有 token（輸入與輸出）都按長上下文費率計費」，OpenAI 表示「套用於整個請求」，xAI 表示「套用於請求中的所有 token」，Alibaba 表示「請求中的所有 token 都按對應級距的單價計費」。提示只要超過門檻 1 個 token，前面所有 token 也都會支付較高費率。

API 閘道會直接套用長上下文定價級距嗎？

會，至少我們的測量結果如此。透過一家大型聚合商，9 個分級定價模型超過供應商門檻後，都按供應商的較高費率計費，但模型頁只顯示單一價格。級距存在閘道的定價中繼資料中，不在頁面上。中繼資料也可能漏掉供應商的某一級，例如 qwen3-coder-plus 在 256K 以上的級距。

max_tokens 能讓請求維持在價格級距以下嗎？

不能。max_tokens 限制的是輸出，級距則由輸入長度決定。真正有效的是限制提示的設定，例如 agent 的壓縮視窗或 token 上限（Claude Code /autocompact、Codex model_context_window）、API 的壓縮觸發值，或在請求送出前於用戶端裁切內容。

模型品質會在價格門檻處下降嗎？

我們的測量沒有發現這種情況。在兩個分級 Qwen 模型上，針測試在 256K 門檻兩側都能完全找回資訊，計數任務則是逐步下降，沒有在同一門檻突然惡化。級距是商業規則；模型能力確實會隨長度下降，但變化是連續的。

價格與計價規則取自 2026-09-01 擷取的供應商定價頁面；agent 與 API 設定取自 2026-09-02 的連結文件；帳單測量於 2026-09-01 至 2026-09-03 執行，關閉 thinking，使用加入隨機鹽值的提示，每個聚合商測試點執行兩次。價格會變動；將門檻寫入計費程式碼前，請先確認連結來源。

相關文章：計費單位實務指南（本文深入探討其中的調整條件層）、token 用量解析、提示快取原理、快取最低門檻實測。

← 返回部落格