预算紧、跑量最大，填 deepseek-v3.2-thinking，0.049 元一次；中文长文和语感交给 kimi-k2.5；复杂代码和难推理用 deepseek-v4-pro-thinking；批量清洗、分类、打标给 deepseek-v4-flash-thinking，0.05 元一次；要思考链的中文推理题用 deepseek-r1-thinking。多模态和超长上下文确实要拼，再上 gemini-3.1-pro-preview，同样 0.09 元一次。
deepseek-v3.2-thinking，0.049 元/次kimi-k2.5，0.09 元/次deepseek-v4-pro-thinking，0.09 元/次deepseek-v4-flash-thinking，0.05 元/次deepseek-r1-thinking，0.049 元/次gemini-3.1-pro-preview，0.09 元/次榜单上浮动的几分，落到业务里往往看不出区别。拉开体验的是定位：有的型号把力气花在长文本理解上，有的花在推理链上，有的花在代码调用上。先看清手里这批请求属于哪类——短问答、长文档、代码补全、结构化抽取，四类的选择完全不同。
| 型号 | 单价 | 定位 | thinking 开销 | 适合场景 | 不适合场景 |
|---|---|---|---|---|---|
| deepseek-v3.2-thinking | 0.049 元/次 | 通用主力、跑量底座 | 中等，默认开 | 日常问答、写文案、翻译、客服脚本 | 超长文档、多模态 |
| deepseek-r1-thinking | 0.049 元/次 | 推理专精 | 高，思考链完整 | 数学题、逻辑题、要展示步骤的推理 | 低延迟对话、海量短文本 |
| deepseek-v4-flash-thinking | 0.05 元/次 | 快速批处理 | 低，出结果快 | 数据清洗、分类、打标、格式转换 | 复杂代码重构、长篇写作 |
| deepseek-v4-pro-thinking | 0.09 元/次 | 国产能力上限 | 高，思考更充分 | 复杂代码、架构建议、多步推理 | 海量低价值请求 |
| kimi-k2.5 | 0.09 元/次 | 中文长文与语感 | 较低 | 长文写作、润色、公文、口播稿 | 多模态、重工具调用 |
| kimi-k2.6 | 0.09 元/次 | 长文升级版本 | 较低 | 长文档摘要、结构化改写 | 极限省钱跑量 |
看两列就够了：单价和 thinking 开销。带 thinking 的型号在返回正文前会先生成一段推理，这段推理同样吃时间，同一道题在不同型号上的耗时可差出几倍。延迟敏感的接口，比如自动补全、实时客服，建议避开思考链重的型号。反过来，一次就要拿到准确结论的场景，思考链省下的是返工成本。
| 档位 | 型号 | 单价 |
|---|---|---|
| 0.049 档 | deepseek-v3.2-thinking、deepseek-r1-thinking | 0.049 元/次 |
| 0.05 档 | deepseek-v4-flash-thinking | 0.05 元/次 |
| 0.09 档 | deepseek-v4-pro-thinking、kimi-k2.5、kimi-k2.6 | 0.09 元/次 |
三档之间差不到一分钱，乘上请求量就不是这个数了。一天一万次请求，0.049 档要 490 元，0.09 档要 900 元，差 410 元；按月算是一万二。
0.049 和 0.05 的差距不构成决策依据。真正影响账单的是重试率：一次失败请求重打一遍，等于单价翻倍。稳定性差一档，比单价差一档贵得多，所以成功率和单价要放一起看。
一次请求固定价，输入长度不影响价格。你贴进去 500 字的需求是 0.049 元，贴进去三万字的技术文档还是 0.049 元。这条规则是后面所有成本结论的前提。
拿 deepseek-v3.2-thinking 举例，一次请求塞进 3 万 token 输入：
gpt-6-astra 的输入价 ¥3/百万 token，3 万 token 约 0.09 元同一段输入，按次计费便宜了将近一半。输入再翻一倍多，按次价格纹丝不动，按量价格会继续往上走。
| 输入长度 | 按次计费（deepseek-v3.2-thinking） | 按量计费（输入 ¥3/百万 token） |
|---|---|---|
| 5 千 token | 0.049 元 | 约 0.015 元 |
| 3 万 token | 0.049 元 | 约 0.09 元 |
| 10 万 token | 0.049 元 | 约 0.3 元 |
结论直接拿去用：输入越长，按次计费越划算。这条正好对上「把整个文件贴给模型改」这种用法——大文件不必切块，整份丢进去，成本一分不多。切块反而更贵，切成五块就是五次请求。
短输入、高并发、输出极短的场景，比如只回一个分类标签，几百 token 就完事，按量计费的单次成本比按次低。判断很简单：单次输入经常低于一万 token 就去算按量；经常几万 token 起，按次更稳，预算也好预估。
改单文件、调单个函数，国产型号早就够用。差距出现在跨文件重构上：一次要动十几个文件、还要保持接口一致时，海外那批型号（claude-sonnet-4-5-thinking，0.09 元/次）的上下文纪律更稳，更不容易忘掉前文改过什么。你的做法很直接：日常单文件修改用国产，跨模块重构切海外，同一张 Key 换个型号名就行。
国产这六个型号的强项在十万字级的中文文档处理。再往上，跨章节的信息串联会开始丢，前面章节的细节到后面就记不住。真要处理上百页的合同、手册、招投标文件，海外的 gemini-3.1-pro-preview（0.09 元/次）更扛得住。别硬塞，超过窗口前先做一层检索，检索用便宜型号跑就够。
本文横评的六个国产型号基本是纯文本能力。识图、看截图、读 PDF 版式，不是它们的战场。项目要做票据识别、界面截图分析、图表理解，这一层直接选海外型号，别在国产型号上反复试。把多模态请求单独走一条通道，文本请求留给国产，这条分工省下的调试时间比省下的钱值钱。
海外的 SDK、文档、社区问答积累更厚，冷门报错更容易搜到现成答案。国产这批走 OpenAI 兼容协议，好处很实在：任何支持自定义地址的客户端都能接，Chatbox、Cherry Studio、NextChat、Cline、RooCode 填地址加 Key 就能跑。差距在细节——参数兼容的边角情况、流式返回的异常分支，踩到的概率略高，上线前留半天调试时间。
固定三档并发 5、20、50，每档各打 200 次请求，任务用同一条中文短请求，比如「把这句话改成 20 字以内的标题」。记录四项：成功率、P50 延迟、P95 延迟、错误码分布。200 次是样本下限，低于这个量 P95 没有参考价值。
这两件事长得很像，靠错误码和时间曲线区分：
timeout、延迟整体抬高但请求还在慢慢返回：模型侧慢，属于这类型号的正常波动429、延迟曲线在某个并发点突然折上去：平台侧限流，你打得太快了500：上游偶发错误，退避重试通常能过拿到结论再动：限流就降并发或者加退避，模型慢就换档位或者换型号。别在限流的时候反复加并发，那只会把错误率推得更高。
| 并发 | 成功率 | P50 | P95 | 主要错误码 |
|---|---|---|---|---|
| 5 | 99% 以上 | 约 2s | 约 6s | 偶发 timeout |
| 20 | 97% 左右 | 约 3.5s | 约 11s | 少量 429 |
| 50 | 88% 左右 | 约 7s | 约 26s | 429 为主，夹杂 500 |
上表是参考区间，不是平台承诺的固定值，网络和时段都会带来差异。跑一遍自己的数据再定并发上限，这半天值得花。
import asyncio, time, statistics, os
from openai import AsyncOpenAI
API_KEY = os.environ["XYUAPI_KEY"]
BASE_URL = "https://xyuapi.top/v1"
# 型号名必须和 /v1/models 返回的 id 一模一样
MODELS = {
"deepseek-v3.2-thinking": 0.049,
"deepseek-r1-thinking": 0.049,
"deepseek-v4-flash-thinking": 0.05,
"deepseek-v4-pro-thinking": 0.09,
"kimi-k2.5": 0.09,
"kimi-k2.6": 0.09,
}
TASK = "把这句话改写成20字以内的标题：远程团队如何用一个接口管理多家大模型。"
REPEAT = 30 # 每个型号发多少条
CONCURRENCY = 5 # 并发上限
client = AsyncOpenAI(api_key=API_KEY, base_url=BASE_URL)
sem = asyncio.Semaphore(CONCURRENCY)
async def one_call(model):
async with sem:
t0 = time.perf_counter()
try:
resp = await asyncio.wait_for(
client.chat.completions.create(
model=model,
messages=[{"role": "user", "content": TASK}],
timeout=120,
),
timeout=120,
)
ok = bool(resp.choices[0].message.content)
code = "ok"
except Exception as e:
ok, code = False, type(e).__name__
return model, ok, code, time.perf_counter() - t0
async def bench(model):
results = await asyncio.gather(*[one_call(model) for _ in range(REPEAT)])
lat = sorted(r[3] for r in results if r[1])
ok_n = sum(1 for r in results if r[1])
p50 = statistics.median(lat) if lat else 0.0
p95 = lat[min(int(len(lat) * 0.95), len(lat) - 1)] if lat else 0.0
errs = {}
for r in results:
if not r[1]:
errs[r[2]] = errs.get(r[2], 0) + 1
unit = MODELS[model]
return model, ok_n / REPEAT, p50, p95, unit, unit * REPEAT, errs
async def main():
rows = []
for m in MODELS:
rows.append(await bench(m))
print("%-28s%9s%8s%8s%10s%9s" % ("model", "success", "P50", "P95", "cost/req", "total"))
total = 0.0
for m, sr, p50, p95, unit, cost, errs in rows:
total += cost
print("%-28s%8.1f%%%7.2fs%7.2fs%10.3f%9.2f" % (m, sr * 100, p50, p95, unit, cost))
if errs:
print("%-28s errors: %s" % ("", errs))
print("all models total cost: %.2f CNY" % total)
asyncio.run(main())pip install openai，Key 放进环境变量 XYUAPI_KEYREPEAT 改成 3 跑一遍，确认六个型号名都能通，再调回 30 或更高CONCURRENCY 从 5 往上加，观察成功率从哪一档开始明显下滑MODELS 里加一行型号名和单价，脚本不用改别的拿两行 curl 就能把型号名验完：
# 1) 列出全部可用型号，把返回的 id 复制出来照着填
curl -s https://xyuapi.top/v1/models \
-H "Authorization: Bearer $XYUAPI_KEY"
# 2) 打一次最小对话请求，确认 Key 和型号都能用
curl -s https://xyuapi.top/v1/chat/completions \
-H "Authorization: Bearer $XYUAPI_KEY" \
-H "Content-Type: application/json" \
-d '{"model":"deepseek-v3.2-thinking","messages":[{"role":"user","content":"说一句你好"}],"max_tokens":32}'/v1/models 返回的结构长这样，data 里的 id 就是能填的型号名：
{
"object": "list",
"data": [
{"id": "deepseek-v3.2-thinking", "object": "model"},
{"id": "kimi-k2.5", "object": "model"}
]
}型号名填错，接口会回一条类似 {"error":{"message":"The model deepseek-v3.2 does not exist ... model not found","type":"invalid_request_error"}} 的错误。排查按三步走：
/v1/models，把返回的 id 列表存成文件-thinking 后缀不能丢，kimi-k2.5 中间那个点也要带上import asyncio, random
from openai import AsyncOpenAI
client = AsyncOpenAI(api_key="在控制台生成的Key", base_url="https://xyuapi.top/v1")
async def call_with_retry(model, messages, max_try=5):
for attempt in range(max_try):
try:
return await client.chat.completions.create(
model=model, messages=messages, timeout=120
)
except Exception as e:
status = getattr(e, "status_code", None)
text = str(e).lower()
# 429 限流、5xx 上游抖动、超时：这三类都值得重试
retryable = status in (429, 500, 502, 503, 504) or "timeout" in text
if not retryable or attempt == max_try - 1:
raise
# 指数退避加随机抖动，避免所有请求同一时刻再撞上去
wait = min(2 ** attempt, 30) + random.uniform(0, 1)
print("retry %d after %.1fs, status=%s" % (attempt + 1, wait, status))
await asyncio.sleep(wait)两个细节决定这套重试有没有用。随机抖动必须加，固定间隔会让失败请求同时回来，把限流撞成第二轮。重试次数要有上限，撞满五次就让它失败并记日志，无限重试只会把额度烧在同一个坏请求上。参数校验类错误（400、404）不要重试，重试一百次也是同样结果。
带 thinking 的型号先生成推理再出正文，复杂题跑两三分钟是常事。超时设 30 秒，会把正常请求判成失败，再重试一遍就是白花两次钱。建议设 120 到 300 秒并开启流式：内容边生成边返回，用户能看到字在动，感知等待明显变短，哪怕总耗时没变。
deepseek-v3.2-thinking，0.049 元/次。这是整张价格表里最低的档位之一，通用能力够用，把它当底座，先让它跑，跑不动再往上换。一天一万次请求不到 500 元。
kimi-k2.5，0.09 元/次。长文写作、润色、公文、口播稿，中文的句子节奏更自然，读起来不像翻译腔。写长内容别省这个钱，返工一次的时间成本远超四分钱差价。kimi-k2.6 同样 0.09 元，长文档摘要和结构化改写交给它。
deepseek-v4-pro-thinking，0.09 元/次。要把国产效果顶到上限就是它，跨文件改动、架构建议、多步推理都放这里。这类请求量通常不大，单价高一点不心疼。
deepseek-v4-flash-thinking，0.05 元/次。出结果快是它的价值，十万条数据的分类任务，快一倍就是省几个小时。判断标准很清晰：答案短、容错高、量大，三样都占就给它。
deepseek-r1-thinking，0.049 元/次。数学题、逻辑推演、要展示步骤的题目，思考链完整，价格还落在 0.049 档。它和 deepseek-v3.2-thinking 同价，选谁看你要不要看推理过程。
只在这三种情况下切：要识图看版式、要处理上百页的超长上下文、要跨十几个文件做大重构。这时候看 gemini-3.1-pro-preview（0.09 元/次）或 claude-sonnet-4-5-thinking（0.09 元/次）。同一张 Key、同一个接口，改个型号名就切过去了，业务代码一行都不用动。
| 你的场景 | 填哪个型号 | 单价 |
|---|---|---|
| 日常问答、跑量 | deepseek-v3.2-thinking | 0.049 元/次 |
| 中文长文写作 | kimi-k2.5 | 0.09 元/次 |
| 复杂代码与推理 | deepseek-v4-pro-thinking | 0.09 元/次 |
| 批量清洗分类打标 | deepseek-v4-flash-thinking | 0.05 元/次 |
| 带步骤的中文推理题 | deepseek-r1-thinking | 0.049 元/次 |
| 多模态与超长上下文 | gemini-3.1-pro-preview | 0.09 元/次 |
先跑一遍上面的压测脚本，拿到你自己网络下的成功率和延迟，再照结论表填型号。顺序是：先定请求类型，再对价格档位，最后用压测数据兜底。反过来容易为用不上的能力多付钱。