国产推理模型盘点：DeepSeek-R1、Qwen-QwQ、Kimi k1.5 等横向对比
“推理模型”（Reasoning Model）是指在生成最终答案前，先输出完整思维链（Chain-of-Thought）的大模型。2025 年 OpenAI 发布 o1 后，国产厂商快速跟进，DeepSeek-R1、通义 QwQ、Kimi k1.5 等陆续上线，部分指标已超越 GPT-o1。本文做横向盘点，帮开发者理清选型逻辑。
如果你是第一次接手要不要换推理模型这种活儿，大概率会踩到的第一个坑不是选型，而是”为什么同一个问题，普通模型答错了，推理模型却答对了”。这背后的机制值得先讲透，不然你很难判断什么场景该上推理模型、什么场景纯属浪费钱。
思维链到底在算什么
普通对话模型是”一次性生成”：拿到 prompt 直接开始吐 token，中间没有回头检查的机会，遇到需要多步推导的题目（数学证明、代码里那种要先分析调用链再改的 bug、复杂的逻辑谜题），经常在某一步走错就一路错到底。
推理模型的做法是在生成最终答案前，先在一个隐藏或半隐藏的”思考区”里把问题拆解、试错、自我纠正，业内管这个叫 test-time scaling（推理时扩展）——简单说就是”用更多计算换更高正确率”，而不是靠更大的模型参数量。DeepSeek-R1 的论文里公开过训练方式：先用强化学习让模型学会”多想几步再答”，再用拒绝采样等手段把高质量的思维链数据蒸馏出来微调。这也是为什么 R1 蒸馏出的 7B/14B/32B 小模型，在数学题上能打过参数量大得多的通用模型——不是小模型变聪明了，是它学会了”先想后答”这个模式。
搞清楚这一点，你就能推出两个直接影响选型和成本的结论：
- 思考越复杂，思维链越长，输出的 token 越多——而绝大多数厂商是按思考 token + 输出 token 分别计费的，这也是为什么推理模型跑一道复杂数学题的账单可能是普通问答的几十倍。
- 思维链本身也会出错——模型在”思考”阶段并不是绝对可靠的，它可能中途换了一个错误方向又绕回来，这也是为什么下文会专门提醒你思维链内容展示给用户时要谨慎。
主流国产推理模型速览
| 模型 | 厂商 | API 模型名 | 开源 | 核心亮点 |
|---|---|---|---|---|
| DeepSeek-R1 | DeepSeek | deepseek-reasoner | 是（671B MoE） | 数学/代码顶级，价格极低 |
| QwQ-32B | 阿里 Qwen 团队 | qwq-32b（DashScope） | 是（32B） | 开源推理模型中最强之一 |
| Kimi k1.5 | 月之暗面 | moonshot-kimi-k1.5（参考官方） | 否 | 超长上下文推理，多模态 |
| Hunyuan-T1 | 腾讯 | 腾讯云 API | 否 | 企业级推理，工具调用优化 |
| ERNIE X1 | 百度 | 千帆平台 | 否 | 搜索增强推理，百度生态 |
模型名以各厂商官方文档为准，部分模型处于内测阶段，接入前请确认 API 权限。
这张表看着简单，但每一行背后都有实际接入时会撞到的细节，值得展开说说：
- DeepSeek-R1 的”671B MoE”指的是混合专家架构总参数量，实际推理时每次激活的参数远小于这个数字，这也是它价格能压这么低的关键原因之一，跟”参数量小所以便宜”是两回事。
- QwQ-32B 标注”是（32B）“指的是稠密（dense）架构，不是 MoE，这意味着它的显存占用和推理延迟更好预估，适合你要自己算清楚部署成本的场景。
- Kimi k1.5 的 API 模型名请务必以月之暗面官方文档实时核对，官方接口命名有调整过历史，直接抄网上博客里的旧名字大概率会拿到 404 或者 model not found。
- 表格里没列的一点：这几家的思维链（reasoning_content 或等价字段）是否会计入上下文长度限制，各家策略不一样，长对话场景务必先用官方文档核实，不要凭经验假设。
能力横向对比
| 评测维度 | DeepSeek-R1 | QwQ-32B | Kimi k1.5 | Hunyuan-T1 |
|---|---|---|---|---|
| 数学（AIME 2024） | 顶级 | 强 | 强 | 中等 |
| 代码（SWE-bench） | 顶级 | 强 | 中等 | 中等 |
| 逻辑推理 | ★★★★★ | ★★★★★ | ★★★★ | ★★★★ |
| 最大上下文 | 64k | 128k | 128k | 32k |
| 多模态推理 | 否（文本） | 否（文本） | 是 | 否 |
| 输出思维链 | 是（reasoning_content） | 是 | 是 | 是 |
| 开源可私有化 | 是 | 是 | 否 | 否 |
评级不是拍脑袋打的，说说依据和实测感受：
**数学（AIME 2024）**这一栏参考的是官方或第三方发布的 AIME（美国数学邀请赛）题库测评分数，属于业内比较公认的高难度数学基准。DeepSeek-R1 和 o1 的分数在同一梯队，QwQ-32B 作为一个 32B 的模型能追到”强”档已经很不容易，实测下来它在需要拆分多步的应用题上偶尔会漏掉一个约束条件，复杂到奥赛级别的题目还是 R1 更稳。
**代码（SWE-bench）**衡量的是”给一个真实 GitHub issue，模型能不能生成可以通过测试的修复补丁”，这比单纯写个函数难得多，因为需要先理解整个仓库的上下文。R1 在这项上表现突出，跟它训练数据里强化学习阶段大量用了代码类任务有关。QwQ 和 Kimi 在这项上属于能用但不惊艳，写单文件脚本没问题，改大型仓库的复杂 bug 建议还是上 R1 或者搭配 Agent 框架多轮迭代。
最大上下文这一列直接决定了你能不能把整个需求文档 + 历史对话一次性喂进去。要注意的是，思维链本身也占上下文——如果你的 prompt 已经接近 128k 上限，模型思考过程可能会因为空间不够被压缩甚至截断，实际可用的”净空间”要打个折扣估算，别卡着上限设计业务。
多模态推理目前只有 Kimi k1.5 支持图文混合输入并在此基础上做推理，比如让它看一张手写数学题的照片直接给出推导过程，这是其他几家暂时做不到的差异化能力，如果你的场景涉及图片/图表理解，基本只能选它。
接入示例（OpenAI 兼容写法）
DeepSeek-R1：
from openai import OpenAI
client = OpenAI(
api_key="sk-xxxxxxxxxxxxxxxx",
base_url="https://api.deepseek.com/v1",
)
resp = client.chat.completions.create(
model="deepseek-reasoner",
messages=[{"role": "user", "content": "解方程：x² - 5x + 6 = 0，给出完整推导"}],
)
print(resp.choices[0].message.reasoning_content) # 思维链
print(resp.choices[0].message.content) # 最终答案
这段代码看着和普通 Chat Completions 调用没区别，唯一的关键点是 reasoning_content 这个字段——它是 DeepSeek 在标准 OpenAI 协议之外自己加的扩展字段，不是所有第三方 SDK 或者网关都会原样透传。如果你用的是某些聚合平台转发的接口，拿到 resp.choices[0].message.reasoning_content 报 AttributeError 或者拿到 None，先别怀疑代码写错了，去平台文档确认它是不是把这个字段过滤掉了，或者换了个名字（有的网关会重命名成 thinking 或塞进 extra 字段里）。
另外这里默认用的是非流式调用，实际生产环境几乎不会这么用——推理模型思考时间长，一道复杂题可能要等十几秒到几十秒才返回第一个字节，用户体验上必须上流式输出，让”思考中”的状态先展示出来。流式写法长这样：
stream = client.chat.completions.create(
model="deepseek-reasoner",
messages=[{"role": "user", "content": "解方程：x² - 5x + 6 = 0，给出完整推导"}],
stream=True,
)
for chunk in stream:
delta = chunk.choices[0].delta
if getattr(delta, "reasoning_content", None):
print(delta.reasoning_content, end="", flush=True) # 边想边吐思维链
if getattr(delta, "content", None):
print(delta.content, end="", flush=True) # 最终答案单独输出
注意这里用 getattr 而不是直接 delta.reasoning_content，是因为流式响应里思维链阶段和答案阶段是两个不同的 delta，思考阶段 content 字段通常是 None，反过来答案阶段 reasoning_content 也是 None，直接取值容易踩空指针类的坑。前端要是想做”思考中…”的动画效果，就靠判断这两个字段哪个非空来切换 UI 状态。
QwQ-32B（DashScope 兼容端点）：
client = OpenAI(
api_key="sk-xxxxxxxxxxxxxxxx", # 阿里云 DashScope API Key
base_url="https://dashscope.aliyuncs.com/compatible-mode/v1",
)
resp = client.chat.completions.create(
model="qwq-32b",
messages=[{"role": "user", "content": "分析以下 Python 代码的时间复杂度……"}],
)
print(resp.choices[0].message.content)
QwQ-32B 走的是阿里云 DashScope 的兼容模式端点，接入方式和 OpenAI SDK 基本一致，但有个容易被忽略的参数：DashScope 侧默认可能不返回思维链内容，需要在请求里显式加 extra_body={"enable_thinking": True} 之类的开关（具体字段名以当时的官方文档为准，DashScope 更新过几次接口规范）。如果你调用后发现只有最终答案、没有思考过程，先检查这个开关有没有打开，而不是怀疑模型本身不支持推理。
接入时最容易踩的几个报错，说一下根因和处理方式：
| 报错/现象 | 根因 | 处理方式 |
|---|---|---|
401 Unauthorized | API Key 错误，或者 Key 没有开通对应模型的权限 | 去控制台确认 Key 状态，很多平台推理模型需要单独申请白名单，不是开通了普通模型就自动能调 |
429 Too Many Requests | 触发了 QPS 或 TPM（每分钟 token 数）限流，推理模型限流普遍比普通模型更紧 | 做指数退避重试，别用固定间隔死等，见下面的重试代码 |
请求超时（ReadTimeout） | 客户端默认超时设置太短，而推理模型思考时间可能到几十秒甚至更久 | 把 timeout 参数调到 60~120 秒起步，流式调用下超时的判断应该看”多久没收到新 chunk”而不是”总耗时” |
reasoning_content 为空或字段不存在 | 网关没透传该字段，或者没开启对应的思考开关 | 参照上面两段代码的说明逐项排查 |
| 中文乱码 | 请求或响应没有显式指定 UTF-8 编码，常见于自己手写 HTTP 请求而不是用官方 SDK 的场景 | 用官方 SDK 基本不会遇到，自己拼 HTTP 请求记得设置 Content-Type: application/json; charset=utf-8 |
429 限流的重试逻辑给个可以直接抄的写法：
import time
import random
from openai import RateLimitError
def call_with_backoff(fn, max_retries=5):
for attempt in range(max_retries):
try:
return fn()
except RateLimitError:
if attempt == max_retries - 1:
raise
wait = (2 ** attempt) + random.uniform(0, 1) # 指数退避 + 抖动
time.sleep(wait)
抖动（random.uniform(0, 1)）不是可有可无的装饰，是为了避免你的多个并发请求在同一时刻集体重试，反而造成新一轮拥堵——这在批量跑测评脚本、并发几十个请求的场景里区别很明显。
成本怎么估：推理模型的账单 = 思考 token 单价 × 思考 token 数 + 输出 token 单价 × 输出 token 数（部分厂商思考和输出同价，部分不同价，具体以控制台计费说明为准）。实操中建议先拿 10~20 条你业务里真实的典型问题跑一遍，统计平均思考 token 数，再乘以你预估的日调用量，这个”先小批量实测再外推”的方法比直接按官方宣传的平均值估算靠谱得多，因为不同任务复杂度导致思考长度差异可能有好几倍。
价格定性
截至 2026-06，以官方公示为准：
- DeepSeek-R1：推理模型中价格最低之一，按思考 token + 输出 token 分别计费；
- QwQ-32B：DashScope 定价与 Qwen-Plus 档位接近，有免费额度；
- Kimi k1.5：超长上下文版本按实际 token 计费，文档类推理性价比佳；
- 其他厂商推理模型定价普遍高于通用模型，具体以控制台为准。
可用 价格对比表 对各模型报价做实时横向比较。
选型建议
- 最强数学/代码推理 + 最低成本 → DeepSeek-R1
- 开源私有化 + 单机可跑 → QwQ-32B（32B 量化版可在 2×A100 上运行）
- 超长文档推理 + 多模态 → Kimi k1.5
- 百度/腾讯云生态 → ERNIE X1 / Hunyuan-T1
再落地一点，按具体业务场景给判断依据：
| 你的场景 | 推荐 | 为什么 |
|---|---|---|
| 需要给复杂代码仓库自动修 bug | DeepSeek-R1 | SWE-bench 表现最强，且价格允许你多轮迭代重试 |
| 数据敏感，不能出公司内网 | QwQ-32B 私有化部署 | 开源可本地跑，2×A100 级别硬件量化后可用，数据不出内网 |
| 需要处理带图片的题目或文档 | Kimi k1.5 | 目前唯一支持多模态推理的选项 |
| 已经深度绑定百度/腾讯云生态，走的是企业采购流程 | ERNIE X1 / Hunyuan-T1 | 合规和售后走原有云厂商体系更省事，性能不是唯一考量 |
| 只是想要”看起来更靠谱”的答案，任务本身不复杂 | 别用推理模型 | 普通对话模型 + 好的 prompt 工程就够，上推理模型纯属为延迟和账单买单 |
最后一行是最容易被忽略的：很多团队一上来就无脑给所有接口换推理模型，结果是平均响应时间从 1 秒涨到 15 秒，用户投诉”变慢了”，而实际收益（答案质量提升）在简单任务上几乎感知不到。先用普通模型 + 人工抽检的方式确认”这类任务真的经常出错”，再决定要不要为它单独切换推理模型，这个判断顺序比直接全量切换稳妥。
常见问题
推理模型为什么比普通模型慢这么多？ 推理模型在输出最终答案前会生成数千到数万 token 的内部思维链，这些思考 token 同样消耗 GPU 算力。复杂数学题的”思考”时间可能达到普通问答的 5–20 倍，属于正常现象。
所有任务都应该用推理模型吗？ 否。文案生成、简单 QA、批量摘要等任务用推理模型会显著增加延迟和成本，收益极小。推理模型适合：多步推导、答案需要可解释过程、错误代价高的场景。
思维链内容可以展示给用户吗？ 技术上可以，但需注意：① 思维链可能包含模型自我纠错的中间步骤，直接展示可能引发用户困惑；② 部分厂商协议限制了思维链的商业展示用途，请阅读 API 使用条款。
推理模型可以微调吗？ 开源的 DeepSeek-R1 蒸馏系列（如 7B/14B/32B 版本）和 QwQ-32B 可以基于开源权重做微调或 LoRA 适配，闭源的 Kimi k1.5、Hunyuan-T1、ERNIE X1 目前只能通过官方开放的 API 或平台内的定制化服务间接调整，不支持你拿到权重自己训。如果业务强依赖某个垂直领域（比如法律条文推理、财务报表分析），优先考虑基于开源推理模型微调，而不是硬指望闭源模型靠 prompt 调出你要的效果。
超时时间到底该设多久？ 经验值是：简单数学题（几十字以内）10~20 秒足够，中等复杂度的代码分析或多步逻辑题建议留 60 秒，涉及超长上下文（接近模型上限）或数学证明这类深度推理任务，建议给到 120 秒甚至更长，并优先用流式调用——这样即便总耗时长，用户也能看到”思考中”的实时反馈，而不是死等一个空白页面。生产环境建议做成可配置项，按任务类型动态调整超时阈值，而不是全局写死一个固定数字。
为什么同一个 prompt，多次调用推理模型给出的思维链长度差异很大？ 这是推理模型的正常特性，不是 bug。模型会根据自己”感知到的”题目难度动态决定思考多久，同一个问题因为解码的随机性（temperature 不为 0 时），有时候会走一条更曲折的推理路径，有时候一步到位。如果你的业务对响应时间有硬性要求，可以考虑把 temperature 调低（部分厂商支持设为 0 或接近 0）以降低思维链长度的波动，但要接受这会略微牺牲一部分探索性和创造性答案的概率。
相关阅读：国产大模型 API 全景指南 · DeepSeek-R1 接入与用法 · 国产代码模型对比
分类导航：国产模型专题
实用工具：价格对比表 · Token 计数器