最近开源社区又一个值得关注的消息出现了小红书把 dots3-note 模型权重放出来了。根据发布方给出的信息dots3-note 与之前在同一数学推理评测中拿到 IMO 42 分满分的模型属于同一技术系列也就是说这套模型的竞赛数学解题能力并不是“演示视频”里的特效而是可以被开发者拉下来跑、拿来复现评测、甚至继续微调的权重。这篇文章我不会只做新闻复述而是站在开发者的角度重点解决三件事拆解 IMO 42 分为什么是数学推理模型的重要里程碑讲清楚数学推理模型背后的训练与验证机制从环境搭建、模型下载、推理调用、结果评估到最终工程部署给出一套可复制的本地跑通方案。如果你最近在关注“开源模型”“数学推理”“本地部署”这几个方向这篇文章正好可以帮你把这颗模型快速用起来。1. 背景IMO 42 分为什么这么受关注1.1 IMO 42 分到底意味着什么IMO 是国际数学奥林匹克竞赛的缩写。每年来自世界各地的中学生选手会参加这项比赛试卷一共 6 道题每题 7 分总分 42 分考试分成两天进行每天 3 道题、4 个半小时。对于人类参赛者来说42 分意味着 6 道题全部做对同时证明过程完整、没有漏洞。对于大模型来说这个分数的难度还要更高因为数学竞赛题通常不是“从几个选项里选答案”而是需要先生成解题思路再以严格的数学语言给出证明过程。在早期的大模型评测中模型常常能在基础算术、简单方程上表现不错但面对 IMO 这类需要多步推理和严谨证明的题目时往往会“一本正经地给出错误证明”。因此当某个模型或同系列模型能在完整 IMO 试卷上拿到 42 分满分时代表它至少在竞赛数学这个极其考验推理能力的评测维度上做到了非常高的完成度。1.2 数学推理是检验模型上限的“试金石”很多人可能会问我是一个后端开发者平时又不做竞赛题为什么要关心一个数学推理模型原因是数学推理任务非常适合用来衡量大模型的“系统二能力”。所谓系统一是快速、直觉式的反应系统二则是慢速、有计划、逐步推演的能力。IMO 题目恰恰需要系统二能力题目条件少但隐藏结构多不能靠“背答案”或“记住训练样本中的相似题”蒙混过关错误往往需要反复回溯修正正确的证明必须逻辑闭环。如果一个模型能把数学推理做好说明它在长上下文规划、符号操作、逻辑自洽这些底层能力上是有突破的。而这类能力一旦被验证往往也能迁移到代码生成、复杂工具调用、Agent 任务规划等场景中。另一个重要原因是数学结论“可验证”。代码能不能跑、数学证明对不对这些都是可以用客观规则判断的。这让训练阶段可以设计更可靠的奖励信号而不需要完全依赖人工偏好标注。1.3 开源这个动作的开发者价值在 dots3-note 出现之前高水平的数学推理模型大多以闭源 API 或部分发布的形式存在。闭源 API 虽然使用方便但开发者能做的事情极其有限只能传 prompt 拿结果不能观察中间推理过程不能针对自己的数学题库做微调不能量化、剪枝、蒸馏后部署到边缘设备无法复现论文里的评测结论一旦服务端更新行为可能变化业务很难稳定。开源模型把这些问题打开了。拿到权重之后开发者可以本地起服务、写自动化评测、在私有数据集上检验泛化能力甚至把长思维链数据蒸馏成更小的模型。这也是 dots3-note 这类开源动作最有价值的地方它不是提供一个“截图级别的 Demo”而是把可复现能力直接交到社区手里。2. 数学推理模型背后的关键机制这一节会根据当前开源数学推理模型的常见实现思路做原理拆解。dots3-note 的具体结构、训练细节和评测数据以官方仓库 README、技术报告或开源说明为准但下面几个模块基本是同类模型的“通用骨架”。2.1 思维链与长思维链大模型最早被质疑“只会接龙”但思维链Chain-of-ThoughtCoT出现后模型通过“先写中间推理步骤再给出答案”的方式在数学题上的准确率有了明显提升。后来发展出“长思维链”方向。过去我们习惯用max_new_tokens512控制输出长度但遇到复杂的竞赛题模型可能需要几百甚至上千 token 来做自我探索、试错、回溯。因此推理类模型的生成阶段通常会预留更长的输出空间。从开发者角度看这意味着两件事推理时不能把max_new_tokens设得太小评测时不能只比较最后一行答案而要把模型完整的推理过程保存下来便于分析失败原因。2.2 可验证奖励的强化学习在数学推理模型训练中“可验证奖励”是核心思路之一。传统强化学习需要一个奖励模型来判断动作好坏但数学题的好处在于最终答案对不对是可以被规则判定的。训练流程可以粗略概括为让模型针对一批数学题生成多种解题路径用规则判断最终答案是否与标准答案等价答案正确的生成路径得到正奖励错误路径得到负奖励或较低奖励通过强化学习算法更新模型让模型学到“如何更稳定地找到正确答案”。这种训练方式比单纯依赖人工打分更客观也更容易规模化。竞赛数学恰好提供了大量有标准答案和规范评分标准的题目。2.3 验证器在数学任务中的角色这里要引入“验证器”的概念。数学题的最终结果往往可以表达为等式、集合、不等式或其他精确形式。一个合格的验证器至少需要做到判断模型输出的答案和标准答案是否数学等价判断模型给出的证明步骤是否严谨发现“答案碰巧正确但推理过程错误”的情况。在实际落地时验证器的设计有多种层次验证层次做法可靠性字符串比对直接比较文本低容易误判符号计算比对使用 SymPy 等工具化简求差中高适合代数表达式规则抽取解析\boxed{}等固定格式中依赖输出规范人工核验人类评分高但成本大形式化证明使用 Lean 等证明助手高但建模门槛高对于 IMO 42 分这类成绩最终判定通常不能只看答案还需要证明过程被认可这也是竞赛评测比普通问答评测更严格的地方。2.4 数据与蒸馏数学推理模型的训练离不开高质量数据。除了历史 IMO 题目社区常用数据源还包括各类数学竞赛真题、题库网站、教科书习题和合成数据。由于竞赛题目数量有限许多团队会使用大模型生成大量带有完整推理过程的合成题再经过清洗、去重和难度筛选进入训练集。另外一个常见的工程实践是“蒸馏”。小模型直接做复杂数学推理可能效果不佳但如果我们让一个大模型先生成高质量推理轨迹再用这些轨迹微调小模型往往能把一部分推理能力迁移过去。当前很多 7B、14B 量级的数学推理开源模型其实都经历了类似流程。对普通开发者来说理解蒸馏还有一个实际好处如果你手头只有一块消费级显卡没必要硬扛超大模型选择一个经过蒸馏的中小模型并配合量化部署往往更符合真实资源情况。3. 本地部署前的准备工作接下来进入实操环节。由于 dots3-note 的权重格式和模型结构需要以官方仓库为准本节的示例会按 Hugging Face Transformers 社区常见的模型加载方式来写。如果你的模型结构特殊只需要把加载方式替换为官方示例即可。3.1 硬件与软件环境数学推理模型对显存比较敏感因为推理过程中会产生较长的思维链。建议参考以下配置操作系统LinuxUbuntu 20.04 / 22.04优先Windows/macOS 也可以跑但兼容性差异较多GPUNVIDIA 显卡建议显存不少于 16GBCUDA 版本建议 CUDA 11.8 或 12.xPython 版本3.10 或 3.11核心依赖PyTorch、Transformers、Accelerate推理优化vLLM可选适合高并发场景。如果你显存不够不要急着放弃。后面的章节会介绍 4bit 量化加载和 CPU 慢速推理的降级方案先把流程跑通更重要。3.2 创建虚拟环境并安装依赖推荐为这个项目单独创建 Python 虚拟环境避免污染系统环境python -m venv .venv-dots source .venv-dots/bin/activate如果你的系统是 Windows激活命令改为.venv-dots\Scripts\activate接下来升级 pip并安装 PyTorch。这里使用的 PyTorch 安装命令以 CUDA 12.1 为例pip install --upgrade pip pip install torch --index-url https://download.pytorch.org/whl/cu121然后安装 Transformers 相关依赖pip install transformers accelerate sentencepiece后面下载模型时我会优先使用魔搭 ModelScope。如果你是在国内服务器或本地网络环境ModelScope 的下载速度和稳定性通常更好pip install modelscope最后安装推理加速和数学验证需要的库pip install vllm sympy openai这里的 vllm 主要用于高并发推理sympy 用于数学符号验证openai 用于调用兼容 OpenAI 格式的本地推理服务。3.3 模型下载开源模型发布时一般会同时提供 Hugging Face 和 ModelScope 两个下载渠道。下面以 ModelScope 为例。# 文件路径download_model.py from modelscope import snapshot_download # 注意这里需要替换为官方仓库实际的模型 ID model_dir snapshot_download( your-org/dots3-note, local_dir./models/dots3-note ) print(模型已下载到, model_dir)运行命令python download_model.py下载完成后. /models/dots3-note目录下通常会包含config.json模型结构配置tokenizer.json/tokenizer_config.json分词器model-00001-of-0000X.safetensors权重分片文件generation_config.json生成参数默认配置。如果下载过程因为网络中断或文件较多而失败可以把snapshot_download换成断点续传参数或者使用命令行工具重试。ModelScope 的命令行方式如下modelscope download --model your-org/dots3-note --local_dir ./models/dots3-note不同版本命令可能略有差异遇到问题时优先查看当前安装版本的帮助信息modelscope download --help4. 快速体验跑一道 IMO 真题模型下载完成后最直接的验证方式就是让它做一道 IMO 真题。这里选择一道历史上非常有名的题目题号是 IMO 1959 第 1 题。4.1 准备测试题目题目原文用中文表达如下证明对所有正整数 n分数 (21n4)/(14n3) 是最简分数。这道题非常适合用来初测推理模型原因是题目本身没有复杂的背景知识正确答案是“证明最简”而不是一个具体数值标准的证明方法只需要使用 gcd最大公约数性质。如果模型真的具备数学推理能力它会尝试设 d gcd(21n4, 14n3)然后通过线性组合构造出 1最终说明 d 只能是 1。如果模型只是靠“看起来像数学题”来瞎编则很容易在证明过程中出现明显跳步。4.2 编写推理脚本下面是一个最简的推理脚本。运行时请将MODEL_PATH改成你实际的本地模型路径。# 文件路径run_imo.py import torch from transformers import AutoModelForCausalLM, AutoTokenizer MODEL_PATH ./models/dots3-note # 加载分词器 tokenizer AutoTokenizer.from_pretrained( MODEL_PATH, trust_remote_codeTrue ) # 加载模型 model AutoModelForCausalLM.from_pretrained( MODEL_PATH, torch_dtypetorch.bfloat16, device_mapauto, trust_remote_codeTrue ) model.eval() QUESTION 题目IMO 1959 第 1 题 证明对所有正整数 n分数 (21n4)/(14n3) 是最简分数。 要求 1. 先判断命题是否成立 2. 使用严格的数学语言写出完整证明 3. 最后把关键结论放在 \\boxed{} 中。 messages [ {role: user, content: QUESTION} ] # 优先使用模型自带的 chat template try: prompt tokenizer.apply_chat_template( messages, tokenizeFalse, add_generation_promptTrue ) except Exception: # 如果 tokenizer 没有定义 chat template则使用通用模板 prompt 用户 QUESTION \n助手 inputs tokenizer(prompt, return_tensorspt).to(model.device) with torch.inference_mode(): outputs model.generate( **inputs, max_new_tokens4096, do_sampleFalse ) # 只解码新生成的部分避免把输入重复输出 reasoning tokenizer.decode( outputs[0][inputs[input_ids].shape[1]:], skip_special_tokensTrue ) print(reasoning)脚本中有几个地方值得说明trust_remote_codeTrue部分模型使用自定义代码需要显式信任torch_dtypetorch.bfloat16可以用更少显存加载模型max_new_tokens4096因为数学推理模型往往需要生成很长的思考过程do_sampleFalse先采用贪心解码保证结果可复现。运行命令python run_imo.py4.3 结果解读模型输出的理想结构应该是“结论 证明过程 最终结论”。针对 IMO 1959 第 1 题标准证明的关键步骤大致如下设 d gcd(21n4, 14n3)。因为 d 同时整除分子和分母所以 d 一定能整除它们的任意线性组合。考虑3(14n3) - 2(21n4) 1因此 d 整除 1所以 d 1。既然分子分母的最大公约数为 1分数就是最简分数。当你运行模型时如果它给出的证明包含上述逻辑链说明模型确实理解了解题路径。如果它只输出“显然成立”“因为分子分母互质”这类没有中间推导的话就要怀疑它是否在套模板了。4.4 更高吞吐vLLM 推理Transformers 方式适合单条验证但如果你要跑几十道题或多个并发请求推荐用 vLLM。vLLM 不仅省显存还能用 PagedAttention 等机制提升吞吐。下面的 Python 脚本展示了 vLLM 的同步推理方式# 文件路径run_vllm_batch.py from vllm import LLM, SamplingParams MODEL_PATH ./models/dots3-note llm LLM( modelMODEL_PATH, dtypebfloat16, tensor_parallel_size1, gpu_memory_utilization0.9, trust_remote_codeTrue, ) sampling_params SamplingParams( temperature0.0, max_tokens4096, ) prompts [] questions [ 证明对所有正整数 n分数 (21n4)/(14n3) 是最简分数。, 求方程 x^2 3x - 4 0 的所有实数解。, ] for q in questions: prompts.append(用户 q \n助手) outputs llm.generate(prompts, sampling_params) for output in outputs: generated output.outputs[0].text print(generated) print( * 40)vLLM 的SamplingParams是控制生成的核心参数。temperature0.0表示贪心解码适合追求稳定性的评测。如果希望增加结果多样性可以改成temperature0.6, top_p0.95, max_tokens4096。5. 如何评估数学解题结果跑通推理之后下一个关键问题是如何判定输出对不对。数学题的评测比普通文本生成评测更严格下面给出层层递进的评估方案。5.1 为什么不能只看关键词很多开发者在测试普通问答模型时习惯用“是否包含某个关键词”来判断回答质量。这个方法在数学题上非常危险。例如模型可能输出命题成立分数是最简分数因为分子分母显然互质。这段文字包含了所有正确关键词“成立”“最简”“互质”但并没有给出有效证明。更糟糕的是如果这是一道需要排除特殊边界条件的题目模型可能会漏掉关键情况而得到错误结论。因此评估数学解题能力至少要把“最终答案”和“证明过程”分开看待。5.2 基于\boxed{}的答案抽取为了让答案可以被自动比对许多数学推理模型被训练成“最后一层输出\boxed{}”的格式。例如\boxed{不可约}或者\boxed{x 1 或 x -4}我们可以用正则表达式抽取这个字段# 文件路径extract_answer.py import re def extract_boxed_answer(text: str) - str: 从模型输出中抽取最后一个 \boxed{} 内容。 matches re.findall(r\\boxed\{(.*?)\}, text, flagsre.S) if not matches: return return matches[-1].strip() # 示例 sample_output 结论该分数不可约。 \\boxed{最简分数} print(extract_boxed_answer(sample_output)) # 最简分数抽取出来的字符串只能用于后处理不等于最终判定。5.3 符号等价判断如果题目答案是数值表达式、方程解或函数表达式那么字符串完全相等并不是一个好标准。举个例子模型输出\sqrt{8}标准答案是2\sqrt{2}。两者虽然字符串不同但数学上是等价的。此时可以引入 SymPy 做符号化简# 文件路径check_math.py from sympy import simplify, sympify def answer_equivalent(pred: str, gold: str) - bool: 判断两个数学表达式是否等价。 try: pred_expr sympify(pred) gold_expr sympify(gold) return simplify(pred_expr - gold_expr) 0 except Exception: # 解析失败时降级为字符串比对 return pred.strip() gold.strip() print(answer_equivalent(sqrt(8), 2*sqrt(2))) # True print(answer_equivalent(x 1, x 1.0)) # 取决于解析结果实践时建议先统一格式这个方法的优点是它能处理根式、分式、多项式化简。缺点是它只适合“答案是可解析表达式”的题目不适合集合、不等式范围、反证法结论等场景。5.4 证明与人工核验对于 IMO 级别的题最终极的评估依然需要看证明。自动评估证明是目前研究的热点可选方案包括让更强的大模型做“裁判”对证明过程逐行打分建立 rubric 人工评分表使用 Lean 等证明助手形式化验证将模型证明的关键步骤转为可执行代码再用单元测试验证。在我自己的项目里比较推荐的方法是“自动抽答案 人工核验关键步骤”先用脚本批量跑题自动抽取\boxed{}并计算答案级正确率对答案正确的样本再做证明抽查将错误证明按错误类型分类计算错误、逻辑跳步、条件遗漏、结论幻觉。这套流程能最大化节省人工时间同时避免被“答案对了但证明错了”误导。6. 部署成可调用的推理服务验证完成之后如果你想把模型接入到业务系统、Web 应用或 Agent 工具中最稳妥的方式是把它部署成一个本地推理服务。vLLM 天然支持 OpenAI 兼容的 HTTP 接口方便现有代码接入。6.1 使用 vLLM 启动服务命令行启动方式如下vllm serve ./models/dots3-note \ --served-model-name dots3-note \ --host 0.0.0.0 \ --port 8000 \ --dtype bfloat16 \ --max-model-len 8192 \ --gpu-memory-utilization 0.9 \ --trust-remote-code启动成功后终端会出现类似日志INFO: Application startup complete. INFO: Uvicorn running on http://0.0.0.0:8000这意味着服务已经就绪。6.2 用 curl 验证接口打开另一个终端用 curl 发送请求curl -s http://127.0.0.1:8000/v1/chat/completions \ -H Content-Type: application/json \ -d { model: dots3-note, messages: [ { role: user, content: 证明对所有正整数 n分数 (21n4)/(14n3) 是最简分数。 } ], temperature: 0, max_tokens: 4096 }如果一切正常响应会是一个 JSON 对象其中choices[0].message.content就是模型生成的推理结果。6.3 通过 Python 客户端接入如果你已经安装了 openai Python 包可以用非常接近 OpenAI 官方 SDK 的方式接入本地服务# 文件路径client_demo.py from openai import OpenAI client OpenAI( base_urlhttp://127.0.0.1:8000/v1, api_keyEMPTY, # 本地服务不需要真实 key ) resp client.chat.completions.create( modeldots3-note, messages[ { role: user, content: 证明对所有正整数 n分数 (21n4)/(14n3) 是最简分数。 } ], temperature0, max_tokens4096, ) print(resp.choices[0].message.content)运行python client_demo.py把 HTTP 服务跑起来之后前端、后端、自动化脚本都可以通过同一个接口调用模型业务层不需要关心模型权重和推理细节。7. 常见问题与排查思路本地部署大模型的过程中一定会遇到各种环境问题。下面整理几个高频场景。7.1 常见问题速查表问题现象常见原因解决思路模型下载非常慢或中断网络不稳定 / 文件分片多切换到 ModelScope使用local_dir断点续传加载时显存不足模型权重尺寸超过显存启用 4bit/8bit 量化或降低max_model_len生成结果很短就停止max_new_tokens太小增大到 4096 或更高输出内容大量重复采样温度过高 / 模型重复惩罚设置不当使用贪心解码或设置repetition_penalty模型输出乱码分词器与模型不匹配重新确认下载目录不要混用不同模型文件请求 vLLM 接口超时单次推理 token 太长调大服务端--max-model-len或减小前端请求参数同一个问题多次结果不一致采样参数随机评测时使用temperature0固定输出7.2 模型输出空内容的排查顺序如果模型生成结束后返回空字符串按以下顺序排查检查skip_special_tokensTrue是否误删了正文检查inputs[input_ids]切片是否正确防止把输入部分也算进去临时输出outputs[0]的 shape确认是否有 token 生成把max_new_tokens调大看是不是模型还没来得及输出就被截断用官方仓库提供的 demo 脚本对比排除模型加载方式问题。7.3 显存不足的几种降级方案显存不足是最常见的 GPU 问题尤其是本地开发机。降级方案可以按顺序尝试第一使用量化加载。Transformers 原生支持bitsandbytes可以在加载时启用 4bit 量化from transformers import BitsAndBytesConfig quantization_config BitsAndBytesConfig( load_in_4bitTrue, bnb_4bit_compute_dtypetorch.bfloat16 ) model AutoModelForCausalLM.from_pretrained( MODEL_PATH, quantization_configquantization_config, device_mapauto, trust_remote_codeTrue )第二缩小单次推理的最大长度。数学推理虽然长但 4096 token 不一定每次都需要按任务粒度动态设置长度能节省显存。第三切换到更小的同系列模型。如果官方发布了不同规格的版本优先选择 7B 或 14B 规模如果只能跑超大模型也可以考虑把量化后的模型放到多张 GPU 上。第四使用 CPU 慢速推理。这个方法只适合验证“模型能不能跑”不适合生产。8. 最佳实践与工程建议模型部署成功只是第一步。如果要真正把数学推理模型用到评测或业务中下面这些工程经验值得提前注意。8.1 建立可复现的评测基线跑数学题的时候一定要先把评测条件固定下来固定 prompt 模板固定解码参数评测时建议temperature0固定模型版本记录模型 commit hash固定随机种子保存每道题的完整输入和原始输出而不是只保存最终分数。可复现是数学评测的生命线。如果每次跑题结果都不一样后续的微调、量化、蒸馏优化都无从谈起。8.2 统一输出格式不管是人工分析还是自动裁判混乱的输出格式都会显著增加成本。建议在 prompt 中显式要求模型按照规范格式输出关键结论放在\boxed{}中证明按步骤编号不要省略关键推导如果有多个解需要说明解集。统一格式之后可以降低自动抽取的失败率评测管道也会更稳定。8.3 量化与精度取舍4bit 量化可以让大模型在更小的显存上运行但量化会引入精度损失。对于数学推理任务这种损失有时比普通问答更明显因为长链路推理中的任何一步误差都可能被逐步放大。我的建议是日常验证流程先使用 bfloat16只有在显存成为瓶颈时才考虑 8bit4bit 量化之后必须重新跑一遍基础评测题观察分数是否明显下降涉及高精度符号计算时尽量保持更高的数值精度。8.4 安全与合规边界数学推理模型虽然看起来“很理科”但它在生产环境中依然可能给出错误结果而且错误往往隐藏在一大段看起来非常严密的推理里。所以如果系统要拿模型结果做自动判定、自动改卷、金融决策等敏感操作不能把模型当唯一裁判。工程上建议加入多级防线对结果进行符号验证或规则回查设置置信度阈值低置信度结果转人工保留推理日志方便事后审计模型能力边界要在产品说明里写清楚不能宣称“100% 数学正确”。另外使用任何开源模型都要留意许可证条款。即使模型权重免费开放也要确认商用授权、模型再分发、署名要求等条款。如果仓库没有明确说明不要默认“开源 随便商用”。8.5 长上下文与批量任务如果要做批量评测建议直接使用 vLLM 而不是逐个调用 Transformers。vLLM 支持 continuous batching能动态合并同一批请求吞吐量远高于 for 循环。批量任务的建议是把每条 prompt 的 max_tokens 根据题目难度分组。简单题给 1024 token中等题给 2048竞赛题给 4096。这样可以避免简单题占用过多生成空间进而提高整体吞吐。9. 下一步学习思路拿到 dots3-note 或任何同类型开源数学推理模型后我建议你按下面的顺序推进第一步先复现一次单题推理观察模型在 IMO 1959 第 1 题上的输出理解长思维链的输出风格。第二步整理一份 10 到 20 道题的私有评测集把答案抽取和符号等价判断脚本跑通得到基础准确率。第三步用 vLLM 部署出 HTTP 服务把模型接到自己的 Web 应用或 Agent 脚本中。第四步如果手头显存不足再做量化和蒸馏实验重点观察量化前后准确率变化。第五步研究模型的错误样本。数学推理模型的每一次错误都是一次难得的分析机会模型是在哪一步开始偏离正确方向的是计算错误还是逻辑假设出了问题这些分析远比“刷一个更高 开源数学推理模型 dots3-note 本地部署与评测实战
最近开源社区又一个值得关注的消息出现了小红书把 dots3-note 模型权重放出来了。根据发布方给出的信息dots3-note 与之前在同一数学推理评测中拿到 IMO 42 分满分的模型属于同一技术系列也就是说这套模型的竞赛数学解题能力并不是“演示视频”里的特效而是可以被开发者拉下来跑、拿来复现评测、甚至继续微调的权重。这篇文章我不会只做新闻复述而是站在开发者的角度重点解决三件事拆解 IMO 42 分为什么是数学推理模型的重要里程碑讲清楚数学推理模型背后的训练与验证机制从环境搭建、模型下载、推理调用、结果评估到最终工程部署给出一套可复制的本地跑通方案。如果你最近在关注“开源模型”“数学推理”“本地部署”这几个方向这篇文章正好可以帮你把这颗模型快速用起来。1. 背景IMO 42 分为什么这么受关注1.1 IMO 42 分到底意味着什么IMO 是国际数学奥林匹克竞赛的缩写。每年来自世界各地的中学生选手会参加这项比赛试卷一共 6 道题每题 7 分总分 42 分考试分成两天进行每天 3 道题、4 个半小时。对于人类参赛者来说42 分意味着 6 道题全部做对同时证明过程完整、没有漏洞。对于大模型来说这个分数的难度还要更高因为数学竞赛题通常不是“从几个选项里选答案”而是需要先生成解题思路再以严格的数学语言给出证明过程。在早期的大模型评测中模型常常能在基础算术、简单方程上表现不错但面对 IMO 这类需要多步推理和严谨证明的题目时往往会“一本正经地给出错误证明”。因此当某个模型或同系列模型能在完整 IMO 试卷上拿到 42 分满分时代表它至少在竞赛数学这个极其考验推理能力的评测维度上做到了非常高的完成度。1.2 数学推理是检验模型上限的“试金石”很多人可能会问我是一个后端开发者平时又不做竞赛题为什么要关心一个数学推理模型原因是数学推理任务非常适合用来衡量大模型的“系统二能力”。所谓系统一是快速、直觉式的反应系统二则是慢速、有计划、逐步推演的能力。IMO 题目恰恰需要系统二能力题目条件少但隐藏结构多不能靠“背答案”或“记住训练样本中的相似题”蒙混过关错误往往需要反复回溯修正正确的证明必须逻辑闭环。如果一个模型能把数学推理做好说明它在长上下文规划、符号操作、逻辑自洽这些底层能力上是有突破的。而这类能力一旦被验证往往也能迁移到代码生成、复杂工具调用、Agent 任务规划等场景中。另一个重要原因是数学结论“可验证”。代码能不能跑、数学证明对不对这些都是可以用客观规则判断的。这让训练阶段可以设计更可靠的奖励信号而不需要完全依赖人工偏好标注。1.3 开源这个动作的开发者价值在 dots3-note 出现之前高水平的数学推理模型大多以闭源 API 或部分发布的形式存在。闭源 API 虽然使用方便但开发者能做的事情极其有限只能传 prompt 拿结果不能观察中间推理过程不能针对自己的数学题库做微调不能量化、剪枝、蒸馏后部署到边缘设备无法复现论文里的评测结论一旦服务端更新行为可能变化业务很难稳定。开源模型把这些问题打开了。拿到权重之后开发者可以本地起服务、写自动化评测、在私有数据集上检验泛化能力甚至把长思维链数据蒸馏成更小的模型。这也是 dots3-note 这类开源动作最有价值的地方它不是提供一个“截图级别的 Demo”而是把可复现能力直接交到社区手里。2. 数学推理模型背后的关键机制这一节会根据当前开源数学推理模型的常见实现思路做原理拆解。dots3-note 的具体结构、训练细节和评测数据以官方仓库 README、技术报告或开源说明为准但下面几个模块基本是同类模型的“通用骨架”。2.1 思维链与长思维链大模型最早被质疑“只会接龙”但思维链Chain-of-ThoughtCoT出现后模型通过“先写中间推理步骤再给出答案”的方式在数学题上的准确率有了明显提升。后来发展出“长思维链”方向。过去我们习惯用max_new_tokens512控制输出长度但遇到复杂的竞赛题模型可能需要几百甚至上千 token 来做自我探索、试错、回溯。因此推理类模型的生成阶段通常会预留更长的输出空间。从开发者角度看这意味着两件事推理时不能把max_new_tokens设得太小评测时不能只比较最后一行答案而要把模型完整的推理过程保存下来便于分析失败原因。2.2 可验证奖励的强化学习在数学推理模型训练中“可验证奖励”是核心思路之一。传统强化学习需要一个奖励模型来判断动作好坏但数学题的好处在于最终答案对不对是可以被规则判定的。训练流程可以粗略概括为让模型针对一批数学题生成多种解题路径用规则判断最终答案是否与标准答案等价答案正确的生成路径得到正奖励错误路径得到负奖励或较低奖励通过强化学习算法更新模型让模型学到“如何更稳定地找到正确答案”。这种训练方式比单纯依赖人工打分更客观也更容易规模化。竞赛数学恰好提供了大量有标准答案和规范评分标准的题目。2.3 验证器在数学任务中的角色这里要引入“验证器”的概念。数学题的最终结果往往可以表达为等式、集合、不等式或其他精确形式。一个合格的验证器至少需要做到判断模型输出的答案和标准答案是否数学等价判断模型给出的证明步骤是否严谨发现“答案碰巧正确但推理过程错误”的情况。在实际落地时验证器的设计有多种层次验证层次做法可靠性字符串比对直接比较文本低容易误判符号计算比对使用 SymPy 等工具化简求差中高适合代数表达式规则抽取解析\boxed{}等固定格式中依赖输出规范人工核验人类评分高但成本大形式化证明使用 Lean 等证明助手高但建模门槛高对于 IMO 42 分这类成绩最终判定通常不能只看答案还需要证明过程被认可这也是竞赛评测比普通问答评测更严格的地方。2.4 数据与蒸馏数学推理模型的训练离不开高质量数据。除了历史 IMO 题目社区常用数据源还包括各类数学竞赛真题、题库网站、教科书习题和合成数据。由于竞赛题目数量有限许多团队会使用大模型生成大量带有完整推理过程的合成题再经过清洗、去重和难度筛选进入训练集。另外一个常见的工程实践是“蒸馏”。小模型直接做复杂数学推理可能效果不佳但如果我们让一个大模型先生成高质量推理轨迹再用这些轨迹微调小模型往往能把一部分推理能力迁移过去。当前很多 7B、14B 量级的数学推理开源模型其实都经历了类似流程。对普通开发者来说理解蒸馏还有一个实际好处如果你手头只有一块消费级显卡没必要硬扛超大模型选择一个经过蒸馏的中小模型并配合量化部署往往更符合真实资源情况。3. 本地部署前的准备工作接下来进入实操环节。由于 dots3-note 的权重格式和模型结构需要以官方仓库为准本节的示例会按 Hugging Face Transformers 社区常见的模型加载方式来写。如果你的模型结构特殊只需要把加载方式替换为官方示例即可。3.1 硬件与软件环境数学推理模型对显存比较敏感因为推理过程中会产生较长的思维链。建议参考以下配置操作系统LinuxUbuntu 20.04 / 22.04优先Windows/macOS 也可以跑但兼容性差异较多GPUNVIDIA 显卡建议显存不少于 16GBCUDA 版本建议 CUDA 11.8 或 12.xPython 版本3.10 或 3.11核心依赖PyTorch、Transformers、Accelerate推理优化vLLM可选适合高并发场景。如果你显存不够不要急着放弃。后面的章节会介绍 4bit 量化加载和 CPU 慢速推理的降级方案先把流程跑通更重要。3.2 创建虚拟环境并安装依赖推荐为这个项目单独创建 Python 虚拟环境避免污染系统环境python -m venv .venv-dots source .venv-dots/bin/activate如果你的系统是 Windows激活命令改为.venv-dots\Scripts\activate接下来升级 pip并安装 PyTorch。这里使用的 PyTorch 安装命令以 CUDA 12.1 为例pip install --upgrade pip pip install torch --index-url https://download.pytorch.org/whl/cu121然后安装 Transformers 相关依赖pip install transformers accelerate sentencepiece后面下载模型时我会优先使用魔搭 ModelScope。如果你是在国内服务器或本地网络环境ModelScope 的下载速度和稳定性通常更好pip install modelscope最后安装推理加速和数学验证需要的库pip install vllm sympy openai这里的 vllm 主要用于高并发推理sympy 用于数学符号验证openai 用于调用兼容 OpenAI 格式的本地推理服务。3.3 模型下载开源模型发布时一般会同时提供 Hugging Face 和 ModelScope 两个下载渠道。下面以 ModelScope 为例。# 文件路径download_model.py from modelscope import snapshot_download # 注意这里需要替换为官方仓库实际的模型 ID model_dir snapshot_download( your-org/dots3-note, local_dir./models/dots3-note ) print(模型已下载到, model_dir)运行命令python download_model.py下载完成后. /models/dots3-note目录下通常会包含config.json模型结构配置tokenizer.json/tokenizer_config.json分词器model-00001-of-0000X.safetensors权重分片文件generation_config.json生成参数默认配置。如果下载过程因为网络中断或文件较多而失败可以把snapshot_download换成断点续传参数或者使用命令行工具重试。ModelScope 的命令行方式如下modelscope download --model your-org/dots3-note --local_dir ./models/dots3-note不同版本命令可能略有差异遇到问题时优先查看当前安装版本的帮助信息modelscope download --help4. 快速体验跑一道 IMO 真题模型下载完成后最直接的验证方式就是让它做一道 IMO 真题。这里选择一道历史上非常有名的题目题号是 IMO 1959 第 1 题。4.1 准备测试题目题目原文用中文表达如下证明对所有正整数 n分数 (21n4)/(14n3) 是最简分数。这道题非常适合用来初测推理模型原因是题目本身没有复杂的背景知识正确答案是“证明最简”而不是一个具体数值标准的证明方法只需要使用 gcd最大公约数性质。如果模型真的具备数学推理能力它会尝试设 d gcd(21n4, 14n3)然后通过线性组合构造出 1最终说明 d 只能是 1。如果模型只是靠“看起来像数学题”来瞎编则很容易在证明过程中出现明显跳步。4.2 编写推理脚本下面是一个最简的推理脚本。运行时请将MODEL_PATH改成你实际的本地模型路径。# 文件路径run_imo.py import torch from transformers import AutoModelForCausalLM, AutoTokenizer MODEL_PATH ./models/dots3-note # 加载分词器 tokenizer AutoTokenizer.from_pretrained( MODEL_PATH, trust_remote_codeTrue ) # 加载模型 model AutoModelForCausalLM.from_pretrained( MODEL_PATH, torch_dtypetorch.bfloat16, device_mapauto, trust_remote_codeTrue ) model.eval() QUESTION 题目IMO 1959 第 1 题 证明对所有正整数 n分数 (21n4)/(14n3) 是最简分数。 要求 1. 先判断命题是否成立 2. 使用严格的数学语言写出完整证明 3. 最后把关键结论放在 \\boxed{} 中。 messages [ {role: user, content: QUESTION} ] # 优先使用模型自带的 chat template try: prompt tokenizer.apply_chat_template( messages, tokenizeFalse, add_generation_promptTrue ) except Exception: # 如果 tokenizer 没有定义 chat template则使用通用模板 prompt 用户 QUESTION \n助手 inputs tokenizer(prompt, return_tensorspt).to(model.device) with torch.inference_mode(): outputs model.generate( **inputs, max_new_tokens4096, do_sampleFalse ) # 只解码新生成的部分避免把输入重复输出 reasoning tokenizer.decode( outputs[0][inputs[input_ids].shape[1]:], skip_special_tokensTrue ) print(reasoning)脚本中有几个地方值得说明trust_remote_codeTrue部分模型使用自定义代码需要显式信任torch_dtypetorch.bfloat16可以用更少显存加载模型max_new_tokens4096因为数学推理模型往往需要生成很长的思考过程do_sampleFalse先采用贪心解码保证结果可复现。运行命令python run_imo.py4.3 结果解读模型输出的理想结构应该是“结论 证明过程 最终结论”。针对 IMO 1959 第 1 题标准证明的关键步骤大致如下设 d gcd(21n4, 14n3)。因为 d 同时整除分子和分母所以 d 一定能整除它们的任意线性组合。考虑3(14n3) - 2(21n4) 1因此 d 整除 1所以 d 1。既然分子分母的最大公约数为 1分数就是最简分数。当你运行模型时如果它给出的证明包含上述逻辑链说明模型确实理解了解题路径。如果它只输出“显然成立”“因为分子分母互质”这类没有中间推导的话就要怀疑它是否在套模板了。4.4 更高吞吐vLLM 推理Transformers 方式适合单条验证但如果你要跑几十道题或多个并发请求推荐用 vLLM。vLLM 不仅省显存还能用 PagedAttention 等机制提升吞吐。下面的 Python 脚本展示了 vLLM 的同步推理方式# 文件路径run_vllm_batch.py from vllm import LLM, SamplingParams MODEL_PATH ./models/dots3-note llm LLM( modelMODEL_PATH, dtypebfloat16, tensor_parallel_size1, gpu_memory_utilization0.9, trust_remote_codeTrue, ) sampling_params SamplingParams( temperature0.0, max_tokens4096, ) prompts [] questions [ 证明对所有正整数 n分数 (21n4)/(14n3) 是最简分数。, 求方程 x^2 3x - 4 0 的所有实数解。, ] for q in questions: prompts.append(用户 q \n助手) outputs llm.generate(prompts, sampling_params) for output in outputs: generated output.outputs[0].text print(generated) print( * 40)vLLM 的SamplingParams是控制生成的核心参数。temperature0.0表示贪心解码适合追求稳定性的评测。如果希望增加结果多样性可以改成temperature0.6, top_p0.95, max_tokens4096。5. 如何评估数学解题结果跑通推理之后下一个关键问题是如何判定输出对不对。数学题的评测比普通文本生成评测更严格下面给出层层递进的评估方案。5.1 为什么不能只看关键词很多开发者在测试普通问答模型时习惯用“是否包含某个关键词”来判断回答质量。这个方法在数学题上非常危险。例如模型可能输出命题成立分数是最简分数因为分子分母显然互质。这段文字包含了所有正确关键词“成立”“最简”“互质”但并没有给出有效证明。更糟糕的是如果这是一道需要排除特殊边界条件的题目模型可能会漏掉关键情况而得到错误结论。因此评估数学解题能力至少要把“最终答案”和“证明过程”分开看待。5.2 基于\boxed{}的答案抽取为了让答案可以被自动比对许多数学推理模型被训练成“最后一层输出\boxed{}”的格式。例如\boxed{不可约}或者\boxed{x 1 或 x -4}我们可以用正则表达式抽取这个字段# 文件路径extract_answer.py import re def extract_boxed_answer(text: str) - str: 从模型输出中抽取最后一个 \boxed{} 内容。 matches re.findall(r\\boxed\{(.*?)\}, text, flagsre.S) if not matches: return return matches[-1].strip() # 示例 sample_output 结论该分数不可约。 \\boxed{最简分数} print(extract_boxed_answer(sample_output)) # 最简分数抽取出来的字符串只能用于后处理不等于最终判定。5.3 符号等价判断如果题目答案是数值表达式、方程解或函数表达式那么字符串完全相等并不是一个好标准。举个例子模型输出\sqrt{8}标准答案是2\sqrt{2}。两者虽然字符串不同但数学上是等价的。此时可以引入 SymPy 做符号化简# 文件路径check_math.py from sympy import simplify, sympify def answer_equivalent(pred: str, gold: str) - bool: 判断两个数学表达式是否等价。 try: pred_expr sympify(pred) gold_expr sympify(gold) return simplify(pred_expr - gold_expr) 0 except Exception: # 解析失败时降级为字符串比对 return pred.strip() gold.strip() print(answer_equivalent(sqrt(8), 2*sqrt(2))) # True print(answer_equivalent(x 1, x 1.0)) # 取决于解析结果实践时建议先统一格式这个方法的优点是它能处理根式、分式、多项式化简。缺点是它只适合“答案是可解析表达式”的题目不适合集合、不等式范围、反证法结论等场景。5.4 证明与人工核验对于 IMO 级别的题最终极的评估依然需要看证明。自动评估证明是目前研究的热点可选方案包括让更强的大模型做“裁判”对证明过程逐行打分建立 rubric 人工评分表使用 Lean 等证明助手形式化验证将模型证明的关键步骤转为可执行代码再用单元测试验证。在我自己的项目里比较推荐的方法是“自动抽答案 人工核验关键步骤”先用脚本批量跑题自动抽取\boxed{}并计算答案级正确率对答案正确的样本再做证明抽查将错误证明按错误类型分类计算错误、逻辑跳步、条件遗漏、结论幻觉。这套流程能最大化节省人工时间同时避免被“答案对了但证明错了”误导。6. 部署成可调用的推理服务验证完成之后如果你想把模型接入到业务系统、Web 应用或 Agent 工具中最稳妥的方式是把它部署成一个本地推理服务。vLLM 天然支持 OpenAI 兼容的 HTTP 接口方便现有代码接入。6.1 使用 vLLM 启动服务命令行启动方式如下vllm serve ./models/dots3-note \ --served-model-name dots3-note \ --host 0.0.0.0 \ --port 8000 \ --dtype bfloat16 \ --max-model-len 8192 \ --gpu-memory-utilization 0.9 \ --trust-remote-code启动成功后终端会出现类似日志INFO: Application startup complete. INFO: Uvicorn running on http://0.0.0.0:8000这意味着服务已经就绪。6.2 用 curl 验证接口打开另一个终端用 curl 发送请求curl -s http://127.0.0.1:8000/v1/chat/completions \ -H Content-Type: application/json \ -d { model: dots3-note, messages: [ { role: user, content: 证明对所有正整数 n分数 (21n4)/(14n3) 是最简分数。 } ], temperature: 0, max_tokens: 4096 }如果一切正常响应会是一个 JSON 对象其中choices[0].message.content就是模型生成的推理结果。6.3 通过 Python 客户端接入如果你已经安装了 openai Python 包可以用非常接近 OpenAI 官方 SDK 的方式接入本地服务# 文件路径client_demo.py from openai import OpenAI client OpenAI( base_urlhttp://127.0.0.1:8000/v1, api_keyEMPTY, # 本地服务不需要真实 key ) resp client.chat.completions.create( modeldots3-note, messages[ { role: user, content: 证明对所有正整数 n分数 (21n4)/(14n3) 是最简分数。 } ], temperature0, max_tokens4096, ) print(resp.choices[0].message.content)运行python client_demo.py把 HTTP 服务跑起来之后前端、后端、自动化脚本都可以通过同一个接口调用模型业务层不需要关心模型权重和推理细节。7. 常见问题与排查思路本地部署大模型的过程中一定会遇到各种环境问题。下面整理几个高频场景。7.1 常见问题速查表问题现象常见原因解决思路模型下载非常慢或中断网络不稳定 / 文件分片多切换到 ModelScope使用local_dir断点续传加载时显存不足模型权重尺寸超过显存启用 4bit/8bit 量化或降低max_model_len生成结果很短就停止max_new_tokens太小增大到 4096 或更高输出内容大量重复采样温度过高 / 模型重复惩罚设置不当使用贪心解码或设置repetition_penalty模型输出乱码分词器与模型不匹配重新确认下载目录不要混用不同模型文件请求 vLLM 接口超时单次推理 token 太长调大服务端--max-model-len或减小前端请求参数同一个问题多次结果不一致采样参数随机评测时使用temperature0固定输出7.2 模型输出空内容的排查顺序如果模型生成结束后返回空字符串按以下顺序排查检查skip_special_tokensTrue是否误删了正文检查inputs[input_ids]切片是否正确防止把输入部分也算进去临时输出outputs[0]的 shape确认是否有 token 生成把max_new_tokens调大看是不是模型还没来得及输出就被截断用官方仓库提供的 demo 脚本对比排除模型加载方式问题。7.3 显存不足的几种降级方案显存不足是最常见的 GPU 问题尤其是本地开发机。降级方案可以按顺序尝试第一使用量化加载。Transformers 原生支持bitsandbytes可以在加载时启用 4bit 量化from transformers import BitsAndBytesConfig quantization_config BitsAndBytesConfig( load_in_4bitTrue, bnb_4bit_compute_dtypetorch.bfloat16 ) model AutoModelForCausalLM.from_pretrained( MODEL_PATH, quantization_configquantization_config, device_mapauto, trust_remote_codeTrue )第二缩小单次推理的最大长度。数学推理虽然长但 4096 token 不一定每次都需要按任务粒度动态设置长度能节省显存。第三切换到更小的同系列模型。如果官方发布了不同规格的版本优先选择 7B 或 14B 规模如果只能跑超大模型也可以考虑把量化后的模型放到多张 GPU 上。第四使用 CPU 慢速推理。这个方法只适合验证“模型能不能跑”不适合生产。8. 最佳实践与工程建议模型部署成功只是第一步。如果要真正把数学推理模型用到评测或业务中下面这些工程经验值得提前注意。8.1 建立可复现的评测基线跑数学题的时候一定要先把评测条件固定下来固定 prompt 模板固定解码参数评测时建议temperature0固定模型版本记录模型 commit hash固定随机种子保存每道题的完整输入和原始输出而不是只保存最终分数。可复现是数学评测的生命线。如果每次跑题结果都不一样后续的微调、量化、蒸馏优化都无从谈起。8.2 统一输出格式不管是人工分析还是自动裁判混乱的输出格式都会显著增加成本。建议在 prompt 中显式要求模型按照规范格式输出关键结论放在\boxed{}中证明按步骤编号不要省略关键推导如果有多个解需要说明解集。统一格式之后可以降低自动抽取的失败率评测管道也会更稳定。8.3 量化与精度取舍4bit 量化可以让大模型在更小的显存上运行但量化会引入精度损失。对于数学推理任务这种损失有时比普通问答更明显因为长链路推理中的任何一步误差都可能被逐步放大。我的建议是日常验证流程先使用 bfloat16只有在显存成为瓶颈时才考虑 8bit4bit 量化之后必须重新跑一遍基础评测题观察分数是否明显下降涉及高精度符号计算时尽量保持更高的数值精度。8.4 安全与合规边界数学推理模型虽然看起来“很理科”但它在生产环境中依然可能给出错误结果而且错误往往隐藏在一大段看起来非常严密的推理里。所以如果系统要拿模型结果做自动判定、自动改卷、金融决策等敏感操作不能把模型当唯一裁判。工程上建议加入多级防线对结果进行符号验证或规则回查设置置信度阈值低置信度结果转人工保留推理日志方便事后审计模型能力边界要在产品说明里写清楚不能宣称“100% 数学正确”。另外使用任何开源模型都要留意许可证条款。即使模型权重免费开放也要确认商用授权、模型再分发、署名要求等条款。如果仓库没有明确说明不要默认“开源 随便商用”。8.5 长上下文与批量任务如果要做批量评测建议直接使用 vLLM 而不是逐个调用 Transformers。vLLM 支持 continuous batching能动态合并同一批请求吞吐量远高于 for 循环。批量任务的建议是把每条 prompt 的 max_tokens 根据题目难度分组。简单题给 1024 token中等题给 2048竞赛题给 4096。这样可以避免简单题占用过多生成空间进而提高整体吞吐。9. 下一步学习思路拿到 dots3-note 或任何同类型开源数学推理模型后我建议你按下面的顺序推进第一步先复现一次单题推理观察模型在 IMO 1959 第 1 题上的输出理解长思维链的输出风格。第二步整理一份 10 到 20 道题的私有评测集把答案抽取和符号等价判断脚本跑通得到基础准确率。第三步用 vLLM 部署出 HTTP 服务把模型接到自己的 Web 应用或 Agent 脚本中。第四步如果手头显存不足再做量化和蒸馏实验重点观察量化前后准确率变化。第五步研究模型的错误样本。数学推理模型的每一次错误都是一次难得的分析机会模型是在哪一步开始偏离正确方向的是计算错误还是逻辑假设出了问题这些分析远比“刷一个更高