Mỗi open-weights model release lớn trong ba năm qua đều là biến thể của cùng một kiến trúc: autoregressive transformer, predict từng token một, từ trái sang phải. DiffusionGemma-26B, được Google DeepMind phát hành ngày 10 tháng 6 theo Apache 2.0, là sự phá vỡ nghiêm túc đầu tiên khỏi pattern đó từ một major lab.

Con số headline là 1.000+ token mỗi giây trên H100. Nhanh hơn 4-5x so với autoregressive model tương đương trên cùng phần cứng. Nhưng câu hỏi thú vị hơn là tại sao — vì câu trả lời thay đổi cách bạn nghĩ về model này phù hợp với mục đích gì.

Autoregressive Generation Tạo Ra Latency Floor Như Thế Nào

Để hiểu điều gì mới, bạn cần hiểu điều gì cũ. Autoregressive transformer có ràng buộc cấu trúc: mỗi token phụ thuộc vào tất cả token trước đó. Bạn không thể generate token N cho đến khi token 1 đến N-1 hoàn thành. Tính toán vốn là tuần tự.

Điều này tạo ra latency floor cứng. Dù bạn throw bao nhiêu phần cứng vào vấn đề, per-token generation time có mức tối thiểu. Với output 1.000 token ở 250 token/giây, bạn chờ ít nhất 4 giây — ngay cả với compute vô hạn.

Giới hạn cấu trúc khác: autoregressive model không thể chỉnh sửa. Khi token được generate, nó đã committed. Nếu model bắt đầu đi sai hướng ở token 3, nó có thể cố recover từ token 4-100, nhưng không thể quay lại. Đây là lý do bạn đôi khi thấy frontier model tạo ra response bắt đầu mạch lạc rồi xuống cấp — các token đầu đẩy model vào góc chết.

Uniform State Diffusion: Generate Canvas, Không Phải Stream

DiffusionGemma hoạt động khác. Đây là cơ chế:

  1. Thay vì generate token 1, rồi token 2, rồi token 3… model mở một “canvas” — chuỗi có độ dài cố định (tối đa 256 token) được điền với random placeholder token.

  2. Sau đó nó chạy một series “denoising passes” trên toàn bộ canvas đồng thời. Trong mỗi pass, model nhìn tất cả vị trí cùng lúc (bidirectional attention) và lock in token mà nó tự tin nhất.

  3. Sau mỗi pass, một số token được cố định (“frozen”) và những token không chắc chắn tiếp tục được tinh chỉnh trong pass tiếp theo.

  4. Tiếp tục đến khi tất cả token được frozen — tạo ra toàn bộ output.

Insight quan trọng: bidirectional attention có nghĩa là model có thể thấy toàn bộ output khi tinh chỉnh bất kỳ token riêng lẻ nào. Nó có thể chỉnh sửa quyết định sớm dựa trên những gì nó quyết định generate sau. Autoregressive model về cơ bản không thể làm điều này.

Tốc độ đến từ tính song song: trong mỗi pass, model lock in khoảng 15-20 token tự tin đồng thời thay vì từng cái một.

Thông Số Kỹ Thuật

DiffusionGemma-26B-A4B là model Mixture of Experts 26B parameter chỉ activate 3.8B parameter mỗi forward pass. “A4B” trong tên nghĩa là “Active 4 Billion” — đây là compute inference bạn thực sự dùng.

Số liệu chính:

  • H100: 1.000+ token/giây
  • RTX 5090: 700+ token/giây
  • VRAM: 18GB cho phiên bản quantized (vừa trên một GPU consumer)
  • Context window: 256K token
  • Input modalities: text, image, video (interleaved)
  • License: Apache 2.0

18GB VRAM footprint quan trọng. Nghĩa là model này chạy trên một consumer card cao cấp (RTX 4090, RTX 5090) mà không cần quantization tricks. Với tổ chức muốn chạy inference locally vì lý do data privacy, yêu cầu phần cứng là hợp lý.

Model Này Thực Sự Tốt Cho Gì

Caveat chất lượng là có thật: chất lượng tổng thể thấp hơn Gemma 4 autoregressive model chuẩn. Benchmark của chính Google cho thấy điều này. Đừng dùng DiffusionGemma cho task đòi hỏi sustained multi-step reasoning hoặc complex instruction following nơi bạn cạnh tranh với Gemini 2.5 Pro.

Nơi kiến trúc tỏa sáng:

Code infilling và in-context editing. Đây là killer use case. Khi bạn điền code trong existing context — “hoàn thành function này với code xung quanh” — bidirectional attention thực sự tốt hơn autoregressive. Model có thể thấy code đến trước và sau gap, chính xác là thông tin bạn muốn cho infilling. Copilot-style edits giữa file được lợi nhiều hơn từ điều này so với generation đầu file.

Constrained generation. Khi format output được xác định một phần — bạn biết cấu trúc của những gì bạn cần và chỉ muốn model điền vào các field cụ thể — diffusion model xử lý điều này tự nhiên hơn. Canvas bắt đầu với token đã biết của bạn và model điền phần còn lại.

High-throughput batch processing. Nếu bạn chạy pipeline xử lý hàng nghìn input tương tự, lợi thế throughput cộng dồn. Ở 1.000 token/giây so với 250 token/giây, bạn xử lý 4x volume với cùng hardware budget.

Latency-sensitive interactive application. Ở 1.000 token/giây, response 200 token (một API reply điển hình) đến trong 0.2 giây. Đó là dưới ngưỡng nhận thức của con người cho “đang chờ.” Với tool nơi AI response là một phần của tight feedback loop, điều này thay đổi đáng kể tính toán UX.

Cách Chạy

Model có trên Hugging Face tại google/diffusiongemma-26B-A4B-it. Inference API khác với autoregressive model — bạn không sample token theo token, bạn chạy denoising loop:

from transformers import AutoModelForCausalLM, AutoTokenizer
import torch

model_id = "google/diffusiongemma-26B-A4B-it"
tokenizer = AutoTokenizer.from_pretrained(model_id)
model = AutoModelForCausalLM.from_pretrained(
    model_id, 
    torch_dtype=torch.bfloat16,
    device_map="auto"
)

# Generation dùng num_diffusion_steps thay vì max_new_tokens
inputs = tokenizer("Hoàn thành function này:\ndef binary_search(arr, target):", return_tensors="pt")
outputs = model.generate(
    **inputs,
    num_diffusion_steps=20,   # nhiều steps hơn = chất lượng tốt hơn, chậm hơn
    max_length=256,
    do_sample=False
)
print(tokenizer.decode(outputs[0]))

Parameter num_diffusion_steps là đòn bẩy trade-off chất lượng/tốc độ chính. Nhiều steps tạo ra output chất lượng cao hơn nhưng giảm throughput. Mặc định 20 steps là điểm xuất phát hợp lý; với code generation bạn có thể đẩy lên 30-40 để có chất lượng tốt hơn.

Implication Kiến Trúc Với Developer Tooling

Sự phân chia giữa autoregressive và diffusion inference sẽ quan trọng với cách bạn architect AI-powered developer tool trong 12 tháng tới.

Với feature cần chất lượng reasoning tối đa — giải thích code phức tạp, architecture review, multi-file refactor — hãy dùng autoregressive model (Gemma 4, Fable 5, v.v.). Lợi thế chất lượng là có thật.

Với feature nơi tốc độ và throughput chi phối — autocomplete, inline code infilling, real-time suggestion khi bạn gõ — latency profile của DiffusionGemma làm nó competitive với model lớn hơn nhiều mà bạn sẽ phải host với chi phí lớn hơn.

Middle ground thú vị: code linting và style suggestion, nơi bạn xử lý file hiện tại liên tục khi developer gõ. Ở 0.2 giây mỗi response, bạn có thể cho feedback real-time không có độ trễ “đang suy nghĩ…” làm AI linting hiện tại cảm giác awkward.

Quyết định của Google open-source điều này theo Apache 2.0 cũng đáng chú ý. Open-weights text diffusion space rất mỏng so với image diffusion — có open-weights image diffusion model tốt (Stable Diffusion, FLUX) nhưng không có gì tương đương cho text. DiffusionGemma-26B thay đổi điều đó, và Apache 2.0 license nghĩa là commercial use không bị giới hạn.

Hãy theo dõi quality gap. Kiến trúc là đúng đắn, lợi thế throughput là thực, và open-weights availability tốt cho ecosystem. Nếu Google thu hẹp quality gap trong iteration tiếp theo, điều này trở nên thực sự competitive với autoregressive model trên phạm vi task rộng hơn.

Xuất nội dung

Bình luận