dots3-note开源数学模型：本地部署与数学推理评测实战

dots3-note 是小红书最近开源的一个数学模型名字里的 note 很容易让人联想到轻量或笔记场景但它所在系列此前在 IMO 级别的数学评测中拿到过满分成绩也就是 6 道题每题 7 分、合计 42 分的那种满分。这样一来dots3-note 最值得关注的价值就清楚了它不是一个只能聊天的模型而是把接近竞赛数学推理能力的一支开放了出来方便开发者在本地环境做解题生成、数学评测、逻辑推理相关测试。如果你正在做数学题解、解题步骤生成、竞赛题辅助训练或者想找一个能在离线环境跑通的开源推理模型这篇文章可以帮你省掉不少试错时间。我会先说明应该怎么理解“同系列满分”这句话再讲本地部署前的硬件和依赖确认然后给出单道题的完整推理链路接着聊批量数学评测的注意事项最后放一套排查顺序。下面按实际落地顺序拆一遍。1. 先理解 dots3-note 到底是什么定位1.1 “同系列满分”不等于“dots3-note 满分”从这次开源信息来看dots3-note 和另一个在 IMO 评测里拿 42 分满分的模型属于同一条模型系列。这句话要拆开看满分成绩属于同系列中更完整或更强的版本dots3-note 是同一个系列里带 note 后缀的产物大概率面向轻量部署、本地运行和日常任务不能因为系列里有满分成绩就默认 note 版本在所有数理题上都能稳定拿满分。这个判断非常关键。实际测试开源模型时系列内不同尺寸、不同蒸馏方式的表现差异经常比系列之间的差异还要大。你下载的是 note 版本就应该用 note 版本能够承载的任务去验收而不是拿系列最高分作为它的及格线。1.2 它适合做什么不适合做什么根据名称和同系列背景来理解dots3-note 的核心价值应该在数学推理和分步解题。适合做的场景数学证明题、代数题、不等式、数论问题这类需要分步推导的任务需要同时输出过程和最终结论的解题辅助工具数学竞赛题目切片测试和模型推理能力评估在教育类产品里做解题步骤生成、错题解释。不适合一开始就指望它做的场景长篇中文文章创作、复杂小说生成需要实时联网检索的事实问答多模态图片识别任务除非模型卡里明确标注支持视觉输入超出上下文长度限制的长文档分析。这不是说它不能做普通问答而是说你在选型时要先抓住它的长板。它最值得验证的一定是推理能力和数学解题文本生成的通用性应该放到第二优先级。常规大模型已经能处理的事情不需要为它额外付出部署成本。2. 部署前先确认硬件、依赖和模型文件2.1 不同显存容量对应不同跑法拿到模型后的第一步不是直接写推理脚本而是先看模型卡上标注的参数规模、精度要求和上下文长度。这里有个很实在的经验先看模型名和仓库说明不要靠猜。dots3-note 这个名字没有直接告诉你它是 7B、14B 还是更大所以“能不能在我的机器上跑”必须结合模型权重体积来判断。按常见部署条件可以先把环境分成四档环境类型建议做法需要留意的点无 GPU、纯 CPU用小上下文和量化权重试跑速度会很慢适合验证链路不适合批量评测8GB 显存优先尝试 4bit 量化限制 max_new_tokens显存紧张时容易 OOM先单题通过再扩大任务量16GB 显存中等精度加载或量化后提高少量并发看模型体积不一定要上完整精度24GB 以上显存完整精度或 bf16 加载可以进一步做批量任务和服务化部署我没有办法替你拍板具体显存要求因为模型参数量和量化方式会直接改变占用。原始资料里也没有给出明确的硬件门槛所以落地时要以模型仓库页面为准。先把环境想到最差比如你只有 8GB 显存那就按“量化 短输出 单并发”的配置去准备。除了显卡显存内存和磁盘也不能忽略。模型权重下载通常需要几十 GB 级别的磁盘空间如果下载之后还要做格式转换或量化磁盘占用会翻倍甚至更多。建议先清理出足够空间再开始拉模型。2.2 依赖安装和模型下载运行这类开源模型常见的最小依赖组合是 Python、PyTorch、transformers、accelerate。如果要做量化还要加 bitsandbytes 或者对应的量化库如果要服务化部署再考虑 vLLM 这类推理框架。下面是一份基础安装命令pip install torch transformers accelerate bitsandbytes pip install modelscope国内网络环境下我建议优先用 ModelScope 下载模型速度通常比直接走境外仓库稳定得多。下载命令类似这样modelscope download --model 组织名/dots3-note --local_dir ./models/dots3-note这里的“组织名/dots3-note”要替换成你在模型仓库里实际看到的 ID不要复制一个不存在的路径去跑。下载前先打开模型页确认两件事一是模型 ID 是否拼写正确二是 README 里是否有特殊加载说明。为什么先做这一步因为很多开源模型都有自定义代码和特殊分词器配置直接统一用 AutoModelForCausalLM 加载不一定能成功。模型卡里如果写了需要 trust_remote_codeTrue或者要求指定某个模型家族类名那就是它在提醒你加载方式有特殊要求别忽略。下载完成后建议检查目录里的文件是否齐全。常见缺失包括 safetensors 切片文件不完整、tokenizer 文件缺失、配置文件版本不匹配。文件不全会导致启动时报错而且报错信息不一定直白。3. 用一道 IMO 风格题目验证单条推理链路3.1 最小推理代码部署环境准备好之后不要急着做复杂封装先写一个最简单的推理脚本用一道题跑通整条链路。下面是常见的最小加载代码from transformers import AutoModelForCausalLM, AutoTokenizer import torch model_dir ./models/dots3-note tokenizer AutoTokenizer.from_pretrained(model_dir, trust_remote_codeTrue) model AutoModelForCausalLM.from_pretrained( model_dir, torch_dtypetorch.bfloat16, device_mapauto, trust_remote_codeTrue, )如果你的显存不够跑 bfloat16可以把加载参数改成 load_in_4bitTrue并确保已经安装 bitsandbytes。加载成功后再构造输入question ( 设 a、b 是正整数且 ab1 能整除 a^2b^2。\n 证明(a^2b^2)/(ab1) 是完全平方数。\n 请先分步推理再给出最终结论。 ) messages [{role: user, content: question}] input_text tokenizer.apply_chat_template( messages, tokenizeFalse, add_generation_promptTrue ) inputs tokenizer(input_text, return_tensorspt).to(model.device) outputs model.generate( **inputs, max_new_tokens2048, do_sampleFalse, ) response tokenizer.decode( outputs[0][inputs[input_ids].shape[1]:], skip_special_tokensTrue, ) print(response)这里最关键的一步是 apply_chat_template。很多人在纯文本拼接上翻车因为模型训练时用的对话模板和普通 text2text 输入不完全一样。如果不套模板而直接把题目拼在字符串后面输入输出很容易混乱或者带上大量特殊 token。3.2 关键参数怎么设置上面代码里我用了 do_sampleFalse也就是贪心解码。数学类评测我非常建议先用这个配置因为每一步都取概率最高的 token结果最稳定也最容易复现。如果一上来就开高温度采样同一个题目可能每次输出都不一样你很难判断到底是模型不会做还是随机性带来的波动。max_new_tokens 要给够。数学证明往往需要先写一段推导过程再写结论如果只给 256 或 512很可能推理到一半就被截断最后看不到最终结论。我一般先用 2048 做冒烟测试确认模型能在合理长度内完成推导后再根据实际输出长度调整。如果后续要做多样化生成或者需要同一个问题采样多个结果来投票再把 do_sample 改成 True同时把 temperature 设置到 0.6 到 0.8 之间。注意温度过高会让证明过程出现幻觉比如中间步骤突然出现没有根据的恒等式这在数学评测里比答错更麻烦。3.3 成功的输出长什么样一次成功的数学推理输出通常具备三个特征开头会有一个引入条件或设未知量的过程中间分步骤推导每步之间有逻辑关系结尾有明确结论而且结论能对应题目要求。如果你的输出是“这道题主要考查某个知识点”“我们可以尝试一个思路”这类泛泛而谈却没有具体推导那说明 prompt 没有把推理能力激发出来或者模型权重本身不太适合该题型。这时候先换一道更简单的题验证不要急着调一堆参数。还要区分“最终答案”和“推理过程中的临时结论”。有些模型会先写一些尝试性步骤这些步骤不一定都对。测试时不要只看屏幕最后一行要顺着推理过程看一眼中间有没有明显漏洞。自动评测时应该把最终答案抽取和过程校验分开处理不能因为结尾写了个答案就判定全对。4. 单题跑通之后再做批量数学评测4.1 批量任务必须带结果落盘和错误隔离单道题跑通后很多人第二件事就是写一个 for 循环把所有题目一次性丢进去然后盯着屏幕看。这种做法的风险很高中途只要有一道题触发显存溢出、超时或者解析异常整个进程就可能直接退出前面的结果全丢。我更建议把批量任务拆成“一题一结果”的结构每道题单独调用一次生成函数单独写入一个文件异常单独记录。下面是一个可参考的任务框架import json import time from pathlib import Path def run_one_question(q: str) - str: # 这里放前面验证过的单题推理逻辑 return response_text questions json.load(open(math_problems.json, encodingutf-8)) out_dir Path(eval_results) out_dir.mkdir(exist_okTrue) for item in questions: try: answer run_one_question(item[question]) record { id: item[id], question: item[question], expected: item.get(answer, ), predicted: answer, } (out_dir / f{item[id]}.json).write_text( json.dumps(record, ensure_asciiFalse, indent2), encodingutf-8, ) except Exception as e: (out_dir / f{item[id]}.error.log).write_text( repr(e), encodingutf-8 )这样做的第一个好处是进度可恢复。某道题失败后只需要单独重跑这道题不需要把整个题目集重新生成一遍。第二个好处是输出和日志分开不会出现“结果和报错混在一起最后不知道哪条对应哪条”的情况。还要给每道题设置合理的时间预算。推理模型在难题上可能生成很长的过程如果没有超时控制遇到一道模型反复绕圈的题整个批量任务都可能卡住。常见做法是设置单题最长等待时间超时后记为失败并继续下一题。4.2 题目格式和答案抽取要单独设计批量评测的另一个坑是题目格式不统一。有人在 JSON 里存的是 LaTeX 格式有人存的是纯文本有人题目标题里带了额外说明。模型对不同格式的敏感程度比你想象的高。建议在批量前先做一轮格式检查把题目统一成同一种表达方式尤其是数学符号。比如用 a^2 还是 a^{2}用 $\frac{a}{b}$ 还是 a/b这些都会影响输出稳定性。答案抽取也不能只用简单规则。比如模型输出里有“因此答案是 1”和“而中间过程 b 的取值可以是 1”简单正则可能把第一个 1 当成最终答案。建议在后处理里先做一次“最终结论定位”寻找“最终”“综上”“therefore”“boxed”这类信号词再提取后面的公式或数字。如果模型输出格式不固定可以先做一个小样本标注确认抽取规则在不同题型上的准确率再应用到全量题目。打分环节同样要谨慎。数学题不是所有都能用字符串匹配判断对错。数值型题目可以做表达式化简后对比证明题则需要人工或规则校验关键步骤。如果只是要快速看准确率可以先按最终答案匹配但报告里要写清楚这是“答案匹配口径”不是“步骤正确率”。5. 不同显卡条件下的跑法和取舍5.1 小显存机器先跑通再谈优化如果你的显卡只有 8GB 显存第一目标是“稳定生成”不是“速度最快”。此时可以把加载方式改成 4bit 量化把上下文长度和 max_new_tokens 控制在一个合理范围内同时避免同时开多个并发任务。一次只跑一道题观察 GPU 占用和生成速度确认没有 OOM 后再逐步增加任务量。量化确实会带来一定精度损失尤其在数学推理上可能偶尔出现和完整精度不一样的结果。在小显存机器上做评测时如果某个结果非常反常我的建议是先怀疑量化再用完整精度在同样题目上复测一次。不要因为一次量化结果就把模型判死刑。5.2 服务化和高并发怎么选如果你的任务量很大比如要跑几千道题或者要做成 API 给业务调用单纯用 transformers 写循环就不太够。常见做法是引入 vLLM 这类推理框架。vLLM 会做动态批处理、显存复用和请求排队在并发推理场景下的吞吐通常明显高于逐条调用。使用 vLLM 时可以先以 OpenAI 兼容接口的方式把模型启起来再让评测脚本向接口发请求。这样评测脚本和模型进程解耦模型崩溃时可以单独重启不会把已经跑完的题目结果带走。不过 vLLM 对模型结构和版本有一定要求不是所有模型都能直接支持要看模型仓库里的部署说明。不同跑法的对比可以整理成下表跑法适合场景优点代价transformers 单题推理冒烟测试、验证链路代码简单、易调试速度慢不适合高并发4bit 量化运行8GB 小显存机器显存占用小可能有少量精度损失bf16 完整加载16GB 以上显存输出更接近完整精度显存和磁盘占用更高vLLM 服务化大量题目、接口调用并发吞吐高、队列管理方便需要额外配置和兼容性确认在我实测时最常见的流程是先用 transformers 在 8GB 环境里跑通两道题确认模型文件和 prompt 格式没问题然后换到资源更充足的机器上用 bf16 或高精度做完整评测最后如果确实要长期提供服务再上 vLLM。每一级切换都要保留上一次已验证的输入和输出样本方便问题定位。6. 报错和输出异常时的排查顺序6.1 启动类报错先看环境和文件如果模型加载失败不要第一时间怀疑模型坏了。先看报错类型再把环境逐项核对。常见启动报错和排查方向CUDA out of memory显存不够。先降低精度、减小 max_new_tokens、关掉其他占显存进程。不要一上来就换更大的模型。KeyError 或模型结构类报错大概率加载方式和模型不匹配。检查模型卡是否要求 use_flash_attention、trust_remote_code 或特定模型类。OSError、路径不存在确认 model_dir 是否填对目录里是不是真的有 safetensors 和 tokenizer 文件。dtype 相关告警如果 CPU 不支持 bfloat16加载时会降级到 float32速度会明显变慢。可以显式指定 torch_dtypetorch.float32或者换支持 bf16 的设备。依赖版本冲突transformers、accelerate、bitsandbytes 版本太老或太新都可能出现兼容问题。升级依赖时不要一次性全升建议记录当前版本逐步排查。还有一个容易被忽略的问题磁盘空间不足。模型在加载时会做权重文件映射如果磁盘只剩几个 GB加载到一半可能报一个和路径无关的写入错误。看到怪异报错时先看剩余空间再决定是否继续排查模型层。6.2 输出乱、短、空时按输入到参数的顺序查如果模型能正常启动但输出质量不对我建议按下面顺序排查先看 prompt 格式。有没有用对对话模板题目的数学符号有没有被转义破坏是不是同时混了太多无关指令再看输入长度。题目本身是否接近或超过模型支持的上下文如果输入很长生成空间会被压缩容易出现截断。再看生成参数。max_new_tokens 是否给得太少do_sample 是不是误开了高温度重复惩罚是否设置得过高导致模型不断改口再看量化或精度。4bit 下同一道题结果不稳定可以先用完整精度跑一次对比。最后再判断模型能力边界。排查完上面四步之后如果题目依然做不对那很可能就是模型在当前版本下确实没掌握这类解法。换一道同类但更简单的题可以快速确认是能力边界还是偶发错误。排查时最忌讳的是“现象一出现就直接调参数”。比如模型输出很短你先别急着把 temperature 拉到 0.9应该先确认是提前结束、被截断还是模型确实没话说了。前者的修复方式是调 max_new_tokens 和停止条件后者的修复方式是换 prompt两者完全不同。一个比较实用的做法是给生成过程加日志记录每次生成的 token 数、是否触发结束符、耗时和显存峰值。这些日志看起来不起眼但批量跑了十几个小时后你会发现它能帮你快速定位是不是某一类题目格式导致生成陷入死循环。单题跑通时也要顺手记下这些基准值后面所有改动都跟基准值对比效率会高很多。7. 落地前需要心里有数的几条边界7.1 note 版本和完整版本不是一回事dots3-note 这个名称里的 note按常见命名逻辑很可能是轻量版、精简版或者面向日常使用的版本。轻量版的价值在于部署成本低但代价通常是能力上限低于同系列的完整模型。正式项目选型时不建议拿着 note 版本的口径去承诺“IMO 42 分水平”这是很容易出现的误会。更稳妥的做法是先用真实业务题目给 note 版本做一次小规模能力摸底统计它在你的题型分布上的准确率、超时率、输出完整率再决定能否上线。任何来自系列荣誉的宣传数据都不能替代你自己业务集上的测试结果。7.2 数学满分不代表所有数理任务稳定就算同系列版本在 IMO 级别的题目上拿过满分也只能说明它在竞赛题分布上的强项。实际业务里还有应用题、图表题、多步计算、几何图形推理等不同类型每一类都有可能超出它的训练覆盖。尤其是需要识别图片中的几何图形时如果模型本身不支持视觉输入那就只能靠文字描述能力会大打折扣。上线前要按题型分桶测试而不是按整体平均分判断。最好把失败样本单独挑出来看判断是题目理解错、计算错、步骤跳步还是格式不规范。不同类型错因对应的改进方法不一样理解错要调 prompt计算错要考虑工具调用校验步骤跳步要考虑生成参数或训练数据覆盖格式不规范要在后处理阶段兜底。7.3 最后确认许可证和部署范围开源模型可以下载测试不代表可以无约束地商用。不同模型仓库会用不同的开源协议有的允许商用但有附加条件有的不允许用于特定场景。正式接业务之前要把模型仓库页的 License 和 README 完整读一遍确认使用范围、分发限制、署名要求。这里有个经验不要因为能下载就默认“完全免费可用”许可证是一个独立的确认环节。模型本身和配套代码会持续更新等你看到这篇文章时说明文档里的加载方式、支持范围、参数规模都可能有调整。所以要以当时的模型仓库主页和发布说明为准。模型评测这件事永远要先跑一遍自己的样例再相信宣传页里的结论。