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

最近开源社区又一个值得关注的消息出现了：小红书把 dots3-note 模型权重放出来了。根据发布方给出的信息，dots3-note 与之前在同一数学推理评测中拿到 IMO 42 分满分的模型属于同一技术系列，也就是说，这套模型的竞赛数学解题能力并不是“演示视频”里的特效，而是可以被开发者拉下来跑、拿来复现评测、甚至继续微调的权重。

这篇文章我不会只做新闻复述，而是站在开发者的角度，重点解决三件事：

1. 拆解 IMO 42 分为什么是数学推理模型的重要里程碑；
2. 讲清楚数学推理模型背后的训练与验证机制；
3. 从环境搭建、模型下载、推理调用、结果评估到最终工程部署，给出一套可复制的本地跑通方案。

如果你最近在关注“开源模型”“数学推理”“本地部署”这几个方向，这篇文章正好可以帮你把这颗模型快速用起来。

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-Thought，CoT）出现后，模型通过“先写中间推理步骤，再给出答案”的方式，在数学题上的准确率有了明显提升。

后来发展出“长思维链”方向。过去我们习惯用max_new_tokens=512控制输出长度，但遇到复杂的竞赛题，模型可能需要几百甚至上千 token 来做自我探索、试错、回溯。因此，推理类模型的生成阶段通常会预留更长的输出空间。

从开发者角度看，这意味着两件事：

• 推理时不能把max_new_tokens设得太小；
• 评测时不能只比较最后一行答案，而要把模型完整的推理过程保存下来，便于分析失败原因。

2.2 可验证奖励的强化学习

在数学推理模型训练中，“可验证奖励”是核心思路之一。传统强化学习需要一个奖励模型来判断动作好坏，但数学题的好处在于，最终答案对不对是可以被规则判定的。

训练流程可以粗略概括为：

1. 让模型针对一批数学题生成多种解题路径；
2. 用规则判断最终答案是否与标准答案等价；
3. 答案正确的生成路径得到正奖励，错误路径得到负奖励或较低奖励；
4. 通过强化学习算法更新模型，让模型学到“如何更稳定地找到正确答案”。

这种训练方式比单纯依赖人工打分更客观，也更容易规模化。竞赛数学恰好提供了大量有标准答案和规范评分标准的题目。

2.3 验证器在数学任务中的角色

这里要引入“验证器”的概念。数学题的最终结果往往可以表达为等式、集合、不等式或其他精确形式。一个合格的验证器至少需要做到：

• 判断模型输出的答案和标准答案是否数学等价；
• 判断模型给出的证明步骤是否严谨；
• 发现“答案碰巧正确但推理过程错误”的情况。

在实际落地时，验证器的设计有多种层次：

对于 IMO 42 分这类成绩，最终判定通常不能只看答案，还需要证明过程被认可，这也是竞赛评测比普通问答评测更严格的地方。

2.4 数据与蒸馏

数学推理模型的训练离不开高质量数据。除了历史 IMO 题目，社区常用数据源还包括各类数学竞赛真题、题库网站、教科书习题和合成数据。由于竞赛题目数量有限，许多团队会使用大模型生成大量带有完整推理过程的合成题，再经过清洗、去重和难度筛选进入训练集。

另外一个常见的工程实践是“蒸馏”。小模型直接做复杂数学推理可能效果不佳，但如果我们让一个大模型先生成高质量推理轨迹，再用这些轨迹微调小模型，往往能把一部分推理能力迁移过去。当前很多 7B、14B 量级的数学推理开源模型，其实都经历了类似流程。

对普通开发者来说，理解蒸馏还有一个实际好处：如果你手头只有一块消费级显卡，没必要硬扛超大模型，选择一个经过蒸馏的中小模型并配合量化部署，往往更符合真实资源情况。

3. 本地部署前的准备工作

接下来进入实操环节。由于 dots3-note 的权重格式和模型结构需要以官方仓库为准，本节的示例会按 Hugging Face Transformers 社区常见的模型加载方式来写。如果你的模型结构特殊，只需要把加载方式替换为官方示例即可。

3.1 硬件与软件环境

数学推理模型对显存比较敏感，因为推理过程中会产生较长的思维链。建议参考以下配置：

• 操作系统：Linux（Ubuntu 20.04 / 22.04）优先，Windows/macOS 也可以跑，但兼容性差异较多；
• GPU：NVIDIA 显卡，建议显存不少于 16GB；
• CUDA 版本：建议 CUDA 11.8 或 12.x；
• Python 版本：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 --help

4. 快速体验：跑一道 IMO 真题

模型下载完成后，最直接的验证方式就是让它做一道 IMO 真题。这里选择一道历史上非常有名的题目，题号是 IMO 1959 第 1 题。

4.1 准备测试题目

题目原文用中文表达如下：

证明：对所有正整数 n，分数 (21n+4)/(14n+3) 是最简分数。

这道题非常适合用来初测推理模型，原因是：

• 题目本身没有复杂的背景知识；
• 正确答案是“证明最简”，而不是一个具体数值；
• 标准的证明方法只需要使用 gcd（最大公约数）性质。

如果模型真的具备数学推理能力，它会尝试设 d = gcd(21n+4, 14n+3)，然后通过线性组合构造出 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_code=True ) # 加载模型 model = AutoModelForCausalLM.from_pretrained( MODEL_PATH, torch_dtype=torch.bfloat16, device_map="auto", trust_remote_code=True ) model.eval() QUESTION = """题目（IMO 1959 第 1 题）： 证明：对所有正整数 n，分数 (21n+4)/(14n+3) 是最简分数。 要求： 1. 先判断命题是否成立； 2. 使用严格的数学语言写出完整证明； 3. 最后把关键结论放在 \\boxed{} 中。""" messages = [ {"role": "user", "content": QUESTION} ] # 优先使用模型自带的 chat template try: prompt = tokenizer.apply_chat_template( messages, tokenize=False, add_generation_prompt=True ) except Exception: # 如果 tokenizer 没有定义 chat template，则使用通用模板 prompt = "用户：" + QUESTION + "\n助手：" inputs = tokenizer(prompt, return_tensors="pt").to(model.device) with torch.inference_mode(): outputs = model.generate( **inputs, max_new_tokens=4096, do_sample=False ) # 只解码新生成的部分，避免把输入重复输出 reasoning = tokenizer.decode( outputs[0][inputs["input_ids"].shape[1]:], skip_special_tokens=True ) print(reasoning)

脚本中有几个地方值得说明：

• trust_remote_code=True：部分模型使用自定义代码，需要显式信任；
• torch_dtype=torch.bfloat16：可以用更少显存加载模型；
• max_new_tokens=4096：因为数学推理模型往往需要生成很长的思考过程；
• do_sample=False：先采用贪心解码，保证结果可复现。

运行命令：

python run_imo.py

4.3 结果解读

模型输出的理想结构应该是“结论 + 证明过程 + 最终结论”。针对 IMO 1959 第 1 题，标准证明的关键步骤大致如下：

设 d = gcd(21n+4, 14n+3)。因为 d 同时整除分子和分母，所以 d 一定能整除它们的任意线性组合。考虑：

3(14n+3) - 2(21n+4) = 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( model=MODEL_PATH, dtype="bfloat16", tensor_parallel_size=1, gpu_memory_utilization=0.9, trust_remote_code=True, ) sampling_params = SamplingParams( temperature=0.0, max_tokens=4096, ) prompts = [] questions = [ "证明：对所有正整数 n，分数 (21n+4)/(14n+3) 是最简分数。", "求方程 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是控制生成的核心参数。temperature=0.0表示贪心解码，适合追求稳定性的评测。如果希望增加结果多样性，可以改成temperature=0.6, top_p=0.95, max_tokens=4096。

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, flags=re.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 等证明助手形式化验证；
• 将模型证明的关键步骤转为可执行代码，再用单元测试验证。

在我自己的项目里，比较推荐的方法是“自动抽答案 + 人工核验关键步骤”：

1. 先用脚本批量跑题；
2. 自动抽取\boxed{}并计算答案级正确率；
3. 对答案正确的样本再做证明抽查；
4. 将错误证明按错误类型分类：计算错误、逻辑跳步、条件遗漏、结论幻觉。

这套流程能最大化节省人工时间，同时避免被“答案对了但证明错了”误导。

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，分数 (21n+4)/(14n+3) 是最简分数。" } ], "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_url="http://127.0.0.1:8000/v1", api_key="EMPTY", # 本地服务不需要真实 key ) resp = client.chat.completions.create( model="dots3-note", messages=[ { "role": "user", "content": "证明：对所有正整数 n，分数 (21n+4)/(14n+3) 是最简分数。" } ], temperature=0, max_tokens=4096, ) print(resp.choices[0].message.content)

运行：

python client_demo.py

把 HTTP 服务跑起来之后，前端、后端、自动化脚本都可以通过同一个接口调用模型，业务层不需要关心模型权重和推理细节。

7. 常见问题与排查思路

本地部署大模型的过程中，一定会遇到各种环境问题。下面整理几个高频场景。

7.1 常见问题速查表

7.2 模型输出空内容的排查顺序

如果模型生成结束后返回空字符串，按以下顺序排查：

1. 检查skip_special_tokens=True是否误删了正文；
2. 检查inputs["input_ids"]切片是否正确，防止把输入部分也算进去；
3. 临时输出outputs[0]的 shape，确认是否有 token 生成；
4. 把max_new_tokens调大，看是不是模型还没来得及输出就被截断；
5. 用官方仓库提供的 demo 脚本对比，排除模型加载方式问题。

7.3 显存不足的几种降级方案

显存不足是最常见的 GPU 问题，尤其是本地开发机。降级方案可以按顺序尝试：

第一，使用量化加载。Transformers 原生支持bitsandbytes，可以在加载时启用 4bit 量化：

from transformers import BitsAndBytesConfig quantization_config = BitsAndBytesConfig( load_in_4bit=True, bnb_4bit_compute_dtype=torch.bfloat16 ) model = AutoModelForCausalLM.from_pretrained( MODEL_PATH, quantization_config=quantization_config, device_map="auto", trust_remote_code=True )

第二，缩小单次推理的最大长度。数学推理虽然长，但 4096 token 不一定每次都需要，按任务粒度动态设置长度能节省显存。

第三，切换到更小的同系列模型。如果官方发布了不同规格的版本，优先选择 7B 或 14B 规模；如果只能跑超大模型，也可以考虑把量化后的模型放到多张 GPU 上。

第四，使用 CPU 慢速推理。这个方法只适合验证“模型能不能跑”，不适合生产。

8. 最佳实践与工程建议

模型部署成功只是第一步。如果要真正把数学推理模型用到评测或业务中，下面这些工程经验值得提前注意。

8.1 建立可复现的评测基线

跑数学题的时候，一定要先把评测条件固定下来：

• 固定 prompt 模板；
• 固定解码参数，评测时建议temperature=0；
• 固定模型版本，记录模型 commit hash；
• 固定随机种子；
• 保存每道题的完整输入和原始输出，而不是只保存最终分数。

可复现是数学评测的生命线。如果每次跑题结果都不一样，后续的微调、量化、蒸馏优化都无从谈起。

8.2 统一输出格式

不管是人工分析还是自动裁判，混乱的输出格式都会显著增加成本。建议在 prompt 中显式要求模型按照规范格式输出：

• 关键结论放在\boxed{}中；
• 证明按步骤编号；
• 不要省略关键推导；
• 如果有多个解，需要说明解集。

统一格式之后，可以降低自动抽取的失败率，评测管道也会更稳定。

8.3 量化与精度取舍

4bit 量化可以让大模型在更小的显存上运行，但量化会引入精度损失。对于数学推理任务，这种损失有时比普通问答更明显，因为长链路推理中的任何一步误差都可能被逐步放大。

我的建议是：

• 日常验证流程先使用 bfloat16；
• 只有在显存成为瓶颈时才考虑 8bit；
• 4bit 量化之后，必须重新跑一遍基础评测题，观察分数是否明显下降；
• 涉及高精度符号计算时，尽量保持更高的数值精度。

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 脚本中。

第四步，如果手头显存不足，再做量化和蒸馏实验，重点观察量化前后准确率变化。

第五步，研究模型的错误样本。数学推理模型的每一次错误都是一次难得的分析机会：模型是在哪一步开始偏离正确方向的？是计算错误，还是逻辑假设出了问题？这些分析远比“刷一个更高