DiffusionGemma: Tạo văn bản nhanh hơn gấp 4 lần

 (blog.google)
3 điểm bởi GN⁺ 4 giờ trước | 1 bình luận | Chia sẻ qua WhatsApp
  • DiffusionGemma là mô hình mở thử nghiệm 26B MoE theo giấy phép Apache 2.0, tạo đồng thời toàn bộ khối văn bản bằng phương pháp diffusion cho văn bản
  • Thay vì sinh token tuần tự như các LLM tự hồi quy thông thường, mô hình dùng sinh song song 256 token để cung cấp khả năng tạo văn bản nhanh hơn tới 4 lần trên GPU chuyên dụng
  • Khi suy luận, chỉ 3.8B tham số trong tổng số 26B được kích hoạt; khi lượng tử hóa, mô hình có thể chạy trong giới hạn 18GB VRAM, phù hợp với GPU chuyên dụng cao cấp dành cho người dùng phổ thông
  • Attention hai chiều và cơ chế tự sửa lặp lại mang lại lợi thế cho các tác vụ có cấu trúc phi tuyến, như chỉnh sửa inline, điền mã, chuỗi axit amin và đồ thị toán học
  • Vì là mô hình thử nghiệm ưu tiên tốc độ và sinh bố cục song song, chất lượng đầu ra tổng thể thấp hơn Gemma 4 tiêu chuẩn; với các ứng dụng cần chất lượng cao nhất, nên triển khai Gemma 4 tiêu chuẩn

Giá trị mới cho nhà phát triển

  • DiffusionGemma là mô hình mở mang tính thử nghiệm để khám phá diffusion cho văn bản, vượt qua cách xử lý tuần tự từng token của các LLM tự hồi quy thông thường bằng cách sinh đồng thời toàn bộ khối văn bản
  • Đây là mô hình 26B Mixture of Experts (MoE) được phát hành theo giấy phép Apache 2.0 và có thể tạo văn bản nhanh hơn tới 4 lần trên GPU
  • Dựa trên mức độ thông minh trên mỗi tham số của dòng Gemma 4 và Gemini Diffusion research, mô hình tích hợp một diffusion head mới để tối đa hóa tốc độ sinh
  • Các mô hình Gemma 4 tự hồi quy vẫn là tiêu chuẩn cho đầu ra production chất lượng cao, còn DiffusionGemma được thiết kế cho các nhà nghiên cứu và nhà phát triển muốn khám phá quy trình làm việc cục bộ có tính tương tác, nơi tốc độ là yếu tố quan trọng

  • Các đánh đổi chính

    • Suy luận nhanh chuyển nút thắt cổ chai của việc giải mã từ băng thông bộ nhớ sang năng lực tính toán, cho tốc độ xuất token nhanh hơn tới 4 lần trên GPU chuyên dụng
    • Tạo hơn 1000 token mỗi giây trên một NVIDIA H100 và hơn 700 token mỗi giây trên NVIDIA GeForce RTX 5090
    • Khả năng tiếp cận phần cứng đến từ kiến trúc chỉ kích hoạt 3.8B tham số khi suy luận trong tổng số 26B MoE
    • Khi lượng tử hóa, mô hình có thể chạy trong giới hạn 18GB VRAM của các GPU chuyên dụng cao cấp dành cho người dùng phổ thông
    • Attention hai chiều sinh song song 256 token ở mỗi lượt truyền xuôi, cho phép mọi token tham chiếu lẫn nhau
    • Điều này có lợi trong các miền phi tuyến như chỉnh sửa inline, điền mã, chuỗi axit amin và đồ thị toán học
    • Tự sửa là cơ chế mô hình liên tục tinh chỉnh đầu ra khi đánh giá toàn bộ khối văn bản cùng lúc, từ đó sửa lỗi gần như theo thời gian thực
    • Trạng thái thử nghiệm và khuyến nghị cho production được nêu rõ: vì ưu tiên tốc độ và sinh bố cục song song, chất lượng đầu ra tổng thể thấp hơn Gemma 4 tiêu chuẩn

  • Ví dụ fine-tuning

    • Hiệu năng ở các tác vụ cụ thể có thể được cải thiện bằng fine-tuning
    • Unsloth đã fine-tune DiffusionGemma để giải Sudoku, một tác vụ vốn khó với mô hình tự hồi quy vì mỗi token phụ thuộc vào các token tương lai
    • Attention hai chiều của DiffusionGemma khiến các tác vụ như Sudoku trở nên dễ hơn nhiều

Vì sao dùng diffusion cho văn bản

  • Cộng đồng nghiên cứu AI đã khám phá sinh văn bản dựa trên diffusion trong nhiều năm, nhưng việc áp dụng nó vào các mô hình lớn vẫn là một thách thức
  • DiffusionGemma giải quyết vấn đề này bằng cách thay đổi cách mô hình sử dụng phần cứng

  • Đánh đổi so với mô hình hiện có

    • Phần lớn mô hình ngôn ngữ tạo token theo kiểu máy đánh chữ, từ trái sang phải, từng token một
    • Trên đám mây, cách này hiệu quả vì máy chủ có thể gom hàng nghìn yêu cầu người dùng để xử lý theo lô, chia sẻ tải phần cứng
    • Khi một người dùng chạy cục bộ, việc sinh từng từ không tận dụng hết GPU hoặc TPU chuyên dụng, khiến phần cứng thường xuyên phải chờ “lần gõ phím” tiếp theo
    • DiffusionGemma phác thảo đồng thời cả đoạn gồm 256 token, cung cấp cho bộ xử lý máy tính những khối công việc lớn hơn trong một lần
    • Cấu trúc này biến suy luận mô hình từ một máy đánh chữ tuần tự thành một máy in lớn có thể in ra toàn bộ khối văn bản cùng lúc

  • Tăng tốc cho suy luận cục bộ và ít đồng thời

    • Mức tăng tốc của DiffusionGemma được thiết kế cho suy luận cục bộ và suy luận có độ đồng thời thấp
    • Trong môi trường phục vụ đám mây QPS cao, các mô hình tự hồi quy cũng có thể được triển khai để bão hòa tài nguyên tính toán một cách hiệu quả
    • Trong môi trường QPS cao, lợi thế giải mã song song của DiffusionGemma giảm đi và chi phí phục vụ có thể cao hơn
    • Lợi thế về thông lượng mạnh nhất trên một bộ tăng tốc đơn với kích thước batch từ thấp đến trung bình

Cách diffusion cho văn bản hoạt động

  • Diffusion cho văn bản áp dụng vào văn bản một quy trình tương tự cách AI tạo ảnh: bắt đầu từ nhiễu thị giác rồi lặp đi lặp lại để cải thiện thành hình ảnh rõ nét
  • Ở giai đoạn đầu tiên là canvas, mô hình bắt đầu từ một canvas gồm các token giữ chỗ ngẫu nhiên
  • Ở giai đoạn cải thiện lặp, mô hình thực hiện nhiều lượt, cố định các token đúng rồi dùng chúng làm tín hiệu ngữ cảnh để tinh chỉnh phần còn lại
  • Ở giai đoạn tinh chỉnh cuối, văn bản hội tụ thành đầu ra chất lượng cao
  • Vì mô hình có thể xử lý toàn bộ đoạn trong lúc sinh, nên có thể tạo ra các mẫu hành vi như đóng chính xác định dạng Markdown phức tạp hoặc sinh và render mã gần như theo thời gian thực

Cách bắt đầu

  • Trọng số mô hình thử nghiệm được cung cấp theo giấy phép Apache 2.0 cởi mở và có thể truy cập trên Hugging Face
  • Có thể xem cách tích hợp trong DiffusionGemma developer guide, và tìm hiểu sâu hơn về cơ chế bên trong tại A Visual Guide to DiffusionGemma
  • Có thể phục vụ mô hình bằng MLX, vLLM, Hugging Face Transformers
  • Tích hợp vLLM nhận được hỗ trợ từ Red Hat
  • Để thử nghiệm nhanh, có sẵn hướng dẫn fine-tuning dựa trên Hackable Diffusion, bộ công cụ JAX mô-đun được thiết kế cho tính kết hợp
  • Fine-tuning cũng có thể được khám phá với Unsloth và NVIDIA NeMo
  • Hỗ trợ chính thức cho llama.cpp sẽ sớm được cung cấp

Tối ưu hóa và môi trường chạy

  • Thông qua hợp tác với NVIDIA, việc tối ưu hóa đã được thực hiện trên toàn bộ stack phần cứng, mang lại khả năng tương thích và hiệu năng cho cả môi trường người dùng phổ thông lẫn hệ thống doanh nghiệp
  • Môi trường người dùng phổ thông hỗ trợ lượng tử hóa cho GPU GeForce RTX 5090 và 4090
  • Môi trường doanh nghiệp cung cấp hiệu năng cao trên Hopper và Blackwell với các kernel NVFP4 tiên tiến
  • NVIDIA DGX Spark và DGX Station cho triển khai cục bộ kiểu desk-side, cùng RTX PRO cho chuyên gia AI, cũng nằm trong nhóm mục tiêu
  • NVFP4 với hỗ trợ native số thực dấu phẩy động 4 bit giúp tăng tốc thông lượng tính toán, cho phép mô hình chạy nhanh hơn với độ chính xác gần như không suy hao
  • Có thể chọn cách chạy trên GPU desktop chuyên dụng, Gemini Enterprise Agent Platform Model Garden, hoặc NVIDIA NIM

Bài viết liên quan

1 bình luận

 
GN⁺ 4 giờ trước
Ý kiến từ Hacker News

  • Gần đây tôi chuyển sang OpenCode nên đã dùng thử khá nhiều model không thuộc các phòng nghiên cứu frontier lớn ở Mỹ, và bất ngờ là model tôi thích nhất lại là Mercury
    Không phải vì nó “thông minh”, mà vì nó nhanh đến vô lý. Nó cho cảm giác gần với pair programming hơn là kiểu trải nghiệm tác tử hiện đại, nơi bạn nhập prompt rồi ngồi chờ; vừa có được lợi ích của AI, vừa lấy lại phần nào cảm giác lập trình thời tiền AI nên thú vị hơn. Nó không giống một máy đánh bạc nơi bạn nhập prompt, chờ đợi và cầu mong hướng đi là đúng; tôi cũng bắt đầu dùng các model nhỏ như Gemini Flash Lite hay GPT Mini/Nano thường xuyên hơn. Có model open-weight ra mắt nên tôi rất háo hức và sẽ thử ngay

    • Nếu có thể chạy thử nghiệm nhanh và rẻ, đồng thời cũng nhanh chóng tạo ra các chỉ số chi phí thấp để phân biệt code tệ hay code viết qua loa, thì khi thời gian là yếu tố quan trọng, model nhanh nhưng kém hơn một chút có thể tốt hơn model chậm nhưng giỏi hơn hẳn
      Tôi đã có kết quả dùng LLM khá tốt khi đặt một chỉ số đo độ phức tạp thực tế thay vì độ phức tạp chu trình, rồi tự động hoàn tác cho đến khi phần độ phức tạp tăng thêm so với chức năng nằm trong phạm vi hợp lý
    • Mercury-2 rất xuất sắc. Tôi thường dùng nó làm trọng tài trong llm-consortium
      Vì cửa sổ ngữ cảnh của nó tương đối nhỏ, nên để dùng cho consortium lớn hơn thì có thể cấu hình kiểu meta-consortium đệ quy như sau:
      llm consortium save cns-glm -m glm-5.2 -n 5 --arbiter mercury-2 --judging-method rank
      llm consortium save cns-kimi -m k2.6 -n 5 --arbiter mercury-2 --judging-method rank
      llm consortium save cns-meta-glm-kimi -m cns-glm -m cns-kimi --arbiter mercury-2 --judging-method synthesis
      Giờ chỉ cần đưa prompt vào cns-meta-glm-kimi, nó sẽ chọn câu trả lời tốt nhất trong 5 câu từ kimi và glm tương ứng, rồi tổng hợp hai câu trả lời chiến thắng
    • Tôi tự hỏi điều này sẽ ảnh hưởng đến model cục bộ cho coding đến mức nào. Nếu dùng model khuếch tán nhanh hơn Qwen hay Gemma 4 nhiều lần, có lẽ tôi sẽ phải tự chuẩn bị nhiều hơn như thời trước AI, nhưng điều đó đôi khi lại là điều tốt, và có vẻ ta sẽ làm việc được với các model rất nhanh và rất rẻ ngay trên máy cục bộ
      Nếu không phải chạy những phép tính nặng kéo dài, thì chi phí chạy trên phần cứng cục bộ cũng có thể rẻ hơn chăng
    • Tôi hiểu rất rõ ý đó. Trong dự án cá nhân, Claude chậm đến mức khó chịu nên tôi đã chuyển sang Google Antigravity và các model Flash, và khác biệt về tốc độ là cực lớn
      Tôi vào guồng tốt hơn và tập trung vào công việc hơn. Tôi không ngờ tốc độ lại tạo ra khác biệt lớn đến vậy. Với codebase rất phức tạp và lớn, thời gian phản hồi chậm của Claude có thể đánh đổi lấy khả năng xử lý độ phức tạp của tác vụ; nhưng Antigravity hay các model nhanh khác lại phù hợp hơn nhiều khi bạn muốn lặp lại chu trình viết code, chạy và debug theo kiểu nhỏ gọn, nhẹ nhàng
    • Đúng vậy, tốc độ mới là mấu chốt. Việc nó tạo ra boilerplate POJO hay data class với tốc độ điên rồ 300+ tok/s là rất tuyệt, và trong kiểu công việc đó thì Flash-Lite còn hữu ích hơn GPT-5.5
      Chậm quá là bạn bị mắc kẹt trong cái vòng lặp chờ bất đồng bộ chết tiệt đó

  • Google tiếp tục cho thấy sức mạnh. Việc Gemini vẫn chưa cạnh tranh hơn Claude hay các model của OpenAI ở mảng code hay tác tử là điều đáng ngạc nhiên, nhưng rõ ràng Google vẫn sở hữu nhân lực AI thuộc hàng đầu ngành
    Dường như Google đang tập trung vào các ca sử dụng chạy trên điện thoại hoặc gần như thời gian thực hơn là các LLM suy luận lớn. Những cải thiện về hiệu quả như thế này rất có thể sẽ cực kỳ quan trọng với AI trong tương lai. Thời kỳ trợ giá token để khóa người dùng vào một hệ sinh thái nhất định đang dần kết thúc, và lúc phải trả chi phí thực sự đang đến gần. Công ty nào tìm ra cách vận hành model thực sự thông minh với hiệu quả chi phí tốt sẽ là bên chiến thắng. DeepSeek rẻ hơn GPT 5.5 hay Opus 4.8 hơn một bậc độ lớn, và dù kém hơn hai model đó thì cũng không đến mức chí mạng. Nếu model coding tốt nhất thực sự tiết kiệm đủ nhiều thời gian của con người thì tôi sẵn sàng trả gấp 10 lần, nhưng chênh lệch 100 lần thì khó chấp nhận, như trong các benchmark gần đây khi GPT 5.5 Pro đắt hơn DeepSeek hơn 200 lần và đắt hơn Opus 4.8 khoảng 30 lần

    • Fable có giá gấp đôi Opus và trông cũng khá cạnh tranh với GPT-Pro, nên nếu các cơ chế an toàn quá mức không phải vấn đề lớn thì đây có thể là một lựa chọn ổn
      Google cũng có tùy chọn “Deep Research” riêng trong mảng này và có vẻ hoạt động tốt. Điểm hay của DeepSeek là có thể chạy trên phần cứng cục bộ mà không tốn chi phí API. Nếu đó là điều bạn coi trọng thì việc nó kém Opus hay GPT một chút không phải vấn đề lớn
    • Cuối cùng thì có lẽ Google sẽ thắng. Họ đang tập trung vào những yếu tố quan trọng là hiệu năng trên mỗi watt và hiệu năng trên mỗi đô la
      Họ đang tự làm phần cứng suy luận, và đang tiến tới edge computing để giảm độ trễ cùng overhead tính toán. Các LLM lớn hiện vẫn chưa hiệu quả về chi phí, còn Google thì đang để đối thủ đốt vốn đầu tư để “bán” cho người tiêu dùng dưới giá vốn. Ngay cả sau khi bong bóng AI vỡ, những công ty như Google vẫn sẽ sống khỏe, và bong bóng này dường như đang nhằm lột bỏ lớp vỏ của một số tập đoàn khổng lồ

  • Một số phản hồi đang bỏ qua ưu điểm của phương pháp khuếch tán. Điều này có thể tạo khác biệt lớn trên các thiết bị biên như điện thoại hay GPU máy tính
    Bộ giải mã của LLM phải xét toàn bộ các token trước đó nên tính từng token một. Bộ giải mã LLM hiện tại mở rộng tốt khi tải đủ lớn để gom nhiều suy luận thành batch, và trong môi trường đó lợi thế của khuếch tán là khá hạn chế. Ở edge thì khác. Bộ tăng tốc suy luận bị đói vì phải liên tục chuyển các trọng số cỡ GB từ RAM. RAM tiêu dùng như LPDDRx/GDDRx có băng thông thấp hơn HBM, và vì yêu cầu là tuần tự nên không thể gom theo batch phần tính toán trọng số dùng chung. Khuếch tán có thể tính token song song nên giảm bớt nút thắt băng thông bộ nhớ

    • Thiết bị edge không chỉ thiếu băng thông bộ nhớ mà hiệu năng tính toán cũng rất hạn chế. Trên thực tế, ngay cả khi không có nhiều batch, lượng tính toán khả dụng cũng nhanh chóng bão hòa và đụng trần nhiệt độ/công suất rất rõ ràng
      Nói rằng trong suy luận edge “yêu cầu về bản chất là tuần tự” cũng không hẳn đúng. Nhiều yêu cầu có thể diễn ra đồng thời, tức nhiều cuộc chat cùng lúc, và nếu có đủ dung lượng bộ nhớ để chứa KV cache thì vẫn có thể áp dụng xử lý theo batch. Nếu mô hình khuếch tán cho chất lượng thấp hơn với nhiều phép tính hơn, còn mức tiết kiệm băng thông bộ nhớ cũng mơ hồ, thì tôi chưa rõ nó giúp được gì
    • Nhìn chung là đúng, nhưng đang trộn lẫn attention với cấu trúc tự hồi quy/nhân quả. Vấn đề thật sự ngăn việc tận dụng thêm tính toán là cấu trúc tự hồi quy/nhân quả
      Khuếch tán cũng có thể dùng attention, và mô hình này thực tế đúng là dùng attention

  • NVIDIA đang cung cấp endpoint miễn phí cho mô hình này. Chi tiết ở https://build.nvidia.com/google/diffusiongemma-26b-a4b-it, cần tạo tài khoản và có lẽ còn phải xác minh số điện thoại
    Tôi còn thử bắt nó vẽ pelican: https://tools.simonwillison.net/markdown-svg-renderer#url=ht...

    • Nếu là mô hình đủ nhanh thì thậm chí có thể yêu cầu các khung hình hoạt hình. Ví dụ frame 1 là chân phải ở vị trí 12 giờ, chân trái ở vị trí 6 giờ; frame 2 là chân phải ở 3 giờ, chân trái ở 9 giờ
      Khi đó hiển nhiên phải báo cáo số khung hình pelican mỗi giây, chứ không phải số token mỗi giây
    • Tôi đăng ký từ vài tuần trước, đã làm đúng quy trình nhưng tài khoản vẫn chưa được xác minh. Nếu tài khoản chưa được xác minh thì không thể dùng API

  • Một phần giải thích trực quan rất hay về cách mô hình khuếch tán văn bản như DiffusionGemma hoạt động: https://newsletter.maartengrootendorst.com/p/a-visual-guide-...

  • Mới vài ngày trước tôi còn nghĩ Google hoàn toàn không nhắc gì đến mô hình tạo văn bản bằng khuếch tán sau khi demo ở I/O một năm trước
    Có tin đồn là chạy nó quá đắt, nhưng nếu so DiffusionGemma với Gemma thường trên cùng phần cứng 1x H100 như biểu đồ được cung cấp thì có vẻ không phải vậy. Ngoài việc có vẻ hơi kém hơn Gemma một chút, tôi thắc mắc nhược điểm của tốc độ này là gì

    • Câu trả lời cho “tôi thắc mắc nhược điểm của tốc độ này là gì” có lẽ nằm ở đoạn này:
      “Mức tăng tốc của DiffusionGemma được thiết kế cho suy luận cục bộ và suy luận có độ đồng thời thấp. Trong phục vụ đám mây với QPS cao, các mô hình tự hồi quy có thể được batch hiệu quả để bão hòa năng lực tính toán, nên lợi thế giải mã song song của DiffusionGemma giảm đi và chi phí phục vụ có thể cao hơn”
    • Với mô hình tự hồi quy tiêu chuẩn, nếu có 256 người dùng thì chẳng hạn có thể tạo 256 token cùng lúc. Cách này cũng có thể tạo 256 token cho một người dùng, nhưng cần nhiều bước lan truyền xuôi hơn
      Vì vậy quá trình khuếch tán dùng nhiều GFLOPs hơn, và nếu có đủ người dùng thì bạn vốn đã có thể cân bằng giữa bộ nhớ và tính toán

  • “DiffusionGemma đảo ngược sự kém hiệu quả này. Thay vì dự đoán từng từ theo thứ tự, nó tạo bản nháp của cả một đoạn 256 token cùng lúc. Bằng cách đưa cho bộ xử lý máy tính những khối công việc lớn hơn trong một lần, nó tận dụng phần cứng tối đa. Nó nâng cấp suy luận mô hình từ một chiếc máy đánh chữ gõ từng ký tự thành một cỗ máy in khổng lồ in ra cả khối văn bản cùng lúc”
    “Nó hoạt động như một mô hình mixture-of-experts (MoE) tổng cộng 26B, nhưng chỉ kích hoạt 3.8B tham số trong lúc suy luận, và khi lượng tử hóa thì thoải mái nằm trong giới hạn 18GB VRAM của GPU chuyên dụng cao cấp dành cho người dùng phổ thông”
    Vậy nghĩa là Gemma 4 26B là một mô hình MoE chạy rất nhanh trên GPU 24GB của tôi bằng ollama. Cái này nghe giống speculative decoding, nhưng tôi nghĩ với mô hình MoE thì cách đó không hoạt động. Với những ai không theo dõi chuyện này như công việc thì có quá nhiều thay đổi để theo kịp

    • Đây là một mô hình khác có số tham số gần như giống hệt gemma4 MoE hiện có, khá dễ gây nhầm lẫn. Lướt nhanh qua thì chưa rõ một trong hai đã được huấn luyện từ mô hình kia theo cách nào hay chưa
      Cơ chế này không giống speculative decoding. Speculative decoding vẫn là tuần tự, thường đi vài token một lần. Khuếch tán thì không vậy, nó xử lý cả khối văn bản cùng lúc. Tôi vẫn chưa đọc tài liệu, nhưng đoán là nó được huấn luyện để một số expert nhất định giữ ổn định trên toàn bộ khối khuếch tán

  • Trên 3090 Ti của tôi, nó còn không đạt gần tới tốc độ quảng cáo, nhưng nhìn nó “điền dần” câu trả lời cũng khá vui
    Tôi đã thử bài test “pelican SVG đi xe đạp” của Simon, và kết quả khá tối giản nhưng vẫn đáp ứng yêu cầu: https://gist.github.com/peterc/7672e74ec1437945e5fca5ce2c1c9... -- đây là kết quả chạy Q4 quantization trên llama.cpp đã được vá. Tôi cũng tò mò không biết kết quả của Simon khác nhiều đến mức nào

  • Mô hình suy luận kiểu khuếch tán sẽ trông như thế nào nhỉ? Có phải là khuếch tán rất lâu một khối [thinking] có độ dài được ấn định מראש, rồi ở khối đầu ra cuối cùng thì dùng nội dung của khối thinking đó như một phần của đầu vào không?
    Và ngay từ đầu mô hình khuếch tán xác định độ dài đầu ra bằng cách nào? Là một tham số đặt trước, hay là khuếch tán một token [end] ở đâu đó giữa chừng, khá tò mò

  • Trông thì rất hay, nhưng ngay cả khi model chạy cục bộ đã khá ổn thì cảm nhận thực tế vẫn thua rõ rệt so với cả API rẻ nhất, nên tôi không mấy muốn hy sinh dù chỉ một chút chất lượng để đổi lấy tốc độ
    Chắc chắn sẽ có giá trị với một số trường hợp sử dụng, nhưng tôi tò mò không biết có ví dụ cụ thể nào thực sự định triển khai vào production không

    • Viết unit test hoặc bootstrap thì có thể khá ổn
      Không cần đến mức Opus cũng viết được, mà lặp lại cũng dễ