Opus 4.8 1M Fast API：上下文、速度與 Token 成本
為開發者解析 Opus 4.8 1M 上下文與 Fast 模式：速度、定價、提示快取，以及何時值得使用 Fast 配置。
嗨，我是 Dora。我的路由表裡已經有 Opus 4.7 了。這篇文章要回答的問題是：opus 4.8 1m fast 這個設定是否值得在同一張表裡佔有一席之地，以及在什麼條件下值得。如果你正在生產環境中跑多模型架構，試著決定要不要啟用 1M context、Fast Mode，或兩者皆用——這篇文章就是給你的成本與延遲分析。
不是發布評測，也不是遷移指南。只是針對這兩個關鍵開關的成本與延遲數學。
1M Context 的標準定價
首先值得了解的，是 Anthropic 沒有額外收費的部分。
無長 context 附加費
Anthropic 的定價文件確認：Opus 4.8 以標準定價提供完整的 1M token context window。在 200K 沒有分層調整，在 512K 沒有門檻，也沒有獨立的長 context SKU。不論你的 prompt 是 10K 還是 900K，輸入計費為 $5/M，輸出為 $25/M。
這件事比表面上看起來更重要。大多數長 context 模型採分層定價——超過某個門檻後，整個請求就會跳到 2x 費率。如果你在單一路由層後面跑多個不同供應商的模型，這種不對稱性是最難建模的痛點之一。Opus 4.8 的費率保持不變，讓跨路由表的成本預測更加一致。
代價在於 tokenizer。Opus 4.7 引入了一個新的 tokenizer，Anthropic 文件記載它對相同輸入最多會多用 1.35 倍的 token。最初的 Opus 4.7 公告解釋了這個取捨——tokenizer 的變更改善了許多任務的效能，代價是相同輸入大約會映射到 1.0–1.35 倍更多的 token。Opus 4.8 繼承了這個 tokenizer。在技術內容（程式碼、JSON）上的實際量測，落在接近 1.4x。所以「標題價格不變」伴隨著「輸入量增加」。程式碼密集型工作負載的實際成本，比費率卡顯示的要高出許多。純英文散文基本上不受影響。
128K 最大輸出
同步最大輸出 128K，透過 beta header 的 Batch 最大輸出 300K。1M context 數字是輸入端的；輸出仍有上限。這是「為什麼失敗了」工單最常見的來源——一個長 context 請求在生成途中撞到輸出上限。如果你要把現有工作流程從 200K 模型遷移到 opus 4.8 fast mode 或標準 1M 版本，請確認 max_tokens 已經調高。新的 tokenizer 會更快消耗掉這個預算。
Fast Mode 說明
Fast Mode 才是真正改變 opus 4.8 1m fast 決策的槓桿。opus 4.8 fast mode 端點和標準端點使用相同模型、相同能力——但成本和延遲特性截然不同。
2.5 倍速度，研究預覽狀態
Fast Mode 在相同輸出品質下，比標準端點快約 2.5 倍。相同的模型權重，相同的 context window。改變的是吞吐量。
它在 API 上是研究預覽版，需要等候名單才能使用。在 Claude Code 內，/fast 命令可以在執行階段切換 session。在 API 上，你需要以組織為單位啟用存取權限。「研究預覽」的定位值得認真看待——容量、可用時段和確切定價結構仍可能改變。現在不要在它上面建立生產環境 SLA。
$10/$50（標準的 2 倍，比 4.7 便宜 3 倍）
這裡的數學開始變得有趣。Claude opus 4.8 fast 定價恰好是標準的 2 倍：每百萬 token 輸入 $10，輸出 $50。在 Opus 4.7 上，等效的 Fast 層是 $30/$150——是標準費率的六倍。Anthropic 在 4.8 將倍率降到了 2 倍。claude opus 4.8 fast 費率的這個變化，是它在路由決策中定位轉變最大的單一因素。
三點觀察。
第一，Fast Mode 過去是豪華層——示範時開啟，生產時關閉，因為倍率會把預算燒光。在 2 倍費率下，它現在已經可以在延遲敏感的路由上持續開著。經濟邏輯翻轉了。
第二，2 倍倍率適用於整個 context window。在 1M 時沒有獨立的 Fast 費率。所以 opus 4.8 1m fast 就只是標準 1M 定價 × 2。很好建模。
第三，Fast Mode 的成本案例仍然必須跨越任何溢價層都需要跨越的門檻：延遲改善是否比用一個本來就夠快的更便宜模型跑相同工作負載更划算？對許多路由來說，答案仍然是否定的。
成本疊加方式
多個定價修飾符可以同時套用在同一個請求上，而且它們的組合方式並不完全相同。
Fast + prompt caching + 資料駐留倍率
Fast Mode 定價與其他修飾符疊加：
- Prompt caching 倍率套用在 Fast Mode 定價之上。 Cache 寫入和 cache 讀取是以 Fast 基本費率計算，而非標準費率。所以 Fast Mode 請求上的 cache 命中，絕對成本仍然比標準模式下同樣的 cache 命中更貴。
- 資料駐留倍率同樣套用在 Fast Mode 定價之上。 如果你為了歐盟或其他資料駐留要求而支付區域溢價，該溢價是以 Fast 費率計算的。
對 opus 4.8 token usage 建模的實際影響：如果你在現有路由表中已經有 caching + 資料駐留倍率，Fast Mode 的情況並非單純的 2 倍。而是 2 倍再疊加你原本就在支付的那些倍率。在決定這個取捨是否可接受之前，先針對你的實際設定跑一遍數學。
Opus 4.8 的最小可快取 prompt 長度降至 1,024 token，比之前的門檻更低。對於那些 caching 以前根本不會觸發的短 prompt agent 迴圈來說，這是個小小的利好。
新 tokenizer（約多 35% 的 token）
我在上面提過這點；在成本疊加的脈絡下值得再次強調。自 Opus 4.5 以來，標題費率沒有動過——$5/$25。但 Opus 4.7 和 4.8 都使用新的 tokenizer，對相同輸入最多可消耗多 35% 的 token。Anthropic 自家的定價頁面直接說明了這一點。
所以當你在疊加修飾符時，基本單位和 4.6 時代不一樣了。對 4.8 來說，「節省 20% 的 caching」是針對一個本來就大了 30-40%（對程式碼密集型工作負載）的輸入量來計算的。如果你在以成本為基準對比 4.8 和舊模型，要以 token 數量標準化，而不只是費率。
何時啟用 Fast
誠實的答案：不要預設開啟。claude api fast mode 選項是針對特定請求形狀的工具，而非全域開關。把 claude api fast mode 想成是每條路由的決策，而非每個組織的決策。
延遲敏感 vs 成本敏感的工作負載
Fast Mode 真正值得其 2 倍成本的情況：
- 互動式 copilot，其中 time-to-first-token 和 tokens-per-second 會明顯影響使用者體驗。2.5 倍的速度差異是感知得到的。
- 值班摘要器、警報分類、面向客戶的 agent——任何掛牆時鐘延遲是主要成本的地方。
- 示範和銷售路徑，模型需要感覺靈敏的場合。
浪費成本的情況：
- 批次處理。 如果你不是在等待它，模型跑多快都無所謂。直接用半價的 Batch API 就好。
- 背景 agent 無人值守地在夜間執行。
- 路由上較小、較快的模型本來就能滿足品質要求的情況。 Sonnet 4.6 已經便宜許多、也快許多了。如果任務不需要 Opus 級別的能力，Fast Mode 是錯誤的優化軸向。
在路由表中，我的心理模型是：Fast Mode 是你套用在已經有充分理由使用的 Opus 路由上的升級。它不是用來替代那些應該在上游就做出的路由決策的。
Fast 不可用的地方（Batch、AWS）
來自文件的兩個硬性限制：
- Fast Mode 不適用於 Batch API。 Batch 是非同步的，所以延遲溢價沒有任何價值。Anthropic 不銷售它。如果你想在非延遲敏感的工作上做成本優化，Batch API 是另一個方向——輸入和輸出各打五折，但放棄了實時響應。
- Fast Mode 不適用於 AWS 上的 Claude Platform。 如果你的生產部署是在 AWS Bedrock 上，且因為合規或合約原因繞過了 Anthropic 的直接 API，Fast Mode 就不在選單上。標準端點可以用。在圍繞 Fast 進行架構之前，值得仔細確認你的部署路徑。
它可以在直接的 Claude API 和其他支援的渠道上使用，但在正式承諾前，請依照官方 Fast Mode 文件確認。
限制與取捨
我踩過或差點踩過的事情清單：
- 切換模型時 cache 失效。 Prompt cache 是按模型分區的。從 4.7 遷移到 4.8，或從 4.8 標準切換到 4.8 Fast，都會讓快取的前綴失效。在新端點上的前幾個 session 要支付完整的 cache 寫入成本。請相應地規劃遷移視窗。
- Token 數量漂移。 相同內容，在 4.6 和 4.8 上跑
count_tokens，會得到不同的數字。如果你的帳單儀表板或速率限制預測是基於歷史 4.6 token 數量，opus 4.8 token usage 在你切換模型 ID 的那天就會讀到一個突變，甚至在任何工作流程改變之前就已如此。 - effort 等級影響輸出成本。 Opus 4.8 有 effort 層級（預設 high，extra，Claude Code 中的 max）。更高的 effort 意味著更多推理 token，無論是否顯示都以輸出費率計費。相同的 prompt 根據 effort 的不同，可能產生差異很大的帳單。
- Fast Mode 容量。 研究預覽意味著可用容量無法保證。對於生產路由，請確保內建了回退到標準端點的機制。
常見問題
在 Opus 4.8 上同時開啟 1M context + Fast Mode 真的會讓我的成本翻倍嗎？
大概是——但基本單位很重要。1M context 是以標準定價計算的，所以 context 大小本身不會增加費率。Fast Mode 是輸入和輸出各增加 2 倍。在此之上再疊加 caching 倍率和資料駐留，實際成本取決於設定。在不考慮 cache 命中率的情況下，每個請求的帳單大約是你之前標準 1M 成本的 2 倍。
Fast Mode 是正式可用還是仍在研究預覽階段？
在 Claude API 上是研究預覽，需要[截至發布日期]的存取權限才能使用。在 Claude Code 中，可透過 /fast 命令立即使用。容量和定價結構在正式發布前可能改變。請查看 Fast Mode 文件以了解目前狀態。
我可以搭配 Batch API 或在 AWS 上使用 Fast Mode 嗎？
兩者皆否。Fast Mode 與 Batch API 不相容（batch 是非同步的，所以延遲沒有任何價值），而且它在 AWS 上的 Claude Platform 不可用。僅限直接 Claude API [截至發布日期]。
新的 tokenizer 會增加我在 Opus 4.8 上多少 token 用量？
Anthropic 文件記載的範圍是比 4.7 之前的模型多 1.0x 到 1.35x 的 token，程式碼和結構化資料會落在該範圍的頂端。純英文散文幾乎不受影響。對真實工作負載的獨立量測顯示，技術內容略高於文件記載的上限。在依賴單一倍率之前，請對你實際工作負載的代表性樣本執行 count_tokens。
什麼時候真的值得啟用 Fast Mode 而不是維持標準模式？
當掛牆時鐘延遲直接影響體驗或下游工作流程，而且該任務確實需要 Opus 級別的品質時。互動式 copilot、實時 agent、面向客戶的對話。對批次作業、背景處理，或路由上更便宜更快的模型本來就能達到品質門檻的情況，不值得。
結論
opus 4.8 1m fast 的決策是兩個開關，而非一個。1M context 開關在費率層面基本上是免費的——你透過 tokenizer 付出代價，而非費率卡。Fast Mode 開關是真實的 2 倍，但倍率低到足以在延遲真正重要的路由上站得住腳。
如果你已經在跑多模型架構：標準 1M 以和 4.7 相同的成本形狀插入長 context Opus 角色；Fast Mode 是一個值得在延遲關鍵路由上選擇性啟用的新槓桿，而非預設值。在正式決定之前，先建模 cache 和資料駐留的疊加效果。在信任任何成本預測之前，先對真實樣本重新執行 count_tokens。
我的資料到此為止。研究預覽狀態意味著把這些數字視為當前狀態，而非承諾。
往期文章：
