Benchmark保留率高，就代表模型真的好用吗？从DeepSeek-R1蒸馏模型看公开测评与业务选型的差距

本文基于DeepSeek官方模型卡和公开论文进行资料分析，不包含147AI自有测试。文中模型成绩均为DeepSeek官方报告结果，不是独立复测。资料查阅日期为2026年8月3日。

如果一款蒸馏模型在公开测试中拿到了教师模型95%的分数，我们能不能说，它保留了教师95%的能力？

这个说法很顺口，也很容易被记住。问题是，95%后面省略了最重要的部分：在哪套题上，用什么提示词和生成参数，以什么方式评分？

拿DeepSeek-R1-Distill-Qwen-32B来说。按照DeepSeek官方模型卡的数据，它在MATH-500上得到94.3分，DeepSeek-R1是97.3分。两者相除，得到约96.9%。如果只看这项数学测试，“保留率接近97%”在算术上没有错。

换到LiveCodeBench，两个模型的分数分别是57.2和65.9，单项得分比例约为86.8%。到了GPQA Diamond，这个比例约为86.9%。还是同一个学生模型和教师模型，换一项测试，比例就变了。

先说结论：“Benchmark保留率”不是通行的标准化学术指标，也不是模型自带的固定属性。本文保留这个说法，是为了讨论它为什么容易让人误判；后文将其称为“本文试算的单项得分比例”。它不能表示模型保留了多少完整能力，也不适合跨Benchmark求简单平均。

Benchmark测量的到底是什么

Benchmark通常译作基准测试。一套严谨的Benchmark有相对固定的测试数据、运行方法和评分规则，和随手找几道题试模型不是一回事。

Benchmark = 测试数据 + 测试流程 + 评分规则

例如，AIME 2024来自美国数学邀请赛，主要考查竞赛数学推理；MATH-500是一组数学问题；GPQA Diamond聚焦难度较高的研究生水平科学问答；LiveCodeBench则持续收集较新的编程题，并用测试用例等方式评价代码能力。

这些测试的价值很实在。不同模型回答同一批题，接受同一套评分，至少比“我随便问了三个问题，感觉这个模型更聪明”可靠得多。研发团队可以用它们筛掉明显不合适的模型，也能观察模型升级前后的变化。

本文试算的单项得分比例，计算方式是：

本文试算的单项得分比例
= 学生模型在某项Benchmark中的得分
÷ 教师模型在同项、同协议Benchmark中的得分
× 100%

这里有两个不能省略的前提：同一项测试，评测协议可比。AIME 2024和AIME 2025不能直接混算，pass@1和pass@64也不是同一个指标。提示词、采样温度、最大输出长度不同，最终分数可能随之变化。

这个比例偶尔还会超过100%。它只表示学生模型在该项测试中的报告分数高于教师模型，不表示学生模型的整体能力已经超过教师。不同Benchmark的量纲、难度、判分方式和分数分布也不同，把几项比例再算一个平均数不会得到可靠的“总能力保留率”。

DeepSeek-R1蒸馏模型的公开成绩有多高

DeepSeek使用R1生成的样本微调了六个较小的稠密模型，参数规模覆盖1.5B、7B、8B、14B、32B和70B。它们基于Qwen2.5或Llama 3系列模型继续训练。其中，R1-Distill-Qwen-7B的底座是Qwen2.5-Math-7B，而不是名称相近的Qwen2.5-7B-Instruct。

下面摘取DeepSeek官方模型卡中的四项结果，只保留R1和三个Qwen蒸馏模型。R1与蒸馏模型分别来自官方评测中的主模型表和蒸馏模型表：

数据来源：DeepSeek-R1官方模型卡，查阅于2026年8月3日。模型卡是动态页面，后续可能更新。上表是官方报告中两张表的并列展示，不是本文复测，也不是147AI的API测试结果，更不能视为同一环境下完成的独立配对实验。

这组结果解释了R1蒸馏模型为什么受到关注。7B模型在MATH-500上的官方报告分数已经达到92.8，14B和32B更高。DeepSeek-R1论文也讨论了用大模型生成的推理样本增强小模型的方法。

为了看清同一个比值会怎样改变直觉，下面用R1作为分母做一次试算。每个单元格同时列出“单项得分比例”和学生模型相对R1的绝对分差：

这些比例由本文根据官方分数计算，不是DeepSeek发布的统一指标。同一个7B模型，在MATH-500上的比例是95.4%，到了LiveCodeBench只有57.1%。两项都没有算错，差别来自测试内容。

接近满分时，比例还会受到天花板效应影响。以MATH-500为例，32B模型和R1的绝对分差是3.0分，看起来不大；如果以100分为满分换算未通过比例，则分别是5.7%和2.7%，前者约为后者的2.1倍。这个数字只描述该项官方测试分数的另一种观察角度，不能直接推导成生产环境中的失败率。它提醒我们：只看96.9%这个比值，容易低估高分区间内的差异。

这里没有给出置信区间。公开表格只提供聚合分数，而pass@1又来自多次采样估计；缺少逐题结果、配对记录和完整运行日志时，硬算一个区间反而会制造虚假的精确感。后续如果做独立复测，应保存逐题输出，并报告样本量、置信区间或配对差异。

公开分数还有自己的运行语境。DeepSeek-R1论文写明，评测时最大生成长度设为32,768 Token，采样温度为0.6，top_p=0.95。AIME和GPQA每题采样64次，MATH和CodeForces采样16次，LiveCodeBench采样8次，再用多次结果估计pass@1。官方使用建议也提到，评测模型时应多次测试并取平均值。

本文查阅的是DeepSeek-R1论文arXiv v2，修订于2026年1月4日；该论文另有2025年发表于《Nature》的版本。若企业调用API时限制较短输出，使用不同提示词，或者要求模型一次生成就稳定返回结构化结果，实际场景已经和官方评测不同。这不削弱官方成绩，只是划出了它能够支持的结论范围。

为什么公开高分不等于业务已经可用

模型进入业务系统后，问题会变得琐碎，甚至有些无聊。生产事故却经常藏在这些地方。

假设任务是从售后工单里抽取订单号、问题类型和退款意向。模型把三个值都找对了，却在JSON前写了一句“以下是提取结果”，或者给输出套上Markdown代码围栏。人能看懂，下游解析器可能直接报错。标准数学题不会测到这种失败。

再看知识库问答。一个回答可能符合常识，读起来也很流畅，但材料里根本没有这条信息。通用知识测试会奖励答对的事实，企业场景有时正好相反：材料没有答案，就应该明确说不知道。

SQL生成也一样。语法正确只说明数据库能运行，查询条件写错、漏掉空值或者把LEFT JOIN写成INNER JOIN，返回的仍然可能是一张看似正常的表。业务需要检查结果，而不是只看代码像不像SQL。

这些例子指向几类公开推理榜单通常不会完整覆盖的指标：

• 输出格式能否直接被程序解析；
• 回答是否严格受给定材料约束；
• 同一个请求重复运行时，成功和失败会不会来回波动；
• 模型是否遵守长度、字段、语言和工具调用约束。

模型能力之外还有服务层。真实API会遇到超时、限流、排队和上游切换。模型权重相同，部署硬件、量化方式、路由策略和版本更新也会改变用户实际拿到的结果。因此，“这个模型得分多少”和“这个API在我的生产环境里表现怎样”应该分开记录。

2026年的预印本UniComp提供了一个相关旁证。该研究比较了剪枝、量化和蒸馏等六种压缩技术，覆盖40个数据集。作者报告，压缩后的事实记忆、推理、多语言和指令遵循能力并不同步变化，性能与可靠性也可能分离。

截至2026年8月3日，本文查阅的是UniComp的arXiv v5，修订于2026年5月23日。它不是DeepSeek-R1的中文生产部署研究，也没有覆盖所有代码生成、多智能体和企业工作流。因此，它只能支持“压缩模型需要多维评测”这一判断，不能证明某个具体蒸馏模型一定会发生同样的退化，更不能替代业务测试。

企业选模型时，应该怎样使用Benchmark

我更愿意把公开Benchmark当成筛选工具，而不是采购结论。一套相对稳妥的流程可以分成四步。

第一步是用公开榜单缩小范围，同时保留业务当前方案作为基线。这个基线不一定是大模型，也可能是现用模型、规则系统、RAG方案或一个更便宜的小模型。没有基线，“新模型提高了多少”就无从判断。

第二步是做探索性试测。30到100条经过人工检查、覆盖常见失败边界的任务，通常足以暴露一些明显问题，例如JSON频繁解析失败或材料外信息过多。但这批样本不能用来证明真实失败率很低，更不能单独支撑采购或上线决定。客户信息要先脱敏，标准答案和成功条件则要在测试前定好。

第三步才是正式评估。样本应按业务类型、难度、语言、输入长度和高风险边界分层，调试提示词使用的样本不能再充当最终测试集。训练集、验证集和测试集要独立划分，并做去重和污染检查。主观题可以采用盲评或双人复核；可以按统计方法计算的指标，应同时报告样本量和置信区间。医疗、金融、权限操作等高风险场景还需要专项红队测试和固定回归集。

第四步是灰度上线和持续监控。每次测试都要冻结或记录模型ID、上游服务商、量化方式、路由策略、提示词、生成参数和评测时间。否则，即使模型名称没变，下一次结果也未必可复现。灰度阶段还应预先设置回滚条件，避免发现异常后才临时讨论什么叫“不合格”。

一张业务选型表，可以这样设计：

Token单价之外，成本应该怎样算

模型页面上的Token单价只是请求价格。如果一个便宜模型经常输出错误格式，需要重试或人工修改，最终成本会被抬高。可以先计算每千次自动完成任务的API成本：

每千次自动完成任务的API成本
= 全部API调用费用（包含失败调用与重试）
÷ 无需人工修正且达到成功标准的任务数
× 1000

如果分母为零，这项指标应标记为“不可用”，不能继续拿它和其他模型比较。同时记录首次成功率和重试后成功率，才能看出费用究竟花在正常调用还是补救失败上。

人工复核与返工成本应该单列，不能藏进Token费用。若比较对象还包括自行蒸馏或私有化部署方案，则要另外核算训练、硬件、部署、监控和运维成本。把这些数字拆开，通常比强行合成一个总分更容易发现问题。

关于147AI

我们在帮助用户接入不同模型时，经常遇到类似问题：榜单分数很高，接入实际流程后却未必合适。因此，这篇文章没有替读者给出一个统一答案。更稳妥的办法，是先用公开Benchmark缩小范围，再用自己的提示词、输出格式和任务标准做验证。需要比较不同模型时，可以在147AI查看当前可用模型和接口信息。

参考资料

1. DeepSeek-AI，DeepSeek-R1官方模型卡，查阅于2026年8月3日。本文模型分数、底座信息及官方评测设置据此整理；该页面可能动态更新。
2. DeepSeek-AI, DeepSeek-R1: Incentivizing Reasoning Capability in LLMs via Reinforcement Learning, arXiv v2, 2026年1月4日修订；另见《Nature》645卷，633–638页，2025年。
3. Jonathan von Rad et al., UniComp: A Unified Evaluation of Large Language Model Compression via Pruning, Quantization and Distillation, arXiv v5, 2026年5月23日修订。本文将其作为预印本旁证使用。
4. Naman Jain et al., LiveCodeBench: Holistic and Contamination Free Evaluation of Large Language Models for Code, 2024，查阅于2026年8月3日。