场景与需求
我维护的小工具站和脚本集要接的活五花八门：客服问答、文章摘要、分类打标是日常大头；隔三差五有硬骨头——日志里找根因、代码评审、数据口径核算。之前一律用同一个模型，结果是简单任务在为用不到的推理能力买单，难任务又嫌它想得不深。
需求拆开是三条：
- 简单任务要快、要便宜，延迟敏感；
- 复杂任务要推理质量，愿意多花钱多等；
- 接入成本要低——最好还是同一个接口，靠参数切换，不要维护两套客户端。
DeepSeek 官方 API 恰好把这两类能力分成两个模型名挂在同一个接口下，接入方式见DeepSeek API 接入教程。
候选方案
| 方案 | 接口模型名 | 特点 | 适合 |
|---|---|---|---|
| V3 系（非推理） | deepseek-chat | 直接给答案，速度快、单价低 | 对话、写作、摘要、分类、格式转换 |
| R1 系（推理） | deepseek-reasoner | 先输出思考过程再给答案，数学/代码/复杂推理强 | 难题求解、代码评审、Agent 规划 |
| 本地蒸馏版 | Ollama 里的 deepseek-r1 各档 | 零 token 成本、数据不出门 | 隐私草稿、离线兜底，能力弱于满血版 |
两个模型名是稳定入口：deepseek-chat 对应 V3 系非推理模型，deepseek-reasoner 对应 R1 系推理模型，背后版本会升级、入口名不变【待补：当前映射的具体版本号】。本地蒸馏档位的选择单独成篇，见本地跑 DeepSeek 要什么配置。
关键差异有三点。其一，输出结构不同：reasoner 会先吐思考过程（流式下在扩展字段 reasoning_content 里），再给最终答案，这段思考本身也占输出量。其二，计费不同：思考 tokens 也按输出计费【待补：官方计费口径原文】，所以同一个问题 reasoner 的实际成本可能是 chat 的数倍。其三，延迟不同：reasoner 要想完才答，首字延迟和总时长都显著更高，交互场景体感明显。
还有一条工程层面的限制：reasoner 的思考内容是给人看的中间产物，官方文档提示不要把 reasoning_content 拼回下一轮请求当上下文用【待补：官方文档原文位置】，多轮对话只需要携带最终答案，把思考链也带上只会白白放大输入成本。
测算模型与假设
先定费用与耗时的估算式（单价【待补：官网价格页】）：
单次成本 = 输入 tokens × 输入单价 + 输出 tokens × 输出单价
reasoner 输出 tokens ≈ 思考 tokens + 最终答案 tokens
单次耗时 ≈ 首 token 延迟 + 输出 tokens ÷ 生成速度用量假设（示例数字，发布前替换为真实统计【待补：近一个月调用日志】）：
| 假设项 | 取值 |
|---|---|
| 日均请求 | 200 次 |
| 任务构成 | 摘要/分类/问答 80%，推理类 20% |
| chat 单次输出 | 约 300 tokens |
| reasoner 单次输出 | 思考约 800 + 答案约 400 tokens |
| 月请求量 | 约 6000 次 |
路由错误是双向亏钱的：该走推理的活塞给 chat，答错了要返工，一次返工等于两次调用还搭上一次坏体验；不该走推理的活塞给 reasoner，多出来的思考 tokens 全是白花的钱，延迟还翻倍。所以”怎么路由”和”选哪个模型”是同级别的问题，后面的决策框架主要就是在解前者。
测算结果表
按上面的假设推一版（单价与速度实测【待补】，发布前用真实数据重算全表）：
| 维度 | deepseek-chat | deepseek-reasoner |
|---|---|---|
| 单次输出 tokens | 约 300 | 约 1200（含思考） |
| 单次成本（相对） | 1 倍基准 | 约 3~5 倍 |
| 首 token 延迟 | 秒级 | 明显更长【待补：实测数据】 |
| 月成本占比（按 20% 用量） | 约 55% | 约 45% |
| 数学/代码题表现 | 够用但非强项 | 强项【待补：同题实测正确率】 |
结论在算之前就浮出来了：20% 的推理请求，花掉接近一半的预算。如果推理请求里再混进本不需要推理的活，浪费还会放大；反过来，把该推理的活塞给 chat 返工重试，省的钱也都会赔进去。
决策框架
三个问题依次问，答案决定路由：
- 任务有没有可验证的正确答案？ 有（数学、代码逻辑、根因分析）→ 倾向 reasoner；没有（文风改写、摘要、闲聊）→ chat。
- 要不要看推理链？ 需要审计”为什么这么判”的场景（风控解释、评分依据）→ reasoner 的思考过程本身就是交付物的一部分。
- 延迟与成本预算内吗？ 在线交互对延迟敏感，reasoner 慎用；离线跑批不敏感，可以放宽。
补一条产品细节：切到 reasoner 后，界面和日志要给思考内容留展示位，并配”思考中”的状态提示，否则用户看到首字迟迟不来会以为卡死了——首字延迟变长是它区别于 chat 最直观的体感。
落到代码里就是一行路由函数，接在业务分发层：
REASONING_TASKS = {"math", "code_review", "root_cause", "planning"}
def pick_model(task_type: str) -> str:
return "deepseek-reasoner" if task_type in REASONING_TASKS else "deepseek-chat"同一个问题两个模型的直观差异，curl 就能对比：
curl https://api.deepseek.com/chat/completions \
-H "Content-Type: application/json" \
-H "Authorization: Bearer $DEEPSEEK_API_KEY" \
-d '{"model": "deepseek-reasoner", "messages": [{"role": "user", "content": "9.11 和 9.9 哪个大"}]}'reasoner 的返回里会先看到一段思考内容，再是最终答案；换成 deepseek-chat 则直接给答案。两个模型的调用方式和参数完全一致，切换成本就是一个字符串——这正是同一家 API 内部做分层的优势。若还在纠结 API 与本地部署的取舍，先看DeepSeek 怎么用：网页版/App/API/本地部署怎么选。
我的最终选择
- 默认 deepseek-chat：占八成的日常任务全部走它，快和便宜是硬道理；
- reasoner 进白名单：只有数学核算、代码评审、根因分析三类任务路由过去，并限制触发频率，避免被滥用成默认选项；
- 本地蒸馏版做隐私层：涉敏文本先在本地用小模型脱敏和打草稿，结果再上 API 精加工，部署配置见本地跑 DeepSeek 要什么配置；
- 每月对账一次：按上面的测算表回填真实数据，推理请求占比若超过 30% 就重新评估白名单。
这套结构的要点不是”哪个模型更好”，而是让任务类型决定模型，而不是让习惯决定。