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

Mô hình hiển thị token đầu tiên sớm nhất trong bài kiểm tra mới nhất của chúng tôi cũng là mô hình hoàn thành chậm nhất. Vào ngày 2026-10-03, chúng tôi đã truyền một prompt qua bốn mô hình. claude-sonnet-5-5 dẫn đầu về token hiển thị đầu tiên (2.981 ms) nhưng lại chậm nhất về tổng thời gian (12.384 ms). Khoảng cách đó chính là cốt lõi của sự khác biệt giữa độ trễ và thông lượng LLM: một con số cho biết người dùng phải đợi bao lâu để thấy văn bản, con số còn lại cho biết công việc hoàn thành nhanh như thế nào. Bài viết này định nghĩa từng chỉ số, trình bày các phép đo nội bộ nhỏ của chúng tôi cùng những hạn chế của chúng, và cung cấp một bộ công cụ (harness) mà bạn có thể chạy với TokenLab API.

Những điểm chính

• Ba con số, ba công việc. Thời gian đến token đầu tiên (TTFT), tổng thời gian và số token đầu ra mỗi giây trả lời cho các câu hỏi khác nhau. Chat, tác nhân (agents) và công việc hàng loạt (batch) đều dựa trên một chỉ số khác nhau.
• Tách biệt sự kiện đầu tiên khỏi token hiển thị đầu tiên. Trên deepseek-v4.1-flash, hai giá trị trung vị cách nhau 2.334 ms và 3.925 ms. Các delta suy luận (reasoning deltas) có thể đến trước bất kỳ văn bản hiển thị nào.
• Token suy luận tiêu tốn ngân sách max_tokens của bạn. Tại max_tokens 400, deepseek-v4.1-flash trả về khoảng 0 token hiển thị và gemini-3.8-flash khoảng 14 token. Ở mức 2000, cả hai đều trả lời đầy đủ.
• Đọc số lượng token từ khối usage. Đừng ước tính chúng từ ký tự.
• Tốc độ mô hình không làm tăng giới hạn yêu cầu của bạn. Giới hạn tốc độ (rate limits), giới hạn token và tốc độ mô hình là các ràng buộc riêng biệt.
• Mẫu của chúng tôi nhỏ. Nó chỉ có năm lần chạy mỗi mô hình, một client, một prompt và một ngày. Nó cho thấy cách đo lường, không phải ai là người nhanh nhất.

Ba con số tốc độ: Độ trễ LLM so với thông lượng trong thực tế

Hãy chia "tốc độ" thành các phần, vì mỗi phần có một chủ sở hữu khác nhau: mạng, mô hình và hàng đợi của riêng bạn.

gửi yêu cầu
  -> sự kiện stream đầu tiên          (bất kỳ khối SSE nào; có thể là delta suy luận)
  -> token nội dung hiển thị đầu tiên (delta.content không trống đầu tiên)
  -> token cuối cùng + khối usage cuối cùng

Thời gian đến token đầu tiên (TTFT) là thời gian từ khi gửi yêu cầu đến khi token đầu tiên đến nơi. Chúng tôi ghi lại hai phiên bản. Sự kiện stream đầu tiên là khối SSE đầu tiên thuộc bất kỳ loại nào. Token nội dung hiển thị đầu tiên là khối đầu tiên có choices[0].delta.content không trống. Đối với các mô hình suy luận trước khi trả lời, sự kiện đầu tiên có thể là một delta suy luận (delta.reasoning_content) đến trước văn bản hiển thị rất lâu. Một bộ công cụ chỉ theo dõi delta.content sẽ đo thời gian đến token hiển thị đầu tiên, không phải thời gian đến byte đầu tiên. Người dùng cảm nhận được cái hiển thị.

Tổng thời gian chạy từ khi gửi yêu cầu đến khi kết thúc stream. Nó bao gồm suy luận, thời gian mạng và bất kỳ thời gian chờ thử lại nào bạn thêm vào.

Token đầu ra mỗi giây là số token đầu ra chia cho tổng thời gian. Hãy lấy số lượng token từ usage.completion_tokens, bao gồm cả các token suy luận. Chúng tôi chia cho tổng thời gian, không phải cửa sổ hiển thị. Một số mô hình trong mẫu của chúng tôi đã gửi văn bản hiển thị trong vài khối lớn, vì vậy tỷ lệ dựa trên cửa sổ sẽ gây hiểu lầm.

Khối lượng công việc	Theo dõi đầu tiên	Sau đó	Tại sao
Chat	Token hiển thị đầu tiên	Tổng thời gian	Người dùng nhìn vào một ô trống cho đến khi văn bản hiển thị xuất hiện.
Agents	Tổng thời gian	Token hiển thị đầu tiên	Mỗi bước thường đợi bước trước đó, vì vậy tổng thời gian mỗi bước sẽ cộng dồn.
Trích xuất hàng loạt hoặc tóm tắt	Token đầu ra mỗi giây, và chi phí mỗi tác vụ	Dung lượng giới hạn yêu cầu	Không ai theo dõi token đầu tiên, và giới hạn yêu cầu của tài khoản sẽ chặn tốc độ bạn gửi công việc.

Các cuộc gọi không stream, chẳng hạn như trích xuất JSON có cấu trúc, chỉ hiển thị tổng thời gian. Hãy stream chúng trong quá trình kiểm tra nếu bạn muốn có sự phân tách.

Những gì chúng tôi đã đo lường vào ngày 2026-10-03

Phương pháp. Đây là phép đo nội bộ của TokenLab, được quan sát vào ngày 2026-10-03, đối với POST https://api.tokenlab.sh/v1/chat/completions (nguồn). Mỗi yêu cầu sử dụng stream=true và stream_options.include_usage=true. Chúng tôi đã thực hiện 5 lần chạy tuần tự mỗi mô hình từ một client duy nhất ở Đông Á, sử dụng fetch của Node 24. Prompt là "Giải thích cách HTTP keep-alive giảm độ trễ cho các client API. Viết khoảng 200 từ." Mọi mô hình đều sử dụng cài đặt suy luận mặc định. Thời gian là đồng hồ thực tế phía client, và tất cả các lần chạy đều thành công (5/5) cho mỗi hàng dưới đây.

Mô hình (max_tokens 2000)	Trung vị sự kiện stream đầu tiên	Trung vị token hiển thị đầu tiên	Trung vị tổng thời gian	Trung vị token hoàn thành (suy luận)	Ước tính token/s
deepseek-v4.1-flash	2.334 ms	3.925 ms	5.204 ms	453 (225)	87
gemini-3.8-flash	6.892 ms	6.892 ms	8.626 ms	826 (528)	96
claude-sonnet-5-5	2.981 ms	2.981 ms	12.384 ms	418 (không báo cáo)	34
gpt-5.6-luna	3.262 ms	3.262 ms	8.183 ms	313 (42)	38

Cột token/s là ước tính của chúng tôi: trung vị token hoàn thành chia cho trung vị tổng giây, ví dụ 453 ÷ 5,204 ≈ 87. Đây là tỷ lệ của các trung vị, không phải trung vị của các tỷ lệ mỗi lần chạy.

Những gì các con số cho thấy, và không hơn:

• Thứ tự theo token hiển thị đầu tiên (claude-sonnet-5-5, gpt-5.6-luna, deepseek-v4.1-flash, gemini-3.8-flash) khác với thứ tự theo tổng thời gian (deepseek-v4.1-flash, gpt-5.6-luna, gemini-3.8-flash, claude-sonnet-5-5). Một chỉ số không thể thay thế cho chỉ số kia.
• deepseek-v4.1-flash có khoảng cách 1.591 ms giữa sự kiện đầu tiên và token hiển thị đầu tiên. Trung vị đầu ra hiển thị của nó là khoảng 228 token, được gửi trong 87 sự kiện trong 1.304 ms.
• Đối với gemini-3.8-flash, sự kiện đầu tiên và token hiển thị đầu tiên có chung trung vị là 6.892 ms. Văn bản hiển thị của nó đến trong trung vị 11 sự kiện trong 1.734 ms, vì vậy stream này có dạng khối thay vì từng token một.
• claude-sonnet-5-5 đã gửi trung vị 371 sự kiện trong 9.186 ms, và gpt-5.6-luna đã gửi 265 sự kiện trong 4.901 ms.

Chi phí đi kèm với tốc độ. Giá dưới đây đến từ API mô hình TokenLab, được quan sát vào ngày 2026-10-03, với giá cập nhật ngày 2026-10-02T16:53:30.068Z. Cột cuối cùng là ước tính: trung vị token hoàn thành nhân với tỷ lệ đầu ra, chỉ tính phía đầu ra. Kiểm tra hồ sơ sử dụng để biết các khoản phí thực tế.

Mô hình	Đầu vào mỗi 1M	Đầu ra mỗi 1M	Max token đầu ra	Ước tính phía đầu ra, lần chạy trung vị	Nguồn
deepseek-v4.1-flash	$0,15 ngoài giờ cao điểm, $0,30 cao điểm	$0,60 ngoài giờ cao điểm, $1,20 cao điểm	384.000	453 × $0,60 / 1M ≈ $0,00027 ngoài giờ, ≈ $0,00054 cao điểm	model API
gemini-3.8-flash	$0,375	$1,875	65.536	826 × $1,875 / 1M ≈ $0,00155	model API
claude-sonnet-5-5	$0,60	$3	128.000	418 × $3 / 1M ≈ $0,00125	model API
gpt-5.6-luna	$0,06	$0,36	128.000	313 × $0,36 / 1M ≈ $0,00011	model API

Đối với gpt-5.6-luna, các mức giá đó áp dụng khi đầu vào tối đa là 272K token. Trên mức đó, toàn bộ yêu cầu sử dụng mức giá 2x đầu vào và 1,5x đầu ra.

Hạn chế của mẫu này. Năm lần chạy tuần tự từ một client ở Đông Á là một lát cắt mỏng. Prompt chỉ là một yêu cầu bài luận ngắn, vì vậy kết quả sẽ thay đổi theo khu vực, thời gian trong ngày, prompt và độ dài đầu ra. Chúng tôi không kiểm tra tính đồng thời, vì vậy không có gì nói lên điều gì sẽ xảy ra khi chịu tải. Hãy coi bảng này là mẫu cho bài kiểm tra của riêng bạn, chạy từ khu vực nơi các lần chạy sản xuất diễn ra. Nếu bạn muốn có cái nhìn rộng hơn về các mô hình, bảng xếp hạng API LLM của TokenLab cho nhà phát triển là một điểm khởi đầu. Kiểm tra phương pháp và ngày tháng của nó trước khi bạn tin tưởng vào bất kỳ con số tốc độ nào ở đó. Đừng thay đổi mô hình một cách âm thầm: hướng dẫn về độ tin cậy, được quan sát vào ngày 2026-10-03, lưu ý rằng việc thay thế có thể làm thay đổi chất lượng, giá cả, độ dài ngữ cảnh và công cụ.

Token suy luận và max_tokens: tại sao 400 lại trả về gần như không có gì

Chúng tôi cũng đã chạy cùng một prompt với max_tokens đặt thành 400. Cùng phương pháp, cùng năm lần chạy, cùng ngày (nguồn).

Mô hình (max_tokens 400)	Trung vị token hoàn thành	Trung vị token suy luận	Đầu ra hiển thị (xấp xỉ)	Trung vị token hiển thị đầu tiên	Trung vị tổng thời gian
deepseek-v4.1-flash	400	400	0 token	3.795 ms	4.693 ms
gemini-3.8-flash	396	382	14 token	4.199 ms	4.240 ms
claude-sonnet-5-5	400	không báo cáo	400 token	3.088 ms	11.078 ms
gpt-5.6-luna	317	42	275 token	3.040 ms	8.083 ms

Các trung vị được tính theo cột, vì vậy các cột của một hàng không cần phải mô tả một lần chạy duy nhất. Đó là lý do tại sao deepseek-v4.1-flash hiển thị thời gian hiển thị đầu tiên bên cạnh trung vị của các sự kiện hiển thị bằng không.

Kết quả rất rõ ràng. deepseek-v4.1-flash và gemini-3.8-flash đã tiêu tốn gần như toàn bộ ngân sách 400 token cho suy luận và trả về gần như không có văn bản hiển thị nào. Việc tăng max_tokens lên 2000 đã tạo ra câu trả lời đầy đủ. Token suy luận được tính trong usage.completion_tokens. Chúng được báo cáo riêng trong usage.completion_tokens_details.reasoning_tokens.

Khi chúng tôi thấy kết quả 400 token đầu tiên, lỗi trông giống như một câu trả lời trống, không phải vấn đề ngân sách. Ba bước kiểm tra làm cho nó trở nên rõ ràng:

1. Đọc khối usage cuối cùng, được kích hoạt bởi stream_options={"include_usage": True}. Nếu reasoning_tokens gần bằng completion_tokens và văn bản trống, ngân sách đã dành cho suy luận.
2. Kiểm tra finish_reason. Hướng dẫn streaming (được quan sát vào ngày 2026-10-03) liệt kê length là giá trị khi đạt giới hạn token.
3. So sánh với đầu ra tối đa của mô hình. Ví dụ, API mô hình liệt kê 384.000 cho deepseek-v4.1-flash và 65.536 cho gemini-3.8-flash, vì vậy 400 chỉ là một phần nhỏ so với những gì các mô hình cho phép.

Tham chiếu Tạo Chat Completion (được quan sát vào ngày 2026-10-03) cũng liệt kê max_completion_tokens và reasoning_effort. Nó nói rằng các giá trị được hỗ trợ phụ thuộc vào mô hình, vì vậy hãy đọc trang mô hình trước khi đặt bất kỳ giá trị nào. Chúng tôi đã không kiểm tra chúng, và chúng tôi đã chạy mọi hàng với suy luận mặc định. Hãy xác định giới hạn từ prompt của riêng bạn: trong lần chạy của chúng tôi, một câu trả lời 200 từ tạo ra khoảng 228 đến 418 token hiển thị, và thêm tới 528 token suy luận.

Bộ công cụ đo lường cho URL cơ sở TokenLab

Script này sử dụng URL cơ sở TokenLab, đọc số lượng token từ khối usage, và ghi lại sự kiện stream đầu tiên tách biệt với token nội dung hiển thị đầu tiên. Nó cũng giữ lại các header phản hồi để gỡ lỗi sau này. Nó tuân theo các cài đặt client trong tài liệu (timeout=30.0, max_retries=0) để SDK không thêm các lần thử lại ẩn vào thời gian của bạn. ID mô hình là ID chúng tôi đã đo; hãy thay thế bằng bất kỳ ID nào có định dạng yêu cầu được chấp nhận bao gồm openai_chat_completions.

import json
import os
import statistics
import time

from openai import OpenAI

client = OpenAI(
    api_key=os.environ["TOKENLAB_API_KEY"],
    base_url="https://api.tokenlab.sh/v1",
    timeout=30.0,
    max_retries=0,
)

PROMPT = "Giải thích cách HTTP keep-alive giảm độ trễ cho các client API. Viết khoảng 200 từ."

def measure(model: str, max_tokens: int = 2000) -> dict:
    start = time.perf_counter()
    raw = client.chat.completions.with_raw_response.create(
        model=model,
        messages=[{"role": "user", "content": PROMPT}],
        max_tokens=max_tokens,
        stream=True,
        stream_options={"include_usage": True},
    )
    headers = raw.headers
    first_event = first_visible = None
    visible_events = 0
    usage = None
    finish_reason = None

    for chunk in raw.parse():
        now = time.perf_counter() - start
        if first_event is None:
            first_event = now
        if chunk.usage is not None:
            usage = chunk.usage
        if not chunk.choices:
            continue
        choice = chunk.choices[0]
        if choice.delta.content:
            visible_events += 1
            if first_visible is None:
                first_visible = now
        if choice.finish_reason:
            finish_reason = choice.finish_reason

    total = time.perf_counter() - start
    details = getattr(usage, "completion_tokens_details", None)
    completion = usage.completion_tokens if usage else None
    return {
        "model": model,
        "request_id": headers.get("x-request-id"),
        "routing_time_ms": headers.get("x-routing-time-ms"),
        "first_event_s": first_event,
        "first_visible_s": first_visible,
        "total_s": total,
        "completion_tokens": completion,
        "reasoning_tokens": getattr(details, "reasoning_tokens", None),
        "visible_events": visible_events,
        "finish_reason": finish_reason,
        "tokens_per_s": completion / total if completion else None,
    }

if __name__ == "__main__":
    runs = [measure("gemini-3.8-flash") for _ in range(5)]
    print(json.dumps(runs[0], indent=2))
    print("trung vị total_s:", statistics.median(r["total_s"] for r in runs))

Một vài lưu ý về việc đọc đầu ra:

• first_event_s kích hoạt trên bất kỳ khối nào, bao gồm khối chỉ có vai trò hoặc khối suy luận. first_visible_s chỉ kích hoạt trên delta.content không trống. Nếu hai giá trị này chênh lệch vài giây, mô hình đang suy luận trước khi trả lời.
• Số lượng token đến từ khối usage cuối cùng. Khối đó có danh sách choices trống, đó là lý do tại sao vòng lặp kiểm tra chunk.usage trước khi bỏ qua nó.
• Chạy nó năm lần trở lên, ghi lại khu vực, và báo cáo trung vị cùng với kích thước mẫu.
• Đối với các mô hình liệt kê openai_responses, hướng dẫn streaming hiển thị các phản hồi streaming với các sự kiện response.output_text.delta và response.completed. Sự phân tách tương tự áp dụng: đo thời gian sự kiện đầu tiên, sau đó là delta văn bản đầu tiên.
• Hãy coi một stream đóng trước response.completed hoặc lý do kết thúc stop là chưa hoàn thành, không phải là thành công nhanh.

Các header và định danh cần ghi lại để gỡ lỗi độ trễ

Một yêu cầu chậm rất khó gỡ lỗi nếu bạn chỉ giữ lại thời lượng. Tham chiếu API và hướng dẫn khắc phục sự cố, cả hai được quan sát vào ngày 2026-10-03, nêu tên các định danh đáng giữ lại.

Định danh	Nơi xuất hiện	Sử dụng cho
X-Request-ID	Header phản hồi, khi có sẵn	Hỗ trợ và gỡ lỗi cho một yêu cầu
request_id	Thân lỗi, nhật ký bảng điều khiển, hồ sơ sử dụng	Hỗ trợ cấp yêu cầu và đối soát
X-Routing-Time-MS	Header phản hồi, khi có sẵn	Thời gian dành cho việc chọn phân phối, trước khi tạo
X-Task-ID, task_id, poll_url	Phản hồi tạo và trạng thái bất đồng bộ	Các tác vụ hình ảnh, video, âm nhạc và 3D
X-Billing-Transaction-ID	Header sau khi thanh toán cuối cùng, khi có sẵn	Đối soát chi phí
ID tác vụ hoặc người dùng của riêng bạn	Ứng dụng của bạn	Tìm yêu cầu đằng sau khiếu nại của người dùng

Đối với mỗi cuộc gọi, hãy ghi lại endpoint, phương thức, mô hình, mã trạng thái, dấu thời gian và độ trễ. Thêm các tên trường bạn đã gửi (không phải prompt), số lần thử lại của bạn, và liệu việc thử lại có tạo ra tác vụ mới hay tiếp tục tác vụ cũ. Bộ công cụ của chúng tôi thêm thời gian phân tách và số lượng token từ khối usage.

Hai cảnh báo. Phản hồi streaming có thể ổn định sau khi stream kết thúc, vì vậy header thanh toán có thể vắng mặt ngay cả khi việc sử dụng được ghi lại sau đó. Đối với số tiền đã thanh toán, hãy sử dụng hồ sơ sử dụng của Management API thay vì chỉ số lượng token phản hồi. Ngoài ra, hãy ghi lại giá trị X-TokenLab-Delivery-Policy nếu bạn đặt một giá trị. Tham chiếu nói rằng nó chấp nhận auto, verified hoặc official, rằng một giá trị không hợp lệ trả về 400, và một tùy chọn không khả dụng trả về 503 với code: delivery_tier_unavailable và retryable: true. Không bao giờ ghi lại Authorization, khóa API, URL đã ký, prompt đầy đủ hoặc dữ liệu cá nhân.

Chi tiết yêu cầu bảng điều khiển được giữ trong 30 ngày kể từ khi ghi lại, vì vậy hãy sao chép các ID bạn cần vào nhật ký của riêng bạn. Trong đường ống của chúng tôi, chúng tôi sắp xếp các ID này theo chế độ xem yêu cầu; bài đăng về bảng điều khiển yêu cầu TokenLab đề cập đến chế độ xem đó.

Giới hạn tốc độ, thử lại và độ trễ LLM so với thông lượng

Tốc độ mỗi stream và thông lượng tài khoản là các trần khác nhau. Hướng dẫn giới hạn tốc độ, được quan sát vào ngày 2026-10-03, liệt kê các giá trị tầng tiêu chuẩn bên dưới. Nó lưu ý rằng chúng có thể thay đổi theo cấu hình đang hoạt động và được thực thi trên mỗi khóa API.

Tầng	Yêu cầu mỗi phút
Người dùng	1.000
Đối tác	10.000
VIP	10.000

Khi bạn vượt quá giới hạn, API trả về 429 rate_limit_exceeded với header Retry-After. Thân phản hồi ví dụ của hướng dẫn mang "retryable": true và "retry_after": 8. Hướng dẫn nói hãy tin tưởng các giá trị X-RateLimit-Limit và Retry-After được trả về hơn bất kỳ bảng nào được sao chép. Nó cũng nói rằng một mô hình nhanh hơn không làm tăng giới hạn yêu cầu của tài khoản bạn.

Đây là phép tính cho công việc hàng loạt. Đây là ước tính của chúng tôi từ các trung vị trên, không phải kiểm tra tải. Các stream đồng thời xấp xỉ yêu cầu mỗi giây nhân với giây mỗi yêu cầu. Tại 1.000 yêu cầu mỗi phút (khoảng 16,7 mỗi giây):

• Với deepseek-v4.1-flash tại trung vị tổng 5,204 s, khoảng 87 stream chạy cùng lúc.
• Với claude-sonnet-5-5 tại trung vị 12,384 s, khoảng 206 stream chạy cùng lúc.

Một stream chậm hơn có nghĩa là cần nhiều tính đồng thời hơn để đạt được cùng tốc độ yêu cầu. Việc đạt giới hạn sau đó thêm thời gian chờ vào thời gian tạo. Giới hạn token không được đề cập trong các trang chúng tôi đã sử dụng, vì vậy hãy kiểm tra tài khoản của bạn và trang mô hình cho những giới hạn đó.

Cách thử lại mà không làm hỏng các con số của bạn:

• Tôn trọng Retry-After khi có mặt. Nếu không, hãy sử dụng exponential backoff với jitter ngẫu nhiên và giới hạn thử lại cứng.
• Đặt SDK thành max_retries=0 và thử lại ở một nơi. Nếu không, hai lớp sẽ thử lại cùng một cuộc gọi và thời gian của bạn sẽ bị tính gấp đôi.
• Không bao giờ thử lại các lỗi xác thực, ủy quyền, số dư hoặc quyền. Thử lại các phản hồi 5xx tạm thời với backoff ngắn.
• Sau khi sự kiện đầu tiên đến, một stream bị gián đoạn là chưa hoàn thành và không được khởi động lại tự động. Việc lặp lại yêu cầu có thể tạo ra đầu ra khác và một khoản phí khác.
• Ghi lại số lần thử lại và thời gian chờ tách biệt với thời gian mô hình, để một lần chạy bị điều tiết không trông giống như một mô hình chậm.

Đây là mô hình thử lại có giới hạn của hướng dẫn:

import random
import time
from openai import RateLimitError

def chat_with_rate_limit_retry(client, model, messages, attempts=4):
    for attempt in range(attempts):
        try:
            return client.with_options(max_retries=0).chat.completions.create(
                model=model,
                messages=messages,
            )
        except RateLimitError as exc:
            if attempt == attempts - 1:
                raise
            header = exc.response.headers.get("Retry-After")
            wait = float(header) if header else min(30, 2 ** attempt + random.random())
            time.sleep(wait)

Ngoài ra, hãy giới hạn tính đồng thời, không chỉ số yêu cầu trung bình mỗi phút, và xếp hàng các đợt bùng nổ. Theo dõi các phản hồi 429 lặp lại trên mỗi khóa API để một client không thể lấn át phần còn lại của ứng dụng của bạn.

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

Token mỗi giây cao hơn có luôn là trải nghiệm người dùng nhanh hơn không?

Không. Trong mẫu ngày 2026-10-03 của chúng tôi, claude-sonnet-5-5 cho thấy token hiển thị đầu tiên sớm nhất (2.981 ms) nhưng tổng thời gian dài nhất (12.384 ms). deepseek-v4.1-flash bắt đầu văn bản hiển thị muộn hơn (3.925 ms) và hoàn thành đầu tiên (5.204 ms). Cái nào cảm thấy nhanh hơn phụ thuộc vào việc người dùng xem stream hay đợi câu trả lời đầy đủ. Năm lần chạy từ một client không thể giải quyết điều đó cho khối lượng công việc của bạn.

Tại sao phản hồi stream của tôi trả về với gần như không có văn bản?

Bạn có thể đã tiêu tốn ngân sách cho suy luận. Tại max_tokens 400, deepseek-v4.1-flash đã sử dụng 400 token suy luận và trả về khoảng 0 token hiển thị. Kiểm tra usage.completion_tokens_details.reasoning_tokens trong khối usage cuối cùng và finish_reason. Sau đó tăng giới hạn; ở mức 2000, cả hai mô hình suy luận trong bài kiểm tra của chúng tôi đều trả lời đầy đủ.

Mô hình nhanh hơn có làm tăng giới hạn tốc độ của tôi không?

Không. Hướng dẫn giới hạn tốc độ nói rằng tốc độ mô hình, giới hạn token và giới hạn tốc độ tài khoản là các ràng buộc riêng biệt. Một stream nhanh hơn kết thúc sớm hơn và giải phóng một khe đồng thời, nhưng giới hạn yêu cầu mỗi khóa của bạn vẫn giữ nguyên. Hãy yêu cầu hỗ trợ một giới hạn khác nếu bạn cần.

Tôi nên gửi ID nào cho bộ phận hỗ trợ khi stream chậm?

Gửi request_id (hoặc X-Request-ID), endpoint, phương thức, mô hình, dấu thời gian và mã trạng thái. Thêm task_id và poll_url cho công việc bất đồng bộ và billing_transaction_id khi có mặt. Bao gồm thời gian phân tách của bạn và thân lỗi an toàn, và biên tập lại các khóa, prompt và phương tiện riêng tư trước.

Chạy bộ công cụ trên với prompt của riêng bạn, sau đó so sánh những gì bạn đo lường với bảng xếp hạng mô hình TokenLab.