Qwen3.8-Max 的 0902 快照价格和上一版完全一样，每百万输入 token $2.00、输出 $6.00。它同时在每次请求上多花 38 个输入 token。 我们在三个长度不同的 prompt 上测了这个差值，每次都是 38，没有浮动。下面所有内容来自 2026 年 9 月 4 日的 实时目录和实时 API 调用。
我们测到了什么
同样的 prompt，同样的参数，两个模型字符串。 唯一的区别是哪个快照来应答。
| Prompt | qwen3.8-max |
qwen3.8-max-0902 |
差值 |
|---|---|---|---|
Reply with exactly: ok |
28 | 66 | +38 |
What is 2+2? |
30 | 68 | +38 |
Rewrite this GROUP BY as a window function. |
33 | 71 | +38 |
这些是 /v1/chat/completions 返回的 usage.prompt_tokens，请求体除模型字符串外完全相同。三个不同长度的 prompt 上偏移量恒定，说明这是加在每次调用前面的固定开销，而不是那种会随输入长度放大的分词器变更。
按每百万输入 token $2.00 算，38 个 token 是每次请求 $0.000076。几十次调用时它什么都不是，上了量就是真金白银：
| 请求数 | 多出的输入 token | 多出的成本 |
|---|---|---|
| 10,000 | 380,000 | $0.76 |
| 1,000,000 | 38,000,000 | $76 |
| 10,000,000 | 380,000,000 | $760 |
所以准确的总结是：单 token 价格没变，单次调用的底噪变了，这件事重不重要取决于你的请求次数而不是 token 总量。高频短 prompt 的负载感受最明显，因为 38 个 token 加在 28 个 token 的 prompt 上，输入侧直接翻了一倍还多。
价目表一模一样
| 每百万 token 费率 | qwen3.8-max |
qwen3.8-max-0902 |
|---|---|---|
| 输入 | $2.00 | $2.00 |
| 输出 | $6.00 | $6.00 |
| 缓存读 | $0.25 | $0.25 |
| 缓存写 | $2.50 | $2.50 |
| 联网搜索 | 每次 $0.01 | 每次 $0.01 |
读取自 2026 年 9 月 4 日实时 /v1/models 响应里的 pricing 对象，每一格都对得上。能力有提升而不涨价属于好情况；这些费率跟上一代旗舰以及直连 QwenCloud 怎么比，见 Qwen3.8 Max 价格与接入指南。
阿里说改了什么
代码、协同智能体能力和视觉理解。 2026-09-02 快照的目录描述提到代码与协同智能体能力显著增强、视觉理解优化，同时明确保留上一版的 1M 上下文、深度推理模式以及图片和视频输入。
这段描述里没有的是 benchmark 数字，所以现在还没有可以拿去对榜单核实的东西。能力提升这部分请当作厂商说法，而 38 token 这个测量结果是可以独立验证的那部分，因为它确实可以。
上下文窗口那一行需要加个说明
两个版本都是 1M 上下文模型，但目录的上报方式不同。 不带日期的版本报 context_length: 1131072，0902 快照报 1000000。两者的描述都写 1M，最大补全长度也都是 131,072 token。
这看起来像能力缩水，但几乎可以肯定不是。1,131,072 等于 1,048,576 加 82,496，读起来像是「输入上限加一点余量」而不是一个干净的对外数字；1,000,000 才是那个整数营销口径。稳妥的解读是上报口径变了而不是模型变了。不稳妥的解读是看到数字变小就认定阿里缩了窗口，然后照着一个可能不存在的限制去做设计。
如果你的负载真的会逼近百万 token 的上下文，那就在你准备上线的那个快照上实测真实上限，而不是相信目录里的任何一个数字。1,000,000 token 以下在两个版本上都是安全的。
其余部分完全相同
| 属性 | 两个版本 |
|---|---|
| 最大补全 token | 131,072 |
| 输入模态 | 文本、图片 |
| 输出模态 | 文本 |
| 端点 | /v1/chat/completions、/v1/responses |
| 参数 | temperature、top_p、max_tokens、stop、tools、tool_choice、response_format、reasoning |
| 分词器 | qwen |
参数列表逐字节一致，这也是迁移只需改一个字符串的原因：
- "model": "bailian/qwen3.8-max"
+ "model": "bailian/qwen3.8-max-0902"
一个值得知道的坑：空内容
两个版本都是推理模型，这会产生一种看起来像失败、其实不是的结果：
{"usage": {"prompt_tokens": 66, "completion_tokens": 20,
"completion_tokens_details": {"reasoning_tokens": 20}}}
20 个补全 token，全部是推理 token，content 回来是空字符串。什么都没坏。在推理模型上把 max_tokens 设成 20，预算在吐出第一个可见字符之前就花在思考上了，响应在上限处被截断。
修法是调大 max_tokens，不是重试也不是换模型。实用规则：在推理模型上，max_tokens 要同时覆盖推理和回答，而推理不管你看不看得见都按输出费率计费。把 max_tokens 当成答案长度来估，正是一个好模型看起来坏掉的原因。
钉住日期，还是跟着指针走
bailian/qwen3.8-max-0902 是冻结的，bailian/qwen3.8-max 不是。 在生产环境中调用大模型时，使用 qwen-max-0902 这类带日期后缀的固定版本端点，与使用 qwen-max 浮动指针端点会产生不同的行为， 与 OpenRouter 等聚合网关均支持指定具体版本号来锁定模型快照，从而避免因底层模型静默更新导致输出特征发生漂移。
这些情况钉带日期的字符串：
输出必须可复现，比如要过评审或审批流程。
一个很大的 prompt 库是对着某一版验证过的，重新验证代价很高。
你想自己决定行为什么时候变，而不是在生产环境里发现它变了。
这些情况用不带日期的字符串：
你更愿意跟着阿里当前的推荐走，不想为此重新部署。
你的 prompt 足够稳健，换快照不构成回归风险。
这是常见的取舍，两边都有代价：钉住意味着在你主动动手之前拿不到改进，跟着指针走意味着你产品底下的模型可能在你没发布任何东西的情况下变了。不管选哪个，都要有意识地选，因为「第一次随手打的那个字符串」正是一个模型被永久钉死然后悄悄过时的原因。
这个模型的位置
放到更大的盘子里看，Qwen3.8 Max 的 $2.00 / $6.00 是旗舰档的价格。Qwen3.8 Max vs DeepSeek V4 Flash 回答的是「有没有更便宜的替代」，Codex CLI 配置指南讲的是把它当编码后端来跑，而这恰好是 0902 快照声称提升最大的那类负载。
来源
价格、上下文长度、参数和模态读取自 2026 年 9 月 4 日的实时 /v1/models 端点。38 token 的差值是同一天对每个模型各发三次实时 /v1/chat/completions 调用测得的，请求体除模型字符串外完全相同。
参考来源
- ofox 文档：模型目录 — https://docs.ofox.io/zh/develop/models
