Gemma 4 Ra Mắt Mà Không Có Dữ Liệu MTP — Đây Là Lý Do Tại Sao Điều Đó Quan Trọng

Google phát hành Gemma 4 vào ngày 3 tháng 4 năm 2026 — một họ mô hình open-weight với kết quả benchmark ấn tượng, khả năng đa phương thức và ngữ cảnh lên đến 256K. Trên giấy, đây là một bản phát hành đáng chú ý. Nhưng chỉ trong vài giờ, cộng đồng phát hiện ra thứ đang thiếu: các Multi-Token Prediction head đã bị loại bỏ khỏi trọng số công khai.

Mô hình đã được huấn luyện cùng MTP. Framework LiteRT của chính Google bao gồm các thành phần MTP. Nhưng phiên bản mà mọi người có thể tải xuống từ HuggingFace? Chỉ có sinh autoregressive tiêu chuẩn. Không tăng tốc. Không speculative decoding.

Bài viết này giải thích MTP là gì, tại sao nó quan trọng, và quyết định này có ý nghĩa gì với bất kỳ ai chạy Gemma 4 trên phần cứng của riêng mình.

Gemma 4 Là Gì?

Gemma 4 là họ mô hình open-weight mới nhất của Google DeepMind, phát hành theo giấy phép Apache 2.0. Nó có bốn kích thước:

Các khả năng chính bao gồm hỗ trợ đa phương thức gốc, gọi hàm, đầu ra JSON có cấu trúc, và huấn luyện trên hơn 140 ngôn ngữ. Biến thể 31B xếp hạng #3 trên bảng xếp hạng văn bản LMArena.

Bên trong, Gemma 4 giới thiệu một số cải tiến kiến trúc: các lớp attention cục bộ cửa sổ trượt và toàn cục xen kẽ, RoPE tỷ lệ (p-RoPE), Per-Layer Embeddings (PLE), KV cache chia sẻ, và tối ưu bộ nhớ “Keys equal Values”.

Về mặt con số, đây là một bản phát hành mạnh mẽ. Vấn đề nằm ở những gì không có trong trọng số công khai.

Multi-Token Prediction Là Gì?

Các mô hình ngôn ngữ lớn tiêu chuẩn sinh văn bản mỗi lần một token. Mỗi token yêu cầu một lần forward pass đầy đủ qua mô hình. Token tiếp theo không thể bắt đầu cho đến khi token trước hoàn tất. Đây là giải mã autoregressive, và nó vốn dĩ là tuần tự.

Multi-Token Prediction (MTP) thay đổi điều này bằng cách thêm các prediction head bổ sung vào mô hình. Thay vì chỉ dự đoán token tiếp theo, mô hình dự đoán các token N+1, N+2, N+3, v.v. — tất cả trong một lần forward pass duy nhất.

Đây là cách nó hoạt động:

1. Giai đoạn huấn luyện: Các prediction head nhẹ bổ sung được huấn luyện cùng mô hình chính. Mỗi head học cách dự đoán một vị trí tương lai khác nhau (trước 1, trước 2, trước 3, v.v.)
2. Giai đoạn suy luận: Các head bổ sung sinh các token “nháp” song song. Mô hình chính sau đó xác minh tất cả chúng trong một lần forward pass duy nhất.
3. Xác minh: Nếu các token nháp khớp với những gì mô hình chính sẽ sinh ra, tất cả đều được chấp nhận cùng lúc — bỏ qua nhiều bước giải mã tuần tự. Nếu một token nháp sai, quá trình sinh quay lại vị trí đó.

Điều này liên quan chặt chẽ đến speculative decoding, nhưng với một lợi thế quan trọng: các token nháp đến từ chính mô hình thay vì yêu cầu một “mô hình nháp” nhỏ hơn riêng biệt.

MTP Nhanh Hơn Bao Nhiêu?

Mức tăng tốc phụ thuộc vào tần suất các token nháp đúng (“tỷ lệ chấp nhận”). DeepSeek V3 đã chứng minh tác động thực tế:

Tỷ lệ chấp nhận 2,4 có nghĩa là trung bình, mỗi lần forward pass qua mô hình chính tạo ra 2,4 token thay vì 1. Đầu ra hoàn toàn giống với giải mã tiêu chuẩn về mặt toán học — mọi token đều được xác minh. Bạn có cùng chất lượng với tốc độ gần gấp đôi.

Sẵn sàng phát triển doanh nghiệp của bạn?

Bắt đầu dùng thử miễn phí ngay hôm nay và xem kết quả trong vài ngày.

Yêu cầu demo Đăng nhập

Chuyện Gì Đã Xảy Ra Với Gemma 4

Một người dùng HuggingFace (@shadowlilac ) phát hiện rằng gói LiteRT của Google cho Gemma 4 chứa các MTP prediction head và chức năng multi-token prediction. Nhưng trọng số phát hành công khai trên HuggingFace không có gì cả.

Các thành phần MTP đã bị cố tình loại bỏ:

• Không có MTP head trong checkpoint
• Không có MTP trong cấu hình mô hình
• Không có MTP trong forward pass

Giải Thích Của Google

Một kỹ sư Google (@srikanta-221 ) xác nhận đây là hành động có chủ đích:

Mô hình công khai chỉ cung cấp giao diện autoregressive tiêu chuẩn “để tương thích rộng rãi.” Các MTP head được loại khỏi cấu hình mô hình, forward pass và checkpoint. Điều này đảm bảo tương thích với các API của HuggingFace Transformers và duy trì hành vi checkpoint và runtime nhất quán.

Google đóng khung MTP như một “tối ưu hóa khi triển khai” thay vì tính năng cốt lõi của mô hình. Các MTP prediction head chỉ được giữ lại trong các mô hình xuất qua LiteRT — framework suy luận trên thiết bị của chính Google.

Tại Sao Đây Là Vấn Đề

Lời giải thích không đứng vững khi xem xét kỹ:

1. Mô hình đã được huấn luyện với MTP. Khả năng này tồn tại. Loại bỏ nó khỏi bản phát hành là một lựa chọn, không phải giới hạn kỹ thuật.

2. Các engine bên thứ ba không thể triển khai nó. vLLM, llama.cpp, SGLang và các framework suy luận khác không thể sử dụng speculative decoding dựa trên MTP nếu không có các prediction head. Các engine này phục vụ phần lớn các triển khai LLM mã nguồn mở.

3. Người dùng nhận được phiên bản chậm. Không có MTP, Gemma 4 chạy ở tốc độ autoregressive tiêu chuẩn. Khoảng cách hiệu suất đã rõ ràng trong thực tế:

4. Nó tạo ra sự phụ thuộc vào hệ sinh thái. Framework LiteRT của Google được lợi thế tốc độ. Những người còn lại nhận được mô hình chậm hơn. Đối với một bản phát hành “open-weight” theo Apache 2.0, đây là sự bất đối xứng đáng kể.

Cách Speculative Decoding Hoạt Động (và Tại Sao MTP Tốt Hơn)

Để hiểu tại sao các MTP head bị thiếu lại quan trọng, cần thấy vị trí của MTP trong quá trình phát triển của tối ưu hóa suy luận.

Phương pháp 1: Speculative Decoding Truyền Thống

Một “mô hình nháp” nhỏ hơn riêng biệt đề xuất token. Mô hình chính xác minh chúng song song. Nếu các bản nháp đúng, nhiều token được chấp nhận mỗi bước.

• Ưu điểm: Hoạt động với bất kỳ cặp mô hình nào
• Nhược điểm: Cần duy trì và tải mô hình thứ hai; chất lượng mô hình nháp giới hạn mức tăng tốc; tốn thêm bộ nhớ

Phương pháp 2: MTP (Prediction Head Tích Hợp)

Mô hình chính có các prediction head nhẹ riêng để sinh token nháp. Không cần mô hình riêng biệt.

• Ưu điểm: Không cần mô hình bổ sung; tích hợp chặt chẽ hơn nghĩa là tỷ lệ chấp nhận cao hơn; ít tốn bộ nhớ hơn
• Nhược điểm: Chỉ hoạt động nếu các prediction head được bao gồm trong bản phát hành

Tại Sao MTP Chiến Thắng

Các MTP prediction head được huấn luyện cùng với mô hình chính. Chúng chia sẻ cùng các biểu diễn nội bộ và học phân phối token của chính mô hình. Điều này thường tạo ra tỷ lệ chấp nhận cao hơn so với mô hình nháp bên ngoài, nghĩa là nhiều token được chấp nhận hơn mỗi bước xác minh và tốc độ sinh nhanh hơn tổng thể.

Các prediction head cũng rất nhỏ — thường chỉ thêm 1-3% vào tổng số tham số của mô hình. Chi phí bộ nhớ là không đáng kể so với việc tải một mô hình nháp riêng biệt.

Tham gia bản tin của chúng tôi

Nhận các mẹo, xu hướng và ưu đãi mới nhất miễn phí.

Địa chỉ email

Đăng ký

Tác Động Rộng Hơn

Đây không chỉ là câu chuyện về Gemma 4. Quyết định này tạo tiền lệ cho mức độ “mở” thực sự của các bản phát hành open-weight.

Những gì người dùng mất:

• Speculative decoding dựa trên MTP trên bất kỳ engine suy luận bên thứ ba nào
• Khả năng tinh chỉnh hoặc thử nghiệm với các MTP head
• Ngang bằng hiệu suất với công cụ triển khai riêng của Google

Những gì người dùng vẫn có:

• Trọng số mô hình cơ bản (thực sự tốt)
• Speculative decoding truyền thống sử dụng mô hình nháp riêng biệt (issue vLLM #38893 theo dõi hỗ trợ Eagle3 cho Gemma 4)
• Các kỹ thuật lượng tử hóa và tối ưu hóa tiêu chuẩn

Phản ứng của cộng đồng rất thẳng thắn. Đồng thuận sau 24 giờ là kết quả benchmark của Gemma 4 có tính cạnh tranh — ngang bằng hoặc thua nhẹ Qwen 3.5 — nhưng sản phẩm “chưa hoàn thiện.” Tốc độ, tính ổn định và công cụ hỗ trợ cần cải thiện. Các vấn đề bổ sung bao gồm HuggingFace Transformers ban đầu thiếu hỗ trợ kiến trúc Gemma 4, PEFT không xử lý được các loại lớp mới, và người dùng Mac gặp lỗi crash khi tải các mô hình lớn hơn.

Bạn Có Thể Làm Gì?

Nếu bạn đang đánh giá Gemma 4 để triển khai, đây là các lựa chọn thực tế:

Sử dụng speculative decoding truyền thống. Các mô hình nháp bên ngoài vẫn có thể tăng tốc suy luận Gemma 4. Các framework như vLLM đang thêm hỗ trợ Eagle3 speculative decoding riêng cho Gemma 4. Mức tăng tốc sẽ không bằng MTP tích hợp, nhưng vẫn tốt hơn không có gì.

Cân nhắc các lựa chọn thay thế cho khối lượng công việc ưu tiên tốc độ. Qwen 3.5 cho tốc độ token-per-second tốt hơn đáng kể trên phần cứng tương đương. Nếu tốc độ suy luận là ràng buộc chính của bạn, Qwen hiện cung cấp tỷ lệ tốc độ-chất lượng tốt hơn.

Theo dõi các giải pháp từ cộng đồng. Các bản xuất LiteRT chứa các MTP head. Các nhà nghiên cứu có thể tìm cách trích xuất và gắn lại chúng vào trọng số HuggingFace, mặc dù Google chưa chính thức hỗ trợ hướng đi này.

Phản hồi ý kiến. Các kỹ sư Google đang tích cực theo dõi các chủ đề thảo luận trên HuggingFace. Các yêu cầu kỹ thuật rõ ràng về việc phát hành MTP head có trọng lượng.

Kết Luận

Gemma 4 là một họ mô hình có năng lực với các cải tiến kiến trúc thực sự và kết quả benchmark mạnh mẽ. Quyết định loại bỏ các MTP prediction head khỏi bản phát hành công khai — trong khi vẫn giữ chúng trong framework LiteRT của Google — làm suy yếu chữ “mở” trong open-weight.

MTP không phải là một tối ưu hóa nhỏ. Nó có thể mang lại tăng tốc suy luận 1,5–2 lần mà không ảnh hưởng đến chất lượng đầu ra. Giữ lại nó khỏi trọng số công khai trong khi mô hình rõ ràng được huấn luyện cùng nó tạo ra hệ thống hai tầng: suy luận nhanh cho công cụ của Google, suy luận chậm cho tất cả những người còn lại.

Đối với cộng đồng AI mã nguồn mở, thông điệp rất rõ ràng: hãy kiểm tra những gì thực sự có trong trọng số, không chỉ các benchmark. Giấy phép mở không phải lúc nào cũng có nghĩa là bản phát hành mở.

Được xây dựng với FlowHunt . Cập nhật những phát triển mới nhất về AI mã nguồn mở trên blog của chúng tôi.