0Pricing
AI Engineering Academy · บทเรียน

การวัดเวลาแฝงของ LLM: TTFT และ TPOT

กำหนดเวลาไปจนถึงโทเค็นแรกและเวลาต่อโทเค็นผลลัพธ์เป็นตัวชี้วัดเวลาแฝงสำคัญสองรายการ เพิ่มเครื่องมือวัดให้แอปพลิเคชันเพื่อวัดทั้งสองค่า และกำหนดเป้าหมาย SLA แยกตามปลายทาง

การวัดเวลาแฝงของ LLM: TTFT และ TPOT เป็นบทเรียน AI Engineering Academy ฟรีบน CoddyKit นี่คือบทเรียนที่ 1 จากทั้งหมด 4 บทเรียน คุณสามารถอ่านบทเรียนทั้งหมดด้านล่างฟรี — จากนั้นลองปฏิบัติด้วยตัวคุณเองในเบราว์เซอร์พร้อมตัวแก้ไขโค้ดในตัวและติวเตอร์ AI ตลอด 24/7 บทเรียนนี้เป็นส่วนหนึ่งของเส้นทางการเรียน AI Engineering Academy และความก้าวหน้าของคุณจะซิงค์ข้ามเว็บและแอป CoddyKit คอร์ส AI Engineering Academy มีบทเรียนทั้งหมด 4 บทเรียน

เหตุใดความหน่วงของ LLM จึงมีสององค์ประกอบ

การวัดความหน่วงของ LLM เป็นตัวเลขเดียวอาจทำให้เข้าใจผิด ที่จริงมีสองระยะที่แตกต่างกัน ได้แก่ เวลาจนกว่า โทเคนแรกจะมาถึง (ความรู้สึกตอบสนองของระบบ) และเวลาที่ใช้สร้าง โทเคนถัด ๆ ไป (ความเร็วเอาต์พุต) โมเดลอาจมี TTFT ดีแต่ TPOT ช้า ทำให้การตอบยาว ๆ รู้สึกอืด แม้การตอบในช่วงแรกจะดูเหมือนมาทันที

TTFT: เวลาจนถึงโทเคนแรก

Time to First Token (TTFT) คือระยะเวลาตั้งแต่ส่งคำขอ API จนได้รับโทเคนแรกสุดของคำตอบ ซึ่งรวมความหน่วงเครือข่าย เวลารอคิวที่เซิร์ฟเวอร์ประมวลผลการอนุมาน และเวลาเติมข้อมูลล่วงหน้า (การประมวลผลโทเคนอินพุต) TTFT มีผลอย่างมากต่อความรู้สึกตอบสนองของระบบ ผู้ใช้จะสังเกตได้เมื่อไม่มีอะไรปรากฏนานเกิน 1-2 วินาที ไม่ว่าโทเคนหลังจากนั้นจะทยอยมาเร็วเพียงใด

import time
from openai import OpenAI

client = OpenAI()

def measure_ttft(prompt: str) -> float:
    start = time.perf_counter()
    first_token_time = None
    stream = client.chat.completions.create(
        model='gpt-4o',
        messages=[{'role': 'user', 'content': prompt}],
        stream=True
    )
    for chunk in stream:
        if chunk.choices[0].delta.content:
            first_token_time = time.perf_counter()
            break  # stop after first token
    return first_token_time - start

TPOT: เวลาต่อโทเคนเอาต์พุต

Time Per Output Token (TPOT) คือเวลาเฉลี่ยระหว่างโทเคนที่ต่อเนื่องกันหลังเริ่มสร้างแล้ว คำนวณจากเวลาสร้างทั้งหมดหารด้วยจำนวนโทเคนเอาต์พุตทั้งหมด TPOT เป็นตัวกำหนดความเร็วในการอ่าน มนุษย์อ่านได้ประมาณ 250 คำต่อนาที ดังนั้น TPOT ที่มากกว่า 100 มิลลิวินาทีต่อโทเคน (10 โทเคนต่อวินาที) จะรู้สึกช้าอย่างเห็นได้ชัดสำหรับคำตอบยาว ๆ

import time
from openai import OpenAI

client = OpenAI()

def measure_tpot(prompt: str) -> dict:
    start = time.perf_counter()
    first_token_time = None
    token_count = 0
    stream = client.chat.completions.create(
        model='gpt-4o',
        messages=[{'role': 'user', 'content': prompt}],
        stream=True
    )
    for chunk in stream:
        delta = chunk.choices[0].delta.content or ''
        if delta:
            if first_token_time is None:
                first_token_time = time.perf_counter()
            token_count += 1
    end = time.perf_counter()
    ttft = first_token_time - start
    generation_time = end - first_token_time
    tpot = generation_time / max(token_count, 1)
    return {'ttft_ms': ttft * 1000, 'tpot_ms': tpot * 1000, 'tokens': token_count}

ความหน่วงรวมเทียบกับ TTFT และ TPOT

ความสัมพันธ์ระหว่างตัวชี้วัดเหล่านี้คือ total_latency = TTFT + (output_tokens × TPOT) สำหรับคำตอบ 500 โทเคนที่มี TPOT 50 มิลลิวินาที การสร้างจะใช้เวลา 25 วินาที สำหรับแอปพลิเคชันแบบสตรีมมิง ให้ปรับปรุง TTFT ก่อน ผู้ใช้ยอมรับการสตรีมที่ช้าได้ดีกว่าหน้าจอว่างเปล่า สำหรับการประมวลผลเป็นชุดที่ไม่ใช้การสตรีม ความหน่วงรวมคือสิ่งสำคัญ ดังนั้นให้ปรับปรุง TPOT ด้วยการเลือกโมเดลที่อนุมานได้เร็วกว่า

# Latency breakdown for a 200-token response
ttft_ms = 450       # half a second to first token
tpot_ms = 25        # 25ms per token = 40 tokens/sec
output_tokens = 200

total_latency = ttft_ms + (tpot_ms * output_tokens)
print(f'TTFT:  {ttft_ms}ms')
print(f'Generation: {tpot_ms * output_tokens}ms')
print(f'Total: {total_latency}ms ({total_latency/1000:.1f}s)')
# Output:
# TTFT:  450ms
# Generation: 5000ms
# Total: 5450ms (5.5s)

ปัจจัยที่ส่งผลต่อ TTFT

TTFT ถูกกำหนดเป็นหลักโดย ต้นทุนการเติมข้อมูลล่วงหน้า ซึ่งเพิ่มขึ้นตามจำนวนโทเคนอินพุต พรอมต์ระบบ 10,000 โทเคนจะมี TTFT สูงกว่าพรอมต์ 1,000 โทเคน 10 เท่า หากปัจจัยอื่นเท่ากัน ปัจจัยอื่น ๆ ได้แก่ ภาระของเซิร์ฟเวอร์ (เวลารอคิว) เวลาไป-กลับของเครือข่ายไปยังจุดปลายทาง API และการแคชพรอมต์ที่ช่วยลดงานเติมข้อมูลล่วงหน้าที่ต้องทำจริงหรือไม่ ลดความยาวพรอมต์ระบบเพื่อให้ TTFT ต่ำลง

# TTFT scales approximately linearly with input tokens
# Measured typical values for gpt-4o (2026):
# 500 input tokens:   ~400ms TTFT
# 2000 input tokens:  ~600ms TTFT
# 10000 input tokens: ~1500ms TTFT
# 32000 input tokens: ~4000ms TTFT

# Use prompt caching to avoid paying for repeated long prefixes:
# Cached tokens: ~200ms saved per 1000 cached tokens

ปัจจัยที่ส่งผลต่อ TPOT

TPOT ถูกกำหนดเป็นหลักโดย ขนาดโมเดลและฮาร์ดแวร์ โมเดลขนาดเล็ก (GPT-4o-mini) ถอดรหัสได้เร็วกว่าโมเดลขนาดใหญ่ (GPT-4o) มาก สำหรับโมเดลที่โฮสต์เอง ขนาดชุดข้อมูลและแบนด์วิดท์หน่วยความจำ GPU เป็นปัจจัยหลัก สำหรับโมเดลที่โฮสต์โดย OpenAI ค่า TPOT เปลี่ยนแปลงตามภาระของเซิร์ฟเวอร์ แต่โดยทั่วไปอยู่ที่ 15-40 มิลลิวินาทีต่อโทเคน คุณควบคุม TPOT ของ API ที่มีผู้ให้บริการโฮสต์โดยตรงไม่ได้ การเลือกโมเดลคือคันโยกหลักของคุณ

# Typical TPOT benchmarks (approximate, 2026):
# gpt-4o-mini:   15-20ms per token (50-65 tokens/sec)
# gpt-4o:        25-40ms per token (25-40 tokens/sec)
# claude-3.5-haiku: 20-25ms per token
# claude-3.5-sonnet: 30-50ms per token
# local llama-3.1-8B on A100: 8-12ms per token
# local llama-3.1-70B on 4xA100: 25-35ms per token

กำหนดเป้าหมาย SLA แยกตามจุดปลายทาง

ปลายทางไม่ได้ทั้งหมดจำเป็นต้องมีเป้าหมายด้านเวลาแฝงเหมือนกัน ปลายทางสำหรับแชตมี SLA ของ TTFT ที่เข้มงวด (ผู้ใช้คาดหวังให้น้อยกว่า 500 มิลลิวินาที) ขณะที่ปลายทางสำหรับสรุปผลแบบกลุ่มสามารถยอมรับเวลาแฝงหลายวินาทีได้ ให้กำหนด เป้าหมาย SLA สำหรับแต่ละปลายทาง อย่างชัดเจน และเก็บข้อมูลของแต่ละปลายทางแยกกัน เป้าหมายทั่วไป ได้แก่ แชตแบบโต้ตอบ = p95 ของ TTFT <600 มิลลิวินาที การดึงข้อมูลจากเอกสาร = p95 ของเวลารวม <10 วินาที และงานแบบกลุ่ม = ไม่มี SLA แบบเรียลไทม์

SLA_TARGETS = {
    'chat':       {'ttft_p95_ms': 600,  'total_p95_ms': 8000},
    'extraction': {'ttft_p95_ms': 1500, 'total_p95_ms': 10000},
    'summary':    {'ttft_p95_ms': 2000, 'total_p95_ms': 30000},
    'batch':      {'ttft_p95_ms': None, 'total_p95_ms': None},
}

การบันทึกเมตริกเวลาแฝง

บันทึก TTFT และ TPOT สำหรับคำขอในการใช้งานจริงทุกคำขอด้วยการบันทึกแบบมีโครงสร้าง ให้รวมชื่อโมเดล ปลายทาง จำนวนโทเค็นของพรอมต์ จำนวนโทเค็นเอาต์พุต และระบุว่าพบข้อมูลในแคชหรือไม่ ข้อมูลนี้ช่วยให้คุณคำนวณการกระจายของเปอร์เซ็นไทล์ (p50, p95, p99) ตรวจพบการถดถอยหลังการอัปเดตโมเดล และหาความสัมพันธ์ระหว่างเวลาแฝงที่พุ่งสูงกับความลึกของคิวหรือเหตุขัดข้องของผู้ให้บริการ

import structlog

log = structlog.get_logger()

def log_latency(endpoint: str, model: str, metrics: dict):
    log.info(
        'llm_latency',
        endpoint=endpoint,
        model=model,
        ttft_ms=round(metrics['ttft_ms'], 1),
        tpot_ms=round(metrics['tpot_ms'], 1),
        output_tokens=metrics['tokens'],
        total_ms=round(metrics['ttft_ms'] + metrics['tpot_ms'] * metrics['tokens'], 1)
    )

การคำนวณเปอร์เซ็นไทล์จากตัวอย่าง

ค่าเฉลี่ยดิบทำให้เข้าใจเวลาแฝนผิดพลาดได้ เพราะค่าผิดปกติที่ช้ามากเพียงไม่กี่ค่าจะดันค่า mean ให้สูงขึ้น ทั้งที่ไม่ได้ส่งผลต่อผู้ใช้ส่วนใหญ่ ให้รายงานเปอร์เซ็นไทล์ p50, p95 และ p99 เสมอ โดยทั่วไป P95 เป็นเมตริก SLA ที่ใช้กันมากที่สุด หมายความว่า 95% ของคำขอเสร็จสิ้นภายในเวลานั้น ใช้ NumPy หรือโมดูลสถิติเพื่อคำนวณเปอร์เซ็นไทล์จากตัวอย่างเวลาแฝงที่บันทึกไว้

import numpy as np

def compute_percentiles(samples: list, label: str = 'latency_ms'):
    arr = np.array(samples)
    stats = {
        'count': len(arr),
        'p50': np.percentile(arr, 50),
        'p95': np.percentile(arr, 95),
        'p99': np.percentile(arr, 99),
        'mean': np.mean(arr),
        'max': np.max(arr)
    }
    print(f'{label}:')
    for k, v in stats.items():
        print(f'  {k}: {v:.1f}')
    return stats

การลดเวลาแฝงด้วย max_tokens

การกำหนดขีดจำกัด max_tokens ที่เหมาะสมช่วยลดเวลาแฝนรวมในกรณีเลวร้ายที่สุด โดยป้องกันไม่ให้คำตอบยาวเกินควบคุม หากกรณีใช้งานของคุณต้องการคำตอบไม่เกิน 200 โทเค็น ให้ตั้งค่า max_tokens=250 วิธีนี้ยังช่วยจำกัดค่าใช้จ่ายด้วย ให้ใช้ร่วมกับ การส่งผลลัพธ์แบบสตรีม เพื่อให้ผู้ใช้เห็นเอาต์พุตได้ทันทีขณะที่ระบบยังสร้างคำตอบฉบับเต็มอยู่ อย่าปล่อยให้ max_tokens ไม่จำกัดในปลายทางที่ใช้งานจริง

response = client.chat.completions.create(
    model='gpt-4o',
    messages=[{'role': 'user', 'content': question}],
    max_tokens=300,  # cap at 300 tokens
    stream=True
)

# With max_tokens=300 and TPOT=30ms:
# worst-case total generation = 9000ms
# Without limit: could run to 4096+ tokens = 123s+

ลำดับความสำคัญในการปรับปรุงเวลาแฝง

เมื่อเวลาแฝงสูงเกินไป ให้แก้คอขวดตามลำดับความสำคัญ ขั้นแรก เปิดใช้การส่งผลลัพธ์แบบสตรีม เพื่อให้ผู้ใช้เห็นเอาต์พุตทันที แม้เวลาแฝนรวมจะยังสูง ขั้นที่สอง ทำให้พรอมต์ระบบสั้นลง เพื่อลด TTFT ขั้นที่สาม เพิ่มการแคชคำนำหน้าพรอมต์ เพื่อเฉลี่ยต้นทุนการเติมอินพุตล่วงหน้าจากคำขอที่เกิดซ้ำ ขั้นที่สี่ เปลี่ยนไปใช้โมเดลขนาดเล็กลง หากคุณภาพยังเป็นที่ยอมรับ สุดท้าย พิจารณาการอนุมานบนโครงสร้างพื้นฐานที่โฮสต์เอง เพื่อควบคุมทั้ง TTFT และ TPOT ได้สูงสุด

# Latency optimization checklist (in priority order):
# 1. Enable streaming (perceived latency: immediate)
# 2. Shorten system prompt by 50% (TTFT: -20%)
# 3. Enable prompt prefix caching (TTFT: -40% on cache hits)
# 4. Downgrade to gpt-4o-mini for simple queries (TPOT: -40%)
# 5. Self-host llama-3.1-8B for high-volume simple queries
#    (TPOT: 8ms vs 25ms; TTFT: 100ms vs 450ms)

ตรวจสอบความเข้าใจอย่างรวดเร็ว

ทดสอบความเข้าใจของคุณเกี่ยวกับ TTFT และ TPOT ในฐานะเมตริกเวลาแฝงของ LLM

สรุปบทเรียน

ในบทเรียนนี้ คุณได้เรียนรู้ว่า TTFT (Time to First Token) ใช้วัดการตอบสนองที่ผู้ใช้รับรู้และเพิ่มขึ้นตามจำนวนโทเค็นอินพุต, TPOT (Time Per Output Token) ใช้กำหนดความเร็วในการสร้างผลลัพธ์และควบคุมโดยหลักด้วยขนาดของโมเดล และ เป้าหมาย SLA รายปลายทางร่วมกับเมตริกเปอร์เซ็นไทล์ เป็นแนวทางที่เหมาะสมสำหรับติดตามเวลาแฝงในระบบที่ใช้งานจริง บทถัดไป เราจะนำการกระจายภาระงานระหว่างคีย์ API หลายรายการมาใช้งาน

คำถามที่พบบ่อย

บทเรียน “การวัดเวลาแฝงของ LLM: TTFT และ TPOT” ฟรีหรือไม่

ใช่ — ข้อความเต็มของ “การวัดเวลาแฝงของ LLM: TTFT และ TPOT” ฟรีให้อ่านที่นี่บนเว็บ เพื่อปฏิบัติแบบโต้ตอบ (ตัวแก้ไขโค้ดในตัวและติวเตอร์ AI ตลอด 24/7) และปลดล็อคส่วนที่เหลือของคอร์ส AI Engineering Academy ให้อัปเกรดเป็น CoddyKit PRO คอร์ส AI Engineering Academy มีบทเรียนทั้งหมด 4 บทเรียน

คุณจะเรียนรู้อะไรในบทเรียน “การวัดเวลาแฝงของ LLM: TTFT และ TPOT”

กำหนดเวลาไปจนถึงโทเค็นแรกและเวลาต่อโทเค็นผลลัพธ์เป็นตัวชี้วัดเวลาแฝงสำคัญสองรายการ เพิ่มเครื่องมือวัดให้แอปพลิเคชันเพื่อวัดทั้งสองค่า และกำหนดเป้าหมาย SLA แยกตามปลายทาง คุณปฏิบัติ AI Engineering Academy ด้วยโค้ดที่ใช้งานได้จริงที่คุณเรียกใช้โดยตรงในเบราว์เซอร์ และติวเตอร์ AI ตลอด 24/7 ตอบคำถามของคุณขณะที่คุณไปผ่านบทเรียน

คุณต้องมีประสบการณ์ก่อนที่จะเริ่มเรียน AI Engineering Academy หรือไม่

ไม่จำเป็นต้องมีประสบการณ์มาก่อน AI Engineering Academy บน CoddyKit ออกแบบมาสำหรับผู้เริ่มต้นไปจนถึงผู้เรียนขั้นสูง คุณสามารถเริ่มต้นที่นี่หรือเริ่มจากตัวแรกและเรียนด้วยความเร็วของคุณเอง นี่คือบทเรียนที่ 1 จากทั้งหมด 4 บทเรียน

บทเรียน “การวัดเวลาแฝงของ LLM: TTFT และ TPOT” ใช้เวลานานแค่ไหน

บทเรียน CoddyKit ส่วนใหญ่ใช้เวลาประมาณ 5–10 นาที แต่ละบทเรียนจึงสั้นและเป็นแบบโต้ตอบ คุณสามารถก้าวหน้าอย่างต่อเนื่องและกลับมาเรียนต่อจากตรงที่เพิ่งหยุดบนเว็บและแอปได้เลย

ฉันเขียนและรันโค้ดในบทเรียน AI Engineering Academy นี้ได้ไหม

ได้ บทเรียน AI Engineering Academy ทุกบทมีตัวแก้ไขโค้ดในตัว คุณจึงเขียนและรันโค้ดจริงได้เลยในเบราว์เซอร์ และได้รับข้อเสนอแนะจาก AI ในทันที — ไม่ต้องติดตั้งในเครื่องของคุณ

บทเรียนทั้งหมดในหลักสูตรนี้

  1. การวัดเวลาแฝงของ LLM: TTFT และ TPOT
  2. การกระจายโหลดและกลยุทธ์หลายคีย์
  3. ผู้ให้บริการสำรองและตัวตัดวงจร
  4. งบประมาณเวลาและการลดระดับบริการอย่างราบรื่น
← กลับไปที่ AI Engineering Academy