Tuần trước OpenAI và Cerebras giới thiệu chế độ “Ultrafast” cho GPT-5.6 Sol: tối đa 750 token đầu ra mỗi giây, khoảng 14 lần tốc độ inference tiêu chuẩn, và theo cả hai công ty — không đánh đổi chất lượng. Phản ứng đầu tiên của tôi là hoài nghi; “không đánh đổi chất lượng” là kiểu tuyên bố thường ẩn một ghi chú nhỏ ở đâu đó. Nhưng kiến trúc đằng sau nó không phải là mẹo quantization hay một model chưng cất nhỏ hơn. Đó là một câu trả lời phần cứng thực sự khác cho một vấn đề mà mọi tech lead xây sản phẩm dựa trên LLM đều từng cảm nhận: sinh token bị giới hạn bởi băng thông, không phải bởi năng lực tính toán. Sự khác biệt này quan trọng hơn con số headline, nên tôi muốn đi qua lý do, rồi bàn cụ thể nó nên thay đổi gì trong cách ta thiết kế UX cho agent.
Điểm nghẽn mà không prompt engineering nào sửa được
Trên stack inference GPU tiêu chuẩn, để sinh mỗi token cần stream trọng số model từ HBM (bộ nhớ băng thông cao) vào các lõi tính toán, chạy forward pass, rồi lặp lại cho token tiếp theo. Với model lớn, đó là hàng chục đến hàng trăm gigabyte di chuyển qua bus bộ nhớ cho mỗi token. GPU đã nhanh hơn ở phép nhân ma trận; nhưng chưa nhanh hơn tương ứng ở việc di chuyển lượng dữ liệu đó qua lại. Đó là bức tường băng thông bộ nhớ, và đó là lý do độ trễ sinh token tăng chậm hơn nhiều so với năng lực model trong hai năm qua.
Wafer-Scale Engine của Cerebras né tránh vấn đề này bằng cách giữ trọng số model thường trú trong SRAM on-chip — 44GB trên một chip cỡ cả tấm wafer — thay vì HBM bên ngoài. Không có chuyến đi khứ hồi đến bộ nhớ ngoài chip trong lúc sinh. Đánh đổi là chip wafer-scale đắt, khó sản xuất, và chỉ hợp lý cho khối lượng công việc inference ở quy mô thực sự lớn — bạn không chạy cái này ở homelab. Nhưng với một nhà cung cấp phục vụ model frontier cho hàng triệu request, đây là một câu trả lời kiến trúc chính đáng chứ không phải con số marketing.
Vì sao 14 lần không chỉ là “giống vậy nhưng nhanh hơn”
Đây là phần dễ bỏ qua nếu chỉ lướt qua như một con số benchmark: thay đổi độ trễ token hơn 10 lần không chỉ làm UX hiện tại nhanh hơn, nó thay đổi những pattern UX nào khả thi. Tôi đã xây đủ tính năng dựa trên LLM để đúc kết một quy tắc thô: nếu độ trễ cảm nhận vượt khoảng 300-500ms cho đoạn output có ý nghĩa đầu tiên, người dùng bắt đầu cảm nhận hệ thống đang “suy nghĩ” thay vì “phản hồi”, và pattern tương tác cần thích ứng — chỉ báo streaming, render từng phần, UI suy đoán. Ở 750 token/giây, một phản hồi 500 token — một đoạn văn hoàn chỉnh, một diff code nhỏ, một kế hoạch tool-call có cấu trúc — hoàn tất trong chưa đầy một giây. Đủ nhanh để không còn là “sinh” mà gần với “tính toán”, mở ra các pattern tương tác trước đây khá gượng gạo:
- Chuỗi tool đồng bộ không cần spinner. Một agent cần ba lệnh gọi LLM tuần tự để lên kế hoạch, thực thi, và xác minh một bước có thể làm cả ba trong một khoảnh khắc “loading” cảm nhận được thay vì ba giai đoạn hiển thị.
- Autocomplete inline cho output có cấu trúc, không chỉ code — điền form, sinh config, SQL — ở tốc độ cạnh tranh với hệ thống dựa trên rule, mà không có sự giòn gãy của hệ thống dựa trên rule.
- Hội thoại voice và multi-turn agent thời gian thực không còn “khoản thuế” độ trễ “để tôi suy nghĩ” quen thuộc khiến voice agent cảm giác cứng nhắc so với con người.
Điều tôi thực sự sẽ thay đổi trong request path của agent
Nếu sản phẩm của bạn có luồng agent nhạy cảm với độ trễ, tôi sẽ đối xử với tin này như bất kỳ bước nhảy phần cứng nào khác: đừng tái kiến trúc sản phẩm quanh một tính năng beta của một vendor, nhưng cũng đừng tiếp tục coi độ trễ sinh token là chi phí cố định phải thiết kế phòng thủ xung quanh. Cụ thể, ba thứ tôi đang làm khác đi trong quý này:
# Trước: một response lớn, độ trễ không giới hạn, bắt buộc streaming UI
def plan_and_execute(task):
plan = llm.generate(f"Plan steps for: {task}", stream=True)
for step in plan.steps:
result = llm.generate(f"Execute: {step}", stream=True)
return result
# Với tốc độ sinh dưới 1 giây cho đoạn ngắn, gộp các lệnh gọi
# đồng bộ hẹp trở nên khả thi thay vì là gánh nặng UX
def plan_and_execute_fast(task):
plan = llm.generate(f"Plan steps for: {task}", max_tokens=300)
results = [llm.generate(f"Execute: {s}", max_tokens=200) for s in plan.steps]
return summarize(results) # cả chuỗi có thể hoàn tất dưới ~1sThứ nhất, tôi đang rà soát luồng agent nào của team dùng streaming thuần túy như cơ chế che giấu độ trễ, so với streaming vì nội dung thực sự hưởng lợi từ việc hiển thị tăng dần (viết văn dài, tail log trực tiếp). Nhóm đầu là ứng viên để gộp lại thành lệnh gọi đồng bộ khi model nền đủ nhanh — streaming UI có chi phí phức tạp thực sự (xử lý trạng thái từng phần, hủy, khôi phục lỗi giữa chừng) mà bạn không muốn gánh nếu không cần.
Thứ hai, tôi đang xem lại nơi ta làm lập kế hoạch agent nhiều bước. Nhiều kiến trúc “lên kế hoạch rồi thực thi” tồn tại một phần để gộp độ trễ — suy nghĩ hết trước để người dùng chỉ chờ một lần. Nếu độ trễ mỗi bước giảm một bậc độ lớn, các vòng lặp plan-observe-replan xen kẽ (gần với cách con người thực sự xử lý một task mơ hồ) trở nên khả thi trở lại, và chúng thường cho kết quả tốt hơn một kế hoạch cứng nhắc lập từ đầu.
Thứ ba — và đây là điều nhàm chán nhưng quan trọng — tôi không giả định giá cả hay khả năng truy cập này sẽ phổ quát. Chế độ Ultrafast ra mắt ở bản preview giới hạn cho khách hàng chọn lọc; chi phí mỗi token cho inference wafer-scale chưa công khai, và các thông báo “inference hiệu quả” trước đây không phải lúc nào cũng đi kèm giá tương ứng rẻ. Hãy coi đây là bản xem trước hướng đi của kinh tế học token, chứ không phải thứ để đưa vào kế hoạch capacity ngay hôm nay.
Lời cảnh báo thành thật
Tôi chưa tự chạy cái này — quyền truy cập còn giới hạn — nên mọi thứ ở trên là lý luận kiến trúc từ benchmark công khai, không phải benchmark tôi tự tạo. Nếu bạn có quyền truy cập, điều tôi thực sự sẽ kiểm chứng trước khi tin vào tuyên bố “không đánh đổi chất lượng” là liệu nó có đúng trên bộ eval của chính bạn, không phải của vendor. Các tối ưu hóa thời điểm inference có lịch sử là lossless trên giấy nhưng khác biệt tinh vi khi vào production — các cài đặt sampling khác nhau, đường dẫn độ chính xác số khác nhau, có thể dịch chuyển phân phối output theo cách không hiện ra trên benchmark chuẩn nhưng lại hiện ra trong đánh giá của một code-review agent. Kiểm chứng trước khi xây quyết định sản phẩm trên nền tảng đó.
Nguồn: Cerebras Powers Ultrafast Mode for OpenAI’s GPT-5.6 Sol, OpenAI: Previewing Ultrafast mode, GPT-5.6 Sol goes 14x faster