上个月我们团队在做一个文档处理 pipeline——要把客户上传的合同 PDF 做三件事：生成摘要、提取结构化字段、再用 AI 补一段代码把数据灌进 CRM。老板让我出个成本预算，我说行，那我就把手头能用的模型都跑一遍真实数据，算个账。

结果算完我人傻了。同样 1000 份合同跑下来，最贵的方案和最便宜的方案之间差了 11 倍。不是什么"贵一点便宜一点"的问题，是直接决定这个功能做不做得起的问题。

这篇文章我把整个测算过程、踩的坑、最终选型逻辑全写出来。如果你也在纠结"到底选哪个模型省钱"，这篇应该能帮你少走弯路。

测试任务设计

我没搞那种"写一首诗"的玩具 benchmark，用的是真实业务场景：

场景 A：代码生成
输入：一段自然语言需求描述（平均 320 tokens），要求输出可运行的 Python 函数（平均输出 580 tokens）。跑了 200 条。

场景 B：长文档摘要
输入：合同全文（平均 12,400 tokens），输出 500 字摘要（约 380 tokens）。跑了 150 份。

场景 C：结构化信息提取
输入：合同全文 + JSON Schema 定义（平均 13,200 tokens），输出结构化 JSON（平均 420 tokens）。跑了 150 份。

三个场景加起来，输入输出 token 量我都记了精确数字，下面直接算钱。

核心参数与定价对比表

先把 2026 年 4 月各模型的官方定价列出来（美元/百万 tokens）：

模型	输入价格	输出价格	上下文窗口	最大输出	缓存输入折扣
GPT-5.5	$12.00	$48.00	256K	32K	50% off
GPT-5.5 Mini	$1.50	$6.00	256K	32K	50% off
Claude Opus 4.7	$15.00	$75.00	200K	32K	90% off
Claude Sonnet 4.6	$3.00	$15.00	200K	16K	90% off
Claude Haiku 4.5	$0.80	$4.00	200K	8K	—
Gemini 3.5 Flash	$0.15	$0.60	1M	8K	75% off
Gemini 3.1 Pro	$3.50	$10.50	2M	8K	—
DeepSeek V4 预览版	$0.55	$2.19	128K	8K	—
DeepSeek V3.2	$0.27	$1.10	128K	8K	—
Qwen3	$0.40	$1.60	128K	8K	—

光看这张表你可能觉得"选最便宜的不就行了"。实际跑下来不是这么回事。

Benchmark 与质量约束

便宜的模型如果质量不达标，返工成本更高。我先跑了一轮质量评估：

模型	代码生成通过率	摘要 ROUGE-L	结构化提取准确率	综合可用
GPT-5.5	94.5%	0.72	97.3%	✅
GPT-5.5 Mini	82.0%	0.65	91.2%	✅（需复检）
Claude Opus 4.7	96.0%	0.74	98.1%	✅
Claude Sonnet 4.6	91.5%	0.71	96.5%	✅
Claude Haiku 4.5	76.0%	0.58	88.4%	⚠️ 场景受限
Gemini 3.5 Flash	79.5%	0.63	90.8%	✅（需复检）
Gemini 3.1 Pro	89.0%	0.69	95.2%	✅
DeepSeek V4 预览版	90.5%	0.70	95.8%	✅
DeepSeek V3.2	85.0%	0.66	92.1%	✅（需复检）
Qwen3	86.5%	0.67	93.0%	✅（需复检）

代码生成通过率低于 85% 的我直接排除了——返工一次等于白花钱。Haiku 4.5 在代码场景基本不能用，但做简单摘要还行。

三场景成本测算（人民币）

按 1 USD = 7.24 CNY 换算（4 月 22 号汇率）。

场景 A：代码生成（200 条）

总输入：200 × 320 = 64,000 tokens
总输出：200 × 580 = 116,000 tokens

模型	输入费用	输出费用	总费用(CNY)	单条成本
GPT-5.5	¥5.56	¥40.32	¥45.88	¥0.229
GPT-5.5 Mini	¥0.69	¥5.04	¥5.73	¥0.029
Claude Opus 4.7	¥6.95	¥63.00	¥69.95	¥0.350
Claude Sonnet 4.6	¥1.39	¥12.60	¥13.99	¥0.070
Gemini 3.5 Flash	¥0.07	¥0.50	¥0.57	¥0.003
DeepSeek V4 预览版	¥0.25	¥1.84	¥2.09	¥0.010
Qwen3	¥0.19	¥1.34	¥1.53	¥0.008

场景 B：长文档摘要（150 份）

总输入：150 × 12,400 = 1,860,000 tokens
总输出：150 × 380 = 57,000 tokens

模型	输入费用	输出费用	总费用(CNY)	单份成本
GPT-5.5	¥161.57	¥19.81	¥181.38	¥1.209
GPT-5.5 Mini	¥20.20	¥2.48	¥22.68	¥0.151
Claude Opus 4.7	¥201.97	¥30.95	¥232.92	¥1.553
Claude Sonnet 4.6	¥40.39	¥6.19	¥46.58	¥0.311
Gemini 3.5 Flash	¥2.02	¥0.25	¥2.27	¥0.015
DeepSeek V4 预览版	¥7.40	¥0.90	¥8.30	¥0.055
Qwen3	¥5.38	¥0.66	¥6.04	¥0.040

场景 C：结构化提取（150 份）

总输入：150 × 13,200 = 1,980,000 tokens
总输出：150 × 420 = 63,000 tokens

模型	输入费用	输出费用	总费用(CNY)	单份成本
GPT-5.5	¥172.01	¥21.90	¥193.91	¥1.293
Claude Opus 4.7	¥215.01	¥34.21	¥249.22	¥1.661
Claude Sonnet 4.6	¥43.00	¥6.84	¥49.84	¥0.332
Gemini 3.5 Flash	¥2.15	¥0.27	¥2.42	¥0.016
DeepSeek V4 预览版	¥7.88	¥1.00	¥8.88	¥0.059

三场景总成本汇总

把三个场景加起来，跑完一整批（200+150+150=500 条任务）的总花费：

模型	总成本(CNY)	日均（按 20 工作日摊）	质量评级
Claude Opus 4.7	¥552.09	¥27.60	S
GPT-5.5	¥421.17	¥21.06	S
Claude Sonnet 4.6	¥110.41	¥5.52	A
GPT-5.5 Mini	¥28.41	¥1.42	B+
DeepSeek V4 预览版	¥19.27	¥0.96	A-
Qwen3	¥7.57*	¥0.38	B
Gemini 3.5 Flash	¥5.26	¥0.26	B

*Qwen3 结构化提取场景偶尔输出格式不合规，实际可能需要 retry，真实成本 ×1.1~1.2

差距就在这里——Opus 4.7 跑完一批 ¥552，Gemini 3.5 Flash 只要 ¥5.26。差了 105 倍。但质量差距也摆在那里。

API 调用实战代码

我跑测试用的代码框架，三个场景共用一套 client：

from openai import OpenAI
import json, time

client = OpenAI(
 api_key="your-key",
 base_url="https://api.ofox.io/v1"
)

def run_code_gen(prompt: str, model: str) -> dict:
 """场景A：代码生成"""
 start = time.time()
 resp = client.chat.completions.create(
 model=model,
 messages=[
 {"role": "system", "content": "你是一个 Python 开发专家，只输出可运行的代码，不要解释。"},
 {"role": "user", "content": prompt}
 ],
 temperature=0.2,
 max_tokens=2048
 )
 latency = time.time() - start
 return {
 "code": resp.choices[0].message.content,
 "input_tokens": resp.usage.prompt_tokens,
 "output_tokens": resp.usage.completion_tokens,
 "latency_ms": int(latency * 1000)
 }

def run_summarize(doc_text: str, model: str) -> dict:
 """场景B：长文档摘要"""
 resp = client.chat.completions.create(
 model=model,
 messages=[
 {"role": "system", "content": "用500字以内概括这份合同的核心条款、双方义务和违约责任。"},
 {"role": "user", "content": doc_text}
 ],
 temperature=0.3,
 max_tokens=1024
 )
 return {
 "summary": resp.choices[0].message.content,
 "input_tokens": resp.usage.prompt_tokens,
 "output_tokens": resp.usage.completion_tokens
 }

def run_extraction(doc_text: str, schema: dict, model: str) -> dict:
 """场景C：结构化提取"""
 resp = client.chat.completions.create(
 model=model,
 messages=[
 {"role": "system", "content": f"从合同中提取信息，严格按以下 JSON Schema 输出：\n{json.dumps(schema, ensure_ascii=False)}"},
 {"role": "user", "content": doc_text}
 ],
 temperature=0.0,
 max_tokens=1024,
 response_format={"type": "json_object"}
 )
 return {
 "data": json.loads(resp.choices[0].message.content),
 "input_tokens": resp.usage.prompt_tokens,
 "output_tokens": resp.usage.completion_tokens
 }

跑批量测试的时候我用了并发 + 重试：

import asyncio
from openai import AsyncOpenAI

async_client = AsyncOpenAI(
 api_key="your-key",
 base_url="https://api.ofox.io/v1"
)

async def batch_run(tasks, model, concurrency=5):
 semaphore = asyncio.Semaphore(concurrency)
 results = []

 async def _run_one(task):
 async with semaphore:
 for attempt in range(3):
 try:
 resp = await async_client.chat.completions.create(
 model=model,
 messages=task["messages"],
 temperature=task.get("temperature", 0.2),
 max_tokens=task.get("max_tokens", 2048)
 )
 return {"ok": True, "resp": resp}
 except Exception as e:
 if "429" in str(e):
 await asyncio.sleep(2 ** attempt)
 else:
 return {"ok": False, "error": str(e)}
 return {"ok": False, "error": "max retries"}

 results = await asyncio.gather(*[_run_one(t) for t in tasks])
 return results

跑 DeepSeek V4 预览版的时候偶尔会碰到这个错：

Error code: 429 - {'error': {'message': 'Rate limit reached for model deepseek-v4-preview', 'type': 'rate_limit_error'}}

把并发从 10 降到 5 就好了。反正它便宜，慢点跑也无所谓。

调用链路与架构

graph TB
 A[任务队列<br/>500条混合任务] --> B{任务路由}
 B -->|代码生成<br/>质量优先| C[Claude Sonnet 4.6]
 B -->|长文档摘要<br/>成本优先| D[DeepSeek V4 预览版]
 B -->|结构化提取<br/>准确率优先| E[Claude Sonnet 4.6]
 B -->|简单摘要<br/>极致省钱| F[Gemini 3.5 Flash]

 C --> G[API 聚合网关<br/>统一 base_url]
 D --> G
 E --> G
 F --> G

 G --> H[结果校验]
 H -->|格式错误/质量不达标| I[Fallback: GPT-5.5]
 H -->|通过| J[写入数据库]

不同预算下的最优组合方案

折腾完之后总结的方案矩阵：

方案一：月预算 < ¥100（个人项目/demo）

• 代码生成 → DeepSeek V4 预览版（通过率 90.5%，够用）
• 摘要 → Gemini 3.5 Flash（质量凑合，极便宜）
• 结构化提取 → DeepSeek V4 预览版
• 月成本估算：约 ¥38（按每天 25 条混合任务）

方案二：月预算 ¥100-500（小团队生产环境）

• 代码生成 → Claude Sonnet 4.6（通过率 91.5%，性价比最优）
• 摘要 → DeepSeek V4 预览版（质量够，成本低）
• 结构化提取 → Claude Sonnet 4.6（准确率 96.5%）
• 月成本估算：约 ¥220（按每天 50 条混合任务）

方案三：月预算 > ¥500（质量零容忍）

• 全部任务 → Claude Opus 4.7 或 GPT-5.5
• Fallback → Claude Sonnet 4.6
• 月成本估算：约 ¥1,100（按每天 50 条混合任务）

我们团队最终选了方案二，加了一层 fallback 逻辑：Sonnet 4.6 如果结构化提取 JSON 解析失败，自动重试一次，还不行就 fallback 到 GPT-5.5。实际 fallback 触发率大概 3.5%，月均多花 ¥15 左右，可以接受。

竞品模型横向对比表

综合质量、成本、延迟三个维度打分（5 分制）：

模型	质量	成本	延迟(P95)	综合推荐场景
Claude Opus 4.7	5.0	1.5	2.8s	关键决策、复杂推理
GPT-5.5	4.8	2.0	2.2s	通用全能、工具调用
Claude Sonnet 4.6	4.5	4.0	1.4s	生产环境首选
GPT-5.5 Mini	3.8	4.5	0.9s	批量简单任务
DeepSeek V4 预览版	4.3	4.8	1.8s	高性价比全能
Gemini 3.5 Flash	3.5	5.0	0.6s	极致省钱、高并发
Qwen3	3.7	4.7	1.2s	中文场景
DeepSeek V3.2	3.9	4.9	1.5s	稳定版生产

踩坑记录

坑 1：Prompt Caching 没算进去差很多

Claude Sonnet 4.6 的 prompt caching 折扣是 90% off。我场景 B 和 C 的 system prompt 是固定的，150 份合同用同一个 system prompt，实际输入成本比上面表格还能再省 40% 左右。但这个要求你连续调用、间隔不能太长。我一开始用 sleep(30) 做限流，结果 cache 全失效了，改成 sleep(2) 才吃到缓存。

坑 2：response_format 不是所有模型都支持

DeepSeek V4 预览版支持 response_format: json_object，但 Gemini 3.5 Flash 走 OpenAI 兼容协议时偶尔会忽略这个参数，输出带 markdown code fence 的 JSON。我加了一层后处理 strip 掉 ```json 前缀才解决。

坑 3：Token 计数方式不同导致账单对不上

GPT-5.5 和 Claude 的 tokenizer 不一样，同一段中文文本 Claude 大概多 15-20% tokens。我一开始用 tiktoken 估算所有模型的成本，结果 Claude 的实际账单比预估高了 18%。后来直接看 API 返回的 usage 字段才准。

FAQ

Q1：DeepSeek V4 预览版稳定性怎么样？能上生产吗？
跑了两周，可用率大概 98.7%，偶尔有 429 限流，没碰到过 500 错误。轻量生产可以用，核心链路建议加 fallback。

Q2：Gemini 3.5 Flash 质量那么差为什么还推荐？
看场景。纯摘要（不需要精确数字提取）它完全够用，价格是 Sonnet 4.6 的 1/20。批量预处理、初筛这种"错了也不致命"的环节很适合。

Q3：为什么不测 Llama 4 开源模型自部署？
测了，但自部署的 GPU 成本（A100 按小时租）算下来，除非你日调用量过 10 万次，否则比直接调 API 还贵。我们量不够，没意义。

Q4：Prompt Caching 到底能省多少？
取决于你的 system prompt 长度和调用密度。我的场景里 system prompt 约 800 tokens，连续调用间隔 < 5s，Claude 实际输入成本降了约 42%。间隔超过 5 分钟基本就没缓存了。

Q5：多模型混用怎么管理 API Key 和账单？
我们用的是 API 聚合平台（OpenRouter、ofox.io 这类），一个 Key 调所有模型，后台能按模型维度看每天花了多少。ofox.io 是 0% 加价对齐官方价格，OpenRouter 收 5.5% 手续费，我们最后选了前者。后台能看到每个团队成员调了哪个模型、花了多少钱，月底对账方便。

Q6：GPT-5.5 和 Claude Opus 4.7 到底选哪个？
代码生成两者差不多，Opus 4.7 在长文档理解上略强（ROUGE-L 高 0.02），但贵了 30%。我的建议是：如果你的场景输入 token 量大（>10K），选 GPT-5.5 更划算；如果需要极致准确率且预算充足，Opus 4.7。

Q7：这些价格会变吗？
肯定会。2026 年 Q1 各家降了一轮价，Q2 可能还会降。建议每月初查一次官方 pricing page。我这篇数据是 4 月 22 号的快照。

Q8：结构化提取为什么不用 Function Calling？
试了，效果差不多，但 Function Calling 的 token 开销更大（schema 定义会被算进 input）。直接在 system prompt 里贴 schema + 用 json_object 模式，实测更省钱。

小结

跑完这一轮测试我的结论就一个：别用一个模型打天下。

Claude Sonnet 4.6 是 2026 年 4 月生产环境的甜蜜点——质量够用、价格适中、延迟低。但如果你有大量"不那么重要"的任务（初筛、预处理、简单分类），丢给 Gemini 3.5 Flash 或 DeepSeek V3.2 能省出一大截预算。关键决策环节再用 Opus/GPT-5.5 兜底。

这套混合方案是不是最优解我也不敢打包票——每家的 token 计费方式、缓存策略都在变。但至少目前跑了三周，月成本从最初预估的 ¥800+ 降到了 ¥240 左右，老板没再问我"这个 AI 功能能不能砍掉"。

折腾半天，值了。