模型评测体系与推理系统优化：怎么知道模型真的强、怎么让它又快又省

前半讲如何严谨评测模型（能力维度、基准、数据污染、人工与模型裁判的风险），后半讲推理部署侧的核心优化：量化、蒸馏、投机解码、连续批处理与 KV Cache 管理，建立「训得好」还要「用得起」的系统观

评测：比「跑个分」严肃得多

模型能力是多维的：知识、推理、代码、数学、指令遵循、长文本、多语言、安全、工具调用……没有任何单一分数能概括。严谨评测要按维度选基准（Benchmark），用独立、未被训练见过的题，并报告多个指标与失败案例，而不是只挑一个最好看的数字。

四类互补的评测手段

客观基准

有标准答案的题集，自动判分，覆盖知识/推理/代码/数学等维度

人工偏好评测

盲评、成对比较，衡量主观质量，成本高但接近真实体验

模型当裁判

用强模型给回答打分，便宜可规模化，但有偏见、可被钻空子，需校准

真实任务/在线评测

在真实业务与 A/B 中看完成率、用户反馈，最贴近落地价值

🚫数据污染：榜单虚高的头号原因

如果评测题在预训练语料里出现过，模型可能是「背答案」而非真会。要检测污染、使用最新或私有构造的题、做扰动变体。同理，针对某个榜单反复调参会过拟合该榜单。看到分数先问：题是否见过、是否多维度、是否有失败分析。

上下文窗口变长不等于真能用好长文本。要分别测： needles 类信息检索（长文里找关键句）、多跳推理（跨文档整合）、首尾与中段的位置利用率、以及长文本下的稳定性。常见现象是「中间遗忘」——模型对开头结尾敏感、忽略中段。评测长上下文必须把关键信息放在不同位置，而不是只测最大长度。

训练出模型只是开始，真正服务用户要在有限显卡上追求高吞吐、低延迟、可接受成本。推理瓶颈主要是显存带宽、显存容量和计算，主流优化各打一个点：

推理系统六大优化杠杆

量化

把权重从 FP16 压到 INT8/INT4，省显存、提速，精度损失要评估

蒸馏

用大模型教小模型，缩小体积、降低部署成本

投机解码

小模型快速起草、大模型并行校验，几乎不掉质的提速

连续批处理

动态拼批、不空等最慢请求，显著提升 GPU 吞吐

PagedAttention

像操作系统管内存一样分页管理 KV Cache，减少显存碎片

KV Cache 优化

量化/驱逐/共享前缀缓存，压低长对话显存占用

推理三要素相互制约，需要按业务权衡

显存容量

能同时装下权重与多少并发会话的 KV

吞吐

单位时间服务多少请求/ token

延迟

首 token 时间与生成速度，决定体验

结果回流，持续迭代（回到第一步循环）

批更大吞吐高但单请求延迟升；量化省成本但要盯质量

🐍评测与系统是专家分水岭

初级工程师盯着模型分数和「能不能跑」，专家会同时追问：这个分数可不可信（污染/维度/失败案例），以及这套效果在目标硬件和并发下要花多少钱、延迟多少。能力与成本必须一起评估，才是能落地的工程判断。

选择题

某模型在公开榜单上分数极高，但上线后真实任务表现一般，最需要优先排查的是？

底层原理 · 大厂视角 · 工程经验，点卡片展开

先查数据：标签是否正确、有没有特征和标签泄漏、是否做了归一化；再查损失与学习率：学习率太大震荡、太小几乎不动；接着看批量大小和优化器，最后才怀疑模型结构。一个极好用的冒烟测试是：用极少量样本训练，看损失能不能被压到接近零——能，说明整条代码链路是通的；不能，问题一定在实现里，先别谈调参。