qwen3 coder plus 价格

打算把代码补全、批量改仓库这类活交给 Qwen3 Coder Plus，翻官方页面只看到一串单价，实际跑起来账单对不上，是最常见的卡点。问题通常不在单价，而在计费口径：上下文长度落在哪一档、缓存有没有命中、思考型输出算不算在内。这篇不报具体数字，只给一套看价格结构的顺序，让你打开官方页面就知道该盯哪几行、该拿自己的用量怎么试算。

打算把代码补全、批量改仓库这类活交给 Qwen3 Coder Plus，翻官方页面只看到一串单价，实际跑起来账单对不上，是最常见的卡点。问题通常不在单价本身，而在计费口径：上下文长度落在哪一档、缓存有没有命中、思考型输出算不算在内。下面这套顺序不报具体数字，只告诉你怎么看结构。

打开价格页先别急着记数字，先确认三件事：币种和是否含税、是按量还是走套餐、分档计价的触发条件。这三项对齐之后，再拿自己真实的代码任务量去试算，账单才不会跑偏。本篇给的是排查顺序和判断标准，具体数字一律到站内页面核对当时的版本。

先看清它的价格由哪几块拼起来

代码场景的账单基本由输入、输出、缓存读、缓存写四块组成。很多人只看一个「每百万 token」的总数，忽略了这四项各自的单价和适用条件，结果实跑账单和手算差出一大截。逐项对照官方计价表，把每一块单独标出来，是第一步。

输入计费

你发过去的提示词、文件片段、历史对话都算在内，代码任务里这部分往往被反复放大。

输出计费

模型生成的补全、diff、工具调用参数，通常比输入贵，代码任务输出占比不低。

缓存读

命中缓存后按优惠价计读，前提是你的请求前缀稳定可复用。

缓存写

首次写入缓存或刷新缓存的开销，命中率低时它可能吃掉省下的钱。

分档计价是另一个坑。上下文或请求长度跨过某个门槛后，是整体跳档还是只对超出部分跳档，两种算法结果差别很大。先把这条规则问清楚，再决定要不要为长上下文单独做限额。币种、含税与否、按量还是套餐也要先对齐，可以到 官方 API 价格 与 倍率、折扣、赠送额度：比价前必须对齐的 4 个口径 交叉确认。

代码场景的用量形状和聊天不一样

聊天的上下文一般很短，代码任务完全不同。一轮补全可能带上整个文件甚至多个仓库片段，输入量会被反复放大。所以先量清楚你的平均上下文长度，再谈单价才有意义。拿一份真实任务样本，统计它的输入、输出和轮次，比看任何别人的结论都准。

• 一轮补全带上整文件或多仓库片段，输入被放大，先量平均上下文长度再比价。
• 多轮编辑会累积历史，同一份上下文被反复重发，成本是线性叠上去的。
• 改一个 bug 跑十几轮工具调用很常见，每轮都算一次调用，预算按「轮次 × 单轮成本」估。
• 如果任务以短补全为主，大上下文档位的价格优势就体现不出来，别硬套长上下文场景的结论。

想快速试算，可以到 Token 单价换算 拿真实样本跑一遍，把输入、输出、缓存三项分别填进去，看哪一项占比最高。占比最高的那一项，就是你后面优化和谈判的重点。

走中转和缓存：两个最容易跑偏的地方

如果你不直连官方，而是走中转渠道，最终单价会在官方基础上叠一层渠道倍率，同一个模型不同渠道可以差出一截。接之前把候选渠道比一遍，到 中转站目录 和 价格变动追踪 看当时的倍率和变动情况，不要只信第一次报价。

缓存口径各家写法不同，别拿 A 家的命中率去套 B 家。想搞清命中条件和省钱位置，参考 上下文缓存和提示缓存差在哪？命中条件与省钱位置 对齐定义。限速被卡后重发的那部分算不算钱，要在接入前就问清，见 API 限速被卡之后重发，算不算重复计费？。

拿到报价后，用三步验证它是否适合你

报价看完不等于选型完成。用一套固定流程验证一遍，才能知道这个价格结构对你这种任务量到底划不划算。下面三步不需要复杂工具，一份真实任务样本加一天实跑就能做完。

1. 取样本挑一份真实代码任务，统计输入 token、输出 token 和工具调用轮次，写成一张表。
2. 算理论按官方当前单价算一遍理论成本，输入、输出、缓存分开算，别混在一起。
3. 跑一天接入实跑一天，把实际账单和理论值记下来，算两者差距百分比。

差距超过预期就去查三件事：缓存命中、上下文档位、渠道倍率，这三项能解释绝大多数偏差。模型版本和价格都会变，写死的数字没有意义，每次选型前到 AI 模型库 和 官方 API 价格 看当时的数字。反过来，如果你的任务量很小，或者对成本不敏感，这套流程就不必做，直接按体验选更快。