- Chỉ vài tuần sau khi ra mắt Gemma 4, Google đã vượt mốc 60 triệu lượt tải xuống và công bố drafter dự đoán đa token (MTP) dành cho dòng sản phẩm Gemma 4
- MTP drafter là một kiến trúc giải mã suy đoán (speculative decoding) chuyên biệt, giúp tăng tốc độ suy luận lên tới 3 lần mà không làm giảm chất lượng đầu ra hay logic suy luận, và đã được thử nghiệm trên phần cứng dùng LiteRT-LM, MLX, Hugging Face Transformers và vLLM
- Suy luận LLM tiêu chuẩn gặp nút thắt lớn về băng thông bộ nhớ vì phải chuyển hàng tỷ tham số từ VRAM sang các đơn vị tính toán để tạo ra một token duy nhất; MTP để một drafter nhẹ đề xuất nhiều token tương lai rồi để mô hình đích xác minh song song
- Nếu mô hình đích đồng ý với các token bản nháp, nó sẽ chấp nhận toàn bộ chuỗi trong một lượt truyền thuận duy nhất và đồng thời tạo thêm một token nữa, nhờ đó ứng dụng thường có thể xuất ra chuỗi bản nháp cùng token bổ sung trong thời gian vốn chỉ đủ để tạo một token
- MTP drafter chia sẻ các giá trị kích hoạt của mô hình đích và KV cache, áp dụng kỹ thuật phân cụm embedder hiệu quả cho các mô hình biên E2B·E4B, và trọng số được cung cấp theo giấy phép Apache 2.0 trên Hugging Face và Kaggle
Vì sao cần giải mã suy đoán
- Suy luận LLM tiêu chuẩn bị ràng buộc bởi băng thông bộ nhớ nên độ trễ dễ trở thành nút thắt
- Bộ xử lý phải dành phần lớn thời gian để chuyển hàng tỷ tham số từ VRAM sang các đơn vị tính toán chỉ để tạo ra một token duy nhất
- Cấu trúc này, đặc biệt trên phần cứng tiêu dùng, khiến tài nguyên tính toán không được tận dụng đầy đủ và làm tăng độ trễ
- Giải mã suy đoán tách riêng việc tạo token và xác minh token
- Một mô hình đích nặng, ví dụ Gemma 4 31B, được ghép với một drafter nhẹ là mô hình MTP để dự đoán nhiều token tương lai cùng lúc bằng phần tài nguyên tính toán đang nhàn rỗi
- Drafter đề xuất nhiều token trong thời gian ngắn hơn thời gian mô hình đích xử lý một token, còn mô hình đích xác minh các token được đề xuất theo kiểu song song
Cách MTP hoạt động
- Các mô hình ngôn ngữ lớn tiêu chuẩn tạo văn bản theo kiểu tự hồi quy, mỗi lần chỉ tạo đúng một token
- Cách này tiêu tốn cùng một lượng tính toán cho cả việc nối tiếp đơn giản như dự đoán “words” sau “Actions speak louder than…” lẫn việc giải các câu đố logic phức tạp
- MTP giảm sự kém hiệu quả này bằng giải mã suy đoán do các nhà nghiên cứu Google giới thiệu trong Fast Inference from Transformers via Speculative Decoding
- Nếu mô hình đích đồng ý với các token bản nháp, nó sẽ chấp nhận toàn bộ chuỗi trong một lượt truyền thuận duy nhất, đồng thời bản thân mô hình đích cũng tạo thêm một token nữa
- Ứng dụng thường có thể xuất ra toàn bộ chuỗi bản nháp và thêm một token nữa trong khoảng thời gian vốn cần để tạo ra một token duy nhất
Tác động hiệu năng cho nhà phát triển
- Với nhà phát triển, tốc độ suy luận thường là nút thắt chính khi triển khai production
- Trong các tác nhân tự động cần lập kế hoạch nhiều bước nhanh, trợ lý lập trình và ứng dụng di động phản hồi cao chạy hoàn toàn on-device, độ trễ tính bằng mili giây cũng rất quan trọng
- Khi dùng mô hình Gemma 4 cùng drafter tương ứng, có thể đạt được các lợi ích sau
-
Cải thiện độ phản hồi
- Có thể giảm mạnh độ trễ cho chat gần thời gian thực, ứng dụng giọng nói nhập vai và workflow dạng agent
-
Tăng tốc phát triển cục bộ
- Chạy nhanh các mô hình 26B MoE và 31B Dense trên máy tính cá nhân và GPU tiêu dùng để hỗ trợ các workflow lập trình ngoại tuyến và tác tử phức tạp
-
Nâng cao hiệu năng on-device
- Giúp các mô hình E2B và E4B xuất kết quả nhanh hơn trên thiết bị biên, từ đó hỗ trợ giảm mức tiêu thụ pin của thiết bị
-
Không suy giảm chất lượng
- Vì mô hình Gemma 4 gốc vẫn giữ vai trò xác minh cuối cùng, nên có thể cung cấp cùng mức suy luận và độ chính xác với tốc độ nhanh hơn nhiều
- Ví dụ chạy Gemma 4 26B trên NVIDIA RTX PRO 6000 so sánh số token mỗi giây giữa suy luận tiêu chuẩn và MTP drafter, cho thấy độ trễ giảm còn khoảng một nửa trong khi chất lượng đầu ra giữ nguyên
- Có thể tải video so sánh để xem
Tối ưu hóa nội bộ của MTP drafter
- Nhiều cải tiến kiến trúc đã được áp dụng để làm cho MTP drafter vừa nhanh vừa chính xác
- Mô hình bản nháp tận dụng tự nhiên các giá trị kích hoạt của mô hình đích và chia sẻ KV cache của mô hình đích
- Nhờ chia sẻ KV cache, mô hình lớn không lãng phí thời gian tính lại ngữ cảnh mà nó đã xử lý
- Trên các mô hình biên E2B và E4B, bước tính toán logit cuối cùng trở thành nút thắt lớn, vì vậy một kỹ thuật phân cụm hiệu quả được triển khai trong embedder để tăng tốc quá trình sinh
- Các tối ưu hóa theo từng phần cứng cũng đã được phân tích
- Trên Apple Silicon, mô hình mixture-of-experts 26B có các thách thức định tuyến riêng khi kích thước batch là 1, nhưng khi xử lý đồng thời nhiều yêu cầu, tốc độ cục bộ có thể tăng tối đa khoảng 2,2 lần
- Kích thước batch ví dụ là 4~8, và trên NVIDIA A100 cũng xuất hiện mức cải thiện tương tự khi tăng batch size
- Kiến trúc trực quan, cách chia sẻ KV cache và cách embedder hiệu quả hoạt động có thể xem trong giải thích kỹ thuật chuyên sâu
Cách sử dụng và nơi cung cấp
- MTP drafter cho dòng Gemma 4 được cung cấp theo cùng giấy phép mã nguồn mở Apache 2.0 như Gemma 4
- Có thể xem cách dùng MTP với Gemma 4 trong tài liệu
- Trọng số mô hình có thể tải xuống từ Hugging Face và Kaggle
- Có thể thử suy luận nhanh hơn với transformers, MLX, vLLM, SGLang, Ollama
- Có thể dùng thử trực tiếp qua Google AI Edge Gallery trên Android hoặc iOS
- Google kỳ vọng mức tăng tốc này sẽ thúc đẩy phát triển trong hệ sinh thái Gemma là Gemmaverse
1 bình luận
Ý kiến trên Hacker News
Gemma và Gemini dùng ít token đầu ra hơn rất nhiều so với các mô hình khác mà vẫn khá sát hiệu năng benchmark hàng đầu
So Gemma với Qwen thì Qwen nhỉnh hơn một chút, nhưng có khi mất 22 phút cho một tác vụ, còn Gemma thường xong cùng prompt chỉ trong 4 phút dù có thể căn sai vị trí nút bấm
Nhìn bề ngoài thì Gemma kém các mô hình mở dẫn đầu khoảng 5~10%, nhưng chỉ tốn 1/10 thời gian
Cũng chưa từng thấy cần phải nâng cấp như những người khác khoe gói 100 USD/tháng trên Claude hay Codex
Tuy vậy, Gemini đã vài lần bị giảm chất lượng trong năm qua và giới hạn tốc độ cũng chặt hơn, nên không rõ sau này có còn tốt thế này không
Mô hình lớn thường dùng ít token hơn cho cùng một mức độ thông minh, nên điều này có vẻ giải thích được chênh lệch về lượng token
Tôi đã thử trên 4070, đầu ra không quá nhanh nhưng vẫn dùng được
Tôi chưa thử cho các tác vụ phức tạp, nên trong trường hợp đó có thể sẽ khác
Sau Google I/O có lẽ sẽ có nhiều người nhận ra Gemini tốt đến mức nào
Nếu có vấn đề căn chỉnh thì lại phải tốn thêm một lượt token đầu vào và đầu ra để sửa
Hỗ trợ MTP đang được thêm vào llama.cpp, và ít nhất là đang triển khai cho các mô hình Qwen (https://github.com/ggml-org/llama.cpp/pull/20533)
Có vẻ Gemma 4 cũng sẽ sớm theo sau
Trong vài tháng gần đây, mức cải thiện về chất lượng và tốc độ của các mô hình local/tự host thật sự đáng kinh ngạc
Với người đã chạy mô hình local từ lâu như tôi thì đây đúng là giai đoạn rất thú vị
Tôi rất muốn sớm thấy nó so với MTP sẽ ra sao
Đó là một công cụ khá ổn
Google gần như đang một mình chống đỡ mảng mô hình mã nguồn mở ở phương Tây
Gemma 4 31B rất xuất sắc
Nhưng để nhét được bản tốt nhất, gồm cả khả năng thị giác và cả drafter sắp ra mắt, vào 24GB VRAM thì khá đau đầu
Bộ máy của tôi không thể gắn thêm GPU, và để có hiệu năng cao nhất thì có vẻ либо phải mua thêm một chiếc 4090 quá đắt, hoặc thay cả dàn
--no-mmproj-offloadthì có thể để bộ chiếu đa phương thức, tức phần hiểu âm thanh, hình ảnh và PDF, trong RAM hệ thốngTất nhiên như vậy sẽ không có tăng tốc GPU, nhưng sẽ tiết kiệm VRAM
Nó còn có thể tinh chỉnh theo từng tác vụ tốt hơn, nên có thể chọn ưu tiên tư duy và độ chính xác hay ưu tiên tốc độ suy luận
Nhìn máy tính viết chữ làm tôi nhớ lại thời kết nối modem vào BBS ngày xưa
Cảm giác như nâng từ modem 300 baud lên 1200 baud, tức là cải thiện lớn, nhưng vẫn khá chậm, và có lẽ sau này chúng ta sẽ tự hỏi sao mình từng chịu được thứ này
Nhìn token chảy ra giống như nhìn ảnh JPEG tải lên từng hàng pixel, cũng gợi nhớ đến đủ loại hoạt ảnh loading/kết nối mà app từng tự nghĩ ra trước khi tốc độ đủ nhanh
Những gì Cerebras hay Taalas đang làm là vài tín hiệu thú vị cho thấy hướng đó có thể mở ra điều gì
Cũng rất vui khi tưởng tượng xem điều gì sẽ khả thi nếu ngay cả các mô hình tối tân hiện nay cũng có thể dùng ở mức hàng triệu token mỗi giây với chi phí rất thấp
So sánh modem với Claude mà Claude tự tính ra là thế này: với 2368 ký tự, 300 là 1 phút 19 giây, 1200 là 19,7 giây, 2400 là 9,9 giây, 14.4K là 1,6 giây, 33.6K là 705ms, 56K là 447ms, còn Claude là 7,9 giây
Tốc độ ở mức vài nghìn token mỗi giây
Chiến lược của Google có vẻ hơi khác so với các nhà cung cấp frontier khác
Có vẻ họ tập trung nhiều hơn vào hiệu quả hiệu năng trên chi phí tính toán thay vì hiệu năng thuần túy, nên có thể vì thế mà Gemini trông như đang tụt lại
Các nhà cung cấp khác đang đụng trần công suất và cả giới hạn trong việc trợ giá chi phí suy luận
Chiến lược của Google có vẻ là mở rộng và triển khai các mô hình này cho hàng tỷ người dùng sẵn có
Ngược lại, nó cho cảm giác như một kiểu thông minh khác với GPT-5 mới nhất và dòng Claude
Nhóm kia ngày càng tập trung vào năng suất và tự động hóa công việc, tối ưu cho các vòng lặp suy luận tự sửa lỗi dài và mang tính agent
Gemini giống một mô hình nền tảng thông minh hơn nhiều, đặc biệt trong chế độ Deep Think thì trực giác cho cảm giác sâu hơn hẳn, nhưng lại không làm tốt bằng ở các vòng lặp agent tự sửa lỗi đường dài
Vài tháng qua, quy trình làm việc của tôi là dùng Gemini cho các bước nhảy sáng tạo và insight, còn với các tác vụ lặp lại hoặc đòi hỏi độ chính xác cao thì tôi thích Codex, Claude và GPT-5.5 Pro hơn
Tôi đã nghỉ dùng mô hình local một thời gian, rồi gần đây cấu hình mô hình 26B A4B trên RTX 3090 bằng vLLM 4-bit, và hoàn toàn bất ngờ với tốc độ lẫn chất lượng có được từ khoản đầu tư dưới 1000 USD
Ban đầu tôi thử với Qwen nhưng nó không ổn định, và vết tích tư duy thì dài vô lý
Nó vẫn khá khó chiều, nhưng chỉ cần chỉnh nhẹ là thật sự rất ấn tượng
Mô hình local là tương lai nên quá tuyệt
Trong tác vụ code thì nó thua Qwen 3.6 khá rõ, nhưng điều đó đúng hơn là cho thấy mô hình Qwen quá xuất sắc
Trên máy tôi, khi so với các mô hình 30B khác thì tg nhanh hơn ít nhất gấp đôi so với kỳ vọng, có lẽ nhờ hybrid attention
Tuy vậy phần xử lý đầu vào lại chậm hơn một chút
Tôi tò mò không biết có ai đã làm cho cái này chạy được trong LM Studio chưa
UI có tùy chọn nhưng dường như không kích hoạt được
[1] https://github.com/ml-explore/mlx-lm/pull/990
[2] https://github.com/ggml-org/llama.cpp/pull/22673
Vì không có mô hình nhỏ nên cần kiểm tra xem bạn có đang dùng mô hình sparse của Gemma hay không
Và tôi đã xóa toàn bộ mô hình ảnh khỏi workspace
Thỉnh thoảng xóa chúng đi thì nó mới hiện ra
Có vẻ các file này bằng cách nào đó gắn với khả năng thị giác và chặn speculative decoding, nhưng đừng hỏi tôi tại sao
Với Gemma thì dùng speculative decoding theo đường llama-server hiệu quả hơn LM Studio
Thường thì nhà cung cấp, bản lượng tử hóa, v.v. phải khớp với nhau hoàn toàn
Có thể sẽ mất thời gian để tìm được một bộ ghép đúng
Trong thử nghiệm của tôi, mô hình Gemma 4 31B cho mức tăng tốc lớn nhất trong tác vụ code khi dùng MLX runner của Ollama, khoảng 2 lần
Tuy vậy, lượng tử hóa làm giảm mạnh tỷ lệ chấp nhận nên cần một máy Mac khá mạnh
Ba mô hình nhỏ hơn còn lại không tốt bằng vì thời gian xác minh mô hình draft đã ăn gần hết phần tăng hiệu năng
Tôi vẫn đang tinh chỉnh xem có thể đạt hiệu năng tốt hơn không
Bạn có thể thử bằng cách chạy
ollama run gemma4:31b-coding-mtp-bf16trên Ollama 0.23.1Nếu được merge vào llama.cpp thì tôi rất muốn dùng thử ngay
Trong môi trường của tôi, Gemma 4 26B-A4B đã nhanh hơn khoảng 3 lần so với Qwen3.6-35B-A3B, nên chỉ nghĩ tới việc cộng thêm 1,5 lần tăng tốc nữa thôi cũng đã hấp dẫn
Tôi cũng thử mô hình draft nhưng kết quả hạn chế, và ngay cả mô hình draft 3B nhỏ hơn cùng mô hình dense Ministral 14B cũng đã tạo ra quá nhiều overhead
Gemma4 26B vượt 200TPS với cùng mức lượng tử hóa
Cũng cần lưu ý là Qwen có hiệu quả suy luận cực thấp
Chuỗi suy nghĩ của nó trung bình dài hơn Gemma khoảng 3 lần
Không biết cái này có giống dự đoán nhánh trong hệ điều hành không
Chỉ là ở đây xác suất đã được nhúng ngay trong chính mô hình, nên đáng tin hơn rất nhiều
Dự đoán nhánh sai sẽ đốt chu kỳ, còn ở đây đoán sai thường chỉ là không kiếm thêm được token thưởng
https://arxiv.org/abs/2211.17192