27B本地大模型选型评测：一套可复现的验证方法

背景：公开数据还没有被复现

据公开报道，一款27B参数的本地Dense模型在综合智能指数上约为52分，在Agent指数上为51分。报道中的对照组包括一款云端Flash模型、一款国际领先模型，以及一款云端Pro模型和一款国产主流模型，后两者约为53分。报道还提到，测试期间模型输出了约1.6亿Token。

这些数字有几处无法核实。报道没有给出模型的完整名称和版本，没有公开测试集和评分脚本，没有标注推理档位（超高思考强度、中等或关闭思考），也没有说明Token的统计口径。因此，本文不判断“追平”是否成立。本文要做的是说明：如果要自己验证，应该怎么做，哪些结论可以采信，哪些暂时不能采信。

第一步：记录可复现的信息

跑分只有在测试条件被完整记录后才有参考价值。每次评测至少记录下面几类信息。

类别	需要记录的字段	说明
模型	完整名称、版本、权重来源、文件校验哈希	以模型发布页为准
量化	精度与量化方法	例如BF16、INT8、AWQ 4-bit
推理框架	框架名称、版本、服务启动参数	每次升级框架都要重新记录
推理参数	推理档位、temperature、top_p、max_tokens、seed	每个档位单独记录一套
上下文	最大上下文长度、系统提示词	所有对照模型保持一致
测试集	名称、版本、题目数量、评分脚本版本	公开集或内部集都要注明
硬件	GPU型号、显存、数量、驱动与CUDA版本	单卡与多卡结果不能直接比较

另外，云端模型可能在后台更新。对比时要记录测试日期和接口返回的模型标识，否则结果无法复现。

第二步：搭建测试环境

显存需求可以先做粗略估算。27B参数的模型，BF16权重约占54GB显存（27×10⁹参数 × 每参数2字节）。INT4量化后权重约占14GB。实际占用还要加上KV Cache和运行时开销，上下文越长，KV Cache占用越多。

以下是使用vLLM启动服务的示例。模型路径需要替换为实际路径。

vllm serve /models/your-27b-model \
  --served-model-name local-27b \
  --max-model-len 32768 \
  --gpu-memory-utilization 0.90 \
  --max-num-seqs 64 \
  --tensor-parallel-size 1

推理档位的开关方式由模型自身决定，需要按模型文档设置。本文不假设具体的参数名。

测试客户端建议走OpenAI兼容接口，并固定随机参数：

resp = client.chat.completions.create(
    model="local-27b",
    messages=messages,
    temperature=0.0,
    top_p=1.0,
    max_tokens=8192,
    seed=42,
)
completion_tokens = resp.usage.completion_tokens
finish_reason = resp.choices[0].finish_reason

即使temperature设为0，批处理等因素仍可能让输出有细微差异，所以每题需要多次运行。

第三步：能力测试，不要依赖单次跑分

能力测试建议覆盖以下维度：数学计算、代码补全、常识推理，以及指令遵循。指令遵循题可以用程序判断结果，例如字数限制、JSON结构、指定格式等。

有三条规则需要遵守。

1. 每道题至少运行3次，记录均值和标准差。
2. 每个推理档位单独出分，不要混在一起算。
3. 比较分数时计算置信区间。以准确率约50%、100道题为例，单次准确率的标准误约为5个百分点。这意味着，在这种规模下，相差1分的两个模型无法区分。文中“差1分”的说法，在大多数测试规模下都处于统计噪声范围内。

agent-">第四步：Agent能力沙箱测试

Agent测试需要一个确定性的工具沙箱。可以模拟天气查询、数据库检索和代码执行三类工具。每个工具返回固定结果，便于复跑。

任务设计为3到6步的连续操作。例如：查询某城市天气，根据结果在数据库中检索用户偏好，生成一段统计代码并执行，最后输出报告。

测试时要记录以下指标。

• 任务在第几步中断，失败原因是什么。
• 工具调用参数是否符合JSON Schema。
• 收到错误信息后能否修正，修正了几次。
• 是否编造了工具没有返回的结果。
• 任务最终完成率。

为了测试异常恢复能力，可以在沙箱中随机注入超时、字段缺失和权限错误。注入比例和随机种子也要记录。

第五步：长文本退化检测

报道中的1.6亿Token提示，