首頁 ai 批次推論吞吐量計算器 產生日期: 2026年7月20日 下午09:34 批次推論吞吐量計算器 輸入 批次大小32每個請求的輸出標記數256批次完成時間5 秒 AI & LLM 批次推論吞吐量計算器 將實測的批次完成時間換算成總吞吐量、單一請求速度與每秒請求數——批次式大型語言模型服務在吞吐量與延遲之間的取捨。 輸入 批次 批次大小 ≥ 1 在一個批次中一起解碼的請求數量。批次越大，越能分攤讀取權重的成本，因此總吞吐量會隨此數量上升，直到記憶體或運算能力耗盡為止。 每個請求的輸出標記數 ≥ 1 批次中每個請求所生成的標記數。為求估算簡潔，假設各請求相同；長度不一會在已完成的序列離開批次後降低利用率。 批次完成時間 秒 在目標硬體上實測，產生整批輸出所花的實際時間。批次中每個請求都要等待這麼久，這決定了單一請求的速度。 結果 輸入數值即可顯示計算結果。 總吞吐量 伺服器每秒在整批中產生的標記總數：32 個請求乘以 256 個標記，再除以 5 秒，約為每秒 ... 個標記。 詳細資料 單一請求吞吐量 單一使用者所感受到的速度——256 個標記歷時 5 秒，約每秒 ... 個標記。批次處理並不會讓任何單一請求變快。 每秒請求數 每秒完成的請求數，32 除以 5 秒（...）。可用於依到達速率來規劃佇列規模。 分享 列印報告 重設 嵌入 嵌入這個計算機 預覽 將這段程式碼貼到您的網頁中即可顯示計算機。 複製程式碼 分享這個計算 開啟此連結的人都會看到您填入的數值。 複製連結 分享至 XFacebookLINE 電子郵件 最後更新：2026-06-22 批次推論吞吐量 批次推論是正式環境的語言模型伺服器達到高利用率的方式：它們不是一次處理一個請求，而是同時處理多個。由於模型權重只讀取一次並在整組中重複使用，伺服器的總輸出會隨批次大小急遽攀升——但每個個別請求都要等待整批完成。本計算器將這兩種視角分開，把實測的批次完成時間換算成總吞吐量、單一請求速度與請求速率。 批次處理的取捨 自迴歸解碼受記憶體限制：每一步都要讀取每個權重以產生一個標記。當只有單一請求進行時，幾乎所有記憶體流量都只服務一位使用者。將數個請求合併成一個批次，同一次權重讀取就能同時為每個請求產生一個標記，因此總標記速率會隨批次大小上升，而頻寬成本幾乎不變。代價在於延遲——請求必須等到包含它的那個批次步驟完成才能離開，因此單一請求的速度不會改善，甚至可能隨批次擴大而略為下降。 公式 由批次大小 BB、每個請求的輸出標記數 NoutN_{out} 以及實測的批次完成時間 tbt_b： vagg=B×Nouttbvreq=NouttbR=Btb\begin{aligned} v_{agg} &= \frac{B \times N_{out}}{t_b} \\ v_{req} &= \frac{N_{out}}{t_b} \\ R &= \frac{B}{t_b} \end{aligned}vaggvreqR=tbB×Nout=tbNout=tbB 其中 vaggv_{agg} 是總吞吐量，vreqv_{req} 是單一請求吞吐量，RR 是每秒完成的請求數。總吞吐量就是單一請求速度乘以批次大小。 範例計算 某伺服器解碼一個包含 32 個請求的批次，每個請求產生 256 個標記，整批於 5 秒內完成： vagg=32×2565=1638.4 tokens/svreq=2565=51.2 tokens/sR=325=6.4 requests/s\begin{aligned} v_{agg} &= \frac{32 \times 256}{5} = 1638.4\ \text{tokens/s} \\ v_{req} &= \frac{256}{5} = 51.2\ \text{tokens/s} \\ R &= \frac{32}{5} = 6.4\ \text{requests/s} \end{aligned}vaggvreqR=532×256=1638.4 tokens/s=5256=51.2 tokens/s=532=6.4 requests/s 營運者看到伺服器每秒輸出超過 1,600 個標記，但每位使用者的閱讀速度約為每秒 51 個標記。若記憶體允許且完成時間維持在約 5 秒，將批次加倍至 64，大致會使總吞吐量翻倍，而單一請求的數值保持不變。 選擇批次大小 只有在工作仍受記憶體限制時，總吞吐量才會隨批次大小持續上升。一旦批次使運算能力飽和，或鍵值快取耗盡裝置記憶體，完成時間的成長就會快過批次，單一請求的延遲也隨之惡化。實務上的目標，是在記憶體仍能容納的前提下，使單一請求延遲維持在可接受範圍內的最大批次，這需要在數個批次大小下量測完成時間來找出。實際伺服器也會使用連續批次處理，請求在每一步加入與離開，而非以固定的一組進行，這會進一步提升持續性的吞吐量。關於決定 vreqv_{req} 的單一串流上限，請參閱推論吞吐量計算器；關於跨多個複本的機群層級容量，請參閱有效每秒標記數計算器。 常見問題（FAQ）為何總吞吐量遠高於單一請求吞吐量？總吞吐量計算伺服器在批次中所有請求所輸出的每一個標記，而單一請求吞吐量則是單一使用者所體驗到的。批次處理只讀取每個模型權重一次，並在整組中重複使用，因此服務的標記總數大致與批次大小成正比上升。然而個別請求仍須等待整個批次完成，因此其感受到的速度不會改善——甚至會隨批次擴大而略為下降。這正是批次服務的核心取捨：對營運者而言是吞吐量，對使用者而言是延遲。 批次越大一定越好嗎？只在一定範圍內如此。當工作仍受記憶體限制時，總吞吐量會隨批次大小上升；但一旦批次使運算能力飽和，或鍵值快取耗盡記憶體，完成時間的成長就會快過批次，單一請求的延遲也隨之惡化。實務上的最佳點，是在記憶體仍能容納的前提下，使單一請求延遲維持在目標範圍內的最大批次，這需要在數個批次大小下量測完成時間來找出。 連續批次處理如何改變這一點？本計算器模擬的是一同開始、一同結束的固定批次。現代伺服器使用連續批次處理，新請求在每一步加入、已完成的請求離開，即使序列長度不同也能讓加速器保持滿載。這會使持續性的總吞吐量高於固定批次的估算，但相同的取捨依然成立：每秒標記總數提升，而任何單一請求仍受解碼速度的限制。 免責聲明 估算假設批次中所有請求生成相同數量的標記並一同開始。實際工作負載會混合不同序列長度並使用連續批次處理，因此實測的總吞吐量會有所不同。在規劃容量之前，請先在目標硬體上以數個批次大小進行基準測試。 推薦的下一個 推論吞吐量計算器 依據模型大小、權重精度與加速器記憶體頻寬，估算大型語言模型解碼速度的記憶體頻寬上限——單一串流每秒可產生標記數的屋頂線。 深入了解有效每秒標記數計算器 從每張加速器的尖峰速度、加速器數量與利用率，估算推論叢集可持續的標記吞吐量——也就是符合現實的產能，而非單一串流的尖峰值。 深入了解 200+ 計算機 · 10 種語言 · 完全免費 更多inference 多模態影像詞元計算器有效每秒標記數計算器批次推論吞吐量計算器每標記 FLOP 計算機推測解碼加速計算機推論吞吐量計算器 +2 more Show less 推論延遲計算器模型 FLOP 使用率計算機 其他ai計算機 cost 文字轉語音成本計算機代理人成本計算機向量資料庫大小計算機向量資料庫成本計算機自架與 API 損益平衡計算機批次 API 節省計算機每元詞元數計算機系統提示攤提計算機函式呼叫詞元額外負擔計算機音訊轉錄成本計算機訓練時間與成本計算訓練碳足跡計算情境成本增長計算機情境視窗容納計算機推論能源成本計算機嵌入成本計算機提示快取節省計算機結構化輸出額外負擔計算機詞元成本計算機詞元轉字數計算機微調成本計算影像生成成本計算機GPU 利用率成本計算器GPU 雲端成本計算機LLM 每月成本計算機LLM 速率限制規劃計算機training 有效批次大小計算訓練 FLOPs 計算梯度累積記憶體計算機資料平行擴展計算資料集詞元數計算算力最佳模型大小計算算力預算可訓練輪數計算管線平行氣泡計算學習率暖身計算Chinchilla 最佳詞元數計算LLM 訓練 VRAM 計算機LoRA 參數計算機infrastructure 注意力記憶體計算機專家混合活躍參數計算機量化模型大小計算器模型下載時間計算器GPU 數量需求計算機KV 快取大小計算機LLM 推論 VRAM 計算器Transformer 參數量計算機retrieval RAG 分塊計算器evaluation 困惑度計算器A/B 測試顯著性計算器LLM 評估樣本數計算器pass@k 計算器所有工具 餘弦相似度計算器 這個計算機對您有幫助嗎？ 有幫助 需要改進 需要改進 我們可以如何改進這個計算機？ 送出回饋 由 OneCalc 提供 ↗
最後更新：2026-06-22 批次推論吞吐量 批次推論是正式環境的語言模型伺服器達到高利用率的方式：它們不是一次處理一個請求，而是同時處理多個。由於模型權重只讀取一次並在整組中重複使用，伺服器的總輸出會隨批次大小急遽攀升——但每個個別請求都要等待整批完成。本計算器將這兩種視角分開，把實測的批次完成時間換算成總吞吐量、單一請求速度與請求速率。 批次處理的取捨 自迴歸解碼受記憶體限制：每一步都要讀取每個權重以產生一個標記。當只有單一請求進行時，幾乎所有記憶體流量都只服務一位使用者。將數個請求合併成一個批次，同一次權重讀取就能同時為每個請求產生一個標記，因此總標記速率會隨批次大小上升，而頻寬成本幾乎不變。代價在於延遲——請求必須等到包含它的那個批次步驟完成才能離開，因此單一請求的速度不會改善，甚至可能隨批次擴大而略為下降。 公式 由批次大小 BB、每個請求的輸出標記數 NoutN_{out} 以及實測的批次完成時間 tbt_b： vagg=B×Nouttbvreq=NouttbR=Btb\begin{aligned} v_{agg} &= \frac{B \times N_{out}}{t_b} \\ v_{req} &= \frac{N_{out}}{t_b} \\ R &= \frac{B}{t_b} \end{aligned}vaggvreqR=tbB×Nout=tbNout=tbB 其中 vaggv_{agg} 是總吞吐量，vreqv_{req} 是單一請求吞吐量，RR 是每秒完成的請求數。總吞吐量就是單一請求速度乘以批次大小。 範例計算 某伺服器解碼一個包含 32 個請求的批次，每個請求產生 256 個標記，整批於 5 秒內完成： vagg=32×2565=1638.4 tokens/svreq=2565=51.2 tokens/sR=325=6.4 requests/s\begin{aligned} v_{agg} &= \frac{32 \times 256}{5} = 1638.4\ \text{tokens/s} \\ v_{req} &= \frac{256}{5} = 51.2\ \text{tokens/s} \\ R &= \frac{32}{5} = 6.4\ \text{requests/s} \end{aligned}vaggvreqR=532×256=1638.4 tokens/s=5256=51.2 tokens/s=532=6.4 requests/s 營運者看到伺服器每秒輸出超過 1,600 個標記，但每位使用者的閱讀速度約為每秒 51 個標記。若記憶體允許且完成時間維持在約 5 秒，將批次加倍至 64，大致會使總吞吐量翻倍，而單一請求的數值保持不變。 選擇批次大小 只有在工作仍受記憶體限制時，總吞吐量才會隨批次大小持續上升。一旦批次使運算能力飽和，或鍵值快取耗盡裝置記憶體，完成時間的成長就會快過批次，單一請求的延遲也隨之惡化。實務上的目標，是在記憶體仍能容納的前提下，使單一請求延遲維持在可接受範圍內的最大批次，這需要在數個批次大小下量測完成時間來找出。實際伺服器也會使用連續批次處理，請求在每一步加入與離開，而非以固定的一組進行，這會進一步提升持續性的吞吐量。關於決定 vreqv_{req} 的單一串流上限，請參閱推論吞吐量計算器；關於跨多個複本的機群層級容量，請參閱有效每秒標記數計算器。 常見問題（FAQ）為何總吞吐量遠高於單一請求吞吐量？總吞吐量計算伺服器在批次中所有請求所輸出的每一個標記，而單一請求吞吐量則是單一使用者所體驗到的。批次處理只讀取每個模型權重一次，並在整組中重複使用，因此服務的標記總數大致與批次大小成正比上升。然而個別請求仍須等待整個批次完成，因此其感受到的速度不會改善——甚至會隨批次擴大而略為下降。這正是批次服務的核心取捨：對營運者而言是吞吐量，對使用者而言是延遲。 批次越大一定越好嗎？只在一定範圍內如此。當工作仍受記憶體限制時，總吞吐量會隨批次大小上升；但一旦批次使運算能力飽和，或鍵值快取耗盡記憶體，完成時間的成長就會快過批次，單一請求的延遲也隨之惡化。實務上的最佳點，是在記憶體仍能容納的前提下，使單一請求延遲維持在目標範圍內的最大批次，這需要在數個批次大小下量測完成時間來找出。 連續批次處理如何改變這一點？本計算器模擬的是一同開始、一同結束的固定批次。現代伺服器使用連續批次處理，新請求在每一步加入、已完成的請求離開，即使序列長度不同也能讓加速器保持滿載。這會使持續性的總吞吐量高於固定批次的估算，但相同的取捨依然成立：每秒標記總數提升，而任何單一請求仍受解碼速度的限制。 免責聲明 估算假設批次中所有請求生成相同數量的標記並一同開始。實際工作負載會混合不同序列長度並使用連續批次處理，因此實測的總吞吐量會有所不同。在規劃容量之前，請先在目標硬體上以數個批次大小進行基準測試。
