對於課堂 project 的 demo 來說，Latency（延遲）絕對是你的首要考量。 當你站在台上 demo 給教授和同學看時，大家都在盯著螢幕等模型吐出結果。如果系統為了追求極致的 Throughput（吞吐量）而把請求都扣住在後台做 Batching，導致畫面卡了 10 秒鐘才開始有反應，那在台下的體感就會覺得「這系統是不是壞了？」。 為了解釋得更清楚，我們可以把這兩個指標在你的情境下拆開來看： 1. Latency（延遲）：Demo 順暢度的生命線 在語言模型的推論中，Latency 通常會再細分為兩個關鍵指標 ： Time To First Token (TTFT)： 從你按下 Enter 到模型吐出第一個字的時間。這對使用者體驗最重要，TTFT 越短，教授覺得系統反應越靈敏。 Time Per Output Token (TPOT)： 模型每生成一個字需要的時間。這決定了字「噴」出來的速度。只要這個速度比人類閱讀的速度快，看起來就很順暢。 2. Throughput（吞吐量）：預算與大規模服務的考量 Throughput 指的是系統單位時間內能處理的總請求數（例如：每秒能生成多少個 Token 或處理多少個 Request）。 為什麼現在先不用管？ 因為在你的課堂 demo 中，同時間最多可能只有你，或是兩三個同學在操作。系統根本沒有「同時湧入上百個請求需要消化」的壓力，所以花費心力與預算去拉高 Throughput 的意義不大。 預算有限的切入策略 既然預算有限，又必須確保 Latency 夠低，你的硬體資源應該「剛剛好」滿足單一請求的極限速度即可，不需要為了不存在的高併發流量去租用超大顯存或多張 GPU 的機器。 你可以把心力放在推論引擎的最佳化上。透過使用像 vLLM 或 SGLang 這類高效的 Inference Engine，搭配量化（Quantization）過的小模型（像是 AWQ 或 GGUF 格式），通常就能在一張相對平價的 GPU（甚至消費級顯卡）上，跑出非常漂亮的 Latency 表現，完美扛住你的期末 Demo。