识破小模型的夸大性能宣传

一句话总结

将模型文件大小和执行性能分开，明确库存部署依据的范围。

为什么需要这个？

看到缩小的模型，报告说“内存也减少了，无论在哪里都更快了”，会失去什么呢？文件是磁盘的字节数，运行进程中也包含Python·推理引擎·工作缓冲区。在部署判断中，不仅需要准确性，还需要在什么环境中测量什么。这个练习不是保证量子化胜利的比赛，而是根据证据决定部署与否的练习。

怎么行动

提供的bench.py只测量模型加载和输入准备的时间，然后调用engine.run。因此，报告的延迟不是网络请求的总响应时间。CPU推理线程固定为1个，在独立进程3轮中，每个批次大小在热启动10次后测量100次。批次大小为1和32。模型运行顺序也每轮轮换。测量值为微秒/批次，每个批次还剩300个原始时间。

实现latency_stats(samples_us, batch_size)时，p50是排序样本的中位数，p95是nearest-rank方式的ceil(0.95×n)第1个值。Python索引在这里减去1。奇数样本的中位数是中间两个数的平均值。不平均每个轮次的p95，将原始样本相加后重新计算。处理量为batch_size×n×1,000,000/sum(samples_us)。将批次32的时间直接反转为每秒请求次数，图像数量会增加32倍。

内存将Linux /proc/self/status的VmHWM转换为字节进行记录。这是整个测量过程的最高驻留内存，不是仅限于模型的内存，也不是GPU内存。在本开发容器的一个测量中，即使模型文件从约70KB减少到24KB，进程HWM也保持在约62MB左右。时间因共享CPU负载、命令集、运行时等而异，因此不将该数字固定为评分正确答案。

benchmark.json同时记录模型和数据的SHA-256。如果重新转换了模型，也需要重新测量。哈希连接和统计检查可以发现旧报告或计算错误，但不是证明学生没有亲自编造和填写的设备。原始样本是可审查的实验记录，不是防伪认证书。

在实际审查会议上提出的问题

在问“它变得有多快？”之前，请先问“它从哪里开始到哪里结束？”。读取文件和加载模型的cold start以及已经准备好的会话的run调用是用户经历的其他情况。与每天打开一次应用程序的人一样，继续处理视频的设备的会话是不同的重要指标。这次练习测量后者的一部分，即准备好的CPU推理，不包括网络、图像预处理、结果传递延迟。

如果三个轮次的p95分别是10、20、100，那么平均43.3可以作为整个p95吗？百分位数由数据数量和顺序决定。三个轮次摘要无法恢复有多少个样本在哪个轮次比较慢。所以助手会保留所有原始时间，重新排序学生函数的总和300个。相反，如果放弃整个原始时间，只保存摘要，就没有理由重新审查异常值了。

请计算一下带有单位的手计算。如果排列大小为32，重复300次，图像总共9600个。如果时间总和为3000000微秒，则为3秒，所以处理量为3200个/秒。如果把排列呼叫次数用分母表示，则为100次/秒，但这个值本身并不错误。错误在于把它命名为图像处理量。报告的键和单位必须固定计算式的含义。

平均情况下，即使很短，也很罕见出现长延迟的模型可能不适合有截止日期的工作。但是，这个练习的p95并不保证硬实时上限。还有尚未观察到的故障或设备条件。电力、热量、长时间稳定性也需要单独的测试。将target_benchmark_required留为true并不是为了完成工作更少，而是准确地跳过无法通过这次证据主张的部分的交接。

最后，在重新转换模型时，请写下需要重新做什么。不仅要重新写哈希值，还要重新运行推理回归和测量。如果将新文件的哈希值粘贴到旧时间样本上，即使连接格式正确，实验记录也是假的。自动评分不能监控所有行为。在实际工作中，留下重现脚本、原始结果和执行条件，让同事以同样的方式重新确认是实践的基本。

下次实习要做的事情

在第7阶段实现统计函数，并运行提供测量助手。第8阶段的release.json记录了该实验的部署条件，即模型文件小于32KiB，精度损失小于1%p。这并不意味着整个过程都在32KiB内完成。target_benchmark_required为true，universally_faster为false。实际设备的延迟、内存、电力验证另行留待。练习结束前请保留源代码和报告。会话结束后工作文件将不会被保留。