推論吞吐量

吞吐量是你每單位時間能處理多少輸入——每秒影像數、影片的每秒影格數（FPS），或伺服器的每秒查詢數（QPS）。延遲在意的是單一輸入要等多久，吞吐量在意的則是總量：伺服器能處理多少路攝影機串流，或你每小時能標註多少張照片。兩者相關，卻是截然不同的目標。

當你以批次處理輸入時，吞吐量約等於 batch_size 除以每批次的延遲。批次處理把固定的額外開銷——核心啟動、權重載入——攤平，並填滿平行硬體（GPU 的張量核心、NPU 的乘加陣列），因此較大的批次通常會提高吞吐量，直到單元完全忙碌的飽和點為止。但此時每個個別輸入都要等整個批次完成，於是延遲上升。這就是延遲與吞吐量的根本取捨；流水線化與同時執行多路串流也能提高吞吐量。

務必在標明批次大小與精度的前提下回報吞吐量，因為缺了它們這個數字就毫無意義。真正有用的產物是吞吐量對延遲的曲線（隨批次增大而變化），尤其是「在延遲 SLA 下的吞吐量」——在維持 p99 延遲低於某上限的同時，你能持續達到的最大 QPS。Triton 之類的服務系統使用動態批次（dynamic batching）把進來的請求湊成批以提升吞吐，同時不撐破每個請求的延遲預算。