- Gemini Diffusion do Google công bố là LLM đầu tiên sử dụng phương pháp khuếch tán (Diffusion) thay vì transformer
- Tương tự như cách dùng trong các mô hình tạo ảnh như Imagen hay Stable Diffusion
- Mô hình này tạo văn bản thông qua quá trình khuếch tán tinh lọc nhiễu theo từng bước, thay vì cơ chế tự hồi quy truyền thống
- Kết quả là tốc độ phản hồi rất nhanh, trong thử nghiệm cho thấy hiệu năng ở mức 857 token/giây
- Dù vẫn còn thiếu benchmark chính xác, Google cho biết tốc độ của nó nhanh hơn Gemini 2.0 Flash-Lite gấp 5 lần
Tổng quan về Gemini Diffusion
- Gemini Diffusion là mô hình ngôn ngữ lớn (LLM) mới được Google công bố
- Thay vì cơ chế tự hồi quy (autoregressive) của các LLM dựa trên transformer truyền thống, mô hình này áp dụng cách tiếp cận khuếch tán (diffusion)
- Cơ chế khuếch tán này hoạt động tương tự các mô hình tạo ảnh như Imagen, Stable Diffusion..., nhưng được áp dụng cho việc sinh văn bản
- Những đặc điểm nổi bật gồm tốc độ phản hồi nhanh và khả năng sửa lỗi hiệu quả trong quá trình sinh
- Trong ví dụ sử dụng, với prompt "Build a simulated chat app", mô hình tạo ra kết quả HTML+JavaScript chỉ trong vài giây và ghi nhận tốc độ sinh tối đa 857 token/giây
Cách mô hình ngôn ngữ khuếch tán hoạt động
- Các mô hình ngôn ngữ tự hồi quy truyền thống sinh token tuần tự từng cái một, nên chậm hơn và cũng có giới hạn về độ nhất quán của đầu ra
- Trong khi đó, mô hình khuếch tán bắt đầu từ nhiễu rồi dần cải thiện kết quả, xử lý toàn bộ câu hoặc đoạn qua nhiều bước cùng lúc
- Nhờ vậy, sinh token song song trở nên khả thi, giúp tạo kết quả với tốc độ rất cao
- Cách tiếp cận này đặc biệt hiệu quả trong các lĩnh vực cần phản hồi tức thì như chỉnh sửa văn bản, toán học và code
Các mô hình tương tự và so sánh hiệu năng
- Trước đây hầu như chưa có LLM khuếch tán thương mại nào; đến tháng 2/2024, dự án Inception Mercury mới xuất hiện như trường hợp đầu tiên
- Về tốc độ và hiệu năng, theo Google, Gemini Diffusion có chất lượng tương đương Gemini 2.0 Flash-Lite nhưng nhanh hơn khoảng 5 lần
- Mô hình này cũng cho thấy tốc độ sinh cao tương tự Cerebras Coder, và dự kiến sẽ có thêm dữ liệu benchmark khách quan trong thời gian tới
Giải thích thêm và đính chính
- Mô hình ngôn ngữ khuếch tán không hoàn toàn thay thế kiến trúc transformer, mà thay đổi cấu trúc sinh văn bản từ tự hồi quy sang khuếch tán
- Cả Mercury và Gemini Diffusion đều dựa trên transformer, nhưng xử lý toàn bộ đầu vào cùng lúc và khác nhau ở cách sinh
- Đây là dạng phát triển hơn từ cơ chế masking và khôi phục kiểu BERT: tăng dần tỷ lệ masking, rồi dần hoàn thiện kết quả ngay cả khi mọi token đều bị masking
- Phương pháp khuếch tán chỉ chốt một phần token ở mỗi bước, rồi lặp lại để tăng dần tỷ lệ token đã được chốt cho tới khi hoàn tất toàn bộ chuỗi
- Ý tưởng cốt lõi của các diffusion LLM là khôi phục dần dần và sinh song song
Kết luận
- Gemini Diffusion là một LLM thế hệ mới với các đặc tính đột phá về tốc độ và chất lượng sinh
- Mô hình này đã mở rộng thành công các ưu điểm của diffusion vốn được chứng minh trong tạo ảnh sang lĩnh vực sinh văn bản
- Kỳ vọng dành cho giá trị ứng dụng thực tế cũng như các kết quả benchmark trong tương lai đang tăng cao
1 bình luận
Ý kiến trên Hacker News
Không rõ bên trong Google thực sự vận hành thế nào, nhưng gần đây phía RWKV có một diễn biến đáng chú ý. Họ đã thử nghiệm thay toàn bộ cơ chế attention hiện có bằng WKV (linear attention), và làm được toàn bộ quá trình này chỉ bằng post-training. Điều điều này gợi ý là phần lớn tri thức hữu ích thực ra nằm trong FFN (feed-forward network), còn bản thân attention có thể không độc đáo hay quan trọng đến vậy như vẫn nghĩ. Xem thêm các liên kết liên quan cũng khá thú vị. Mặt khác, tận dụng attention đã được huấn luyện sẵn và thử nghiệm riêng xem FFN nhanh đến mức nào ở tốc độ training kiểu GPT-2, dù có hơi trái luật, vẫn là một hướng thú vị mà tôi muốn đọc dưới dạng bài báo. Trong những gì tôi đọc hôm qua, có ý rằng tại một thời điểm nhất định, embedding của mọi mô hình trở nên (rất) giống nhau, nên có thể huấn luyện một bộ chuyển đổi đơn giản; và nếu cả hai điều này đều đúng thì có thể chia sẻ embedding và attention để làm cho toàn bộ quá trình huấn luyện nhanh hơn rất nhiều
Attention, xin dành sự tôn trọng lớn nhất cho các nhà nghiên cứu, theo tôi là cách lấy toàn bộ thông tin quá khứ của mạng rồi đưa vào một mạng nơ-ron reverse-MoE. Ở đây, “chuyên gia” không chọn phần nào của mạng để chạy mà chọn phần nào của đầu vào để thực thi. Ai cũng biết cách này sẽ hiệu quả, nhưng nó quá kém hiệu quả nên ngay cả người dùng R hay Python cũng không nghĩ đến chuyện chạy thử. Bản thân việc training đã quá chậm nên đây là một cấu trúc khó có thể thử nghiệm một cách thực tiễn
Tôi nghĩ câu 'Attention is all you need' có thể thực ra được hiểu theo một nghĩa khác
Câu chuyện rằng embedding của các mô hình trở nên (rất) tương đồng và có thể ánh xạ bằng một bộ biến đổi đơn giản xuất phát từ đây
Tôi xem attention là một cách hoàn toàn tùy tiện để chia nhỏ mạng, từ đó cho phép huấn luyện song song. Phần thực sự góp phần vào thành công là 'shortcut connection' giữa các layer. Chính nó trao nhiều ảnh hưởng hơn cho các layer đầu trong lúc huấn luyện
Việc SDPA attention dùng trong transformer hiện nay có tầm quan trọng tương đối thấp đã là điều được biết đến. FFN, normalization và residual connection thì hoàn toàn không thể thay thế, còn attention thì có thể dễ dàng được thay bằng bất kỳ layer nào khác có nhiệm vụ chia sẻ thông tin giữa các token, như pooling, convolution, random mixing, v.v.
Tốc độ thực sự cực kỳ nhanh. Đến giờ tôi vẫn nghĩ trường hợp sử dụng tốt nhất của mô hình là viết code hoàn toàn mới và tạo prototype nhanh. Tôi không thấy nó đặc biệt mạnh trong việc cải tiến các codebase lớn đã được tinh chỉnh lặp đi lặp lại nhiều lần. Một lý do là, theo định nghĩa, mô hình không thể biết về những thứ 'không có trong' codebase. Việc một thứ gì đó 'không có' trong code cũng là một tín hiệu nhiều ý nghĩa, nhưng đây là thứ khá khó biểu đạt. Dù mô hình có thông minh đến đâu thì ở điểm đó vẫn tồn tại giới hạn nền tảng vì thiếu 'ngữ cảnh và kinh nghiệm nội tại'. Ví dụ, ngay cả khi đưa cho một lập trình viên cực giỏi một codebase lớn và yêu cầu xử lý ngay một vấn đề cụ thể, thì một lập trình viên bình thường nhưng hiểu rõ codebase vẫn có thể tạo ra kết quả giá trị hơn trong cùng khoảng thời gian
Có thể giải quyết vấn đề này nếu tập trung vào cách giao tiếp. Workflow chính của tôi dạo này là, khi cần làm việc lớn như tính năng mới hay refactor, tôi bắt đầu trò chuyện với o3 như với một đồng nghiệp. Tôi liên tục dán các file nguồn cần thiết để cung cấp ngữ cảnh, đồng thời thảo luận ở mức khái quát cao về mục tiêu và tình trạng hiện tại của code. Tôi cảm thấy quá trình này giúp làm rõ điều tôi muốn làm cũng như ngữ cảnh của codebase. Sau đó tôi nhờ o3 lập kế hoạch triển khai, rồi chuyển nó sang Codex để chạy chuỗi tự động hóa như đọc source, sửa file, test, v.v. Khi có PR, đôi khi chỉ cần chỉnh tay một chút hoặc thậm chí merge luôn. Tôi đồng ý rằng mô hình cần ngữ cảnh phong phú, nhưng đây không phải giới hạn bản chất mà là vấn đề về cách cộng tác hiệu quả. Khi đủ thuần thục, không chỉ năng suất tăng lên mà với tôi đây còn là cách làm việc khiến đầu óc vui vẻ hơn
Tôi rất đồng cảm với góc nhìn rằng 'những gì không tồn tại trong codebase cũng mang tín hiệu có ý nghĩa'. Tôi làm phần mềm đã lâu nhưng chưa từng ý thức rõ ràng chân lý nền tảng này đến vậy. Một insight rất đáng cảm ơn
Theo kinh nghiệm của tôi đến nay, LLM rất giỏi bắt chước code tốt sẵn có, nhưng trừ khi được yêu cầu thật cụ thể, nó không tự tạo ra phần mới lạ và độc đáo tốt lắm. Nhiều khi nó không ingest đủ codebase nên mình phải chỉ trực tiếp sang các phần khác của project. Dù vậy, sẽ rất tuyệt nếu có thể đưa 'negative prompt' như trong Stable Diffusion
Tôi tò mò nếu LLM có thể đọc toàn bộ git history, issue tracker, thậm chí cả recording các cuộc họp như context thì sẽ cho ra kết quả gì. Còn việc context đầu vào cực lớn có thực sự dẫn đến kết quả hữu ích trong thực tế hay không thì vẫn cần quan sát thêm
Tôi thực sự bất ngờ với công bố lần này. Theo tôi đây là thông báo lớn nhất ở IO, nhưng lại bị lấn át bởi các tin khác như Veo 3, thật đáng tiếc. Việc dùng diffusion model cho sinh code có ý nghĩa rất lớn. Nếu dùng transformer thì nó sẽ thuộc họ DiT (diffusion transformer); vài năm trước tôi từng tham gia một mô hình lai kết hợp diffusion nền U-Net, và từ đó đến nay đã có rất nhiều tiến bộ. Tôi nghĩ lĩnh vực diffusion sắp có một bước nhảy lớn
Tôi tò mò trực giác từ vision transformer sẽ hoạt động thế nào khi áp dụng vào code. Trong thị giác máy tính, mô hình bắt đầu từ nhiễu rồi dần dần làm rõ ảnh mục tiêu theo từng tầng. Nếu áp dụng nguyên lý này vào sinh code thì có vẻ cần một cấu trúc phân cấp giảm dần mức trừu tượng, ví dụ như 'phải dùng Django', 'xác định danh sách endpoint', rồi 'sinh code cụ thể'. Nhưng diffusion không có cơ chế backtracking, nên dù phát hiện vấn đề ở mức thấp cũng bị hạn chế trong việc phản hồi ngay cho layer cấp cao. Ngược lại, transformer chạy toàn bộ mô hình cho từng token nên dễ backtracking và đổi thiết kế khi cần theo từng vấn đề. Có thể mô hình tinh thần của tôi còn sai, nên tôi muốn nghe thêm insight
Veo 3 gây chú ý vì hiệu năng và điểm khác biệt của nó rất trực quan, còn để hiểu giá trị của một bước tiến lớn trong text completion thì phải biết các thành tựu hiện có và ứng dụng tiềm năng. Hiện vẫn còn nhiều người chưa thực sự tin rằng LLM hữu ích cho việc lập trình
Mô hình sinh code dựa trên diffusion thực sự rất đột phá. Một vài ý tưởng đơn giản về những gì loại mô hình này có thể làm gồm: cố định function signature và kết quả rồi sinh các token ở giữa theo cách tận dụng thông tin hai chiều. Thứ hai, đầu tiên phác ra khung lớn của một hàm (giống như để LLM viết các 'chương' của một bài báo), sau đó mới chia nhỏ dần thành phần triển khai. Sinh lặp trong context lớn hơn với sự dẫn hướng từ đủ loại tín hiệu như linters, thông tin AST, v.v. Có quá nhiều thứ để thử nghiệm
Về nguyên tắc, tôi nghĩ cách này có thể có ưu thế lớn, nhưng các mô hình như LLaDA mà tôi đã thử trong thực tế, dù ấn tượng so với lượng tài nguyên huấn luyện ít ỏi, vẫn còn tụt lại theo các thước đo như perplexity. Nó cũng có xu hướng bị cố định trong quá trình sinh nên có vẻ bị hạn chế khi chỉnh sửa sâu văn bản; xác suất masking càng cao thì càng khó sửa đồng thời. Dù vậy, trong thực nghiệm tôi vẫn thu được kết quả khá thực dụng
Tôi đã thấy demo từ những nơi như InceptionLabs rồi nên không đến mức quá bất ngờ
Có vẻ điểm cốt lõi của tin này đang bị chìm mất. Đây là một InstructGPT thực sự nhanh và tốt. Trong tương lai nó chắc chắn sẽ được dùng cho kiểm tra chính tả, codemod, code editor, v.v. Nhờ tính năng Instant edits, có thể chỉnh sửa văn bản cực nhanh và chính xác mà không kèm thêm nội dung hay gợi ý thừa. Tôi đã nhờ nó đổi tên biến trong một đoạn mã mẫu của ShaderToy cho dễ hiểu hơn, sao chép kết quả chạy thử thì vẫn hoạt động tốt, khá bất ngờ
Điểm mạnh của diffusion không chỉ là tốc độ. Theo benchmark ban đầu, so với AR nó còn tốt hơn về suy luận và lập kế hoạch với cùng số tham số. Diffusion cho phép chỉnh sửa ở giữa và không gặp vấn đề thiên lệch token ban đầu
Một tuyên bố khá thú vị. Tôi muốn biết liệu có thể chia sẻ benchmark liên quan hoặc liên kết đến tài liệu làm căn cứ không
Bản thân AR không cản trở việc lập kế hoạch dài, nhưng trong cách triển khai của nhiều mô hình AR phổ biến hiện nay thì kiểu giới hạn đó thường xuất hiện. AR về cơ bản vẫn rất quan trọng để học đúng phân phối
Cá nhân tôi đồng ý, hoặc ít nhất là mong điều đó đúng, nhưng tôi vẫn chưa thấy bài báo hay demo nào về revise diffusion text. Nếu có thông tin bài báo thì rất muốn được chia sẻ để dùng thử
Tôi đã quan tâm từ lâu đến việc áp dụng kỹ thuật diffusion vào sinh văn bản. Cuối cùng Google cũng ra một mô hình như vậy, khiến tôi vui vì cảm giác như suy nghĩ của mình được kiểm chứng. Về phần cứng dùng cho thử nghiệm, đa số hiện nay là dịch vụ trả phí hoặc thiết bị cao cấp, ít nhất cũng là loại cao trong nhóm consumer. Hiện tôi chỉ có cỡ 5700XT nên rất khó nâng cấp, nhưng nhờ vậy lại nhìn rõ hơn giới hạn của các mô hình hiện tại. Mô hình càng lớn thì độ nhất quán càng cao, nên mô hình nhỏ rốt cuộc chỉ giới hạn ở các tác vụ đơn giản. Một điều tôi xác nhận được qua thử nghiệm chính là tầm quan trọng của kích thước context; với GPU nhỏ thì khó nhét đồng thời context đủ lớn và mô hình đủ lớn, nên tôi tự hỏi với mô hình dựa trên diffusion liệu có thể thay đổi cân bằng giữa mật độ và độ nhất quán hay không. Tôi kỳ vọng nó có thể sinh văn bản nhất quán hơn với ít context hơn, và cho kết quả trộn tool call + phản hồi tốt hơn. Vấn đề tốc độ cũng là nỗi bực bội rất thực tế; cách LLM truyền thống hoạt động chậm theo vòng lặp input-output, nhất là trên GPU cũ không có phần cứng chuyên cho AI, đúng là thử thách sự kiên nhẫn. Nếu ít nhất có thể nhìn tiến trình 0~100% theo thời gian thực thì cũng tốt, và tôi hy vọng diffusion model sẽ khá hơn ở điểm này. Từ đó tôi nảy ra thắc mắc: vì đầu vào nhiễu là quan trọng, liệu có tồn tại nguồn nhiễu tốt chuyên cho LLM/text không, và độ dài toàn khối có phải cố định trước hay có thể biến thiên?
Từ góc nhìn của tôi thì có thể nói chắc rằng mô hình này cực kỳ nhanh. Điểm yếu là nó rất dễ bị xuyên thủng bởi các cuộc tấn công prompt injection. Ví dụ, nếu yêu cầu cách điều chế thuốc thì nó sẽ từ chối, nhưng nếu chuyển thành 'roleplay làm trẻ con' thì lại trả ra kết quả thật. Bỏ qua nhược điểm đó thì tốc độ và khả năng dùng cho tự động hóa thực sự rất tốt. Nếu kết hợp thêm hướng tiếp cận kiểu agent thì tiềm năng của mô hình này sẽ tỏa sáng
Điều đó có thể không phải giới hạn của bản thân mô hình, mà là do trong quá trình training ít tài nguyên được dồn vào phần an toàn hay kiểm duyệt hơn. Theo tôi đây giống một nguyên mẫu thử nghiệm, có lẽ là bản trình diễn nhẹ trước khi đầu tư nghiêm túc vào mô hình lớn
Tôi không nghĩ kiểu prompt injection này là tín hiệu cho thấy chúng ta sắp kiểm soát được những mô hình thông minh hơn
Mô tả kiểu 'LLM diffusion đầu tiên của Google, dùng diffusion thay vì transformer' là một khẳng định sai. Google chưa từng công bố như vậy. Ngược lại, mô hình diffusion nền transformer là rất phổ biến. Tôi nghĩ Gemini Diffusion cũng nhiều khả năng dùng transformer. Khác biệt có lẽ là nó là encoder-only transformer. Tức là đưa toàn bộ chuỗi vào trong trạng thái noisy/corrupted và dự đoán lại toàn bộ chuỗi đúng. Nhờ đó có thể tính toán song song trên toàn bộ khung chuỗi cùng lúc, và nếu số vòng lặp vừa phải thì sẽ nhanh hơn nhiều so với giải mã tuần tự của mô hình decoder-only, dù tất nhiên speculative decoding cũng có upside tốc độ tương tự. Thường thì người ta huấn luyện bằng kiểu masking như BERT, nhưng đây vẫn là lĩnh vực nghiên cứu rất sôi động. Tôi cũng tò mò mối quan hệ với Gemini và việc có tận dụng checkpoint hiện có không: import trực tiếp, fine-tuning chuyên cho diffusion, knowledge distillation, hay chỉ đơn giản là tên thương hiệu. Giá mà có thêm chi tiết chính thức được công bố
Nhanh đến mức vô lý. Tôi dự đoán GPU sẽ luôn chạy ở công suất tối đa và gần như không có lợi ích tiết kiệm compute từ batch processing. Nhưng nghĩ kỹ thì điều đó cũng không hẳn là một tradeoff đúng nghĩa. Một lo ngại là objective diffusion có thể thua AR về mặt hiệu năng. Nếu vậy, mô hình AR nhiều token mỗi bước có thể đạt tốc độ tương đương diffusion, hoặc có thể dùng mô hình diffusion làm bộ sinh bản nháp cho speculative decoding
Tôi muốn hiểu vì sao bạn nghĩ dLLM sẽ kém chất lượng hơn arLLM. Vì nó xử lý lặp đi lặp lại đầu ra như một 'tổng thể có cấu trúc' (chủ đề, ý chính, khái niệm, cây từ ngữ), nên theo tôi về chất lượng thậm chí còn có thể tốt hơn
Tradeoff mang tính cấu trúc này sẽ có lợi hơn nhiều trong môi trường tự host. Vì ở đó không cần batch quy mô lớn, nên tuy trên cloud lợi ích ít hơn, với LLM chạy cục bộ lại là ưu điểm lớn
Tôi cực kỳ phấn khích với diffusion LLM. Đội của chúng tôi đang mơ về cơ chế game dạng giọng nói → code, và diffusion có thể chính là mảnh ghép hoàn hảo để hoàn thiện điều đó. Cerebras và Groq rất ấn tượng, nhưng vì là phần cứng tùy chỉnh nên có giới hạn về fine-tuning và scale. Các lựa chọn còn lại thì là MoE với active parameter cỡ 0.5b, nhưng hiện tại chúng tôi chưa có điều kiện đổ nguồn lực vào hướng đó. Nếu có ai từ Google/Deepmind đọc được, xin hãy cung cấp API. Đội chúng tôi đang phát triển một game sandbox sinh sinh, trong đó tác phẩm đầu tiên có cấu trúc cho phép ra lệnh cho quái vật theo thời gian thực. Chúng tôi cũng có video prototype để tham khảo nếu cần