主题
4.2 推理模式 vs 非推理模式的选择
用 R1 写"Hello World"就像用大炮打蚊子——选对模式，既省时间又省钱。
这一节在讲什么？
DeepSeek 提供了两种模式：推理模式（R1）和非推理模式（V3）。很多用户要么"全部用 R1"（浪费钱），要么"全部用 V3"（复杂问题答不好）。这一节我们建立一个清晰的决策框架——什么任务用推理模式、什么任务用非推理模式、两者的成本差异有多大。掌握这个框架，你能在保证质量的前提下，把 API 成本降低 50% 以上。
两种模式的能力对比
| 维度 | V3（非推理模式） | R1（推理模式） |
|---|---|---|
| 模型名 | deepseek-chat | deepseek-reasoner |
| 输入价格 | $0.27/M | $0.55/M |
| 输出价格 | $1.10/M | $2.19/M |
| 思考过程 | 无 | 有（额外消耗 token） |
| 速度 | 快（1-3 秒） | 慢（5-30 秒） |
| 代码生成 | ⭐⭐⭐⭐ | ⭐⭐⭐⭐ |
| 数学推理 | ⭐⭐⭐ | ⭐⭐⭐⭐⭐ |
| 逻辑分析 | ⭐⭐⭐ | ⭐⭐⭐⭐⭐ |
| Function Calling | ⭐⭐⭐⭐ | ⭐⭐⭐ |
| 内容创作 | ⭐⭐⭐⭐⭐ | ⭐⭐⭐ |
什么时候用推理模式（R1）
推理模式适合需要"深度思考"的任务——多步骤推理、数学证明、复杂逻辑分析。
数学推理：
"证明：对任意正整数 n，n³ - n 总能被 6 整除"
→ R1 会逐步推理：先因式分解 n³-n = n(n-1)(n+1)，
然后证明连续三个整数之积必被 6 整除
→ V3 可能直接给出答案，但推理过程不够严谨复杂逻辑分析：
"分析以下代码的时间复杂度，并给出优化方案：
for i in range(n):
for j in range(n):
for k in range(m):
result.append(matrix[i][j] * vector[k])"
→ R1 会逐步分析每层循环的贡献，给出精确的复杂度分析
→ V3 可能给出大致的复杂度，但细节不够准确代码调试与根因分析：
"这个程序在输入 n > 1000 时会栈溢出，帮我分析原因并修复"
→ R1 会深度分析递归调用链，找出栈溢出的根本原因
→ V3 可能给出通用的建议，但不够精准算法设计：
"设计一个 O(n log n) 的算法，找出数组中第 k 大的元素"
→ R1 会推导出快速选择算法，并分析为什么是 O(n log n)
→ V3 可能直接给出代码，但算法选择的推理不够深入什么时候用非推理模式（V3）
非推理模式适合"快速执行"的任务——代码生成、内容创作、简单问答、Function Calling。
日常代码生成：
"用 Express + TypeScript 写一个 POST /api/users 接口"
→ V3 快速生成代码，质量足够好
→ R1 也能生成，但会"过度思考"，浪费时间内容创作：
"写一篇关于 Python 异步编程的技术博客"
→ V3 生成流畅、结构清晰的博客
→ R1 的写作风格可能过于"学术化"，不够自然Function Calling：
调用工具获取天气信息
→ V3 的工具调用更可靠、更快速
→ R1 的 Function Calling 能力不如 V3简单问答：
"Python 的 list 和 tuple 有什么区别？"
→ V3 快速回答，1-2 秒
→ R1 也要"思考"几秒，但答案质量没有明显提升成本对比
R1 的成本比 V3 高很多——不仅单价高，还有思考 token 的额外消耗：
python
# 同样的问题"写一个快速排序"
# V3 的成本
# input: ~50 token × $0.27/M = $0.0000135
# output: ~300 token × $1.10/M = $0.00033
# 合计：$0.00034
# R1 的成本
# input: ~50 token × $0.55/M = $0.0000275
# thinking: ~2000 token × $2.19/M = $0.00438 ← 思考过程！
# output: ~300 token × $2.19/M = $0.000657
# 合计：$0.00506
# R1 的成本是 V3 的 15 倍！对于简单任务，R1 的思考过程是纯粹的浪费——它消耗了大量 token 思考一个不需要深度思考的问题。
决策框架
你的任务需要深度推理吗？
→ 不需要（代码生成、内容创作、简单问答、Function Calling）
→ 用 V3（deepseek-chat）
→ 快速、便宜、质量够用
→ 需要（数学推理、逻辑分析、复杂调试、算法设计）
→ 用 R1（deepseek-reasoner）
→ 深度思考、推理更强
→ 不确定
→ 先用 V3 试一下
→ 如果回答不满意，再切 R1常见误区
误区一：所有任务都用 R1
这是最常见的浪费。R1 的成本是 V3 的 5-15 倍（取决于思考 token 的消耗），对于简单任务，R1 的回答质量跟 V3 差不多，但价格贵得多。养成习惯：简单任务用 V3，复杂推理用 R1。
误区二：R1 的代码生成一定比 V3 好
不一定。对于常规代码生成（写接口、写组件、写脚本），V3 和 R1 的质量差不多。R1 的优势在于需要深度推理的编程任务——算法设计、复杂调试、性能优化。日常编码用 V3 就够了。
误区三：V3 完全不能做推理
V3 也有一定的推理能力——只是不如 R1 强。对于中等复杂度的推理任务（如简单的逻辑分析、代码审查），V3 通常也能给出不错的回答。只有真正需要深度推理的任务才需要 R1。
误区四：R1 的思考过程越多越好
不是。思考过程越长，消耗的 token 越多，费用越高。有时候 R1 会"过度思考"——对简单问题进行不必要的深度推理。如果你发现 R1 的思考过程很长但最终回答跟 V3 差不多，说明这个任务不需要 R1。
小结
这一节我们建立了推理模式 vs 非推理模式的选择框架：V3 适合日常编码、内容创作、Function Calling（快速、便宜）；R1 适合数学推理、逻辑分析、复杂调试（深度思考、更贵）。核心原则是"按需选择"——简单任务用 V3，复杂推理用 R1，不确定时先试 V3。下一节我们学习 max_tokens 与思考过程的配合。