xAI 將Grok 4.7描述為其在程式開發、代理型任務與知識型工作上的前沿模型，具備 500K token 的上下文視窗。根據xAI 目前的定價頁面，在提示低於 200,000 個 token 時，直接 API 費率為每百萬輸入 token $2.00、每百萬快取 token $0.50、每百萬輸出 token $6.00；當提示達到 200,000 個 token 或以上時，xAI 分別列示為 $4.00、$1.00 與 $12.00。這些是 xAI 直連費率，並非第三方平台的通用價格。
實際花費不僅取決於輸入費率。新輸入、快取輸入、輸出、重試、工具呼叫，以及代理工作流程中的模型呼叫次數都會影響帳單。200K 提示門檻尤其重要，因為一旦達到該邊界，xAI 與 CometAPI 都會公佈更高的長上下文費率。
本指南先建立 xAI 的定價基準，再比較目前的CometAPI Grok 4.7 列示。截至 2026 年 9 月 28 日，CometAPI 在標準級距分別列示每百萬新輸入/快取輸入/輸出 token 的價格為 $1.60 / $0.40 / $4.80，長上下文級距為 $3.20 / $0.80 / $9.60——相對應的 xAI 直連費率低 20%。後續章節將說明如何計算工作負載成本、降低浪費，以及如何透過 CometAPI 存取該模型。所有價格皆為當下快照，投入生產前應重新核對。
xAI Direct 與 CometAPI Grok 4.7 定價比較
xAI 直連費率（每 1M tokens 的美元費率）
| Token 類別 | 低於 200K 提示 token | 長上下文（≥200K） |
|---|---|---|
| 新輸入 | $2.00 | $4.00 |
| 快取輸入 | $0.50 | $1.00 |
| 輸出 | $6.00 | $12.00 |
CometAPI 費率（每 1M tokens 的美元費率）
| Token 類別 | CometAPI：低於 200K 提示 token | CometAPI：長上下文級距 |
|---|---|---|
| 新輸入 | $1.60 / 1M tokens | $3.20 / 1M tokens |
| 快取輸入 | $0.40 / 1M tokens | $0.80 / 1M tokens |
| 輸出 | $4.80 / 1M tokens | $9.60 / 1M tokens |
200K 提示邊界之所以重要，是因為兩個平台目前對 Grok 4.7 的長上下文費率均為標準級距的兩倍。這是各 API 平台的定價規則，並非模型能力的變化。當應用反覆發送大型提示，或讓代理對話歷史無控制地增長時，請求才會變得更昂貴——而不是因為 Grok 4.7 支援 500K 的上下文視窗。
在預算規劃中，任何預計會碰到該邊界的請求都應先視為長上下文，直到實際計費行為被驗證為止。模型可用性與價格可能變動，因此用於生產的計算器應重新檢查xAI 直連定價與當前的CometAPI 模型頁，而不要將數值永久硬編碼。
Grok 4.7 成本估算公式
將一次請求拆分為各 token 類別分別計價：
request cost = (fresh input tokens × input rate + cached input tokens × cached rate + output tokens × output rate) ÷ 1,000,000
接著把單次請求估算換算為工作負載估算：
monthly cost = request cost × requests per user × active users × days in billing period
使用具代表性的分位數，而非單一平均值。p50 估算描述一般請求，但 p95 的輸入與輸出長度會揭示常常主導帳單的昂貴長尾。對於代理工作流程，請乘上完成一項任務所需的模型呼叫次數。五步驟工作流程就是五次可計費呼叫，而非一次。
範例 1：支援副駕
假設一次支援請求會發送 6,000 個新輸入 token，並產生 800 個輸出 token。它低於 200K 門檻，且未獲得快取折扣。
- 輸入：6,000 × $1.60 ÷ 1,000,000 = $0.00960
- 輸出：800 × $4.80 ÷ 1,000,000 = $0.00384
- 合計：每次請求 $0.01344
若每月 100,000 次請求，估計的 token 成本為 $1,344。若評估顯示 400 token 的答案與 800 token 的答案表現相當，估計將降至每次 $0.01152，或每月 $1,152。僅此一項輸出上限即可每月節省約 $192，約 14.3%，且無需更換模型。
這就是為何要重視輸出控制。在所列 CometAPI 費率下，同級距中輸出 token 的成本是新輸入 token 的三倍。
範例 2：重複使用穩定的 20K-token 前綴
假設每次請求包含 20,000 token 的產品手冊、2,000 token 的新對話上下文，以及 600 token 的回應。
無快取命中的估算為：
- 22,000 個新輸入 token：$0.03520
- 600 個輸出 token：$0.00288
- 合計：每次請求 $0.03808
若 20,000 token 的穩定前綴按快取輸入計費，而僅 2,000 token 保持為新輸入，估算變為：
- 20,000 個快取輸入 token：$0.00800
- 2,000 個新輸入 token：$0.00320
- 600 個輸出 token：$0.00288
- 合計：每次請求 $0.01408
在 100,000 次請求下，即 $1,408 而非 $3,808——估計節省 $2,400，約 63.0%。節省並非自動生效：首次請求、更改過的前綴，或未產生快取命中的路由，仍可能以新輸入費率計費。請先在實際使用資料中確認快取 token 計數，再將估算視為已達成的節省。
範例 3：跨越 200K 的成本
考慮一個長時間執行的代理請求，其提示為 210,000 個 token，輸出為 2,000 個 token。依所列長上下文費率：
- 210,000 個新輸入 token：$0.67200
- 2,000 個輸出 token：$0.01920
- 合計：每次執行 $0.69120
若透過上下文壓縮、檢索過濾與摘要檢查點，將提示降至 180,000 個 token，並保持相同的 2,000 個輸出，則標準級距的估算為：
- 180,000 個新輸入 token：$0.28800
- 2,000 個輸出 token：$0.00960
- 合計：每次執行 $0.29760
差額為每次 $0.39360，約 56.9%。在 10,000 次執行中，估計可節省 $3,936。重點不是刪除有用的上下文，而是僅保留會改變答案的上下文，把其餘內容在請求跨越價格邊界之前先摘要或檢索。
呼叫前預估的 Python 計算器
以下函式使用 CometAPI 目前列示的 Grok 4.7 費率。當總提示達到 200,000 個 token 時，它會保守地套用長上下文級距。
from dataclasses import dataclass
@dataclass(frozen=True)
class Rates:
input_per_million: float
cached_input_per_million: float
output_per_million: float
SHORT = Rates(1.60, 0.40, 4.80)
LONG = Rates(3.20, 0.80, 9.60)
def estimate_grok_47_cost(
fresh_input_tokens: int,
cached_input_tokens: int,
max_output_tokens: int,
) -> float:
prompt_tokens = fresh_input_tokens + cached_input_tokens
rates = LONG if prompt_tokens >= 200_000 else SHORT
return (
fresh_input_tokens * rates.input_per_million
+ cached_input_tokens * rates.cached_input_per_million
+ max_output_tokens * rates.output_per_million
) / 1_000_000
estimate = estimate_grok_47_cost(
fresh_input_tokens=2_000,
cached_input_tokens=20_000,
max_output_tokens=600,
)
print(f"Estimated upper bound: ${estimate:.5f}")
這是一個規劃防護，而非發票。最終成本取決於實際的新輸入、快取輸入、輸出、重試、工具呼叫，以及執行時的有效價格。每次回應後，請儲存回傳的 token 使用量、模型 ID、請求狀態與任務結果，並與供應商的計費紀錄對帳。
五項 Grok 4.7 成本控制措施（按預期影響排序）
1. 讓重複的上下文足夠穩定以利快取
將靜態說明、產品文件、結構綱要與可重用範例放在請求特定內容之前。除非必要，避免在大型共用前綴中變更時間戳、ID、空白或順序。xAI 的 Grok 4.7 指南建議在對話中使用穩定的快取導向識別碼；透過中介路由時，請先確認其支援哪些快取控制與使用欄位，再依賴該機制。
按工作負載量測快取命中的 token 與命中率。若應用程式不斷改動前綴，理論上的快取折扣也沒有價值。
2. 將 200K 視為工程預算，而非達標目標
在門檻下預留餘裕給系統說明、檢索片段、工具結果與下一輪使用者互動。對於代理，將舊回合壓縮為經驗證的摘要，並把原始對話保留在模型上下文之外。對於檢索，先排序與去重片段再插入，而不是送出所有匹配結果。
追蹤提示長度分佈，並在 p95 接近門檻前預警。依 xAI 的官方費率表，一旦提示達到 200K token，該請求的所有 token 都適用長上下文費率。CometAPI 亦同樣為 Grok 4.7 列示更高的長上下文級距。這些是平台的定價條款，而非模型能力。
3. 設定輸出上限，並針對評測集調整推理強度
設定符合產品需求的應用層輸出上限。分類結果可能只需數十個 token；支援回答可能需要數百個；研究報告可能需要更多。這個上限是預算與體驗控制，而非 Grok 4.7 的硬性限制。xAI 在 9 月 21 日的發行說明指出 Grok 4.7 沒有文字輸出上限；這不妨礙應用或特定 API 路由實施自己的請求上限。請以實際使用的路由確認端點或 SDK 是否強制任何請求上限。
Grok 4.7 支援多種推理強度。使用通過代表性評測集的最低強度，並將更高強度保留給確實帶來可量化改善的任務。未經品質驗證就削減推理或輸出，可能導致重試並抹去節省。
4. 在 API 呼叫前拒絕或重塑昂貴請求
根據輸入大小與設定的輸出上限預估上界。若請求超出產品預算，應用可要求使用者收斂任務、摘要上傳材料、減少檢索上下文，或改以核准的非同步流程執行。這比生成後才發現成本更可控。
字元到 token 的粗略近似可作為早期防護，但不應取代 tokenizer 或實際使用資料。語言、程式碼、JSON 與格式會導致截然不同的 token 密度。
5. 以每個成功任務的成本為優化目標，而非每次呼叫成本
一次較便宜但兩次驗證失敗的呼叫，成本可能高於一次成功呼叫。請追蹤：
- 每個被接受答案的成本；
- 每個完成代理任務的成本；
- 重試與回退成本；
- 快取命中率與快取 token 佔比；
- 提示與輸出的 p50 與 p95；
- 品質分數、延遲與人工升級率。
若常規流量不需要 Grok 4.7 的品質或上下文容量，CometAPI 的統一模型目錄可讓應用自行切換模型更容易。保持路由規則明確，在同一任務集上評估各模型，僅將能受益於 Grok 4.7 的請求送往該路由。
實務性的月度成本檢視
每週按功能分組流量，將估計成本與實際使用比較。先從輸出 token 貢獻最大、提示最長、快取命中率最低的功能著手。接著檢視昂貴的離群值，而不是盲目最佳化中位數請求。
| 訊號 | 可能問題 | 首要行動 |
|---|---|---|
| 快取 token 佔比低 | 共用前綴變動過於頻繁 | 穩定化並版本化可重用上下文 |
| 提示集中在接近 200K | 歷史或檢索無邊界 | 壓縮、排序並預留餘裕 |
| 輸出主導支出 | 回答長度超過產品需求 | 降低上限並測試答案品質 |
| 重試成本高 | 驗證、逾時或提示不穩定 | 修正首次呼叫的失敗模式 |
| 成本低但任務完成率差 | 最佳化壓縮了有用品質 | 量測每個被接受結果的成本 |
CometAPI 在 Grok 4.7 成本模型中的定位
CometAPI 在此流程中的角色屬於 API 平台層：它提供對 Grok 4.7 的存取、發布其自有 token 費率，並提供與 OpenAI 相容的進入點。它不會改變 Grok 4.7 的底層模型能力。已經使用 OpenAI 風格客戶端的團隊，可能只需變更 API Key、Base URL 與模型 ID，即可保留相同的客戶端模式（以各端點的相容性為準）。
截至 2026 年 9 月 28 日，CometAPI 列示的 Grok 4.7 費率在標準與長上下文兩個級距均較相應的 xAI 直連費率低 20%。這是一項平台價格比較，而非模型品質主張。正式上線前，團隊也應確認有效的模型 ID、端點參數、快取行為、速率限制、可靠性、支援與計費條款。
若要測試模型，請查看CometAPI Grok 4.7 模型頁上的當前定價與存取細節。將價格表置於設定中、每次呼叫後記錄實際使用，並在模型或產品行為變更時重新執行工作負載估算。
常見問答
Grok 4.7 在 CometAPI 上的每 token 價格是多少？
對於低於 200K token 的提示，CometAPI 目前列示每百萬新輸入 token $1.60、每百萬快取輸入 token $0.40、每百萬輸出 token $4.80。長上下文費率分別為每百萬 token $3.20、$0.80 與 $9.60。
一次 Grok 4.7 API 請求要多少錢？
取決於新輸入、快取輸入、輸出與所適用的上下文級距。將各自的 token 數乘上對應的每百萬費率，相加後再除以一百萬。亦須納入重試，以及多步驟工作流程中每一次模型呼叫。
降低 Grok 4.7 API 成本最簡單的方法是什麼？
從最大的成本驅動因子著手。重複的長指令通常受益於快取；不斷增長的代理歷史受益於壓縮；冗長的回答受益於較低的輸出上限。每次變更後都要確認品質依然可接受。
500K 的上下文視窗是否代表我應該送 500K token？
不。上下文視窗是容量上限，而非建議值。xAI 直連定價與 CometAPI 目前的列示，皆在 200K 提示門檻處採用更高的長上下文費率，因此應用程式只應發送完成任務所需的上下文。
我能在呼叫 Grok 4.7 前預估成本嗎？
可以。先估計輸入 token，選擇正確的上下文級距，加上合理的輸出上限，並計算上界。呼叫後，將估算替換為實際使用資料，用於報表與最佳化。