模型原理与推理
DeepSeek-R1 的开放推理到底开放了什么：RL、蒸馏与生产成本边界
以 2025 年 1 月 20 日至 22 日的首版公告、代码提交、API 快照和论文为边界，拆分 R1-Zero、正式 R1、六个蒸馏模型与 deepseek-reasoner API，并计算名义权重存储的理想估算。
时间与证据
本文采用的事件日是 2025 年 1 月 20 日：DeepSeek 发布 R1 新闻、公开完整首版仓库提交，并同步提供网站和 deepseek-reasoner API。同期信息截止日是 2025 年 1 月 22 日，因为 arXiv v1 技术报告在当天提交，仍落在 T+2 内。文章发布日期与更新日期见页首。
历史恢复使用固定版本而不是当前主分支：发布提交 23807ced 下的 README、技术报告 PDF、MIT License，以及 1 月 21 日抓取的 API Guide 快照。arXiv 在 2026 年出现的 v2 和后来发布的 R1-0528 不参与本文的 T+2 判断。
本文证据等级是 sourced。我没有声称重新训练或完整复现 R1，也没有用 2026 年的接口代替发布时 API。已经实际运行并通过测试的是本文配套的“名义参数权重存储估算器”；模型能力、Benchmark、API 限制和训练流程仍按首版一手资料归因。
当时发生了什么
先纠正“R1 是纯 RL 模型”
这句话只对 R1-Zero 的实验路径大致成立，不适用于正式 DeepSeek-R1。
R1-Zero 从 DeepSeek-V3-Base 出发，不先做 cold-start SFT，直接采用 Group Relative Policy Optimization（GRPO）进行强化学习。对同一个问题生成一组回答后，系统用组内 reward 的均值和标准差估计相对 advantage，从而不需要再训练一个通常与 policy 同规模的 critic。奖励主要来自可验证的正确性，以及对思考区段标签的格式检查；训练模板另外规定了 answer 区段。论文明确表示这一阶段没有使用神经网络 outcome 或 process reward model。
这条路线观察到了更长推理、检查和改写答案等输出行为，但也出现无休止重复、可读性差和语言混合。论文所称 “aha moment” 是研究者对模型输出行为的描述，不等于模型产生意识或真正自我反思。
正式 R1 为了解决可读性与通用能力问题，采用了更完整的管线：
- 使用数千条可读的 cold-start 推理数据对 V3-Base 进行第一次 SFT。
- 执行面向推理的 RL，并增加语言一致性奖励；论文承认这是用少量性能换可读性。
- 对收敛后的模型进行拒绝采样，得到约 600k 推理样本和 200k 非推理样本。
- 使用约 800k 样本训练两个 epoch，完成第二次 SFT。
- 再执行一次覆盖推理、helpfulness 与 harmlessness 的全场景 RL。
所以正式 R1 是“两次 SFT + 两次 RL”的产品化路径。把它写成“完全不靠监督数据，只用 RL 训练”会抹掉 DeepSeek 为可读性、通用任务和安全对齐付出的关键工程步骤。
四类发布对象不能混写
| 对象 | 训练或交付方式 | 首发尺寸与上下文 | 正确理解 |
|---|---|---|---|
| R1-Zero | V3-Base 直接进行 GRPO | 671B 总参数、每 token 激活 37B、权重卡 128K | 研究路径；DeepSeek 报告其 RL 过程中出现更长推理、检查与改写等行为，但可读性不足 |
| 正式 R1 | cold-start SFT、推理 RL、拒绝采样与 800k SFT、全场景 RL | 同为 671B/37B activated、128K 权重上下文 | 正式模型，不是纯 RL |
| R1-Distill | 用约 600k 推理轨迹与 200k 通用样本对 Qwen/Llama 基座做 SFT，没有复刻论文 RL | 1.5B、7B、8B、14B、32B、70B | 小型稠密模型，不是 671B R1 的量化版本或等价副本 |
deepseek-reasoner |
DeepSeek 托管的 Chat Completion 服务 | 首发 API 文档为 64K | 产品接口，有单独功能、输出和服务条款，不等同于权重 checkpoint |
“开放推理”的实际范围也要收紧。首版仓库公开了 README、技术报告、许可证、Benchmark 图和权重入口，但没有公开完整训练代码、约 800k 数据或全部数据处理管线。因此外部可以下载权重、运行推理和研究报告方法，却不能仅凭首版仓库完整复刻 R1 训练。
蒸馏不是缩小文件
六个 Distill 模型使用一组约 800k 的 curated data 对 Qwen2.5 或 Llama 基座进行 sequence-level SFT：其中约 600k 是 reasoning checkpoint 生成并经拒绝采样保留的推理轨迹，约 200k 是复用或由 DeepSeek-V3 生成的通用非推理样本。论文没有公开 teacher logits，也没有说明用 KL divergence 执行传统 logit distillation；这些模型同样没有重跑 R1-Zero/R1 的强化学习管线。
这意味着 Distill-Qwen-32B 的价值来自“把较高质量推理轨迹教给一个 32B 稠密模型”，而不是把 671B MoE 压成 32B。它们的架构、容量、许可证和失败模式都由新基座共同决定，不能继承正式 R1 的全部结论。
首发评测应该怎样读
下表只选少量具有代表性的数字，全部是 DeepSeek 首版报告的 vendor-reported 结果，不是本站复测：
| 模型 | AIME 2024 pass@1 | MATH-500 pass@1 | GPQA Diamond pass@1 | LiveCodeBench Pass@1-CoT | SWE-bench Verified Resolved |
|---|---|---|---|---|---|
| DeepSeek-R1 | 79.8 | 97.3 | 71.5 | 65.9 | 49.2 |
| R1-Distill-Qwen-32B | 72.6 | 94.3 | 62.1 | 57.2 | - |
采样评测使用 temperature=0.6、top_p=0.95，每题采样 64 次估计 pass@1；cons@64 则是多数投票，不应与 pass@1 混写。R1-Zero 在 AIME 2024 上从 15.6% 上升到 71.0% 是 RL 训练过程中的厂商报告，86.7% 是 cons@64，不是同一指标。
首版报告里的 o1-1217 对照值来自 OpenAI 官方报告，而不是完全相同的本地 runner。正确结论是“DeepSeek 报告 R1 在若干数学和代码评测上具有竞争力”，不是“本站证明 R1 全面超越 o1”。
任务判断
假设一家软件公司要为内部仓库建设“高风险变更审查助手”：读取 issue 与 diff，生成风险假设，运行静态检查和测试，再把证据交给工程师审批。数据不能随意外发，但团队也没有大规模 MoE 推理集群。
选型不能只问“R1 强不强”，需要比较三条路线：
| 路线 | 适合做什么 | 主要收益 | 决定性约束 |
|---|---|---|---|
deepseek-reasoner API |
快速验证数学、代码分析和长推理是否提升任务成功率 | 按 Token 计费，无需自建推理集群 | 数据与服务条款；首发无 Function Call/JSON/FIM；64K 接口上下文 |
| 7B-32B Distill 私有化 | 数据敏感、任务窄、硬件预算有限的离线或内网验证 | 部署与版本更可控，可围绕固定任务优化 | 不等价于正式 R1；仍需验证正确率、格式、延迟和基座许可证 |
| 671B 完整 R1 自托管 | 已有多机并行推理、模型服务和容量治理能力 | 可自行控制 checkpoint、推理版本与部署边界 | 总权重、通信、专家路由、KV Cache、可靠性与运维成本很高 |
对这个团队，更合理的第一步不是采购 671B 集群，而是用同一组 50 个真实变更任务比较 API 与一个可承受的 Distill 模型。验收指标至少包括：最终风险命中率、错误告警率、测试执行成功率、有效 JSON 率、P50/P95 延迟、每任务输出 Token、重复率、人工接管率和每个正确结论的总成本。
这项实验尚未在本文执行，因此只能称“实验方案”。它测的是部署路线是否适合业务任务，不是复刻 DeepSeek 的训练或证明通用 Benchmark 排名。
工程影响
权重卡与 API 契约不同
发布时权重卡写 128K 上下文，但 1 月 21 日 API Guide 快照记录 deepseek-reasoner 为 64K；最终答案默认 4K、最大 8K，推理内容最多 32K。接口返回 reasoning_content 与最终 content 两部分，上一轮 reasoning_content 不能回传，否则会得到 400。
当时 API 不支持 Function Call、JSON Output 和 FIM，temperature、top_p 等参数也会被忽略。这些限制说明“模型会推理”不等于“它已经适合现有 Agent 协议”。要接入代码审查工作流，应用层必须负责工具编排、结构校验、重试、超时和人工审批，或者在需要强工具契约的步骤路由到其他模型。
37B activated 不等于只部署 37B
MoE 在每个 token 上只激活约 37B 参数，可以降低计算量；但自托管通常仍需容纳、分片或按设计调度完整模型权重。为了把这件事变成可核算证据，仓库内提供了配套的名义参数权重存储估算器 scripts/estimate-model-weight-memory.mjs：
npm run lab:model-memory
计算使用型号中的十进制名义参数量和二进制 GiB，回答“如果张量数恰好等于名义参数量，按指定位宽理想存放需要多少空间”：
| 模型 | 名义总参数 | 激活参数 | 16-bit 理想估算 | 8-bit 理想估算 | 4-bit 理想估算 |
|---|---|---|---|---|---|
| DeepSeek-R1 | 671B | 37B | 1249.8 GiB | 624.9 GiB | 312.5 GiB |
| R1-Distill-Llama-70B | 70B | - | 130.4 GiB | 65.2 GiB | 32.6 GiB |
| R1-Distill-Qwen-32B | 32B | - | 59.6 GiB | 29.8 GiB | 14.9 GiB |
| R1-Distill-Qwen-14B | 14B | - | 26.1 GiB | 13.0 GiB | 6.5 GiB |
| R1-Distill-Qwen-7B | 7B | - | 13.0 GiB | 6.5 GiB | 3.3 GiB |
| R1-Distill-Qwen-1.5B | 1.5B | - | 2.8 GiB | 1.4 GiB | 0.7 GiB |
这不是发布 checkpoint 的实际内存下界。固定首发 Hugging Face revision 的 safetensors.total 是 684,531,386,000，按相同 4-bit 理想换算约为 318.8 GiB，已经高于 671B 名义估算的 312.5 GiB。两者都不含量化 scale/zero-point、KV Cache、激活、框架工作区、专家并行通信、操作系统、冗余与故障恢复，不能写成“准备相同数量显存就能稳定运行完整 R1”。但它们足以否定“37B 激活所以按普通 37B 模型采购硬件”的错误预算。
推理 Token 会改变任务总成本
发布页历史报价为缓存命中输入 $0.14/M、未命中输入 $0.55/M、输出 $2.19/M，只代表首发时点，不是 2026 当前价格。推理模型的主要变量往往是输出长度、重试和任务完成率，因此单看每百万 Token 单价可能得到错误结论。
更有意义的成本口径是：
每个正确完成任务的总成本
= API 账单中的输入与输出 + 工具/测试 + 重试 + 人工复核 + 基础设施
÷ 正确且可执行的任务数
首发新闻只给出统一的 output token 单价，API Guide 没有进一步说明 reasoning_content 与最终 content 在账单中如何分别累计，因此实际核算要以当期 usage 与账单为准。即使每百万 Token 单价低，长推理仍会增加请求价格与 P95 延迟，还可能触发重试或产生无法解析的输出。模型路由应该由任务难度和预期价值触发，而不是让所有请求都进入最长推理模式。
商业价值
R1 最有价值的商业信号不是“所有任务都应该展示更长 CoT”，而是 可验证任务可以用规则奖励形成训练与评测闭环。数学题有确定答案，代码可以运行测试，结构化约束可以程序检查；这些场景更容易把模型输出转为可以衡量的生产价值。
适合优先验证的方向包括代码候选生成与测试、规则明确的分析、计算校验、带证据的技术排障。价值来自提高每位工程师处理高难任务的吞吐，同时把结果交给测试、规则或人工审批，而不是把 reasoning trace 当成可靠证据。
不适合只靠 R1 v1 完成的场景包括：严格依赖 Function Call 或 JSON Schema 的 Agent；需要稳定多轮角色一致性的客服；中英文之外的语言要求很高的产品；无法程序验证且错误代价很大的开放决策。首版报告也承认 function calling、多轮、复杂角色、JSON、语言混合和 prompt sensitivity 等不足。
完整 R1 自托管的护城河不会来自“下载了 MIT 权重”，而来自并行推理基础设施、任务数据、评测集、成本路由、工具沙箱和人工反馈。Distill 私有化的护城河则更可能来自窄任务数据和持续回归，而不是参数量本身。
关于“低成本训练”必须单独纠错。DeepSeek-V3 首版报告确实把 2.788M H800 GPU-hours 按 $2/GPU-hour 计算为 $5.576M，但该数字覆盖的是 V3 官方训练，且排除架构、算法、数据的前期研究和消融。R1 报告没有公开 R1-Zero/R1 post-training 的 GPU-hours 或美元成本，不能把 $5.576M 写成 R1 训练成本，更不能写成 DeepSeek 的全部研发投入。
局限与风险
第一，首版仓库不足以完整复现训练。权重和报告开放不等于数据、训练代码、奖励实现和基础设施全部开放。本文只能复现参数内存计算，不能把论文训练流程标成本站实测。
第二，reasoning trace 不是形式化证明或审计日志。它可能包含看似连贯但错误的步骤，也可能与最终答案不一致。生产系统应记录输入、模型版本、工具结果、测试和审批，而不是仅保存一段长推理文字。
第三，许可是分层的。DeepSeek 首版代码和权重采用 MIT，并明确允许商业使用、修改和蒸馏；Qwen 蒸馏模型的商业分发仍要评估并履行适用的 Apache-2.0 义务，Llama 8B/70B 蒸馏模型则要评估适用的 Llama 3.1/3.3 Community License、AUP、NOTICE、Built with Llama 和 700M MAU 等条款。MIT 也不覆盖托管 API 的数据处理、SLA 和服务条款。
第四，自托管扩大了安全责任。模型权重来源、量化文件、推理镜像、远程代码、Prompt 数据和日志都进入供应链；还需要租户隔离、输出过滤、配额、审计、升级与回滚。开放权重减少供应商依赖，不会自动减少运维风险。
第五，官方 Benchmark 不能直接预测业务结果。AIME、MATH、GPQA、LiveCodeBench 和 SWE-bench 的题型、采样与 scaffold 不等于企业真实任务。只有固定业务样本、版本、Prompt、工具和指标的回归测试才能支持选型。
面试表达
30 秒结论： DeepSeek-R1 的关键不只是“用 RL 做推理”。R1-Zero 才是 V3-Base 直接 GRPO；正式 R1 为可读性和通用能力加入 cold-start SFT、推理 RL、拒绝采样、约 800k curated data SFT 和第二次 RL。六个 Distill 使用约 600k 推理轨迹与 200k 通用样本对 Qwen/Llama 做 SFT，不是 671B 的量化副本。工程选型还要区分权重 128K 与首发 API 64K、接口功能、许可证和任务总成本。
3 分钟展开： 我会先解释四类对象，再用代码审查助手说明选择。API 适合快速验证，7B-32B Distill 适合受控私有化，完整模型只适合已有多机并行服务能力的团队。37B activated 代表每 token 计算路径，不代表只存 37B 权重；按 671B 名义参数估算的 4-bit 理想存储约 312.5 GiB，而首发 checkpoint 实际张量数换算约 318.8 GiB，运行时还会更高。最终用任务成功率、有效格式、延迟、Token、人工接管和每个正确任务成本比较，而不是只抄 Benchmark。
如果追问“为什么不把 reasoning_content 当审计证据”，答案是自然语言推理可能合理但错误，也不是系统实际执行记录。真正审计需要模型版本、工具输入输出、测试结果、策略判断和人工审批链。
如果追问“R1 是否只花了 557.6 万美元训练”，答案是否定的。V3 报告将其报告的 2.788M H800 GPU-hours 按假设租价 $2/GPU-hour 换算为 $5.576M，并明确排除前期研究与消融；R1 的 post-training 成本没有在首版报告中披露。
复盘
站在 2026 年回看，R1 发布时最值得保留的判断有三点：DeepSeek 首版报告显示，在其训练设置下，可验证奖励与更长推理、检查和改写等行为共同出现；把研究原型变成可用模型仍需要数据、SFT、RL 和可读性取舍；合成轨迹能把部分行为迁移到更小的稠密模型。
需要持续警惕的误读也很稳定：把 R1-Zero 等同正式 R1、把 activated parameters 等同部署体量、把 Distill 等同量化、把权重许可等同 API 条款、把厂商 Benchmark 等同业务成功率。后续版本可以形成新的事件和实验，但不能倒填成 2025 年 1 月 22 日已经知道的事实。
下一步可复现实验应固定 50 个真实代码任务、Prompt、应用层约束、并发和测量窗口，比较 deepseek-reasoner 与 Distill-Qwen-7B/32B。本地模型单独记录硬件与推理配置，托管 API 只记录可观察的延迟、usage 和错误。文章应同时公开成功样本、失败样本、原始 Token 与延迟，而不是只展示最好的回答。
方法披露
本文使用 AI 工具协助论文与历史页面整理、计算脚本审查和图表草拟；参数估算测试由本站本地实际执行，事件日期、一手来源、计算口径、最终文字与判断由作者逐项复核并负责。
修订记录
2025-01-22：初版发布；核验 2025-01-20 至 2025-01-22 的官方新闻、固定提交、首版报告、API 快照和许可证；名义权重存储估算器通过本地测试。
Reusable projects
关联可复用项目
本文已经进入以下工程项目；项目页提供固定版本、运行命令和结果工件。
- 实验验证已独立复现
本地推理容量规划工具
本文实际运行名义权重存储估算器，区分 671B 总参数与 37B 激活参数，并用冻结 JSON 限定 16/8/4-bit 理想估算的适用边界。
Source ledger
来源账本
以下来源用于核对事实、日期与当时可用范围。厂商自报性能不视为本站独立复现。
- DeepSeek-R1 Release
- DeepSeek-R1 release commit
- DeepSeek-R1: Incentivizing Reasoning Capability in LLMs via Reinforcement Learning (v1)
- DeepSeek-R1 first-release README
- DeepSeek-R1 first-release technical report
- DeepSeek reasoning model API guide snapshot
- DeepSeek-R1 release news snapshot
- DeepSeek-R1 release checkpoint metadata
- DeepSeek-R1 first-release MIT License
- DeepSeek-V3 first-release technical report
讨论