DiffusionGemma của Google: Mô hình ngôn ngữ tạo văn bản song song, tự sửa lỗi và nhanh gấp 4 lần

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

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ữ: tạo ra một token tại một thời điểm, từ trái sang phải, mà không có khả năng sửa đổi đầu ra đã cam kết. Mô hình này hoạt động tốt trên đám mây (cloud), nơi kích thước lô (batch sizes) lớn giúp GPU luôn bận rộn. Tuy nhiên, đối với suy luận cục bộ (local inference) hoặc các triển khai có độ đồng thời thấp, GPU thường bị rảnh rỗi phần lớn thời gian.

DiffusionGemma của Google, được ra mắt tuần này, là một mô hình thử nghiệm mã nguồn mở áp dụng kỹ thuật khuếch tán 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à phát hành theo giấy phép Apache 2.0, đây là mô hình ngôn ngữ khuếch tán đầu tiên được hỗ trợ nguyên bản trên nền tảng suy luận mã nguồn mở vLLM.

DiffusionGemma hoạt động như thế nào?

Thay vì tạo ra các token theo thứ tự, DiffusionGemma bắt đầu với một khối 256 token giữ chỗ ngẫu nhiên, giống như một khung vẽ trống. Nó chạy nhiều lần 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í không chắc chắn sẽ được ngẫu nhiên hóa và xem xét lại trong lần lặp tiếp theo, sử dụng thông tin từ vòng trước để thông tin cho lần thử mới. Khối dữ liệu sẽ dần hội tụ cho đến khi đủ vị trí ổn định để neo giữ phần còn lại.

Kiến trúc này mang lại hai đặc điểm chính:

• Tự sửa lỗi (Self-correction): Một mô hình tự hồi quy (autoregressive) nếu 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.
• 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 làm cho mô hình phù hợp về mặt cấu trúc với các nhiệm vụ tạo sinh bị ràng buộc, nơi việc tạo 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 bộ giải Sudoku được tinh chỉnh. 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.

Hiệu suất và Tốc độ

Google cho biết 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. Theo kết quả benchmark của vLLM, phiên bản FP8 đạt tốc độ 1.008 token mỗi giây trên một GPU Nvidia H100 duy nhất với kích thước lô là 1. Trên H200, con số này đạt 1.288 token/giây — nhanh hơn khoảng sáu lần so với mô hình tự hồi quy cơ bản.

Tuy nhiên, lợi thế về tốc độ này có điều kiện:

• 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à điểm nghẽn. Việc tạo khối song song của DiffusionGemma giúp lấp đầy khoảng trống này.
• Nó không thắng: Phục vụ đám mây có 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.

Cấu trúc và Tích hợp

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 như Nvidia RTX 4090 và 5090.

Việc tích hợp vLLM đòi hỏi công việc mới vì DiffusionGemma không phù hợp với mô hình phục vụ tiêu chuẩn. Đội ngũ đã xây dựng khả năng chuyển đổi chú ý theo từng yêu cầu (per-request attention switching) vào cả hai backend Triton và FlashAttention 4.

So sánh và Đánh đổi

So với Gemma 4 tiêu chuẩn, sự đánh đổi ở đây 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.

Đối với các nhiệm vụ bị 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à việc tinh chỉnh có thể khai thác. Tuy nhiên, đối với việc tạo sinh mở, 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 điểm cuối vLLM tương thích OpenAI tiêu chuẩn mà không yêu cầu thay đổi đường ống cụ thể nào cho khuếch tán.

• Đố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. Thay vì phải sử dụng mô hình nhỏ hơn để giảm độ trễ, DiffusionGemma cung cấp 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.
• Đối với khối lượng công việc tạo sinh bị ràng buộc: Cơ chế chú ý hai chiều đáng để được đánh giá, đặc biệt là trong các tác vụ mà đầu ra chính xác phụ thuộc vào ngữ cảnh chưa được tạo ra.

Google thừa nhận rằng đánh đổi về chất lượng là có thật. Đố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à một mô hình đáng để thử nghiệm.