Tokens/second（每秒生成 token 數）
又稱：每秒 token · 生成速度 · tokens/sec · tok/s · 輸出速度
模型每秒能吐出多少個 token。在 decode 階段它主要由記憶體頻寬決定，而不是算力；廠商標示的數字跟你實測的數字往往差很遠。
你會在什麼時候遇到它
這是規格表最愛秀、也最容易誤導的數字。你會在看評測、比硬體時遇到它。陷阱在於：廠商的 tokens/second 通常是在最理想的條件下量的（短提示、低並發、特定量化），跟你實際用的場景差很遠。更根本的是，decode 是記憶體頻寬瓶頸，所以一味加算力並不會讓這個數字變快。不懂這點，你會為了一個漂亮數字買錯硬體。
打個比方
像自來水的流速。決定流速的不是水龍頭多華麗（算力），而是水管多粗（記憶體頻寬）。換一個更貴的水龍頭、水管沒變粗，流速還是一樣。decode 就是這樣：瓶頸在「搬資料」的水管，不在「算」的水龍頭。
最小範例
為什麼「廠商數字」≠「你的數字」：
廠商可能在測：短提示、單請求、特定量化、暖機後最佳狀態
你在用： 長提示、多並發、不同量化、已跑很久（降頻）
而且 tokens/second 有兩個層次，別混：
單串流速度 一個使用者感受到的吐字速度
總吞吐量 整台機器每秒服務所有使用者的 token 總和
→ 提高並發會讓總吞吐量上升，但單串流速度可能下降看到任何 tokens/second，先問三件事：什麼提示長度、什麼並發、什麼量化下量的？脫離條件的數字沒有意義。還要分清你關心的是「單個使用者多快」還是「整台機器總共多快」—— 這是兩個常常互相衝突的目標。
最常搞錯的地方
- 以為加算力（更高 FLOPS）就能提高生成速度。decode 是記憶體頻寬瓶頸，算力已經過剩時，再加幾乎沒用。
- 拿廠商的 tokens/second 當成你會得到的速度。那通常是理想條件下的最佳值，你的長提示、高並發場景會低得多。
- 把「單串流速度」跟「總吞吐量」當同一個數字。一台機器可以總吞吐量很高（服務很多人），但每個使用者的單串流速度只是普通。