DiffusionGemma của Google: Mô hình ngôn ngữ tạo văn bản cực nhanh, tự sửa lỗi và chạy song song 256 token

Các trình tạo hình ảnh GenAI như Stable Diffusion không vẽ tranh từng điểm ảnh từ trái sang phải. Thay vào đó, chúng bắt đầu từ một lớp nhiễu và tinh chỉnh toàn bộ hình ảnh song song cho đến khi hội tụ, một quy trình được gọi là diffusion (phân tán). Trong nhiều năm, việc áp dụng nguyên lý tương tự cho việc tạo văn bản luôn là một thử thách khó khăn ở quy mô lớn.

Các mô hình ngôn ngữ tiêu chuẩn hoạt động giống như một chiếc máy đánh chữ: xử lý từng token một theo thứ tự từ trái sang phải, mà không có khả năng sửa đổi đầu ra đã hoàn tất. Mô hình này hoạt động tốt trên đám mây, nơi kích thước lô (batch sizes) lớn giúp duy trì sự bận rộn cho GPU. Tuy nhiên, đối với việc suy luận cục bộ (local inference) hoặc các triển khai có độ đồng thời thấp, phần lớn thời gian GPU nằm trong trạng thái rỗi rãi.

DiffusionGemma của Google, được phát hành tuần này, là một mô hình thử nghiệm mã nguồn mở áp dụng kỹ thuật diffusion cho việc tạo văn bản ở quy mô sản xuất. Được xây dựng dựa trên nền tảng Gemma 4 và cấp phép theo Apache 2.0, đây là mô hình ngôn ngữ diffusion đầu tiên được hỗ trợ sẵn trên nền tảng suy luận mã nguồn mở vLLM. Nó có khả năng tạo ra một khối 256 token song song thay vì tuần tự, trong đó mọi vị trí token đều "chú ý" đến mọi token khác. Google khẳng định DiffusionGemma tạo văn bản nhanh hơn gấp 4 lần so với các mô hình tiêu chuẩn trên GPU. Với kích thước lò là 1 trên một chiếc Nvidia H100, phiên bản FP8 đạt tốc độ 1.008 token mỗi giây. Trên H200, con số này là 1.288 — nhanh hơn khoảng sáu lần so với cơ sở tự hồi quy (autoregressive) tiêu chuẩn, theo kết quả benchmark của vLLM công bố hôm nay.

Mặc dù đạt được lợi thế về tốc độ, Google không hề thổi phồng quá mức bản phát hành này. Bài đăng ra mắt của công ty đã thừa nhận trực tiếp rằng chất lượng đầu ra tổng thể của DiffusionGemma thấp hơn Gemma 4 tiêu chuẩn, đồng thời bổ sung: "Đối với các ứng dụng yêu cầu chất lượng tối đa, chúng tôi khuyên bạn nên triển khai Gemma 4 tiêu chuẩn."

Cơ chế hoạt động của DiffusionGemma

DiffusionGemma không tạo ra các token theo thứ tự. Nó bắt đầu với một khối 256 token placeholder ngẫu nhiên, tương tự như một khung vẽ trắng, và chạy nhiều vòng tinh chỉnh trên toàn bộ khối đó cùng lúc. Ở mỗi lần lặp, mô hình đánh giá mọi vị trí và "khóa" lại những vị trí mà nó tự tin nhất. Các vị trí chưa chắc chắn sẽ được ngẫu nhiên hóa và xem xét lại ở lượt tiếp theo, mô hình sẽ sử dụng thông tin từ vòng trước để thông báo cho nỗ lực sau. Khối dữ liệu sẽ dần hội tụ cho đến khi đủ vị trí ổn định để đóng vai trò neo giữ cho phần còn lại.

Hai tính năng quan trọng xuất phát từ kiến trúc này bao gồm:

• Tự sửa lỗi (Self-correction). Một mô hình tự hồi quy nếu once tạo ra một token sai sẽ bị mắc kẹt với lỗi đó, vì các token tiếp theo đã dựa trên sai lầm đó. DiffusionGemma có thể xác định các vị trí có độ tin cậy thấp và đánh giá lại chúng ở lần lặp tiếp theo.
• Ngữ cảnh hai chiều (Bidirectional context). Mọi vị trí đều chú ý đến mọi vị trí khác trong khối cùng lúc, bao gồm cả các token xuất hiện sau trong chuỗi. Điều này khiến mô hình phù hợp về mặt cấu trúc cho các tác vụ tạo sinh có ràng buộc, nơi mà việc tạo sinh từ trái sang phải thường thất bại.

Google đã chứng minh cả hai tính năng này với một trình giải Sudoku đã tinh chỉnh (fine-tuned). Mô hình cơ bản không giải được bài toán nào. Sau khi tinh chỉnh trên tập dữ liệu Sudoku, nó đạt tỷ lệ thành công 80% và hội tụ trong 12 bước khử nhiễu thay vì 48 bước. Lợi ích về hiệu suất đến trực tiếp từ khả năng tự sửa lỗi và dừng sớm của mô hình.

Cách thức xây dựng

DiffusionGemma hoạt động như một mô hình Hỗn hợp Chuyên gia (Mixture of Experts - MoE) 26B nhưng chỉ kích hoạt 3,8 tỷ tham số trong quá trình suy luận. Sau khi định lượng (quantized), nó vừa vặn trong 18GB VRAM trên phần cứng tiêu dùng bao gồm cả Nvidia RTX 4090 và 5090. Google và NVIDIA cũng tối ưu hóa cho các máy chủ doanh nghiệp Hopper và Blackwell sử dụng các nhân NVFP4.

Việc tích hợp vào vLLM đòi hỏi nhiều công sức mới vì DiffusionGemma không phù hợp với mô hình phục vụ tiêu chuẩn. Một lô vLLM điển hình áp dụng cùng một loại chú ý cho mọi yêu cầu. Các yêu cầu của DiffusionGemma thay đổi giữa chú ý nhân quả (causal) và hai chiều (bidirectional) khi chúng chuyển đổi qua việc đọc lệnh, tinh chỉnh khung vẽ và xác nhận khối. Đội ngũ đã xây dựng tính năng chuyển đổi chú ý theo từng yêu cầu vào cả hai phần phụ trợ Triton và FlashAttention 4, đồng thời tái sử dụng đường dẫn giải mã suy đoán hiện có cho vòng lặp tinh chỉnh.

Giao diện ModelState mới được xây dựng cho sự tích hợp này được thiết kế để hỗ trợ các mô hình diffusion bổ sung trong vLLM trong tương lai.

Tốc độ thắng ở đâu và thua ở đâu

Lợi thế về tốc độ của DiffusionGemma là có thật nhưng có điều kiện. Việc nó áp dụng hiệu quả phụ thuộc hoàn toàn vào bối cảnh triển khai.

Về các con số. Với kích thước lò là 1 trên một chiếc H100 duy nhất, các benchmark do vLLM công bố cho thấy mô hình FP8 nhanh hơn khoảng năm lần so với cơ sở tự hồi quy tiêu chuẩn. Trên H200, con số này là khoảng sáu lần. Các con số đỉnh cao này phản ánh điều kiện tối ưu: người dùng đơn, phần cứng chuyên dụng, định lượng FP8.

Nơi nó thắng. Suy luận cục bộ, ứng dụng người dùng đơn và phục vụ có độ đồng thời thấp. Trong những điều kiện này, GPU có sức tính toán dư thừa và băng thông bộ nhớ là nút thắt cổ chai. Việc tạo sinh khối song song của DiffusionGemma giúp lấp đầy khoảng trống này.

Nơi它 không thắng. Phục vụ đám mây thông lượng cao. Khi máy chủ xử lý hàng trăm yêu cầu đồng thời, các mô hình tự hồi quy đã làm đầy sức tính toán khả dụng và việc giải mã song song của DiffusionGemma mang lại lợi ích giảm dần.

Ngưỡng chất lượng. Guilherme O'Tina, một nhà nghiên cứu AI, đã đưa ra nhận định sắc bén hơn trên X. "Tạo vật cục bộ so với ảo giác (hallucinations) là những vấn đề khác nhau và điều đó quyết định nơi nó thực sự thắng," O'Tina viết.

So sánh với các giải pháp khác

Các mô hình ngôn ngữ diffusion không phải là mới mẻ. Các nhà nghiên cứu đã xây dựng chúng ở quy mô nhỏ hơn trong vài năm, và Mercury Coder của Inception Labs đã áp dụng cách tiếp cận này về mặt thương mại cho các tác vụ lập trình vào năm 2025. Điều mà DiffusionGemma thêm vào là quy mô — nền tảng MoE 26B, hỗ trợ vLLM nguyên bản và một mô hình được tinh chỉnh theo lệnh có mục đích chung thay vì chỉ dành riêng cho một lĩnh vực.

Sự so sánh hữu ích hơn cho các kỹ sư đánh giá nó so với các công cụ suy luận hiện có là giải mã suy đoán (speculative decoding), và sự khác biệt này rất quan trọng. Giải mã suy đoán giữ một mô hình đích tự hồi quy tiêu chuẩn và sử dụng một mô hình dự thảo nhỏ hơn để đoán trước vài token. Mô hình đích xác minh chúng trong một lần. Nếu lấy mẫu đúng, phân phối đầu ra vẫn giữ nguyên giống với mô hình đích. Kiến trúc không thay đổi.

Andrew Kuncevich, một nhà nghiên cứu ML và AI tập trung vào các hệ thống AI sản xuất, đã nói thẳng trên X. "DiffusionGemma khác biệt. Nó không chỉ đoán token tương lai. Nó tạo ra một khung vẽ 256 token nhiễu và liên tục khử nhiễu toàn bộ khối song song. Vì vậy, nó không chỉ là một mẹo giải mã — đó là một mô hình tạo sinh khác biệt," Kuncevich viết.

So với Gemma 4 tiêu chuẩn, sự đánh đổi là tốc độ lấy chất lượng. Dữ liệu benchmark của Google cho thấy DiffusionGemma thấp hơn Gemma 4 tiêu chuẩn về các chỉ số chất lượng đầu ra chung, với khoảng cách thay đổi tùy theo nhiệm vụ.

Đối với các tác vụ có ràng buộc có cấu trúc, bao gồm điền mã (code infilling), tạo mẫu và các vấn đề yêu cầu lan truyền ràng buộc hai chiều, kiến trúc này có lợi thế cấu trúc mà tinh chỉnh có thể khai thác, như kết quả Sudoku đã chứng minh. Đối với việc tạo sinh mở rộng, Gemma 4 tiêu chuẩn vẫn là lựa chọn mạnh mẽ hơn.

Ý nghĩa đối với doanh nghiệp

DiffusionGemma phục vụ thông qua một điểm cuối vLLM tương thích OpenAI tiêu chuẩn mà không yêu cầu thay đổi đường dẫn cụ thể nào cho diffusion.

Đây không phải là một nâng cấp mô hình có mục đích chung.

Đối với các nhóm chạy suy luận cục bộ hoặc có độ đồng thời thấp, lựa chọn kiến trúc vừa được mở rộng. Cho đến nay, việc giảm độ trễ tạo sinh trên phần cứng GPU chuyên dụng thường đồng nghĩa với việc sử dụng mô hình nhỏ hơn và chấp nhận đánh đổi chất lượng. DiffusionGemma mang lại một con đường thứ ba với cùng dung lượng tham số, trên phần cứng tiêu dùng, với sự hỗ trợ vLLM ngay trong ngày ra mắt.

Đối với khối lượng công việc tạo sinh có ràng buộc, chú ý hai chiều đáng để đánh giá. Điền mã, tạo dữ liệu có cấu trúc và các nhiệm vụ mà đầu ra chính xác phụ thuộc vào bối cảnh chưa được tạo là nơi kiến trúc này có lợi thế cấu trúc.

Giao diện ModelState được xây dựng cho sự tích hợp này được thiết kế để tổng quát khi thêm các mô hình diffusion khác xuất hiện.

Sự đánh đổi chất lượng là có thật và Google thừa nhận điều đó. Đối với các nhóm chạy suy luận cục bộ trên phần cứng GPU chuyên dụng, đây là công cụ đáng để thử nghiệm.