Throughput

Throughput คือปริมาณงานที่ระบบ inference ทำเสร็จได้ต่อหนึ่งหน่วยเวลา เอกสารวัดผลของ NVIDIA NIM สำหรับ LLM ซึ่งอัปเดตล่าสุดเมื่อ 20 กรกฎาคม 2026 นิยามหน่วยวัดไว้หลายตัว ทั้ง inter-token latency, end-to-end request latency และ TPS ต่อผู้ใช้ โดยหน่วยที่วัด throughput ของทั้งระบบมีสองแบบ แบบแรกคือ total tokens per second หรือ TPS ต่อระบบ ซึ่งเอกสารเขียนว่าหมายถึงปริมาณ output token รวมทั้งหมดที่ไหลออกจากทุกคำขอที่วิ่งพร้อมกันอยู่ ณ ขณะนั้น และเครื่องมือ AIPerf คำนวณค่านี้จากจำนวน output token ทั้งหมดหารด้วยเวลาตั้งแต่คำขอแรกถูกส่งไปจนถึงการตอบครั้งสุดท้ายของคำขอสุดท้าย แบบที่สองคือ requests per second หรือ RPS ซึ่งเอกสารนิยามว่าเป็นจำนวนคำขอเฉลี่ยที่ระบบทำสำเร็จได้ในช่วงเวลาหนึ่งวินาที เอกสารหน้าเดียวกันเปิดหัวด้วยคำเตือนว่าเครื่องมือแต่ละตัวนิยามค่าเหล่านี้ไม่เหมือนกัน จึงให้เทียบผลกันเฉพาะเมื่อนิยามตรงกันเท่านั้น

สิ่งที่ทำให้ตัวเลขนี้ถูกตีความผิดกันบ่อยคือระบบหนึ่งมี throughput อยู่สองชั้นที่ขยับสวนทางกัน เอกสารของ NVIDIA อธิบายว่า TPS ต่อผู้ใช้คือ throughput ในมุมมองของ client รายเดียว นิยามเป็นความยาวของ output หารด้วย e2e_latency ของคำขอนั้น และค่านี้จะเข้าใกล้ 1 หารด้วย inter-token latency เมื่อความยาวของ output เพิ่มขึ้นไปเรื่อยๆ แล้วเขียนประโยคที่เป็นหัวใจของเรื่องนี้ต่อทันทีว่า เมื่อจำนวนคำขอที่วิ่งพร้อมกันเพิ่มขึ้น TPS รวมของทั้งระบบจะเพิ่มขึ้น ขณะที่ TPS ต่อผู้ใช้จะลดลงเพราะ latency สูงขึ้น การอัดคำขอเข้าไปพร้อมกันมากขึ้นก็ไม่ได้ช่วยไปได้ไม่จำกัด เอกสารระบุว่า TPS รวมของระบบจะเพิ่มขึ้นจนกินทรัพยากรประมวลผลของ gpu ที่มีอยู่จนเต็ม และเลยจุดนั้นไปแล้ว TPS ลดลงได้ ฝั่งซอฟต์แวร์ที่รันโมเดลก็มีปุ่มปรับที่แลกกันตรงๆ คู่มือ optimization ของ vLLM เขียนว่าสำหรับ throughput ที่เหมาะที่สุด ทีมเอกสารแนะนำให้ตั้ง max_num_batched_tokens มากกว่า 8192 โดยเฉพาะกับโมเดลที่เล็กกว่าซึ่งรันบน GPU ขนาดใหญ่ ขณะที่ค่าที่เล็กกว่านั้น เช่น 2048 จะได้ inter-token latency ที่ดีกว่า เพราะมี prefill มาถ่วง decode น้อยลง ส่วนค่าที่สูงขึ้นจะได้ time to first token ที่ดีกว่า เพราะประมวลผล prefill token ได้มากขึ้นในหนึ่ง batch คู่มือเดียวกันยังระบุว่าการลด max_num_seqs หรือ max_num_batched_tokens จะลดจำนวนคำขอที่อยู่ใน batch พร้อมกัน จึงใช้พื้นที่ KV cache น้อยลง ข้อควรระวังคือคู่มือเขียนคำแนะนำข้อนี้ไว้ในส่วนแก้ปัญหา preemption ที่เกิดตอนพื้นที่ KV cache ไม่พอจนต้องเตะคำขอออกไปคำนวณใหม่ ไม่ใช่ปุ่มที่ปรับลดเพื่อไล่ throughput ให้สูงขึ้น

เวลาต้องตัดสินใจซื้อหรือขยายระบบ คำถามที่ต้องถามคือตัวเลขนั้นวัดตอนมีคำขอวิ่งพร้อมกันกี่คำขอ และวัดด้วย workload หน้าตาแบบไหน วิธีวัดของ artificial-analysis เป็นตัวอย่างที่เห็นภาพ เพราะหน้า methodology เวอร์ชัน 2.2.0 ลงวันที่ 2 มีนาคม 2026 แยก load scenario ไว้สองแบบชัดเจน คือ single prompt ที่ส่ง prompt เดียวเข้า API ของโมเดลทีละครั้ง กับ parallel prompts ที่ส่ง prompt สิบอันเข้าไปพร้อมกัน ส่วนค่า Output Speed หรือ output tokens per second ที่คนมักหยิบไปเทียบกันนั้น หน้าเดียวกันนิยามว่าเป็นจำนวน token เฉลี่ยที่ได้รับต่อวินาทีหลังจากได้รับ token แรกแล้ว ซึ่งเป็นความเร็วของคำตอบเส้นเดียวที่ผู้ใช้นั่งดูไหลออกมาแบบ streaming ไม่ใช่ยอดรวมของทั้งเครื่อง หน้าเดียวกันยังเขียนว่า prompt ที่ยาวกว่าอาจทำให้ทั้ง time to first token นานขึ้นและ output tokens per second ช้าลงเมื่อเทียบกับ prompt ที่สั้นกว่า และระบุว่าค่าที่แสดงเป็นค่ามัธยฐาน P50 ของ 72 ชั่วโมงที่ผ่านมา โดยมีข้อยกเว้นคือ workload ที่ prompt ยาว 100k ซึ่งทดสอบสัปดาห์ละครั้งและแสดงเป็นค่ามัธยฐาน P50 ของ 14 วันที่ผ่านมาแทน แรงจูงใจที่จะปั่นตัวเลขให้สวยก็ถูกเขียนไว้ตรงๆ ในข้อกำหนดความสุจริตของหน้าเดียวกัน ซึ่งห้ามผู้ให้บริการเสิร์ฟ traffic ของ Artificial Analysis ด้วย batch size, concurrency หรือการตั้งค่า load ที่ไม่เป็นตัวแทนของ traffic ทั่วไปบน endpoint เดียวกัน พร้อมยกตัวอย่างในวงเล็บว่า เช่น การรันคำขอสำหรับ benchmark ที่ batch size ต่ำลงเพื่อเพิ่มความเร็วต่อคำขอ ข้อควรระวังอีกข้อคือเพดานที่ผู้ให้บริการตั้งไว้กับความสามารถจริงของเครื่องเป็นคนละเรื่องกัน เอกสาร rate limit ของ Anthropic ระบุว่า rate limit ของ Messages API วัดเป็น requests per minute, input tokens per minute และ output tokens per minute แยกตาม model class และเขียนไว้ว่าเพดานทั้งหมดที่อธิบายในหน้านั้นคือปริมาณการใช้งานสูงสุดที่อนุญาต ไม่ใช่ค่าขั้นต่ำที่รับประกัน หน้าเดียวกันยังระบุว่า rate limit ใช้แยกกันในแต่ละโมเดล จึงเรียกใช้โมเดลต่างตัวกันจนถึงเพดานของแต่ละตัวได้พร้อมกัน ซึ่งเป็นช่องที่ใช้ทำ model-routing ได้เวลาชนเพดานของโมเดลตัวเดียว ข้อควรระวังคือตารางในหน้าเดียวกันมีเชิงอรรถกำกับว่าโมเดลบางตระกูลใช้เพดานร่วมก้อนเดียวกัน เช่น Opus 4.8, 4.7, 4.6 และ 4.5 นับรวมเป็นเพดานเดียว ส่วน Sonnet 4.6 กับ 4.5 ก็นับรวมกัน การสลับไปรุ่นพี่น้องที่อยู่ในก้อนเดียวกันจึงไม่ได้เพดานใหม่ แต่เชิงอรรถเดียวกันเขียนต่อไว้ด้วยว่า Claude Opus 5 และ Claude Sonnet 5 มีเพดานของตัวเองแยกต่างหาก ไม่ได้อยู่ในก้อนรวมนี้ การย้ายไปรุ่นล่าสุดจึงได้เพดานใหม่จริง และเอกสารฉบับเดียวกันเขียนว่าถ้าทำ caching ได้ผล จะเพิ่ม throughput จริงของเราขึ้นได้อย่างมีนัยสำคัญโดยไม่ต้องขอเพิ่ม rate limit เพราะเอกสารระบุว่าโมเดล Claude ส่วนใหญ่ไม่นับ token ที่อ่านจาก cache เข้าเพดาน input token ต่อนาที โดยมีรุ่นที่ตารางกำกับไว้ว่ายังนับรวมอยู่ ซึ่งตอนนี้คือ Claude Haiku 3.5 รุ่นเดียว

ตัวอย่างจากบทสนทนาจริง

ผู้จัดการฝ่ายบริการลูกค้า: ทีมเทคเสนอเครื่องใหม่มาโดยบอกว่าทำได้ 3,000 token ต่อวินาที แต่พอผมลองพิมพ์ถามเองในเดโม มันไหลออกมาไม่ได้เร็วขนาดนั้นเลยครับ ตกลงตัวเลขนั้นจริงหรือเปล่า

หัวหน้าทีมระบบ: จริงทั้งคู่ครับ แต่เป็นคนละตัวเลขกัน 3,000 คือ throughput รวมของทั้งเครื่องตอนมีคำขอวิ่งพร้อมกันเต็มที่ ส่วนที่พี่รู้สึกคือความเร็วของคำขอเดียว พอคำขอที่วิ่งพร้อมกันมากขึ้น ยอดรวมของเครื่องจะสูงขึ้นก็จริง แต่ความเร็วที่ผู้ใช้แต่ละคนได้จะลดลงเพราะเวลารอต่อคำขอยาวขึ้น

ผู้จัดการฝ่ายบริการลูกค้า: งั้นเวลาผมเขียน requirement ส่งให้ผู้ขาย ผมต้องเขียนยังไงถึงจะไม่โดนตัวเลขสวยหลอกครับ

หัวหน้าทีมระบบ: เขียนสองบรรทัดครับ บรรทัดแรกบอกว่าตอนมีคนใช้พร้อมกันกี่คน เครื่องต้องทำงานรวมได้เท่าไร บรรทัดที่สองบอกว่าที่จำนวนคนเท่านั้น ผู้ใช้แต่ละคนต้องได้ความเร็วไม่ต่ำกว่าเท่าไร แล้วขอให้เขาระบุด้วยว่าวัดด้วยเครื่องมืออะไร prompt ยาวเท่าไร และส่งคำขอพร้อมกันกี่อัน เพราะนิยามของแต่ละเครื่องมือไม่ตรงกัน เทียบกันดื้อๆ ไม่ได้

ระวังสับสนกับ

• latency : latency คือเวลาที่คำขอหนึ่งต้องรอ เอกสารของ NVIDIA นิยาม end-to-end request latency ว่าวัดว่าใช้เวลานานแค่ไหนตั้งแต่ส่งคำขอไปจนได้รับคำตอบครบทั้งชุด ซึ่งรวมการเข้าคิว การจัด batch และ network latency ส่วน throughput คือปริมาณรวมที่ระบบทำได้ต่อหน่วยเวลา ปรับอย่างหนึ่งให้ดีขึ้นแล้วอีกอย่างมักแย่ลง เห็นได้จากคู่มือ vLLM ที่แนะนำค่า max_num_batched_tokens มากกว่า 8192 สำหรับ throughput ที่เหมาะที่สุด ขณะที่ค่าเล็กกว่า เช่น 2048 กลับให้ inter-token latency ที่ดีกว่า
• output-tokens : เห็นตัวเลข token ต่อวินาทีเมื่อไหร่ ต้องถามก่อนว่าเป็นของใคร เอกสารของ NVIDIA แยกไว้ว่า TPS ต่อระบบคือ throughput ของ output token รวมทุกคำขอที่วิ่งพร้อมกัน ส่วน TPS ต่อผู้ใช้คือ throughput ในมุมของ client รายเดียว และเมื่อคำขอที่วิ่งพร้อมกันเพิ่มขึ้น ค่าแรกจะขึ้นขณะที่ค่าหลังจะลง โดยค่าแรกจะขึ้นไปจนกินทรัพยากรประมวลผลของ GPU ที่มีอยู่จนเต็ม เลยจุดนั้นไปเอกสารระบุว่า TPS ลดลงได้ เอาสองค่านี้มาเทียบกันตรงๆ จึงไม่ได้
• rate-limit : rate limit คือเพดานที่ผู้ให้บริการตั้งไว้ ไม่ใช่ความสามารถจริงของเครื่อง เอกสารของ Anthropic เขียนว่า rate limit กำหนดจำนวนคำขอ API สูงสุดที่องค์กรหนึ่งทำได้ในช่วงเวลาที่กำหนดไว้ และระบุว่าเพดานทั้งหมดในหน้านั้นคือปริมาณการใช้งานสูงสุดที่อนุญาต ไม่ใช่ค่าขั้นต่ำที่รับประกัน การชนเพดานจึงบอกแค่ว่าเราใช้เกินโควตาของตัวเอง ไม่ได้แปลว่าเครื่องที่ปลายทางทำต่อไม่ไหว
• batch-processing : งานที่รอผลได้ควรส่งเป็นชุดแทนที่จะยิงสด เอกสารของ Anthropic ระบุว่า Message Batches API มีชุด rate limit ของตัวเองที่ใช้ร่วมกันทุกโมเดล ประกอบด้วยเพดาน requests per minute กับเพดานจำนวนคำขอย่อยที่อยู่ในคิวประมวลผลพร้อมกันได้ ตัวเลข throughput ของงานแบบนี้จึงไปคนละทางกับงานสดที่มีคนนั่งรอคำตอบอยู่ปลายทาง