可重复的 1／2／3-job 测试，以及说明哪些工作仍然流畅的报告。
01／高总吞吐量可能掩盖慢 job
假设三个重叠 job，在同一段 10 秒内各生成 200 tokens，总吞吐量是每秒 60 tokens，但每个 job 平均只有 20。这是示意计算，并非 TokFire 成绩。总数说明电脑处理了多少工作；单个 job 的速度更接近一位读者的体验。
记录首个 token 等待时间、完成延迟、每 job 生成速度及任务成功率。工具 agent 还要核对所需工具及最终事实。任务失败时，即使生成速度很高，仍然是失败。
02／运行受控并发测试
在 TokFire Bench 选择一个支持的模型及运行环境，再选接近实际用途的工作负载。先跑一个 job，再选两个及三个并发 job。它们是调用同一模型的独立任务，而非同时加载不同模型。保持模型、上下文、输出上限及工作负载一致。
每组先预热一次，再至少测量三轮。电源模式及后台活动保持一致，失败测试也要保存。记录服务器 slot 和上下文设置；启动三个客户端，不代表后端真的同时处理三段生成。
03／弄清楚正在测试哪项优化
连续批处理让服务端结合多个活跃请求的工作，有机会提升资源利用率，但共享运算及内存仍会限制单个响应。提示缓存则重用相同前缀，主要减少重复读取提示的工作；冷提示及缓存提示应分开比较。
推测解码会先提出候选 token，再由目标模型验证。支持 MTP 的检查点在兼容运行环境中可提供另一种起草路径。收益取决于接受率、额外工作及内存，并非固定倍数。先保存未启用的基准，再以相同工作负载比较，并记录完整运行参数。
04／评估用途，而不只评估电脑
结果表应包含：job 数、完成／尝试任务数、首 token 等待中位数、完成时间中位数及最慢值、每 job 速度、总吞吐量、峰值内存及验证失败。样本很少时，列最慢一轮，比声称有稳定的 p95 更合适。
先定验收标准才测试。例如前台助手需要较短首次等待；后台报告则可接受较长时间，但事实必须正确。这些门槛应标示为自己的目标。每秒 100–200 tokens 可作个人参考偏好，并非所有付费云端模型或方案的已验证保证。