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

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

为什么「跑分高」不能直接信？首先，模型可能在训练时见过这些题——评测集一旦公开，很快就会被爬进预训练语料，模型是背答案而不是真会。其次，单一榜单只测一个侧面：数学满分的模型可能写不通顺的邮件、也可能在该拒答时拒答得很僵硬。再加上「模型当裁判」本身有偏向——它偏爱和自己风格相似的回答、偏爱长回答，这些都需要用人工盲评校准。所以资深工程师看一个模型发布，第一眼不是看总分，而是问：题目新不新、有没有污染、覆盖了哪几个维度、有没有把做错的题拿出来分析。分数只是入口，失败案例才藏着真实能力的边界。

长上下文不是「能塞下」就算

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

为什么要特意提醒「中间遗忘」？因为很多模型在短文本上表现很好，一拉长就暴露问题：它记得开头和结尾，却把塞在正中间的关键信息漏掉了。如果评测只在文档末尾放一句关键句再提问，得到的分数是虚高的——真实使用中用户随便贴一大段文档，关键信息可能落在任何位置。所以长上下文评测有个朴素但关键的做法：把那句「针」故意埋在文档的开头、四分之一、中间、四分之三、结尾，分别测能不能捞出来。位置一换就答不对，说明模型并没有真正「读懂」长文，只是在靠首尾的表面线索答题。这种细节上的较真，才是区分「看起来支持长上下文」和「真的能用长上下文」的关键。

推理优化：让模型又快又省地服务

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

推理和训练的瓶颈很不一样。训练要算梯度、存优化器状态，重计算；推理只是前向一遍，瓶颈往往变成「把权重从显存搬到计算单元」这件事——也就是显存带宽。每生成一个 token，都要把整层权重读一遍，词一多就卡在搬数据上。这就是为什么量化在推理阶段特别值钱：权重从 16bit 压到 4bit，要搬的数据直接减到四分之一，速度立刻上来，而精度损失往往小到用户无感。投机解码利用了「小模型快但糙、大模型慢但准」的不对称：让一个小模型先飞快地草拟几个词，大模型一次性并行校验，对就直接采用，错才回退——几乎不掉质却快很多。连续批处理则解决 GPU 空等：把不同用户的请求动态拼成一批，不让显卡在等某个慢请求时空转。这些手段的共同目标，都是让有限的显卡同时服务更多人、每个人等得更短。