GPT-6 Sol Độ Trễ: 102 Giây Đến Token Đầu Tiên

Bạn đã thay thế gpt-6-astra bằng gpt-6-sol vì giá token đã giảm từ 10 đô la và 50 đô la mỗi triệu xuống còn 2 đô la và 10 đô la. Hóa đơn trông rất tốt. Thế rồi, thời gian phản hồi p95 của bạn vượt quá hai phút, bộ cân bằng tải của bạn bắt đầu trả về lỗi gateway timeout, và bộ phận hỗ trợ tràn ngập các câu hỏi về việc tại sao trang web bị treo.

Không có gì bị hỏng. Bạn đã thay đổi hình dạng của khối lượng công việc, chứ không chỉ giá của nó.

Artificial Analysis đo GPT-6 Sol đạt 115.2 token đầu ra mỗi giây với thời gian cho token đầu tiên là 102.15 giây. GPT-6 Luna đạt 153.9 token đầu ra mỗi giây với 124.23 giây cho token đầu tiên. Hai con số này đi kèm với những lưu ý quan trọng, đó là nửa đầu của bài viết này. Nửa sau là về những gì cần làm với chúng: cách đo độ trễ của token đầu tiên một cách trung thực trên khối lượng công việc của riêng bạn, và bốn thay đổi thiết kế giúp một mô hình 100 giây không làm API của bạn sập theo.

Để có bối cảnh rộng hơn về ba lần ra mắt đột phá trong hai ngày, hãy xem cuộc chiến giá mô hình AI tháng 9 năm 2026.

Con số, và mọi thứ sai lầm khi trích dẫn nó

Đọc cột lưu ý trước cột số liệu.

Ba điều mà cột đó đang nói với bạn.

Đây là số liệu của Artificial Analysis, không phải của OpenAI. OpenAI đã công bố giá, ngữ cảnh, tính khả dụng và một loạt điểm chuẩn khi ra mắt. Họ không công bố con số độ trễ trong tài liệu chúng tôi đọc. Vì vậy, 102.15 giây là của một bên thứ ba chạy bộ kiểm tra riêng trên mạng riêng của họ, và bạn nên coi nó là chỉ dẫn chứ không phải là một đặc điểm kỹ thuật. Hãy ghi chú nó trong tài liệu của riêng bạn theo cách chúng tôi ghi chú ở đây.

Chúng mô tả biến thể lý luận “tối đa”. Các nhãn nỗ lực xuất hiện khắp các bảng điểm chuẩn của cả hai nhà cung cấp khi ra mắt: thấp, trung bình, cao, rất cao, tối đa. Tối đa là cấp cao nhất trong thang đó, và nỗ lực lý luận là đòn bẩy lớn nhất đối với độ trễ của token đầu tiên. Một phép đo cấu hình chậm nhất không phải là phép đo cấu hình bạn sẽ chạy trong sản xuất.

Chúng là các phép đo của một điểm cuối của nhà cung cấp tại một thời điểm. Dung lượng phục vụ, định tuyến và độ sâu hàng đợi thay đổi. Một số liệu trong tuần ra mắt được lấy trong thời điểm lưu lượng truy cập tăng đột biến là trường hợp xấu nhất giả mạo thành một hằng số.

Những gì còn lại sau cả ba lưu ý là hướng đi, và hướng đi là trọng tâm của bài viết này. Mô hình rẻ tiền không phải là mô hình nhanh. Sol có giá bằng một phần năm của Astra mỗi token và Luna có giá bằng một phần hai mươi của Sol, và không có mức giảm giá nào trong số đó mang lại cho bạn một byte đầu tiên nhanh hơn. Theo phép đo này, mô hình rẻ nhất trong dòng sản phẩm lại là mô hình khởi động chậm nhất.

Thời gian cho token đầu tiên là tên gọi sai cho những gì bạn đang đo lường

Trên một mô hình không lý luận, thời gian cho token đầu tiên gần đúng là mạng cộng hàng đợi cộng tiền nạp. Nó tỷ lệ với độ dài lời nhắc và nằm trong hàng trăm mili giây.

Trên một mô hình lý luận, đó là một đại lượng khác mang cùng một nhãn. Mô hình thực hiện suy nghĩ trước khi phát ra bất cứ điều gì bạn yêu cầu, vì vậy khoảng cách trước token hiển thị đầu tiên chứa toàn bộ giai đoạn lý luận. Giai đoạn đó không liên quan đến độ dài lời nhắc của bạn. Nó liên quan đến việc mô hình đánh giá vấn đề khó đến mức nào.

Hai hệ quả sau đó, và cả hai đều gây khó khăn trong sản xuất.

Điều đầu tiên là tốc độ token nhanh không cứu bạn. Sol phát ra 115.2 token mỗi giây khi nó bắt đầu, khá nhanh. Điều này không quan trọng lắm, vì gần như toàn bộ thời gian thực tế được dành trước token đầu tiên.

Thời gian tạo là độ dài đầu ra chia cho 115.2 token mỗi giây, vì vậy bảng đó là phép tính số học trên hai số liệu đo được chứ không phải một phép đo mới. Rút ngắn phản hồi của bạn hầu như không làm thay đổi tổng thời gian. Cắt bớt một câu trả lời dài dòng từ 2.000 token xuống 500 token giúp tiết kiệm mười ba giây trong một cuộc gọi hai phút.

Hệ quả thứ hai là thứ tự xếp hạng thay đổi tùy thuộc vào độ dài phản hồi. Luna có tốc độ token nhanh hơn và khởi động chậm hơn. Chạy hai dòng đối với nhau và chúng giao nhau ở khoảng 10.100 token đầu ra: dưới mức đó, Sol hoàn thành trước mặc dù tạo ra chậm hơn, và trên mức đó, tốc độ của Luna cuối cùng mới bù đắp được thời gian chờ lâu hơn của nó. Hầu như không có gì bạn phục vụ cho người dùng là phản hồi 10.000 token, vì vậy đối với hầu hết các khối lượng công việc, mô hình khởi động chậm hơn đơn giản là mô hình chậm hơn.

Điều gì hỏng trước tiên

Sự cố hiếm khi xảy ra ở chính cuộc gọi mô hình. Đó là mọi thứ bao quanh nó được thiết kế cho một API nhanh.

Thời gian chờ không hoạt động (Idle timeouts). Các bộ cân bằng tải, proxy ngược, cổng API và nền tảng serverless đều giới hạn thời gian kết nối có thể tồn tại mà không có byte nào chảy qua. Nhiều giá trị mặc định đó nằm dưới hai phút. Đừng tin một con số bạn đọc trong một bài đăng trên blog, kể cả bài này: hãy tự mình đọc cấu hình của bạn. Cách khắc phục thường là một chỉ thị, chẳng hạn như proxy_read_timeout trên nginx, cộng với cài đặt phù hợp trên mọi bước nhảy phía trước nó, bao gồm cả thời gian chờ của SDK phía client.

Thử lại (Retries). Một chính sách thử lại hợp lý ở 300 mili giây trở nên nguy hiểm ở 100 giây. Ba lần thử với backoff giờ đây là một yêu cầu mất năm phút, và một loạt các lần thử lại trong một giai đoạn chậm sẽ đặt thêm công việc đồng thời lên chính điểm cuối đã gặp khó khăn. Giới hạn số lần thử, duy trì một bộ ngắt mạch (circuit breaker), và biến mọi cuộc gọi trở thành idempotent để một lần thử lại không thể tính phí hoặc ghi hai lần.

Đồng thời (Concurrency), điều mà mọi người thường bỏ qua. Định luật Little nói rằng số lượng yêu cầu đang thực hiện bằng tốc độ đến nhân với thời gian trong hệ thống. Với một yêu cầu mỗi giây và một cuộc gọi 120 giây, bạn cần 120 yêu cầu đồng thời đang thực hiện chỉ để duy trì. Các kết nối đó chiếm các socket, luồng hoặc lời gọi hàm trong hai phút mỗi cái, và không có cái nào trong số đó hiển thị trên hóa đơn token. Một mô hình rẻ tiền mỗi cuộc gọi vẫn có thể đắt tiền mỗi giây của dung lượng đã giữ.

Giao diện người dùng. Không có spinner nào tồn tại 102 giây. Nếu giai đoạn lý luận nằm trên đường dẫn yêu cầu đồng bộ của bạn, cách khắc phục là kiến trúc, không phải thẩm mỹ.

Cách đo lường nó trên khối lượng công việc của riêng bạn

Số liệu của nhà cung cấp và bên thứ ba là một giả thuyết ban đầu. Lời nhắc của bạn, khu vực của bạn, cài đặt nỗ lực của bạn và mẫu lưu lượng truy cập của bạn quyết định con số thực tế.

Bắt đầu với chế độ xem cấp độ truyền tải, chỉ cần một lệnh:

curl -N -s -o /dev/null \
  -w 'dns=%{time_namelookup} connect=%{time_connect} first_byte=%{time_starttransfer} total=%{time_total}\n' \
  https://api.openai.com/v1/responses \
  -H "Authorization: Bearer $OPENAI_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"model":"gpt-6-sol","input":"Summarise this OpenAPI operation.","stream":true}'

Sau đó, hãy đọc first_byte một cách nghi ngờ. Trên một điểm cuối streaming, các byte đầu tiên thường là một sự kiện mở luồng, không phải một token nội dung, vì vậy time_starttransfer đo khi máy chủ bắt đầu nói chuyện chứ không phải khi mô hình bắt đầu trả lời. Khoảng cách đó chính xác là điều bạn đang cố gắng định cỡ, đó là lý do tại sao một bộ kiểm tra ngây thơ báo cáo một con số dễ chịu.

Đo thời gian chênh lệch nội dung đầu tiên là phép đo quan trọng:

import time
from openai import OpenAI

client = OpenAI(timeout=600)

t0 = time.perf_counter()
first_content = None

with client.responses.stream(
    model="gpt-6-sol",
    input=PROMPT,
    reasoning={"effort": "low"},
) as stream:
    for event in stream:
        if event.type == "response.output_text.delta" and first_content is None:
            first_content = time.perf_counter() - t0
    total = time.perf_counter() - t0

print(f"ttft={first_content:.2f}s total={total:.2f}s")

Tên trường và sự kiện trong các đoạn mã này đến từ các cấu trúc API hiện tại của OpenAI chứ không phải từ thông báo ra mắt GPT-6, vì vậy hãy kiểm tra chúng với tài liệu tham khảo trước khi bạn triển khai. Kỷ luật đo lường là điều cần được áp dụng: ghi lại thời gian đến token nội dung đầu tiên và tổng thời gian là các chỉ số riêng biệt, giữ chúng cho mỗi mô hình và mỗi cấp độ nỗ lực, và báo cáo p95 chứ không phải mức trung bình. Độ trễ của token đầu tiên trên một mô hình lý luận có đuôi dài, và một mức trung bình che giấu chính xác các yêu cầu hết thời gian chờ.

Hãy chạy nó như một kiểm tra theo lịch trình thay vì một lần duy nhất. Lưu yêu cầu streaming trong Apidog, xác nhận thời gian phản hồi, và chạy kịch bản theo lịch trình trong CI để một sự thoái hóa phía nhà cung cấp hoặc một thay đổi cấp độ nỗ lực sẽ hiển thị dưới dạng một thử nghiệm thất bại thay vì một yêu cầu hỗ trợ. Dự án tương tự cung cấp cho công việc giao diện người dùng một cách vượt qua thời gian chờ: trỏ client đến một mock Apidog của điểm cuối của riêng bạn để không ai bị chặn trong hai phút mỗi lần lặp trong khi tích hợp thực tế vẫn đang được xây dựng. Nếu bạn muốn hiểu các nguyên tắc cơ bản đằng sau các số liệu, hướng dẫn của chúng tôi về độ trễ API bao gồm các thuật ngữ.

Bốn thay đổi thực sự hữu ích

Đưa cuộc gọi lý luận ra khỏi đường dẫn đồng bộ. Chấp nhận yêu cầu, trả về 202 Accepted với ID công việc ngay lập tức, và gửi kết quả bằng cách thăm dò hoặc webhook. Đây là thay đổi duy nhất giúp mọi vấn đề khác trở nên nhỏ hơn, vì 102 giây không còn nằm trong một yêu cầu HTTP mà một thứ gì đó ở trên đang chờ đợi nữa.

Định tuyến theo nỗ lực, không theo mô hình. Các số liệu đo được mô tả lý luận tối đa. Hầu hết lưu lượng truy cập không cần đến nó. Phân loại nhiệm vụ trước, gửi phần lớn thông thường ở mức nỗ lực thấp, và dành cài đặt đắt tiền cho các trường hợp xứng đáng. Các điểm chuẩn ra mắt của OpenAI được báo cáo theo từng cấp độ nỗ lực chính vì lý do này, vì vậy cài đặt là một quyết định thiết kế hạng nhất chứ không phải một chi tiết tinh chỉnh.

Truyền dữ liệu (Stream), và hiển thị thời gian chờ một cách trung thực. Nếu có người đang xem, hãy truyền phản hồi và nói rõ điều gì đang xảy ra. Một trạng thái tiến trình phản ánh thực tế tốt hơn một spinner gợi ý rằng có gì đó không ổn.

Ngân sách thời gian thực tế riêng biệt với token. Chi phí cho mỗi tác vụ và độ trễ cho mỗi tác vụ là các trục độc lập, và các bản ra mắt tháng 9 đã làm thay đổi mạnh một trong số chúng. Giữ ngân sách độ trễ cho mỗi điểm cuối bên cạnh ngân sách chi phí, và coi sự thoái hóa ở cả hai là một rào cản phát hành.

Một điều không nên giả định: bản phát hành bộ nhớ đệm lời nhắc của GPT-6 cắt giảm 90% giá đọc đầu vào được lưu trong bộ nhớ đệm và tăng tỷ lệ truy cập, và đó là một khoản tiết kiệm thực sự. Không nhà cung cấp nào công bố tuyên bố về độ trễ cho nó, vì vậy hãy coi bất kỳ cải thiện token đầu tiên nào từ bộ nhớ đệm là thứ cần đo lường chứ không phải thứ để lập kế hoạch.

Mô hình rẻ tiền không phải là mô hình nhanh

GPT-6 Sol với giá 2 đô la và 10 đô la mỗi triệu token là một động thái giá thực sự, và kết quả điểm chuẩn đằng sau nó rất mạnh. Tuy nhiên, không có điều nào trong số đó làm cho nó khởi động nhanh. Theo phép đo độ trễ công khai duy nhất có sẵn, mô hình giúp bạn tiết kiệm 80% giá token của Astra yêu cầu hơn một phút rưỡi trước khi nói một từ, và người anh em rẻ hơn của nó còn yêu cầu lâu hơn nữa.

Giá nằm trên hóa đơn. Độ trễ nằm trong kiến trúc của bạn. Hãy tự mình đo lường cái thứ hai, với một bộ kiểm tra đo thời gian token nội dung đầu tiên chứ không phải byte đầu tiên, trước khi bạn đẩy một mô hình rẻ hơn vào một đường dẫn yêu cầu được xây dựng cho một mô hình nhanh hơn.