Carbon 的思考档位不是简单的「越高越好」：Artificial Analysis 的三档实测显示，默认的 medium 档同时是最便宜、最诚实的一档；而输出上限设错了，模型会把 token 全花在思考上、返回空答案，费用照收。本站综合 eesel.ai 的测评、Inferera 的 API 迁移指南与 Quantslant 的实测，整理出这份避坑指南。先说核心结论：留默认 medium；max_output_tokens 至少 32,768；HTTP 超时 15–20 分钟；high 只配更大的输出预算。
Artificial Analysis 指数 v5.0.1（标准价口径，eesel.ai 11 月 11 日核查）：
| 思考档位 | AA 指数 | 每任务成本 | 编造答案率 |
|---|---|---|---|
| Low | 54 | $7.19 | 20% |
| Medium（默认） | 58 | $6.59 | 4.2% |
| High | 60 | $7.76 | 11% |
反直觉的一点是 medium 比 low 更便宜：弱档位更容易绕圈子、重复尝试，反而耗更多 token（Hacker News 评论区也有人注意到了同样的现象）。编造率的差距更值得看：medium 档约 25 次才编造 1 次，对 Opus 5.5 的约三分之二；high 档编造率反而回升到 11%——思考更久不等于更诚实，AA-Omniscience 也测得 Carbon（high）的幻觉率 11% 高于 Argon 的 4%。eesel 的评分很形象：硬推理与研究 4.5/5，任何需要人等的事 2/5——「后台模型，不是实时回答的模型」。
Carbon 的最大输出上限（流式 65,536 / 非流式 32,768）覆盖思考 token。Google 长解码指南原文：「低值如 8,192 会在思考完成前打断模型」「模型仍在思考时文本可能为空」。Quantslant 两次实测确认了这一点：输出上限 6,000 时，Carbon 花 5,808 tokens 推理、返回空答案，照样收费；正则任务 medium 档用掉全部 16,000 tokens 推理，未返回一行代码。老张博客也遇到同样情况：Carbon 在 high 档处理长日志时，在写出一个字之前就耗尽了输出 tokens。状态会变成 incomplete——把它当作上限问题处理：调高上限、重试，并接受第一次尝试已经上了账单。
Carbon 在请求结构层面是 Argon 的直接替代（改模型 ID 即可），但以下参数会出问题（Inferera 迁移指南，11 月 12 日）：
| 写法 | 结果 | 正确做法 |
|---|---|---|
| thinking_budget | HTTP 400 | 改用 thinking_level：low / medium / high |
| thinking_level=minimal | HTTP 400 | Carbon 没有 minimal 档，用 low |
| candidate_count > 1 | HTTP 400 | 保持为 1 |
| temperature / top_p / top_k | 被忽略 | 直接删掉 |
| max_output_tokens 过低 | 静默截断，空文本照样收费 | 至少 32,768；high 档配更大预算 |
| 默认 HTTP 超时 | 长思考任务超时 | 流式长解码建议 15–20 分钟 |
另有两个默认值陷阱：Carbon 默认 medium——从默认 high 的 Gemini 3.1 Pro Preview 迁移过来的团队，不改代码会降一档，可能误读为能力倒退；Gemini App 内的模型选择器默认则是 High，与 API 默认不同。
AA 模型页数据：Carbon（High）每智能指数任务约 26–27 分钟（同档中位数 13.0 分钟），首个答案 token 约 67.7 秒（中位数 13.45 秒），是同档中最慢的一批。eesel 的实测感受一致：首个词约等 1 分钟，high 档每基准任务约 25.6 分钟。Hacker News 上 GA 公告帖一天内 145 条评论，速度与访问抱怨最先出现。结论很简单：Carbon 不适合任何需要人实时等待的场景；把它当作后台 worker，提交任务后去做别的事。
参考来源：本文为本站原创改写与整理，事实与数据核对自 eesel.ai 测评与 Inferera API 迁移指南（2026-11-11/12）
← 返回 Gemini 4 Carbon 专题Carbon 的思考檔位不是簡單的「越高越好」：Artificial Analysis 的三檔實測顯示，默認的 medium 檔同時是最便宜、最誠實的一檔；而輸出上限設錯了，模型會把 token 全花在思考上、返回空答案，費用照收。本站綜合 eesel.ai 的測評、Inferera 的 API 遷移指南與 Quantslant 的實測，整理出這份避坑指南。先說核心結論：留默認 medium；max_output_tokens 至少 32,768；HTTP 超時 15–20 分鐘；high 只配更大的輸出預算。
Artificial Analysis 指數 v5.0.1（標準價口徑，eesel.ai 11 月 11 日覈查）：
| 思考檔位 | AA 指數 | 每任務成本 | 編造答案率 |
|---|---|---|---|
| Low | 54 | $7.19 | 20% |
| Medium（默認） | 58 | $6.59 | 4.2% |
| High | 60 | $7.76 | 11% |
反直覺的一點是 medium 比 low 更便宜：弱檔位更容易繞圈子、重複嘗試，反而耗更多 token（Hacker News 評論區也有人注意到了同樣的現象）。編造率的差距更值得看：medium 檔約 25 次才編造 1 次，對 Opus 5.5 的約三分之二；high 檔編造率反而回升到 11%——思考更久不等於更誠實，AA-Omniscience 也測得 Carbon（high）的幻覺率 11% 高於 Argon 的 4%。eesel 的評分很形象：硬推理與研究 4.5/5，任何需要人等的事 2/5——「後臺模型，不是實時回答的模型」。
Carbon 的最大輸出上限（流式 65,536 / 非流式 32,768）覆蓋思考 token。Google 長解碼指南原文：「低值如 8,192 會在思考完成前打斷模型」「模型仍在思考時文本可能爲空」。Quantslant 兩次實測確認了這一點：輸出上限 6,000 時，Carbon 花 5,808 tokens 推理、返回空答案，照樣收費；正則任務 medium 檔用掉全部 16,000 tokens 推理，未返回一行代碼。老張博客也遇到同樣情況：Carbon 在 high 檔處理長日誌時，在寫出一個字之前就耗盡了輸出 tokens。狀態會變成 incomplete——把它當作上限問題處理：調高上限、重試，並接受第一次嘗試已經上了賬單。
Carbon 在請求結構層面是 Argon 的直接替代（改模型 ID 即可），但以下參數會出問題（Inferera 遷移指南，11 月 12 日）：
| 寫法 | 結果 | 正確做法 |
|---|---|---|
| thinking_budget | HTTP 400 | 改用 thinking_level：low / medium / high |
| thinking_level=minimal | HTTP 400 | Carbon 沒有 minimal 檔，用 low |
| candidate_count > 1 | HTTP 400 | 保持爲 1 |
| temperature / top_p / top_k | 被忽略 | 直接刪掉 |
| max_output_tokens 過低 | 靜默截斷，空文本照樣收費 | 至少 32,768；high 檔配更大預算 |
| 默認 HTTP 超時 | 長思考任務超時 | 流式長解碼建議 15–20 分鐘 |
另有兩個默認值陷阱：Carbon 默認 medium——從默認 high 的 Gemini 3.1 Pro Preview 遷移過來的團隊，不改代碼會降一檔，可能誤讀爲能力倒退；Gemini App 內的模型選擇器默認則是 High，與 API 默認不同。
AA 模型頁數據：Carbon（High）每智能指數任務約 26–27 分鐘（同檔中位數 13.0 分鐘），首個答案 token 約 67.7 秒（中位數 13.45 秒），是同檔中最慢的一批。eesel 的實測感受一致：首個詞約等 1 分鐘，high 檔每基準任務約 25.6 分鐘。Hacker News 上 GA 公告帖一天內 145 條評論，速度與訪問抱怨最先出現。結論很簡單：Carbon 不適合任何需要人實時等待的場景；把它當作後臺 worker，提交任務後去做別的事。
參考來源：本文爲本站原創改寫與整理，事實與數據覈對自 eesel.ai 測評與 Inferera API 遷移指南（2026-11-11/12）
← 返回 Gemini 4 Carbon 專題Carbon's thinking levels are not a simple "higher is better": Artificial Analysis data across all three levels shows the default medium level is simultaneously the cheapest and the most honest — and if you set the output cap wrong, the model spends everything on thinking and returns an empty answer that is still billed. This guide synthesizes eesel.ai's review, Inferera's API migration guide and Quantslant's measurements. The core advice up front: keep the default medium; set max_output_tokens to at least 32,768; set HTTP timeouts to 15–20 minutes; use high only with a larger output budget.
Artificial Analysis Intelligence Index v5.0.1, at list prices (checked by eesel.ai, Nov 11):
| Thinking level | AA index | Cost per task | Made-up-answer rate |
|---|---|---|---|
| Low | 54 | $7.19 | 20% |
| Medium (default) | 58 | $6.59 | 4.2% |
| High | 60 | $7.76 | 11% |
The counterintuitive part is medium being cheaper than low: weaker settings loop more and retry more, burning more tokens (Hacker News commenters spotted the same oddity). The made-up-rate gap matters more: medium fabricates about once in 25 answers, against roughly two in three for Opus 5.5; high climbs back to 11% — thinking longer does not mean being more honest, and AA-Omniscience likewise measured Carbon (high) hallucinating at 11% versus Argon's 4%. Eesel's scoring puts it vividly: 4.5/5 for hard reasoning and research, 2/5 for anything a person waits on — "a back-office model, not the one that answers live".
Carbon's max output cap (65,536 streaming / 32,768 non-streaming) covers thinking tokens. Google's long-decode guide says it plainly: "A low value, such as 8,192, stops the model before it finishes thinking" and "Text can be empty if the model was still thinking." Quantslant confirmed it twice in practice: with a 6,000-token cap, Carbon spent 5,808 tokens on reasoning and returned an empty answer, still billed; on a regex task at medium effort it spent all 16,000 tokens on reasoning and returned no code. Lao Zhang's blog hit the same thing: Carbon at high effort ran out of output tokens on a long log before writing a word. The status becomes incomplete — treat it as a cap problem: raise the limit, retry, and accept that the first attempt is already on the bill.
Carbon is a drop-in replacement for Argon at the request-schema level (change the model ID and go), but these parameters break (Inferera migration guide, Nov 12):
| Setting | Result | Correct approach |
|---|---|---|
| thinking_budget | HTTP 400 | Use thinking_level: low / medium / high |
| thinking_level=minimal | HTTP 400 | Carbon has no minimal level; use low |
| candidate_count > 1 | HTTP 400 | Keep it at 1 |
| temperature / top_p / top_k | Ignored | Remove them |
| max_output_tokens too low | Silent truncation; empty text still billed | At least 32,768; larger budget for high |
| Default HTTP timeout | Long-thinking tasks time out | 15–20 minutes recommended for streaming long decode |
Two more default traps: Carbon defaults to medium — teams migrating from Gemini 3.1 Pro Preview (which defaults to high) drop a level without changing code, which can read as a regression; and the Gemini app's model picker defaults to High, unlike the API default.
From the AA model page: Carbon (High) takes about 26–27 minutes per Intelligence Index task (median in its tier: 13.0 minutes) and about 67.7 seconds to the first answer token (median 13.45 seconds) — among the slowest in its price tier. Eesel's hands-on experience matches: about a minute before the first word, ~25.6 minutes per benchmark task on high. The Hacker News thread on the GA post drew 145 comments within a day, with speed and access complaints showing up first. The conclusion is simple: Carbon doesn't belong anywhere a person waits in real time; treat it as a background worker — submit the job and go do something else.
Reference source: this article is an original rewrite produced by this site; facts and figures were checked against eesel.ai review and Inferera API migration guide (Nov 11–12, 2026)
← Back to the Gemini 4 Carbon topic page