TTFT และ Tokens per second คืออะไร วัดความเร็ว LLM ยังไง

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

TTFT คืออะไร

TTFT (time to first token) คือเวลาตั้งแต่ส่งคำขอจนได้รับ token แรกของคำตอบ เอกสาร benchmark ของ NVIDIA ระบุว่า TTFT โดยทั่วไปรวมเวลาเข้าคิว เวลา prefill และ network latency ไว้ด้วยกัน พูดง่ายๆ TTFT คือเวลาที่ผู้ใช้จ้องจอเปล่าก่อนเห็นตัวอักษรแรก

สิ่งที่ทำให้ TTFT สูงมีห้าอย่างหลัก

• ความยาว prompt โมเดลต้องอ่าน prompt ทั้งหมดในช่วง prefill ก่อนเขียน token แรก (อธิบายใน AI Inference คืออะไร) agent ที่ส่ง context หลักแสน token จึงรอนานกว่าแชตสั้นๆ ชัดเจน
• cache ไม่ติด ถ้าส่วนต้นของ prompt ตรงกับที่เคยส่ง ผู้ให้บริการใช้ผลเดิมได้ เอกสารของ OpenAI ระบุว่า prompt caching ลดเวลาประมวลผล input ก่อนเริ่มตอบ (ดู Prompt caching และ KV cache)
• คิว ช่วงที่เซิร์ฟเวอร์มีคำขอเยอะ คำขอใหม่ต้องรอก่อนเริ่ม prefill
• การคิดก่อนตอบ โมเดล reasoning สร้าง token ความคิดก่อน ข้อความแรกที่ผู้ใช้เห็นจึงมาช้ากว่า
• ระยะทางเครือข่าย เซิร์ฟเวอร์ที่อยู่ไกลเพิ่มเวลาไปกลับให้ทุกคำขอ

Tokens per second คืออะไร ต่างจาก TTFT อย่างไร

Tokens per second คือจำนวน token ที่โมเดลเขียนได้ในหนึ่งวินาทีหลังจาก token แรกออกมาแล้ว หลายเครื่องมือรายงานเป็นค่ากลับกันคือ inter-token latency (ITL) หรือ time per output token (TPOT) ซึ่งคือเวลาเฉลี่ยระหว่าง token ที่ติดกัน TTFT บอกว่าเริ่มเร็วแค่ไหน ส่วน tokens per second บอกว่าเขียนเร็วแค่ไหน

เวลารวม (e2e) = TTFT + เวลาเขียนคำตอบ
ITL (TPOT)    = (เวลารวม − TTFT) ÷ (จำนวน token ขาออก − 1)
tokens/s      ≈ 1 ÷ ITL

ตัวอย่างตัวเลขสมมติ TTFT 0.8 วินาที คำตอบยาว 400 token ที่ความเร็ว 50 token ต่อวินาที เวลารวมจะราว 0.8 + 8 = 8.8 วินาที ถ้าตัดคำตอบเหลือ 200 token เวลารวมเหลือราว 4.8 วินาที แต่ TTFT เท่าเดิม

ความเร็วช่วงนี้ขึ้นกับว่า GPU อ่าน weight จากหน่วยความจำได้เร็วแค่ไหน เพราะทุก token ต้องรันโมเดลหนึ่งรอบ ปัจจัยหลักคือขนาดโมเดล, memory bandwidth ของการ์ด (ดู GPU สำหรับรัน LLM), quantization ที่ทำให้ weight เล็กลง (ดู Quantization คืออะไร), จำนวนคำขอที่แบ่งการ์ดเดียวกัน และความยาว context

เอกสาร latency ของ OpenAI สรุปว่าการสร้าง token เกือบทุกครั้งเป็นขั้นที่ใช้เวลามากที่สุด ลด output ลงครึ่งหนึ่งอาจลดเวลาได้ราวครึ่งหนึ่ง ขณะที่ลด prompt ลงครึ่งหนึ่งอาจลดได้แค่ 1–5% แต่ถ้า prompt ยาวมากแบบงาน agent ส่วนของ prefill จะกินเวลามากขึ้นตาม

ทำไม AI ตอบช้า สาเหตุที่พบบ่อยมีอะไรบ้าง

AI ตอบช้ามักมาจาก prompt ยาวเกินจำเป็น คำตอบยาวเกินจำเป็น โมเดลใหญ่เกินงาน เซิร์ฟเวอร์มีคิว หรือไม่ได้เปิด streaming จนผู้ใช้ต้องรอคำตอบเสร็จทั้งก้อน ดูอาการก่อนจะรู้ว่าต้องแก้ที่ไหน

สำหรับ agent ตัวเลขที่สำคัญคือ TTFT คูณจำนวนรอบ ถ้า agent เรียกโมเดล 30 รอบ รอบละ 2 วินาทีก่อนเริ่มตอบ จะเสียเวลาไปหนึ่งนาทีเฉพาะการรอ token แรก (ตัวเลขสมมติ)

วัด TTFT และ tokens per second ด้วย curl และ Python อย่างไร

วิธีที่แม่นที่สุดคือเปิด streaming แล้วจับเวลาฝั่ง client เอง จดเวลาตอนส่ง ตอนได้ข้อความชิ้นแรก และตอนจบ แล้วหารจำนวน token ขาออกด้วยเวลาช่วงหลัง สคริปต์ด้านล่างใช้ได้กับ API แบบ OpenAI-compatible

ดูคร่าวๆ ด้วย curl ก่อน

curl -sN https://api.example.com/v1/chat/completions \
  -H "Authorization: Bearer $API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"model": "your-model", "stream": true,
       "messages": [{"role": "user", "content": "อธิบาย KV cache ใน 5 บรรทัด"}]}' \
  -o /dev/null -w 'first byte: %{time_starttransfer}s  total: %{time_total}s\n'

-N ปิด buffer ของ curl ถ้าลบ -o /dev/null ออกจะเห็นข้อความไหลมาจริง ส่วน time_starttransfer คือเวลาถึง byte แรก ซึ่งบางเซิร์ฟเวอร์ส่ง header ออกมาก่อน token แรก จึงใช้เป็นค่าประมาณของ TTFT ได้เท่านั้น ตัวเลขที่แม่นกว่าให้ใช้ Python กับ OpenAI SDK

import os, time
from openai import OpenAI

client = OpenAI(base_url=os.environ["BASE_URL"], api_key=os.environ["API_KEY"])

start = time.perf_counter()
first = usage = None
stream = client.chat.completions.create(
    model=os.environ["MODEL"],
    messages=[{"role": "user", "content": "อธิบาย KV cache ใน 5 บรรทัด"}],
    stream=True,
    stream_options={"include_usage": True},
)
for chunk in stream:
    if chunk.choices and chunk.choices[0].delta.content and first is None:
        first = time.perf_counter()
    if chunk.usage:
        usage = chunk.usage
end = time.perf_counter()

n = usage.completion_tokens
print(f"TTFT {first - start:.2f}s | total {end - start:.2f}s | {n} tokens")
print(f"decode {(n - 1) / (end - first):.1f} tokens/s")

stream_options={"include_usage": True} ทำให้ API ส่ง chunk สุดท้ายที่มีจำนวน token ของทั้งคำขอมาก่อน data: [DONE] ให้รันหลายรอบแล้วดูค่ากลาง (p50) กับค่าหาง (p95 หรือ p99) เพราะค่าเดียวหลอกได้ ถ้าเป็นโมเดลที่คิดก่อนตอบ completion_tokens จะรวม token ความคิดด้วย ตัวเลข tokens/s จึงสูงเกินจริง

ฝั่งคนที่ตั้งเซิร์ฟเวอร์เอง vLLM มีคำสั่ง vllm bench serve ที่ยิงคำขอจำนวนมากแล้วรายงาน TTFT, TPOT และ ITL ทั้งค่าเฉลี่ย ค่ากลาง และ P99 พร้อม throughput รวม (ดู vLLM คืออะไร)

Throughput กับ latency ต่างกันอย่างไร ทำไมต้องแลกกัน

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

เอกสารของ NVIDIA แยกตัวเลขนี้เป็น TPS ต่อระบบ ซึ่งนับ output ของทุกคำขอที่รันพร้อมกัน กับ TPS ต่อผู้ใช้ ซึ่งมองจากคำขอเดียว การตั้งค่าใน vLLM ก็สะท้อนเรื่องเดียวกัน เอกสารแนะนำว่า max_num_batched_tokens ค่าน้อย (เช่น 2048) ให้ ITL ดีกว่าเพราะมีงาน prefill มาแทรก decode น้อยลง ส่วนค่ามากให้ TTFT ดีกว่าเพราะประมวลผล prefill ได้ทีละมาก

ผู้ให้บริการจึงขายจุดแลกนี้เป็นตัวเลือก ณ พฤศจิกายน 2569 มีดังนี้

ลด latency ของ LLM ได้อย่างไร

วิธีที่ได้ผลมากที่สุดคือเปิด streaming เพราะผู้ใช้เห็นข้อความทันทีที่ token แรกมา ไม่ต้องรอจนเสร็จทั้งก้อน เอกสาร latency ของ OpenAI เรียก streaming ว่าวิธีที่ได้ผลที่สุดกับเวลารอที่ผู้ใช้รู้สึก รองลงมาคือให้โมเดลเขียนน้อยลง ส่ง input น้อยลง และให้ส่วนต้นของ prompt ถูก cache

1. เปิด streaming ทุกหน้าที่มีคนรอคำตอบ
2. สั่งให้ตอบสั้น บอกจำนวนประโยคหรือย่อหน้าที่ต้องการ และตั้ง max_tokens เป็นเพดาน
3. ให้ส่วนต้นของ prompt คงที่ คำสั่งระบบและรายการเครื่องมือไว้หน้า ข้อมูลที่เปลี่ยนทุกครั้งไว้ท้าย cache จะได้ติด
4. เลือกโมเดลให้พอดีงาน งานจัดหมวดหรือสรุปสั้นใช้รุ่นเล็กได้
5. ทำงานที่ไม่ขึ้นต่อกันพร้อมกัน แทนการเรียกต่อกันทีละขั้น
6. ไม่ใช้ LLM ในจุดที่โค้ดธรรมดาทำได้ เช่น ตรวจรูปแบบอีเมลหรือแปลงวันที่

สำหรับแชต เมื่อข้อความไหลเร็วกว่าที่คนอ่านทัน การเพิ่ม tokens per second อีกแทบไม่มีใครรู้สึก ตัวเลขที่ผู้ใช้รับรู้คือ TTFT ส่วนงานที่ไม่มีใครอ่านระหว่างทาง เช่น agent หรือ pipeline เบื้องหลัง เวลารวมคือตัวเลขที่ต้องดู

วัด TTFT ของ buzzAI ด้วยสคริปต์เดียวกันได้ไหม

ได้ buzzAI เป็น API แบบ OpenAI-compatible เมื่อได้ API key แล้ว ตั้ง BASE_URL=https://api.heybuzzai.com/v1, MODEL=Qwen3.8-27B และ API_KEY=$BUZZAI_API_KEY แล้วรันสคริปต์ Python ข้างบนได้ตามปกติ Qwen3.8-27B รันบนการ์ด GPU ที่ buzzAI ดูแลเอง ในรุ่น NVFP4 (4-bit) ที่ NVIDIA ทำจากโมเดลนี้ และรองรับทั้ง Chat Completions, Responses และ Anthropic Messages

ตัวเลขที่วัดได้รวมเวลาเข้าคิวด้วย และ buzzAI มีคิวในช่วงที่คนใช้เยอะ ในเวลาทำการ (จันทร์–ศุกร์ 08:00–20:00 น.) แพ็กบริษัทและ slot ที่จองไว้ได้ไปก่อน แพ็ก Personal จึงอาจต้องรอ ทุกแพ็กไม่คิดค่า token สิ่งที่จำกัดคือจำนวน agent ที่รันพร้อมกันและขนาด context ตอนนี้ API ยังไม่เปิดให้ทุกคน ขอร่วมทดสอบได้ที่หน้าแรก และดูแพ็กที่หน้าราคา