Đừng xử model mới chỉ bằng tốc độ

Đừng xử model mới chỉ bằng tốc độ

DiffusionGemma nhanh, mở, chạy local hấp dẫn. Nhưng với builder, câu hỏi đúng không phải model nào hot nhất, mà workload nào đáng đưa ra xét xử.

Có một kiểu drama rất quen trong team AI: sáng thứ Hai, ai đó thả vào Slack một release mới, kèm câu: 'Con này nhanh gấp mấy lần, mình đổi stack không?'

Rồi cả phòng bắt đầu chia phe. Một bên nhìn tokens per second và sáng mắt. Một bên hỏi quality đâu. Một bên nữa, thường là người phải trả hóa đơn GPU, chỉ im lặng mở spreadsheet.

DiffusionGemma của Google rơi đúng vào kiểu phiên tòa đó. Nó là model mở thử nghiệm, 26B Mixture of Experts — kiến trúc chỉ kích hoạt một phần model khi chạy — nhưng mỗi lượt inference chỉ dùng khoảng 3.8B active parameters. Điểm gây chú ý: thay vì sinh chữ từng token từ trái sang phải như model autoregressive truyền thống, nó dùng text diffusion — sinh và tinh chỉnh khối văn bản theo kiểu song song. Google nói hướng này có thể cho tốc độ đến 4x trong một số điều kiện, đạt hơn 1000 tokens/giây trên H100 và hơn 700 tokens/giây trên RTX 5090. Bản quantized vừa trong khoảng 18GB VRAM.

Nghe vậy là đủ để nhiều team muốn bấm tải về. Nhưng nếu bạn đang build hệ thống thật, câu hỏi nên đổi từ: 'Model này có nhanh không?' sang 'Nhanh ở đoạn nào của workflow, và có đáng đổi chất lượng lấy độ trễ không?'

Sơ đồ minh họa cho bài Đừng xử model mới chỉ bằng tốc độ

Sơ đồ tóm tắt ý chính của bài viết.

Thứ đang diễn ra: tốc độ đang thành chứng cứ chính

Các release gần đây có chung một nhịp: open-weight, MoE, chạy local hoặc single GPU, context dài, giấy phép thoáng hơn. DiffusionGemma có Apache 2.0. North Mini Code của Cohere cũng là MoE 30B nhưng chỉ kích hoạt 3B parameters mỗi token, nhắm vào coding agent và terminal tasks. Mellum2 của JetBrains thì định vị như một focal model — model chuyên trách, nhanh, đặt trong pipeline nhiều model chứ không tự nhận thay thế frontier model. Gemma 4 QAT checkpoints lại đánh vào bài toán memory footprint cho edge và consumer GPU.

Đây không phải cuộc đua 'ai to hơn'. Đây là cuộc chuyển dịch sang model đúng vai.

Nói thẳng ra thì, model mới bây giờ giống bị đưa ra trước hội đồng xét xử: benchmark là lời khai, latency là chứng cứ, nhưng verdict cuối cùng phải dựa trên workload của bạn.

Với DiffusionGemma, Google cũng nói khá rõ tradeoff: ưu tiên tốc độ và layout generation song song, nhưng quality tổng thể thấp hơn Gemma 4 autoregressive. Nếu bạn bỏ qua câu đó, bạn đang chỉ đọc nửa hồ sơ.

Mổ xẻ DiffusionGemma: nhanh vì không đi từng bước

Phần thú vị nhất của DiffusionGemma không nằm ở con số 26B. Nó nằm ở cơ chế sinh text.

Model autoregressive sinh token lần lượt: token thứ 10 phụ thuộc vào 9 token trước. Cách này ổn định, dễ kiểm soát, nhưng latency bị kéo dài vì mỗi bước phải chờ bước trước. Text diffusion thì khác: model bắt đầu từ một dạng text chưa hoàn chỉnh rồi lặp lại nhiều vòng để tinh chỉnh cả khối. Với GPU phù hợp, nhiều phần có thể chạy song song hơn.

Ví dụ cụ thể: bạn đang làm editor trong IDE, cần AI đề xuất lại một đoạn comment, rename biến, hoặc viết skeleton cho nhiều test case. Những việc này thường cần phản hồi nhanh, không nhất thiết phải có văn phong hoàn mỹ. Nếu model có thể phác ra cả khối rồi sửa dần, trải nghiệm tương tác có thể mượt hơn.

Nhưng đây cũng là chỗ dễ hiểu sai. Text diffusion không tự động biến mọi tác vụ text thành nhanh và tốt hơn. Nó có thể hợp với:

Nó kém thuyết phục hơn nếu bạn cần câu trả lời dài, chặt, nhiều ràng buộc, hoặc reasoning sâu. Khi đó, model autoregressive chất lượng cao vẫn có lợi thế vì quá trình sinh tuần tự giúp giữ mạch lập luận rõ hơn.

Khung quyết định: đừng hỏi model, hãy hỏi pipeline

Nếu là tech lead, mình sẽ không đưa DiffusionGemma vào backlog bằng nhãn 'thử model mới'. Mình sẽ lập một vụ đối chất nhỏ giữa ba hướng:

| Hướng | Khi nào đáng thử | Rủi ro chính |
|---|---|---|
| DiffusionGemma | Local, latency thấp, chỉnh sửa nhanh, sinh cấu trúc song song | Quality thấp hơn Gemma 4, hành vi diffusion còn mới |
| Gemma 4 QAT | Cần giữ hệ Gemma, giảm memory, chạy edge/local | QAT cải thiện quality ở cùng kích thước, nhưng không biến model nhỏ thành model lớn |
| Model coding chuyên dụng như North Mini Code hoặc Mellum2 | Agentic coding, tool use, code edit, pipeline nhiều model | Cần benchmark bằng repo thật, không chỉ đọc điểm công bố |

Quantization-Aware Training hay QAT là cách train có giả lập nén trọng số từ sớm, giúp model chịu được precision thấp tốt hơn so với nén sau train. Trong công việc, QAT hữu ích khi bạn đã chọn họ model và muốn giảm memory mà không rơi quality quá mạnh.

Context window là vùng ngữ cảnh model còn xử lý trong một lượt. DiffusionGemma và North Mini Code đều nhắc đến 256K tokens, nhưng context dài không đồng nghĩa với hiểu tốt mọi thứ trong đó. Với builder, context dài là diện tích kho chứa; retrieval, prompt packing và eval mới quyết định model có lấy đúng món đồ không.

Vậy framework mình dùng là L-Q-C:

  1. Latency: tác vụ có thật sự bị nghẽn bởi thời gian sinh không?
  2. Quality floor: mức chất lượng tối thiểu để không làm hỏng workflow là gì?
  3. Control surface: bạn có cách đo, fallback, và rollback không?

Nếu workload không có latency pain, đừng đổi kiến trúc chỉ vì release mới. Nếu quality floor cao, hãy giữ model mạnh hơn cho bước quyết định. Nếu chưa có control surface, thử model mới chỉ là thêm biến nhiễu vào production.

Một buổi kiểm chứng: dựng phiên xử nhỏ trước khi scale

Hình dung thế này: team bạn có một extension nội bộ cho developer. AI đang làm ba việc: autocomplete comment, viết unit test skeleton, và giải thích lỗi CI. Bạn muốn biết DiffusionGemma có đáng nhét vào không.

Đừng benchmark bằng prompt ngẫu hứng. Hãy lấy một buổi chiều và làm test nhỏ như sau:

1. Chọn 30 case thật từ workflow

Chia đều:

Đây là ví dụ minh họa về số lượng, không phải chuẩn ngành. Mục tiêu là đủ nhỏ để làm nhanh, đủ thật để không tự lừa mình.

2. Chạy song song hai hoặc ba model

Ví dụ:

case_id: ci_error_07
input: log lỗi + file liên quan
model_a: model hiện tại
model_b: DiffusionGemma
model_c: model coding chuyên dụng nếu có
measure:
  - latency_first_usable_output
  - accepted_by_developer: yes/no
  - edit_distance_after_accept
  - failure_type

Đừng chỉ đo total tokens per second. Với interactive tool, chỉ số đáng nhìn hơn là first usable output — khi nào developer có thứ đủ dùng để tiếp tục gõ.

3. Gắn nhãn failure mode

Tối thiểu nên có:

Mục cuối rất quan trọng. Một model trả lời trong chớp mắt nhưng làm bạn mất thêm 5 phút sửa thì không nhanh, nó chỉ chuyển latency từ GPU sang não người.

4. Đặt tiêu chí dừng trước khi thử

Ví dụ minh họa:

Canary ở đây là triển khai giới hạn cho một nhóm nhỏ để quan sát trước khi mở rộng. Đừng để model mới bước thẳng vào production như nhân chứng chưa qua đối chất.

Điều đáng giữ: model chuyên trách, không phải model toàn năng

Điểm đáng học từ DiffusionGemma không phải là 'diffusion sẽ thay autoregressive'. Cách nghĩ đó quá vội.

Điểm đáng giữ là: một pipeline AI tốt có thể gồm nhiều model nhỏ, nhanh, chuyên vai.

DiffusionGemma có thể là model cho thao tác nhanh, local, nhiều phương án. Gemma 4 QAT có thể là lựa chọn khi cần tiết kiệm VRAM nhưng vẫn bám hệ Gemma. Mellum2 hợp với vai focal model trong pipeline phần mềm. North Mini Code đáng xét nếu workload là agentic coding và terminal. MisoTTS lại là nhắc nhở rằng không phải mọi release 'open weights' đều nằm trong cùng bài toán text/code; audio có trục tradeoff riêng như latency, cảm xúc, và conditioning bằng giọng trước đó.

Builder nên thiết kế router theo tác vụ:

if task in [inline_edit, outline, quick_variants]:
  try fast_local_model
elif task in [code_agent, terminal_plan, repo_edit]:
  use coding_specialist
elif task in [final_answer, user_facing_reasoning]:
  use higher_quality_model
else:
  fallback_to_current_stable_path

Router không cần phức tạp ngay từ đầu. Một bộ rule rõ ràng còn tốt hơn một agent tự chọn model nhưng không ai debug nổi.

Điều nên bỏ qua: bảng xếp hạng không gắn với việc của bạn

Có ba thứ mình sẽ không vội tin khi nhìn release mới.

Thứ nhất, tokens per second không đủ kết án hay tuyên trắng án cho model. Nó cần đi cùng acceptance rate, số lần sửa sau khi accept, và loại tác vụ.

Thứ hai, context dài không thay cho thiết kế retrieval. Nếu bạn nhét cả repo vào context rồi mong model tự xử, bạn đang biến hồ sơ vụ án thành một vali giấy tờ không mục lục.

Thứ ba, open model không tự động rẻ hơn. Self-host có thêm chi phí vận hành: GPU, quantization, serving, monitoring, rollback, bảo mật weight, và người trực khi hệ thống nghẽn. Cloud API giống thuê dịch vụ ngoài; local model giống tự lập phòng vận hành. Không bên nào mặc định đúng.

Sau bài này, điều mình muốn bạn nghĩ khác là: release model không phải lời mời thay thế stack, mà là một giả thuyết cần kiểm chứng trong workload hẹp.

Nếu DiffusionGemma thắng ở inline editing, cho nó làm inline editing. Nếu nó thua ở reasoning, đừng bắt nó biện hộ trước tòa tối cao. Model nhanh nhất không luôn là model đúng nhất; đôi khi nó chỉ là nhân chứng nói rất lẹ.

---
Bụi Wire — nghiện đọc release notes lúc 2 giờ sáng

Nguồn tham khảo