reasoning-from-scratch：用 PyTorch 亲手搭一个会推理的 LLM
Implement a reasoning LLM in PyTorch from scratch, step by step
秒懂
- 它是什么？
- rasbt/reasoning-from-scratch 是《Build a Reasoning Model (From Scratch)》一书的官方代码仓库，以 Qwen3 为基础模型，用 Jupyter Notebook 逐步实现推理增强、GRPO 强化学习和蒸馏。它面向想理解推理机制而非直接调 API 的工程师。
- 适合谁用？
- 适合想深入理解推理 LLM 内部机制的工程师、研究生或技术决策者，尤其是那些不满足于调用现成推理 API、希望看到 GRPO 和蒸馏在代码层面如何落地的人。不适合需要生产级推理模型、追求极致性能或没有耐心阅读大量 Notebook 的团队。
- 能商用吗？
- 可以。Apache-2.0 是宽松许可证：你可以使用、修改并销售基于它的软件，只需保留版权和许可证声明。
- 还在维护吗？
- 在维护。仓库最近一次提交在 9 天前。
- 用什么语言写的？
- 主要是 Jupyter Notebook（依据 GitHub 的语言统计）。
以上回答依据项目的 GitHub 数据（最近同步于 2026年9月15日）和我们的分析，不构成法律意见。
开源项目深度解析
这本书和这个仓库要解决什么问题
大语言模型的推理能力，比如数学解题和逻辑推导，经常被当作一个黑盒。你调用一个带 reasoning 的 API，得到一串思考过程，但不知道中间发生了什么。rasbt/reasoning-from-scratch 想拆掉这层黑盒。它是 Manning 出版社《Build a Reasoning Model (From Scratch)》一书的官方代码，作者是 Sebastian Raschka。仓库的目标很明确：从一个预训练的开源基础模型 Qwen3 出发，用 PyTorch 一步步加上推理能力。方法包括推理时间缩放、强化学习和蒸馏，这些正是 DeepSeek R1、GPT-5 Thinking 等大规模推理模型所采用的技术。这个仓库不是给生产环境用的工具库，而是一套教学代码。它服务的读者是想通过亲手实现来理解推理机制的人，而不是想快速集成推理功能的开发者。
仓库结构：按章节组织的 Jupyter Notebook
整个仓库以 Jupyter Notebook 为主，按书的章节分成目录。每一章都有一个主文件和一个习题解答文件，格式为 chXX_main.ipynb 和 chXX_exercise-solutions.ipynb。章节从第 1 章理解推理模型开始，没有代码。第 2 章用预训练 LLM 生成文本，第 3 章评估推理模型，第 4 章和第 5 章分别讲推理时间缩放和自精炼，第 6 章进入强化学习训练，第 7 章改进 GRPO，第 8 章做蒸馏。附录部分扩展了更多内容，包括 Qwen3 源码解析、使用更大 LLM、批处理和吞吐优化、评估方法以及构建聊天界面。这种组织方式意味着你可以按顺序阅读，也可以直接跳到感兴趣的章节。但如果你只想找一个单独的 Python 包来安装使用，这个仓库会让你失望，因为它的交付物是 Notebook，不是库。
核心机制：从 Qwen3 出发的三种推理增强路径
仓库的核心思路是拿一个现成的开源基础模型 Qwen3，然后在它上面叠加推理方法。这和你从零训练一个 transformer 是两回事，后者是 Raschka 上一本书《Build a Large Language Model (From Scratch)》的内容。这个仓库的重点是推理增强。文档提到三种主要路径。第一种是推理时间缩放，也就是在生成时让模型多次采样或搜索，用更多计算换更好结果，第 4 章和第 5 章覆盖这一块。第二种是强化学习，具体是 GRPO，第 6 章和第 7 章分别讲基础实现和改进。第三种是蒸馏，把一个大推理模型的能力压缩到更小的模型上，第 8 章处理这个。这三种路径在工程上各有代价。推理时间缩放增加延迟，GRPO 训练不稳定且对奖励设计敏感，蒸馏则依赖高质量教师模型。仓库把这些方法都摆在同一个 Qwen3 基座上，方便你对比它们的效果和成本。
运行门槛：消费级硬件的承诺与边界
README 明确说，主章节的代码设计为在消费级硬件上运行，不需要专用服务器硬件，并且会自动利用 GPU（如果可用）。这是一个对个人开发者友好的承诺。但你需要留意这个承诺的边界。它说的是主章节，而附录 D 明确涉及使用更大的 LLM，那部分很可能需要更强的硬件。仓库没有给出具体的显存要求或运行时长，所以你在跑第 6 章的 GRPO 训练时，应该预期在单张消费级显卡上可能需要数小时甚至更久。另一个实际问题是，Notebook 的运行环境。你最好用 conda 或 venv 创建一个干净的 Python 环境，然后按第 2 章的提示安装依赖。仓库没有提供 requirements.txt 的明确内容，所以你需要从 Notebook 中的 import 语句推断依赖版本。这一点对新手不友好，但对熟悉 PyTorch 生态的人来说不是障碍。
一个明显的局限：教学代码不等于生产方案
这个仓库最大的局限是它的定位。README 说得很清楚，目标是开发一个小而功能正常的推理模型，用于教育目的。这意味着代码会优先可读性和教学清晰度，而不是性能和工程健壮性。比如，GRPO 的实现可能不会处理分布式训练，蒸馏流程可能没有做大规模数据管道的优化。如果你把它当作生产推理系统的起点，你会遇到扩展性问题。另一个局限是，它依赖 Qwen3 作为基础模型。Qwen3 的权重和 tokenizer 是单独分发的，你需要自己下载，仓库不负责这一步。如果你所在网络环境访问 Hugging Face 或 ModelScope 有困难，光准备数据就会卡住。此外，仓库的代码测试覆盖三个操作系统，但测试只保证 Notebook 能跑通，不保证训练出的模型在数学基准上有竞争力。
替代方案：从零训练与现成框架的取舍
如果你不想用 Qwen3 作为起点，而是想理解整个 LLM 的构建过程，Raschka 的前一本书《Build a Large Language Model (From Scratch)》是直接的替代。它的仓库 rasbt/LLMs-from-scratch 会带你实现一个基础 transformer，从数据加载到预训练，但不涉及推理增强。这个对比很关键：前者教你造发动机，后者教你装涡轮增压器。另一个替代方向是使用现成的强化学习框架，比如 TRL 或 verl，它们提供了生产级的 GRPO 实现。这些框架的差异在于抽象层级。reasoning-from-scratch 把 GRPO 的每一步展开在 Notebook 里，方便你调试和理解；而 TRL 把 GRPO 封装成几行 API 调用，适合快速实验，但你看不到内部细节。如果你的目标是快速验证一个想法，用 TRL 更高效；如果你的目标是理解 GRPO 的数学和工程实现，这个仓库更合适。
维护、升级与许可的现实考量
仓库的默认分支是 main，最近一次推送是 2026 年 9 月，说明作者仍在维护。它有一个 v1.0 版本发布于 2026 年 5 月，对应书籍的出版周期。但你要注意，Notebook 形式的代码库维护成本不低。PyTorch、Qwen3 模型或相关库一旦升级，Notebook 中的代码就可能出现兼容性问题。仓库有 GitHub Actions 的测试工作流，分别针对 Linux、macOS 和 Windows，这能在一定程度上防止代码腐化，但不能保证所有章节的代码都跟上最新库版本。许可方面，仓库采用 Apache-2.0，这意味着你可以自由使用、修改和分发代码，包括商用，但需要保留版权声明并注明修改。如果你打算把仓库中的代码片段整合到自己的商业产品中，Apache-2.0 比 GPL 类许可更宽松，但你仍然需要遵守其条款。具体法律问题建议咨询专业人士，这里不做法律建议。
值得注意的细节：仓库的自我定位与周边资源
这个仓库不是孤立存在的。它在 README 中明确指向了配套书籍和前一本书的仓库，形成了一个学习路径。如果你已经读过 Raschka 的上一本书，这个仓库是自然的下一步。如果你没有读过，你仍然可以直接从第 2 章开始，因为 Qwen3 是预训练好的，你不需要自己训练基础模型。仓库还包含一个 Troubleshooting Guide 文件，这暗示了作者预期读者会遇到环境或依赖问题。附录 G 教你构建聊天界面，这意味着你有机会把训练好的推理模型包装成一个可交互的 demo。这些周边内容增加了仓库的价值，但也拉长了学习曲线。你需要决定是只读主章节还是连附录一起消化。附录 C 分析 Qwen3 源码，附录 F 讲评估方法，这些对一个想深入推理模型的人来说是加分项，但对只想快速上手的人来说是干扰。
编辑结论
适合想深入理解推理 LLM 内部机制的工程师、研究生或技术决策者，尤其是那些不满足于调用现成推理 API、希望看到 GRPO 和蒸馏在代码层面如何落地的人。不适合需要生产级推理模型、追求极致性能或没有耐心阅读大量 Notebook 的团队。在采用前，先确认你的硬件能否跑通附录 D 中更大的模型，以及你是否接受 Apache-2.0 许可下对衍生作品的义务。最后，验证仓库中 tests 工作流的状态，因为 README 显示代码测试覆盖 Linux、macOS 和 Windows，但实际通过情况需要你自行查看。
社区笔记