Ngày 8/9, Inception Labs ra mắt Mercury 2.5, một language model dựa trên diffusion đạt 1.107 token/giây trên GPU NVIDIA tiêu chuẩn — xấp xỉ gấp 10 lần một model autoregressive hàng đầu chạy trên cùng phần cứng. Model đạt 79% trên GPQA Diamond và 77% trên IFBench, đưa nó vào cùng tầng trí tuệ với các model frontier tối ưu chi phí như Claude Haiku 4.5 và Gemini 3.5 Flash-Lite, trong khi sinh văn bản bằng một cơ chế hoàn toàn khác so với mọi chat model bạn từng triển khai từ trước tới nay.

Điều này đáng để Tech Lead chú ý không phải vì “model nhanh hơn” là tin mới — release nào cũng tuyên bố vậy — mà vì cách sinh diffusion thay đổi vị trí độ trễ nằm ở đâu trong một pipeline agent, và điều đó kéo theo hệ quả kiến trúc.

Autoregressive so với diffusion, trong thực tế

Mọi model họ GPT/Claude/Gemini bạn từng dùng đều sinh từ trái sang phải: dự đoán token N+1 dựa trên token 1..N, nối vào, lặp lại. Độ trễ tỷ lệ với độ dài output vì mỗi token phụ thuộc vào token trước đó — có một chuỗi phụ thuộc tuần tự cứng.

Cách tiếp cận diffusion của Mercury thì ngược lại: bắt đầu từ một chuỗi bị che (nhiễu) hoàn toàn, rồi lặp lại việc khử nhiễu cho toàn bộ output song song qua một số bước tinh chỉnh cố định, mượn quy trình làm nhiễu (masking-corruption) từ các model diffusion ảnh nhưng điều chỉnh cho token rời rạc. Độ dài output vẫn ảnh hưởng tới chất lượng, nhưng không ảnh hưởng tới số bước phụ thuộc tuần tự — toàn bộ chuỗi được tinh chỉnh cùng lúc.

Kết quả thực tế: thay vì ~100 tok/s trên một GPU thông thường, bạn có được 1.000+. Không phải vì GPU nhanh hơn, mà vì thuật toán sinh cần ít lượt tuần tự hơn nhiều để tạo ra cùng một độ dài output.

import time
from inception import Client  # minh họa cấu trúc SDK

client = Client(api_key="...")

start = time.perf_counter()
response = client.chat.completions.create(
    model="mercury-2.5",
    messages=[{"role": "user", "content": "Refactor hàm này thành pure function và thêm type hints."}],
    max_tokens=800,
)
elapsed = time.perf_counter() - start

print(f"{len(response.choices[0].message.content.split())} từ trong {elapsed:.2f}s")
# Trên Mercury 2.5: ~800 token trong chưa tới một giây.
# Cùng request đó với model autoregressive 100 tok/s: 8+ giây.

Chất lượng kém hơn các model autoregressive hàng đầu khoảng 5-15% trên các benchmark suy luận nhiều bước phức tạp, nhưng gần như ngang bằng với structured output, dịch thuật, và sinh nội dung theo khuôn mẫu (template) — những nhóm việc chiếm phần lớn lưu lượng tool-call thực tế của agent.

Nơi điều này thực sự quan trọng: ngân sách độ trễ của vòng lặp agent

Đây là điểm mấu chốt về kiến trúc. Trong một vòng lặp agent nhiều bước — lập kế hoạch, gọi tool, quan sát kết quả, quyết định bước tiếp theo, lặp lại — độ trễ sinh văn bản của model cộng dồn qua từng bước. Một vòng lặp agent năm bước với 2 giây độ trễ sinh mỗi bước là 10 giây thời gian model thuần túy, trước cả khi tính thời gian thực thi tool và round-trip mạng. Đó là khác biệt giữa một agent cảm giác phản hồi nhanh bên trong CLI hoặc IDE, và một agent khiến bạn cảm giác như đang chờ một pipeline CI chậm chạp.

Các model diffusion như Mercury 2.5 nhắm chính xác vào điểm đau này. Nếu điểm nghẽn của bạn là “model mất quá lâu để quyết định làm gì tiếp theo”, chứ không phải “model không đủ thông minh để quyết định đúng”, thì việc tăng tốc sinh gấp 10 lần là đòn bẩy lớn hơn việc chuyển sang một model frontier thông minh hơn nhưng chậm hơn.

Những chỗ tôi sẽ định tuyến các model dạng Mercury trong một pipeline thực tế:

  • Các bước trung gian có cấu trúc: định dạng JSON cho tool-call, format/lint code, sinh diff, điền template — tần suất cao, nhạy cảm với độ trễ, chấp nhận được một khoảng cách chất lượng nhỏ.
  • Mẫu draft-rồi-verify: sinh một bản nháp nhanh bằng Mercury, verify hoặc sửa bằng model frontier chậm hơn chỉ khi bản nháp fail kiểm tra. Đây chính là trực giác speculative-decoding, áp dụng ở cấp pipeline thay vì cấp token.
  • Agent tương tác/nhúng trong IDE: các tác vụ kiểu autocomplete, nơi người dùng cảm nhận bất cứ thứ gì trên ~300ms là độ trễ, bất kể suy luận bên dưới thông minh tới đâu.

Nơi tôi chưa định tuyến nó: bước lập kế hoạch/suy luận thực sự trong vòng lặp agentic, nơi một quyết định sai tốn kém hơn nhiều so với độ trễ tiết kiệm được — refactor nhiều file với các bất biến chéo file tinh vi, review code liên quan bảo mật, bất cứ đâu mà khoảng cách suy luận 5-15% là yếu tố quyết định toàn bộ.

Tín hiệu kiến trúc lớn hơn

Diffusion LLM đã tồn tại như một sự tò mò trong nghiên cứu suốt vài năm (Gemini Diffusion của Google, các bản Mercury trước đó); điều khác biệt bây giờ là Mercury 2.5 đang thu hẹp khoảng cách trí tuệ tới mức thực sự dùng được, trong khi vẫn giữ nguyên lợi thế thông lượng. Sự kết hợp đó — suy luận “đủ tốt” với tốc độ gấp 10 lần, giá $0,04/$0,15 mỗi triệu token — là lần đầu tiên tôi sẽ khuyên một team thực sự đưa một diffusion model vào bảng định tuyến production, đặt cạnh model autoregressive mặc định, chứ không chỉ dừng ở thử nghiệm.

Bài học cho bất kỳ ai đang làm model routing trong stack agent: độ trễ và trí tuệ ngày càng là hai trục có thể tách rời để định tuyến độc lập, giống như cách bạn đã định tuyến theo chi phí. Nếu bạn vẫn coi “dùng model nào” là một quyết định duy nhất cho cả agent thay vì một quyết định định tuyến theo từng bước, các diffusion model chính là lực buộc bạn phải sửa lại điều đó.

Nguồn: AlphaSignal — Inception’s Mercury 2.5 Hits 1,107 Tokens per Second, Digital Applied — Mercury 2: Diffusion LLM at 1000+ Tokens/Second

Xuất nội dung

Bình luận