可重複的 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 可作個人參考偏好，並非所有付費雲端模型或方案的已驗證保證。