Độ trễ và Thông lượng của LLM: Cách người mua API nên đo lường tốc độ

Khi đánh giá các API mô hình, việc hiểu rõ sự đánh đổi giữa độ trễ (latency) và thông lượng (throughput) của LLM là điều cần thiết để tối ưu hóa cả trải nghiệm người dùng lẫn chi phí cơ sở hạ tầng. Độ trễ đo lường thời gian trôi qua để một mô hình phản hồi truy vấn, trong khi thông lượng đo lường khối lượng token được xử lý hoặc tạo ra bởi hệ thống trong một khoảng thời gian cụ thể. Đối với các nhà phát triển và người xây dựng sản phẩm AI, việc tối ưu hóa một chỉ số thường đòi hỏi phải đánh đổi với chỉ số còn lại.

Việc chọn sai chỉ số tốc độ có thể dẫn đến giao diện người dùng chậm chạp hoặc hóa đơn API cao không cần thiết. Bài phân tích này cung cấp một khung làm việc để đo lường các chỉ số này, chọn đúng API cho khối lượng công việc cụ thể của bạn và triển khai các chiến lược tối ưu hóa.

Các điểm chính cần lưu ý

• Thời gian đến token đầu tiên (TTFT) là chỉ số độ trễ quan trọng đối với các ứng dụng tương tác như giao diện trò chuyện, ảnh hưởng trực tiếp đến tốc độ cảm nhận của người dùng.
• Token mỗi giây (TPS) trên mỗi luồng là chỉ số thông lượng chính cho các tác vụ xử lý nền, chẳng hạn như tóm tắt tài liệu hoặc trích xuất dữ liệu hàng loạt.
• Kiến trúc và kích thước mô hình quyết định hiệu suất cơ bản, với các mô hình nhỏ hơn như DeepSeek V4 Flash hoặc Gemini 3.5 Flash mang lại tốc độ nhanh hơn các mô hình hàng đầu như Claude Fable 5 hoặc GPT-5.5.
• Định tuyến đa nhà cung cấp (Multi-provider routing) cho phép các nhà phát triển tối ưu hóa độ trễ hoặc thông lượng một cách linh hoạt dựa trên hiệu suất thời gian thực của nhà cung cấp.

---

Định nghĩa các chỉ số cốt lõi: Độ trễ so với Thông lượng

Để đưa ra quyết định sáng suốt khi mua hoặc định tuyến API, các nhà phát triển phải chia nhỏ "tốc độ" thành các thành phần riêng biệt, có thể đo lường được.

Dòng thời gian của một yêu cầu API LLM:
[Người dùng gửi yêu cầu] 
       │
       ▼ (Truyền tải mạng + Xử lý prompt)
[Thời gian đến token đầu tiên (TTFT)] <--- Quan trọng cho UX tương tác
       │
       ▼ (Tạo tự hồi quy: Token mỗi giây)
[Độ trễ giữa các token (ITL)]  <--- Quyết định sự thoải mái khi đọc
       │
       ▼ (Hoàn tất tạo nội dung)
[Tổng độ trễ]              <--- Quan trọng cho các cuộc gọi chặn không phát trực tuyến

1. Thời gian đến token đầu tiên (TTFT)

TTFT là khoảng thời gian giữa việc gửi yêu cầu API và nhận được token đầu tiên của phản hồi. Chỉ số này bao gồm thời gian khứ hồi mạng, tuần tự hóa prompt và thời gian cần thiết để mô hình xử lý các token đầu vào (giai đoạn prefill). Đối với các ứng dụng tương tác, TTFT là chỉ số quan trọng nhất vì nó quyết định tốc độ người dùng thấy phản hồi bắt đầu xuất hiện.

2. Độ trễ giữa các token (ITL)

ITL là thời gian trung bình trôi qua giữa việc tạo các token liên tiếp trong giai đoạn phát trực tuyến (streaming). Nếu ITL quá cao, văn bản sẽ xuất hiện chậm hơn tốc độ đọc của con người, dẫn đến trải nghiệm người dùng gây thất vọng. Một ITL ổn định, thấp đảm bảo việc hiển thị văn bản mượt mà.

3. Token mỗi giây (TPS)

TPS đại diện cho thông lượng tạo nội dung của mô hình. Nó được tính bằng tổng số token đầu ra chia cho tổng thời gian tạo (không bao gồm giai đoạn prefill). Khi đánh giá thông lượng, các nhà phát triển phải phân biệt giữa:

• TPS người dùng đơn lẻ: Tốc độ tạo của một luồng hoạt động duy nhất.
• Thông lượng hệ thống: Tổng số token mà nhà cung cấp API có thể xử lý đồng thời trên tất cả người dùng đang hoạt động.

4. Tổng độ trễ

Tổng độ trễ là khoảng thời gian hoàn chỉnh của yêu cầu API từ đầu đến cuối. Đối với các yêu cầu không phát trực tuyến, chẳng hạn như trích xuất JSON có cấu trúc hoặc phân loại nền, tổng độ trễ là chỉ số chính cần theo dõi.

---

Sự đánh đổi về kiến trúc: Tại sao tốc độ lại khác nhau

Sự đánh đổi giữa độ trễ LLM và thông lượng bắt nguồn từ vật lý của kiến trúc transformer và băng thông bộ nhớ phần cứng. Trong giai đoạn prefill (quyết định TTFT), việc tính toán có khả năng song song hóa cao vì toàn bộ prompt đầu vào được xử lý cùng lúc. Giai đoạn này thường bị giới hạn bởi khả năng tính toán (compute-bound).

Trong giai đoạn tạo nội dung (quyết định TPS), mô hình tạo từng token một. Mỗi token mới yêu cầu tải tất cả trọng số mô hình từ Bộ nhớ băng thông cao (HBM) vào SRAM của GPU. Quá trình tự hồi quy này bị giới hạn bởi băng thông bộ nhớ (memory-bandwidth bound).

Do những hạn chế này, các nhà phát triển phải căn chỉnh lựa chọn mô hình của họ với các yêu cầu hiệu suất chính:

• Các mô hình hàng đầu: Các mô hình như Claude Fable 5, Claude Opus 4.8 và GPT-5.5 ưu tiên chiều sâu lập luận hơn tốc độ thô. Chúng có số lượng tham số khổng lồ, dẫn đến TTFT cao hơn và TPS thấp hơn.
• Các mô hình nhanh, chi phí thấp: Các mô hình như DeepSeek V4 Flash, Gemini 3.5 Flash và Laguna XS 2.1 được tối ưu hóa cho tốc độ. Chúng sử dụng số lượng tham số nhỏ hơn, giải mã suy đoán (speculative decoding) hoặc kiến trúc chưng cất (distilled architectures) để mang lại TTFT cực thấp và TPS cao.

Các nhà phát triển có thể tham khảo Bảng xếp hạng API LLM của TokenLab dành cho nhà phát triển để so sánh các chỉ số tốc độ thời gian thực giữa các cấp độ mô hình này.

---

Khung quyết định: Khi nào nên ưu tiên độ trễ so với thông lượng

Sự ưu tiên giữa độ trễ và thông lượng phụ thuộc hoàn toàn vào trường hợp sử dụng của ứng dụng.

Trường hợp sử dụng	Chỉ số chính	Chỉ số phụ	Lớp mô hình khuyến nghị
Chatbot tương tác	Thời gian đến token đầu tiên (TTFT)	Độ trễ giữa các token (ITL)	Fast Frontier (ví dụ: Gemini 3.5 Flash)
Trợ lý lập trình	TTFT & TPS luồng đơn	Tổng độ trễ	Lập trình chuyên dụng (ví dụ: Claude Sonnet 5, Kimi K2.7 Code)
Trích xuất dữ liệu hàng loạt	Thông lượng hệ thống	Chi phí mỗi tác vụ	Open-Weight chi phí thấp (ví dụ: DeepSeek V4 Flash, GLM-5.2)
Tác nhân tự hành	Tổng độ trễ (Không phát trực tuyến)	TTFT	Open-Weight lập luận cao (ví dụ: DeepSeek V4 Pro)
Tạo ảnh/video	Tổng độ trễ	Chi phí mỗi ảnh	API phương tiện chuyên dụng (ví dụ: Nano Banana 2, Seedance)

Ứng dụng tương tác (Ưu tiên độ trễ)

Đối với giao diện hội thoại, bot hỗ trợ khách hàng và trợ lý tìm kiếm trực tiếp, tỷ lệ giữ chân người dùng sẽ giảm nếu hệ thống phản hồi chậm. Các nhà phát triển nên ưu tiên giảm thiểu TTFT. Ngay cả khi tổng thời gian tạo mất vài giây, TTFT dưới 300 mili giây vẫn giúp người dùng duy trì sự tương tác.

Xử lý hàng loạt và đường ống (Ưu tiên thông lượng)

Đối với các tác vụ ngoại tuyến như xử lý hàng nghìn hóa đơn PDF, tạo báo cáo hàng ngày hoặc chạy đánh giá hàng loạt, TTFT không quan trọng. Mục tiêu là tối đa hóa tổng khối lượng token được xử lý mỗi phút với chi phí thấp nhất có thể. Các nhà phát triển nên tập trung vào thông lượng hệ thống và hiệu quả chi phí. Để phân tích chuyên sâu về tối ưu hóa chi phí trong quá trình xử lý hàng loạt, hãy xem Điểm chuẩn định tuyến mô hình AI của TokenLab về chi phí mỗi tác vụ.

---

Đo lường hiệu suất API: Ví dụ mã thực tế

Để đo lường chính xác TTFT, ITL và TPS, các nhà phát triển phải sử dụng các API phát trực tuyến và ghi lại dấu thời gian tại các điểm cụ thể trong vòng đời yêu cầu. Dưới đây là tập lệnh Python có thể chạy được sử dụng máy khách tương thích với OpenAI để đo lường các chỉ số này cho một mô hình nhất định.

import time
import os
from openai import OpenAI

# Khởi tạo client (được cấu hình cho OpenRouter hoặc bất kỳ nhà cung cấp tương thích nào)
client = OpenAI(
    base_url="https://openrouter.ai/api/v1",
    api_key=os.environ.get("OPENROUTER_API_KEY", "your_api_key_here")
)

def measure_api_performance(model_name: str, prompt: str):
    print(f"Đang đánh giá các chỉ số tốc độ cho: {model_name}")
    
    start_time = time.time()
    response = client.chat.completions.create(
        model=model_name,
        messages=[{"role": "user", "content": prompt}],
        stream=True
    )
    
    ttft = None
    token_timestamps = []
    total_tokens = 0
    
    for chunk in response:
        chunk_time = time.time()
        # Kiểm tra xem nội dung văn bản có trong chunk không
        if chunk.choices and chunk.choices[0].delta.content:
            content = chunk.choices[0].delta.content
            # Ước tính số lượng token (1 token ≈ 4 ký tự để đo lường sơ bộ)
            estimated_tokens = max(1, len(content) // 4)
            total_tokens += estimated_tokens
            
            if ttft is None:
                ttft = chunk_time - start_time
                print(f"-> Thời gian đến token đầu tiên (TTFT): {ttft:.3f} giây")
            
            token_timestamps.append(chunk_time)
            
    end_time = time.time()
    total_duration = end_time - start_time
    generation_time = total_duration - ttft if ttft else total_duration
    
    # Tính toán độ trễ giữa các token (ITL) và Token mỗi giây (TPS)
    if len(token_timestamps) > 1:
        intervals = [token_timestamps[i] - token_timestamps[i-1] for i in range(1, len(token_timestamps))]
        avg_itl = sum(intervals) / len(intervals)
        tps = total_tokens / generation_time if generation_time > 0 else 0
    else:
        avg_itl = 0
        tps = 0
        
    print(f"-> Tổng độ trễ: {total_duration:.3f} giây")
    print(f"-> Độ trễ trung bình giữa các token (ITL): {avg_itl:.3f} giây")
    print(f"-> Thông lượng ước tính (TPS): {tps:.2f} token/giây")
    print("-" * 50)

# Ví dụ sử dụng với một mô hình nhanh, chi phí thấp
if __name__ == "__main__":
    test_prompt = "Viết một bài luận 200 từ về lịch sử máy tính."
    # Sử dụng ví dụ mô hình định tuyến chi phí thấp hiện tại
    measure_api_performance("google/gemini-3.5-flash", test_prompt)

---

Chiến lược tối ưu hóa cho người mua API

Nếu các phép đo của bạn cho thấy API đã chọn quá chậm hoặc quá đắt, một số chiến lược tối ưu hóa có thể cải thiện hiệu suất.

1. Tối ưu hóa Prompt và giảm Prefill

Vì giai đoạn prefill tỷ lệ thuận với kích thước của prompt đầu vào, việc giảm độ dài prompt sẽ trực tiếp làm giảm TTFT.

• Loại bỏ các hướng dẫn dư thừa.
• Sử dụng bộ nhớ đệm prompt hệ thống (system prompt caching) nếu nhà cung cấp hỗ trợ. Điều này cho phép máy chủ API lưu trữ trạng thái đã biên dịch của một prompt hệ thống dài, bỏ qua việc tính toán prefill trong các yêu cầu tiếp theo.

2. Định tuyến nhà cung cấp động

Theo tài liệu lựa chọn nhà cung cấp của OpenRouter, hiệu suất của một mô hình có thể thay đổi đáng kể tùy thuộc vào máy chủ (nhà cung cấp) nào phục vụ yêu cầu. Một số nhà cung cấp tối ưu hóa cho độ trễ thấp, trong khi những nhà cung cấp khác cung cấp chi phí thấp hơn nhưng đánh đổi bằng tốc độ.

Bằng cách sử dụng các lớp định tuyến, các nhà phát triển có thể:

• Truy vấn nhiều nhà cung cấp để tìm độ trễ thấp nhất hiện tại.
• Thiết lập các đường dẫn dự phòng để nếu một nhà cung cấp chính gặp sự cố về độ trễ, các yêu cầu sẽ tự động chuyển hướng đến một giải pháp thay thế nhanh hơn.
• Lọc các nhà cung cấp dựa trên các ngưỡng hiệu suất cụ thể.

3. Phân tầng mô hình

Đừng sử dụng các mô hình hàng đầu như Claude Fable 5 hoặc GPT-5.5 cho các tác vụ có thể được xử lý bởi các mô hình nhỏ hơn. Hãy triển khai một bộ định tuyến gửi các truy vấn đơn giản (ví dụ: phân loại, định dạng) đến DeepSeek V4 Flash hoặc GLM-5.2, chỉ dành các mô hình đắt tiền cho các bước lập luận phức tạp.

---

Hạn chế của các điểm chuẩn tốc độ

Khi đánh giá các chỉ số tốc độ, các nhà phát triển nên lưu ý những hạn chế sau:

• Biến động mạng: Độ trễ API phụ thuộc rất nhiều vào khoảng cách vật lý giữa máy chủ ứng dụng của bạn và khu vực lưu trữ của nhà cung cấp API. Luôn chạy các điểm chuẩn từ các máy chủ đặt tại cùng khu vực với triển khai sản xuất của bạn.
• Tắc nghẽn nhà cung cấp: Thông lượng và độ trễ dao động trong suốt cả ngày dựa trên các mô hình lưu lượng truy cập toàn cầu. Một lần chạy điểm chuẩn duy nhất không đại diện cho hiệu suất sản xuất nhất quán.
• Sự khác biệt trong ước tính token: Các mô hình khác nhau sử dụng các bộ mã hóa token (tokenizer) khác nhau. Một mô hình có TPS cao hơn có thể không thực sự nhanh hơn nếu bộ mã hóa của nó chia nhỏ các từ thành nhiều token nhỏ hơn so với mô hình cạnh tranh.

---

Câu hỏi thường gặp

Thông lượng (TPS) cao hơn có luôn đồng nghĩa với trải nghiệm người dùng nhanh hơn không?

Không. Nếu một API có thông lượng cao nhưng TTFT kém, người dùng sẽ trải qua một khoảng dừng dài, không phản hồi trước khi văn bản đột ngột xuất hiện trên màn hình. Đối với các ứng dụng tương tác, TTFT thấp quan trọng hơn TPS cao.

Bộ nhớ đệm prompt ảnh hưởng đến độ trễ như thế nào?

Bộ nhớ đệm prompt làm giảm đáng kể TTFT cho các prompt dài. Bằng cách lưu trữ các token đã xử lý của các hướng dẫn hệ thống hoặc tài liệu ngữ cảnh, nhà cung cấp sẽ bỏ qua giai đoạn prefill nặng nề về tính toán trong các yêu cầu tiếp theo, dẫn đến thời gian phản hồi nhanh hơn.

Tôi nên chọn mô hình open-weight hay closed-source để có tốc độ tốt nhất?

Điều đó phụ thuộc vào cơ sở hạ tầng lưu trữ. Các mô hình open-weight như Qwen3.7 Plus, GLM-5.2 hoặc DeepSeek V4 Pro có thể được triển khai trên phần cứng riêng tư chuyên dụng, cho phép bạn đảm bảo thông lượng. Tuy nhiên, các API closed-source được quản lý thường sử dụng cơ sở hạ tầng khổng lồ, được tối ưu hóa mà có thể khó sao chép hiệu quả về chi phí trên các phiên bản riêng tư. Bạn có thể so sánh các bảng xếp hạng hiệu suất hiện tại trên Bảng xếp hạng mô hình của TokenLab.

---

Các bước tiếp theo

Để tối ưu hóa tốc độ và hiệu quả chi phí cho ứng dụng của bạn, hãy bắt đầu bằng cách đo lường khối lượng công việc sản xuất hiện tại của bạn bằng cách sử dụng các chỉ số phát trực tuyến được nêu ở trên.

Bạn đã sẵn sàng đánh giá và so sánh các mô hình mới nhất cho đường ống sản xuất của mình chưa? Bắt đầu ngay với bảng xếp hạng mô hình toàn diện của TokenLab để tìm sự cân bằng tối ưu giữa độ trễ, thông lượng và chi phí cho ứng dụng của bạn.