端侧选型别只看跑分：把延迟和内存做成可对比的两列｜洹拓科技
一、把延迟和内存并排，是把选型从跑分拉回目标硬件
一家 IP 厂商的平台入口把针对该平台优化的模型、代码、工作流和学习路径四类资产放在一起，公开报道里被强调的差异点，是它把不同模型之间的延迟与内存占用做成可直观对比。我们不复述它的产品名，也不引用它给出的任何数值档位，值得抄的是这个动作本身：把选型口径显性化。
端侧选型长期被公开跑分绑架，原因很朴素，跑分是唯一能横向拿到的数。可跑分是在别人的硬件、别人的推理后端、别人的序列长度上测出来的，四个变量里有三个和你的目标设备无关。厂商愿意在自己的入口里把延迟与内存两列并排摆出来，等于承认了另一件事：这些数字只有在指定硬件上才有意义。这对交付方是好事，对客户也是好事，因为它把“这个模型能不能跑”这种含糊问题，变成了“在你这台机器上、这个精度下、这么长的上下文里，P95 是多少毫秒、峰值内存是多少”这种可验收问题。区别在于后者能被反驳，前者只能被相信。
二、五个口径问题，每一个都能让结论翻转
同一张对比表要读得可信，得先回答五个问题。下面这五行我们直接抄进选型评审记录，缺一行就不签字。
| 口径问题 | 为什么必须问 | 口径不一致时结论怎么翻转 |
|---|---|---|
| 在什么批处理长度与序列长度下测的 | 端侧的算力与内存带宽随序列长度变化明显，批大小从一往上加时延迟并非线性 | 只标最小批量、短序列的结果，被拿来支撑长对话与长文档场景 |
| 延迟指首个词元的时延还是端到端 | 交互场景在意第一个字出现的时间，批量任务在意单位时间产出多少 | 两种口径能差一个数量级，混用时最快的那个其实最慢 |
| 内存指权重占用还是含运行时峰值 | 权重是可以直接读出来的，激活、缓存与分配器留白只有在真实负载上才看得见 | 只报权重的方案在低配机型上会跑到一半被系统回收进程 |
| 量化精度是哪一档 | 位宽、分组粒度与敏感层的保留策略各不相同，精度与内存同时被这一档决定 | 拿更低位宽的结果和更高位宽的结果对比，等于什么都没比 |
| 后端是哪一个 | 同一模型在中央处理器、图形处理器与神经网络处理器上的差异很大，且存在算子不支持而回退的情况 | 只报表现最好的那个后端，真实部署时拿不到那个数 |
五个问题里最容易被动过手脚的是第二个和第三个，因为它们的措辞在材料里经常只写“延迟”和“内存”两个词，不写定义。读到光秃秃的两个词，就把这张表当作未提供数据。
三、优化版和开源版是两个条目，不是同一个
厂商优化版与官方开源版必须当成两个资产分别管理。优化通常意味着算子替换、图结构重写、权重换算，有时还带一次精度回退。这带来两条完全不同的排查路径：官方开源版出问题，可以对着上游仓库与已知问题单做二分；优化版出问题，要在转换工具链、算子覆盖清单与运行时三层之间找，而这三层往往不是同一个团队维护，也没有同一套日志。
分开管理要落到四件具体的事上。标识与命名空间分开，不允许两个版本共用一个模型名。权重文件的哈希与来源逐次记录，替换文件时能立刻发现版本串了。版本对应关系成对记录，写清哪个上游版本对应哪个优化版本，缺一侧就是隐患。精度差异要有基线，同一评测集在两个版本上各跑一次，把差值留档，出现精度回退时不需要临时补课。我们见过的端侧事故里，相当一部分不是模型不行，而是现场跑的那个版本没人知道是哪一个。
四、最小选型表：候选模型乘口径乘业务指标
结构很朴素，行是候选模型，列分成两组。第一组是上面那五个口径，每个口径一格。第二组是三项业务指标：该任务上的准确率、业务可接受的延迟上限、可用内存预算。三组列交叉之后，这张表能直接读出“哪个候选在哪个约束下出局”，而不是一堆各自漂亮的数字。
关键是每一格都要有来源，不接受“官方声称”这种写法。来源分三类并打上不同标记：我们自测的、厂商入口给出的、二手材料转述的，可信度按这个顺序递减。空格不允许存在，没有数据就写“未测”并挂上责任人与补测动作，因为空白的格子在评审会上一定会被口头补上，而口头补上的内容不留痕迹。再加一列“谁复核过”，一格数据由第二个人复跑过一次，这张表才有对外说话的资格。
五、自己复现的三步，和三类常见误判
别人的表再整齐也是别人的，要变成自己的结论只需三步。
- 固定一台目标机型与温度条件。写清机型档位、内存配置、设备起始温度与散热结构，同名不同散热设计的机器结果差得很远。
- 用自家真实数据分布做输入，不用通用样例。长度分布、语言混合比例、多轮占比这三项要和线上对得上，否则测的是别人的负载。
- 记录运行时峰值而不是标称值。采样要覆盖加载阶段与稳态阶段，并且分列，因为系统回收进程看的是峰值。
三类误判几乎每个项目都会撞上，各给一条对策。满电与低电状态下结果不同，供电策略会随电量收紧频率上限，对策是把电量区间写进测试条件，或者两档分别记录。忽略持续负载下的降频，短时跑分好看、热平衡之后才见真相，对策是连续跑若干个会话之后取稳态延迟，而不是取最快一次的单次结果。把首次加载耗时算进交互延迟，会让冷启动好看或难看都由运气决定，对策是首帧加载与稳态推理分列，冷启动单独作为一项验收指标，别混进平均值。
六、两类资产的权重、可审计的选择，以及一句完整话术
工作流与学习路径这两类资产常被当作附加说明，实际它们决定接入工时与可维护性，因此要在选型评审里给权重。看三件事：是否有可编译的参考工程，能编译不等于能跑，但连编译示例都没有的入口，接入成本几乎全部落在你身上；是否有算子覆盖清单，写清哪些算子原生支持、哪些需要回退；是否有已知不支持的算子列表，一份诚实的不支持清单比一句全面支持可信得多。这三条不占性能预算，却直接决定三个月后谁来维护这套东西。
再说智能体入口这个说法的工程含义。当“选哪个模型”这件事本身交给一个程序去做，就必须要求它输出选择理由与所用口径，否则选型退化成不可审计的黑箱，事后没人能回答“当初为什么不选另一个”。要落盘的字段是候选集、被排除项与排除依据、所用口径、当时可见数据的来源与时间标识。把选型当成一次决策记录来留证，和给智能体配台账是同一件事。
最后给交付方一句必须照抄的话术：端侧可行性的结论必须写成“在某机型、某精度、某上下文长度、某延迟定义下的 P50 与 P95 延迟和峰值内存”这一整句，缺任何一项就不给可行性结论，宁可回一句未测。洹拓内部把这句话当作端侧评审的格式要求，写不出完整一句的结论一律退回。格式听起来是小事，但只有写成这一整句，客户才会发现有多少格是空的，也才会把补测的预算批下来。