- Gemma 4 ra mắt một loạt mô hình mã nguồn mở mới, bao gồm các phiên bản nhỏ gọn cho thiết bị di động và các mô hình lớn, đa phương thức hiệu suất cao, đặt ra tiêu chuẩn mới cho khả năng của các mô hình nhỏ.
- Kiến trúc được cải tiến với cơ chế chú ý lai (cục bộ và toàn cục), cơ chế chú ý truy vấn nhóm (GQA), và mô hình Mixture of Experts (MOE) 26B đầu tiên giúp tăng cường hiệu quả và hiệu suất đáng kể.
- Các mô hình Gemma 4 hỗ trợ đa phương thức nguyên bản, cải thiện khả năng xử lý hình ảnh với tỷ lệ khung hình và độ phân giải thay đổi, đồng thời giấy phép Apache 2.0 mới giúp tăng tính tiếp cận và dễ dàng tích hợp.
Open Models at Google DeepMind — Cassidy Hardin, Google DeepMind
- Gemma 4 cung cấp các mô hình hiệu quả (2B, 4B) được tối ưu hóa đặc biệt cho ứng dụng trên thiết bị, có khả năng chạy cục bộ trên điện thoại và máy tính xách tay mà không cần gọi API đắt tiền.
- Mô hình Dense 31B là mô hình đa phương thức hiện đại nhất, được thiết kế cho suy luận nâng cao, gọi hàm và đầu ra JSON có cấu trúc, với độ dài ngữ cảnh 256K, lý tưởng cho các quy trình làm việc tự động.
- Mô hình Mixture of Experts (MOE) 26B là phiên bản MOE đầu tiên của Gemma, sử dụng 128 chuyên gia nhưng chỉ yêu cầu 8 chuyên gia được kích hoạt mỗi lượt truyền tiến, mang lại hiệu suất đáng kinh ngạc với tài nguyên thấp.
- Gemma 4 tích hợp cơ chế chú ý cải tiến với sự xen kẽ giữa các lớp cục bộ (sử dụng cửa sổ trượt) và lớp toàn cục, cùng với cơ chế chú ý truy vấn nhóm (GQA) để nâng cao hiệu quả và giảm chi phí bộ nhớ.
- Các mô hình hiệu quả sử dụng Phép nhúng theo từng lớp (PLE) được lưu trữ trong bộ nhớ flash thay vì VRAM, giúp giảm đáng kể hạn chế bộ nhớ trên thiết bị và cải thiện hiệu suất suy luận.
- Khả năng đa phương thức của Gemma 4 được cải tiến để xử lý tỷ lệ khung hình và độ phân giải hình ảnh thay đổi, cho phép các nhà phát triển linh hoạt phân bổ ngân sách mã thông báo cho hình ảnh tùy theo nhu cầu tác vụ (ví dụ: OCR cần độ phân giải cao).
- Giấy phép Apache 2.0 mới giúp các mô hình Gemma 4 dễ tiếp cận hơn, tạo điều kiện thuận lợi cho việc tích hợp vào vòng đời phát triển của lập trình viên từ thử nghiệm đến triển khai.
open-source models— mô hình mã nguồn mởon-device applications— ứng dụng trên thiết bịmixture of experts model(MOE) — mô hình mixture of experts (MOE)parameters— tham sốApache 2.0 license— giấy phép Apache 2.0multimodal— đa phương thứcgrouped query attention(GQA) — cơ chế chú ý truy vấn nhóm (GQA)Per Layer Embeddings(PLE) — Phép nhúng theo từng lớp (PLE)flash memory— bộ nhớ flashvariable aspect ratios/resolutions— tỷ lệ khung hình/độ phân giải thay đổi
Xin chào mọi người, tôi là Cassidy, một nhà nghiên cứu tại Google DeepMind. Hôm nay, tôi rất vui mừng được chia sẻ với các bạn về một số cải tiến kỹ thuật và kiến trúc mà chúng tôi có với Gemma 4.
Giới thiệu Gemma 4 và Giấy phép mới
Tuần trước, chúng tôi đã ra mắt Gemma 4, phiên bản mới nhất trong dòng mô hình mã nguồn mở (open-source models) của chúng tôi. Gemma 4 đã mang lại những cải tiến đáng kinh ngạc ở một quy mô chưa từng thấy trước đây. Chúng tôi có một dòng các mô hình rất nhỏ với hiệu suất đáng kinh ngạc, tạo ra một tiền lệ mới về những gì có thể đạt được với các mô hình mã nguồn mở nhỏ.
Gemma 4 có bốn kích thước. Chúng tôi có hai mô hình effective nhỏ hơn, được thiết kế cho các ứng dụng trên thiết bị (on-device applications). Các mô hình này đã được điều chỉnh và cải tiến để cung cấp hiệu suất đáng kinh ngạc ở quy mô nhỏ, có khả năng chạy cục bộ trên điện thoại, iPad và máy tính xách tay.
Chúng tôi có hai mô hình lớn hơn, bắt đầu với mô hình mixture of experts (mixture of experts model) 26B, đây là MOE (MOE) Gemma đầu tiên. Mô hình này đã được điều chỉnh để có hiệu suất đáng kinh ngạc trong khi chỉ yêu cầu 3,9 tỷ tham số (parameters) hoạt động. Và mô hình lớn nhất của chúng tôi là mô hình dense (dense model) 31B. Mô hình này có hiệu suất vượt trội, một cải tiến lớn so với những gì tồn tại trong Gemma 3, tạo ra một tiền lệ mới chưa từng thấy trước đây.
Nhìn vào các mô hình lớn hơn của chúng tôi, 31B và 26B, cả hai mô hình này đều nằm trong top sáu của tất cả các mô hình mã nguồn mở trên LM arena. Một trong những cải tiến thú vị nhất mà chúng tôi đã ra mắt cùng với Gemma 4 là việc chuyển sang giấy phép Apache 2.0 (Apache 2.0 license). Điều này được thực hiện một cách có chủ đích để làm cho các mô hình của chúng tôi dễ tiếp cận hơn đối với mọi lập trình viên. Bạn sẽ dễ dàng tích hợp Gemma vào vòng đời phát triển (life cycle of development) của mình, từ thử nghiệm ban đầu cho đến triển khai và xây dựng trong vũ trụ Gemma.
Các Mô hình Gemma 4 và Trường hợp sử dụng
Bây giờ, hãy cùng xem xét từng mô hình này là gì và một số trường hợp sử dụng (use cases) mà chúng tôi đã điều chỉnh cho chúng.
Mô hình Dense 31B
Bắt đầu với mô hình dense 31B của chúng tôi. Đây là một mô hình đa phương thức (multi-modal model) hiện đại nhất (state-of-the-art), được xây dựng có mục đích cho khả năng suy luận nâng cao. Mô hình này xếp thứ ba trên bảng xếp hạng AI (AI leader board) toàn cầu. Điều này vượt trội hơn các mô hình có kích thước lớn hơn 20 lần. Đây là một cải tiến lớn.
Gemma 31B có độ dài ngữ cảnh (context length) 256K, được xây dựng có mục đích cho quy trình làm việc tự động (autonomous workflows) với hỗ trợ nguyên bản cho suy luận (thinking), gọi hàm (function calling) và đầu ra JSON có cấu trúc (structured JSON outputs).
Mô hình Mixture of Experts 26B
Chúng tôi cũng có một mô hình 26B nhỏ hơn một chút. 26B này là phiên bản đầu tiên của mô hình mixture of experts trong gia đình Gemma. Chỉ yêu cầu 3,8 tỷ tham số trong bất kỳ lượt truyền tiến (forward pass) nào, mô hình này nhỏ và hiệu quả. Sử dụng tổng cộng 128 chuyên gia (experts) trong khi chỉ yêu cầu 8 chuyên gia trong bất kỳ suy luận (inference) nào, điều này rất hiệu quả để chạy trong khi vẫn duy trì một số hiệu suất đáng kinh ngạc mà chúng tôi đã thấy với mô hình 31B của mình.
Mô hình Effective 2B và 4B
Ở phía nhỏ hơn, chúng tôi đã giới thiệu hai mô hình effective. Các mô hình này được thiết kế cho ứng dụng trên thiết bị (on-device applications) với hỗ trợ bổ sung âm thanh (audio). Đây là các mô hình đầu vào thị giác, văn bản và hình ảnh, thị giác, văn bản và âm thanh (vision, text, and image, vision, text, and audio input models) trong khi vẫn là các mô hình đầu ra chỉ văn bản (text-only output models). Tương tự, chúng tôi có mô hình effective 2B của mình.
Trên nhiều điểm chuẩn (benchmarks) khác nhau, các mô hình này đều đáng kinh ngạc. Nhìn vào hiệu suất của chúng tôi trên các khả năng tác nhân (agentic capabilities), viết mã (coding), đa phương thức (multi-modal), đa ngôn ngữ (multilingual), chúng tôi đã thực sự đặt ra một ranh giới mới cho những gì có thể đạt được với các mô hình Gemma. Điều này vượt trội đáng kể so với mọi thứ chúng tôi có với gia đình mô hình Gemma 3.
Cải tiến Kiến trúc trong Gemma 4
Bây giờ, hãy cùng xem xét những gì thực sự mới trong Gemma 4, chúng tôi đã làm gì và làm thế nào chúng tôi thực sự có thể đạt được hiệu suất đáng kinh ngạc này, bắt đầu từ phía kiến trúc.
Cơ chế Chú ý
Chúng tôi có mô hình dense tiêu chuẩn của mình. Đây là mô hình 31B của chúng tôi cũng như các mô hình effective 2B và 4B nhỏ hơn của chúng tôi. Chúng tôi có khối bộ giải mã (decoder block) tiêu chuẩn của mình. Những gì chúng tôi đã làm với Gemma 4 là chúng tôi đã thực hiện một số cải tiến trong cơ chế chú ý (attention).
Chúng tôi đã giới thiệu tỷ lệ 5:1 của việc xen kẽ lớp cục bộ (local layers) với lớp toàn cục (global layers), trong đó mô hình effective 2B nhỏ hơn của chúng tôi có tỷ lệ 4:1. Điều này có nghĩa là trong các lớp cục bộ của chúng tôi, chúng tôi có một cửa sổ trượt (sliding window) về số lượng mã thông báo (tokens) mà chúng tôi đang chú ý. Và cuối cùng, với các lớp toàn cục của chúng tôi, chúng tôi hiện đã đảm bảo rằng lớp cuối cùng luôn là một lớp toàn cục, nghĩa là lớp cuối cùng của chúng tôi đang chú ý đến tất cả các mã thông báo trước đó.
Trong thực tế, điều này trông như thế nào là các lớp toàn cục của chúng tôi đang chú ý đến mọi mã thông báo được đưa ra trước đó, trong khi các mô hình cục bộ của chúng tôi chỉ chú ý đến một số lượng mã thông báo trước đó cụ thể. Trong các mô hình nhỏ hơn của chúng tôi, chúng tôi có một cửa sổ trượt gồm 512 mã thông báo, trong khi trong các mô hình lớn hơn của chúng tôi, chúng tôi có một cửa sổ trượt gồm 1.024 mã thông báo. Cửa sổ trượt này đã mang lại những cải tiến đáng kể về hiệu quả (efficiency) và tối ưu hóa của các lớp cục bộ của chúng tôi trong khi vẫn duy trì việc truyền thông tin đến các lớp trước đó.
Tuy nhiên, các lớp toàn cục của chúng tôi vẫn khá tốn kém. Mặc dù có sự xen kẽ giữa các lớp cục bộ và lớp toàn cục này, tất cả các lớp toàn cục của chúng tôi vẫn được yêu cầu chú ý đến tất cả các mã thông báo trước đó, điều này làm cho nó khá tốn bộ nhớ (memory intensive) và tốn kém để chạy.
Cơ chế Chú ý Truy vấn Nhóm (GQA)
Và đây là lúc chúng tôi tìm hiểu về việc giới thiệu cơ chế chú ý truy vấn nhóm (grouped query attention). Trong các lớp cục bộ của chúng tôi, chúng tôi nhóm hai truy vấn (queries) lại với nhau để chia sẻ cùng đầu khóa và giá trị (key and value heads). Tuy nhiên, trong các lớp toàn cục của chúng tôi, chúng tôi nhóm tám truy vấn lại với nhau để chia sẻ cùng đầu khóa và giá trị. Vì việc giảm số lượng đầu khóa và giá trị có thể có tác động lớn đến hiệu suất, chúng tôi đã tăng gấp đôi độ dài của đầu khóa và giá trị trong các lớp toàn cục của chúng tôi lên 512 thay vì 252 mã thông báo.
Cơ chế chú ý truy vấn nhóm này đã mang lại những cải thiện hiệu suất đáng kể mà không tốn quá nhiều chi phí bộ nhớ (memory costs) và tăng chi phí suy luận (inference increases) trong việc phục vụ các mô hình này. Tỷ lệ tám truy vấn trên một khóa giá trị (key value) trên tất cả các mô hình của chúng tôi đã mang lại những cải tiến đáng kể về hiệu quả của các lớp toàn cục của chúng tôi.
Những thay đổi cơ chế chú ý (attention changes) này có mặt trên tất cả các mô hình của chúng tôi, nhưng chúng tôi cũng đã giới thiệu một kiến trúc mới với Gemma 4, đó là MOE của chúng tôi.
Kiến trúc Mixture of Experts (MOE)
MOE của chúng tôi có một chuyên gia định tuyến chia sẻ (shared router expert) với tổng số 128 chuyên gia tổng cộng, với tám chuyên gia được kích hoạt trên mỗi lượt truyền tiến. Tất cả các chuyên gia này đều là các mạng nơ-ron truyền thẳng (feed-forward neural networks) nhỏ. Tương tự như kiến trúc mà chúng tôi có với mô hình dense của mình, giờ đây chúng tôi đã thay thế mạng nơ-ron truyền thẳng tiêu chuẩn đó bằng một MOE.
Trong thực tế, điều này trông như thế nào là có chuyên gia chia sẻ cố định (constant shared expert) của chúng tôi, được kích hoạt trên mỗi lượt truyền của mô hình. Chuyên gia chia sẻ này có kích thước gấp ba lần so với các chuyên gia thông thường của chúng tôi. Sau đó, chúng tôi có 128 chuyên gia, mỗi chuyên gia được bộ định tuyến (router) chọn trong bất kỳ lượt truyền nào của mô hình.
Mô hình Effective Dense và Phép nhúng theo từng lớp (PLE)
Và cuối cùng, về phía kiến trúc, chúng tôi đi sâu vào các mô hình effective dense của mình. Vậy effective 2B, effective 4B nghĩa là gì khi chúng tôi nói về mô hình của mình? Đây là lúc chúng tôi xem xét sự khác biệt về số lượng tham số được yêu cầu để vận hành mô hình so với tổng số tham số biểu diễn (representational parameters) hiện có. Mô hình 2B của chúng tôi là hiệu quả (effectively) 2,3 tỷ tham số trong khi có độ sâu biểu diễn (representational depth) là 5,1 tỷ tham số.
Các mô hình này đã được chỉ định và tối ưu hóa đặc biệt để có hiệu suất trên thiết bị (on-device performance) tốt nhất. Chúng được thiết kế để chạy trên điện thoại, chạy trên máy tính xách tay mà không yêu cầu các cuộc gọi API (API calls) đắt tiền đến mô hình được phục vụ ở nơi khác trên thế giới.
Những tiến bộ này được thực hiện nhờ PLE (PLE). Đây là phép nhúng theo từng lớp (per layer embeddings) của chúng tôi, trong đó trong mỗi lớp của chúng tôi, giờ đây chúng tôi có một bảng nhúng (embedding table) chuyên dụng. Trước khi đi sâu vào chính xác bảng nhúng theo từng lớp của chúng tôi trông như thế nào, hãy cùng xem cách lớp nhúng mã thông báo (token embedding layer) hoạt động. Điều này chưa được thay thế trong các mô hình effective của chúng tôi.
Chúng tôi vẫn có bảng nhúng tiêu chuẩn của bạn, nơi bạn xem xét ánh xạ của một ID cho một mã thông báo đến vector nhúng (embedding vector) của nó. Trong E2B của chúng tôi, chúng tôi có kích thước vector nhúng (embedding vector size) là 1.536. Và trong E4B lớn hơn của chúng tôi, chúng tôi có kích thước vector nhúng là 2.560. Đây là nơi chúng tôi lưu trữ phép nhúng vector (vector embeddings) của mỗi mã thông báo này.
Bây giờ, chúng tôi cũng có một bảng nhúng theo từng lớp (per layer embedding table). Đây là nơi, tương tự, chúng tôi có toàn bộ kích thước từ vựng (vocabulary size) và có một biểu diễn nhúng (embedding representation) cho mỗi mã thông báo này. Nhưng bây giờ, chúng tôi cũng có một cái cho mỗi lớp.
Tiến bộ lớn ở đây là việc chúng tôi lưu trữ PLE, bảng nhúng theo từng lớp của chúng tôi, trong bộ nhớ flash (flash memory) thay vì VRAM. VRAM là một trong những hạn chế (constraints) lớn nhất trên thiết bị. Đó là nơi bạn nhanh chóng hết bộ nhớ (memory) trên điện thoại và máy tính xách tay. Vì vậy, bằng cách yêu cầu chúng tôi không cần phải lưu trữ bảng nhúng bổ sung này trong VRAM nữa, và chúng tôi có thể lưu trữ nó trong bộ nhớ flash, chúng tôi có thể đạt được những cải tiến đáng kinh ngạc về phía suy luận (inference side) mà không phải chịu chi phí đắt đỏ của lưu trữ (storage) và bộ nhớ bổ sung này.
Sự khác biệt lớn trong bảng nhúng PLE của chúng tôi, so với bảng nhúng tiêu chuẩn, là chiều nhúng (embedding dimension) của chúng tôi hiện chỉ là 256. Vì vậy, điều này giảm đáng kể so với kích thước của mô hình đầy đủ. Đối với mỗi mã thông báo, ví dụ, "high", chúng tôi hiện có một phép nhúng cho mã thông báo này ở mỗi lớp riêng biệt trong mô hình. Và khi bạn tiến qua các lớp của các mô hình (35 cho 2B và 42 cho mô hình lớn hơn của chúng tôi), bạn sẽ thấy tiến triển (progression) và những cải tiến trong biểu diễn nhúng cho mỗi mã thông báo này ở lớp tiếp theo.
Và điều này hoạt động như thế nào trong thực tế? Bây giờ, ở cuối khối bộ giải mã của chúng tôi, chúng tôi có thể tra cứu phép nhúng theo từng lớp cho mỗi mã thông báo của chúng tôi. Và đây là nơi chúng tôi có thể tra cứu chiều (dimension) 256 và chiếu nó lên kích thước nhúng (embedding size) đầy đủ được mong đợi cho mỗi mô hình của chúng tôi. Cuối cùng, những cải tiến với PLE này cho phép E2B và E4B của chúng tôi vượt trội đáng kể so với các thế hệ mô hình nhỏ Gemma trước đây.
Cải tiến Đa phương thức
Ngoài mọi thứ chúng tôi đã làm về phía kiến trúc, chúng tôi cũng thực sự đã đặt ra một ranh giới mới cho những gì có thể đạt được với đa phương thức (multimodality). Trong Gemma 3, chúng tôi đã giới thiệu thị giác (vision) lần đầu tiên. Chúng tôi đã thêm thị giác vào Gemma 3, thêm hỗ trợ trên tất cả các kích thước của chúng tôi. Và trong mô hình Gemma 3N, chúng tôi đã ra mắt mô hình âm thanh, thị giác và văn bản mã nguồn mở (open-source audio vision and text model) lần đầu tiên. Điều này thực sự đã mở đường cho Gemma 4 trở thành các mô hình đa phương thức nguyên bản. Đa phương thức đã được tích hợp ngay từ đầu trên tất cả các mô hình này với hiệu suất khá đáng kinh ngạc.
Bộ mã hóa thị giác và Tỷ lệ khung hình/Độ phân giải thay đổi
Bắt đầu từ phía thị giác, mô hình 31B và mô hình 26B của chúng tôi đều sử dụng bộ mã hóa thị giác (vision encoder) 550 triệu tham số. Mô hình effective 2B và effective 4B của chúng tôi có một bộ mã hóa (encoder) nhỏ hơn, gọn hơn, được thiết kế tốt hơn với 150 triệu tham số.
Chúng tôi đã đạt được những bước tiến lớn và cải thiện từ Gemma 3 bằng cách giới thiệu tỷ lệ khung hình thay đổi (variable aspect ratios) và độ phân giải thay đổi (variable resolutions). Điều này có nghĩa trong thực tế đối với các lập trình viên là giờ đây bạn có lựa chọn khi chạy một mô hình Gemma để chọn độ phân giải (resolution) và ngân sách mã thông báo mềm (soft token budget) mà bạn muốn phân bổ cho hình ảnh (images). Điều này có sẵn ở năm độ phân giải khác nhau trên tất cả các mô hình của chúng tôi.
Hãy dành một chút thời gian để xem lại cách bộ mã hóa thị giác của chúng tôi hoạt động. Điều chúng ta muốn hiểu ở đây là chúng ta nhận được một hình ảnh ban đầu và hình ảnh này được chia thành các mảng nhỏ (patches), các mảng nhỏ 16x16 điểm ảnh (pixels). Các mảng nhỏ này sau đó được làm phẳng (flattened) và chiếu tuyến tính (linear projected) thành phép nhúng mảng nhỏ (patch embeddings). Các phép nhúng này sau đó được biến đổi để tính đến mã hóa vị trí (positional encodings) của chúng và đây là những gì cuối cùng được hiển thị cho mô hình của chúng tôi.
Với điều này trong tâm trí, hãy cùng nhìn lại tỷ lệ khung hình thay đổi (variable aspect). Chúng ta có thể có các hình ảnh với các tỷ lệ khung hình thay đổi khác nhau, nơi chúng ta có một hình ảnh 4x2 và một hình ảnh 3x3. Điều quan trọng cần hiểu ở đây là mảng nhỏ 4 giờ đây ở một vị trí hoàn toàn khác. Nếu chúng ta mã hóa (encoding) cả hai hình ảnh này theo cùng một cách, chúng ta cần mô hình của mình hiểu rằng mảng nhỏ 4 trong hình ảnh bên trái nằm ở hàng thứ hai. Nó nằm ngay dưới mảng nhỏ đầu tiên của chúng ta so với mảng nhỏ 4 trong hình ảnh bên phải giờ đây nằm ở cuối cùng. Vì vậy, một phát triển quan trọng (critical development) ở đây là chúng ta cần đảm bảo rằng mã hóa vị trí không gian (spatial positional encoding) này cũng được truyền đến mô hình của chúng ta. Ngoài tỷ lệ khung hình thay đổi, chúng tôi cũng phải giới thiệu độ phân giải thay đổi.
Xử lý Hình ảnh Đa độ phân giải
Mặc dù cả hai hình ảnh của chúng ta đều có tỷ lệ 3:2, nhưng chúng lại có độ phân giải rất khác nhau. Hình ảnh bên phải có độ phân giải cao hơn, trong khi hình ảnh bên trái có độ phân giải thấp hơn. Đây là lúc chúng tôi giới thiệu tính năng đa độ phân giải (variable resolutions), cho phép bạn chọn số lượng hình ảnh và mã thông báo bạn muốn phân bổ cho mỗi hình ảnh. Điều này rất quan trọng vì nó cho phép bạn quyết định mức ngân sách mã thông báo muốn chi cho hình ảnh. Đối với các tác vụ như OCR (Nhận dạng ký tự quang học), nhận dạng vật thể không gian (spatial object recognition), bạn nên phân bổ ngân sách cao hơn nhiều để đảm bảo xử lý hình ảnh chất lượng cao, độ phân giải cao. Nếu ứng dụng của bạn hoàn toàn dựa trên văn bản và không sử dụng một số khả năng đa phương thức (multimodal capabilities), bạn có thể phân bổ một ngân sách mã thông báo nhỏ hơn và thấp hơn nhiều. Điều quan trọng cần hiểu ở đây là đây là một cải tiến lớn so với Jumma 3. Trong Jumma 3, chúng tôi phải sử dụng kỹ thuật pan and scan. Khi đó, bạn sẽ cung cấp một hình ảnh có độ phân giải và tỷ lệ khung hình thay đổi, và chúng tôi sẽ chia nó thành một chuỗi các ô vuông và đệm (padded) bất cứ thứ gì cần thiết. Sau đó, một hình ảnh của bạn được chuyển đến mô hình dưới dạng hai, ba, hoặc bốn hình ảnh khác nhau, mỗi hình ảnh được xử lý tuần tự. Giờ đây, với những tiến bộ về độ phân giải và tỷ lệ khung hình thay đổi, chúng tôi có thể xử lý các hình ảnh với số lượng patches khác nhau, tùy thuộc vào hình ảnh thực tế do người dùng cung cấp.
Xử lý và Mã hóa các Miếng Ảnh (Patches)
Điều tiếp theo cần hiểu là làm thế nào chúng ta thực sự lấy các patches hình ảnh này và chuyển chúng qua mô hình. Ở đây, chúng tôi lấy các lưới patches 3x3 và chúng trở thành một phép nhúng (embedding) duy nhất. Phép nhúng duy nhất này sau đó được chuyển tiếp đến một mô hình. Vì vậy, nếu bạn đang chạy một mô hình Jumma với ngân sách mã thông báo là 280, điều này thực sự tương đương với 2.520 patches khác nhau, sẽ được xây dựng từ mỗi hình ảnh của bạn. Đối với bất kỳ thứ gì không vừa trong một chuỗi patches 16x16 hoặc pixel 16x16 cho mỗi patch, chúng tôi sẽ cung cấp thêm phần đệm (padding). Để minh họa về các hình ảnh vuông với năm ngân sách mã thông báo mềm (soft token budgets) và độ phân giải khác nhau được hỗ trợ với Jumma, đây là một ví dụ về độ phân giải, patches và các phần tử được tổng hợp (pooled elements) trong phép nhúng, sẽ tồn tại ở mỗi kích thước khác nhau này. Và đây là lúc bạn thực sự thấy rằng nếu bạn đang thực hiện một tác vụ như phát hiện đối tượng (object detection), OCR, bạn thực sự muốn chạy với độ phân giải và ngân sách mã thông báo chất lượng cao hơn, và đây là nơi chúng tôi có các tùy chọn 560 và 1120 mã thông báo cho các trường hợp sử dụng này. Tổng hợp lại, chúng ta bắt đầu với một hình ảnh có N patches. Mỗi patch này được biến thành N phép nhúng patch (patch embeddings). Sau đó, chúng tôi tổng hợp chúng lại với nhau để tạo ra N/9 mã thông báo mềm (soft tokens) và các mã thông báo mềm này được chiếu tuyến tính (linear projected) thành những gì thực sự được hiển thị cho các mô hình của chúng tôi.
Xử lý Âm thanh và Mô hình Conformer
Bây giờ về phía âm thanh. Khả năng xử lý âm thanh đã được thêm vào E2B và E4B với mục tiêu hỗ trợ dịch thuật (translation) và nhận dạng giọng nói (speech recognition). Điều này được thực hiện thông qua sự kết hợp của một bộ mã hóa âm thanh (audio tokenizer) và một mô hình conformer. Đây là một mô hình conformer với 305 triệu tham số, hoạt động như một bộ mã hóa âm thanh xử lý phép nhúng (embeddings) thay vì mã thông báo (tokens). Về phía bộ mã hóa âm thanh, chúng ta bắt đầu với âm thanh thô (raw audio). Âm thanh thô này được xử lý qua một male spectrogram có khả năng trích xuất các tính năng (features) từ các tệp âm thanh thô. Male spectrogram này sau đó được chia thành các N-mell chunks, được lấy mẫu giảm (down sampled) qua hai lớp tích chập (convolutional layers). Điều này cuối cùng tạo ra N/4 mã thông báo mềm (soft tokens). Những phép nhúng âm thanh (audio embeddings) này là những gì được chuyển tiếp vào mô hình conformer. Mô hình conformer của chúng tôi tuân theo kiến trúc tương tự như những gì chúng ta đã thấy trong các mô hình dày đặc (dense models) và kiến trúc MOE (Mixture of Experts), mặc dù lần này chúng tôi bổ sung thêm một lớp tích chập.
Giới thiệu Dòng Mô hình JAMA và Cách Bắt đầu
Quay trở lại với chủ đề chúng ta bắt đầu hôm nay, dòng mô hình JAMA có bốn mô hình mà chúng tôi đã phát hành công khai vào tuần trước. Chúng tôi có hai mô hình nhỏ hơn được thiết kế cho các ứng dụng trên thiết bị (on-device applications) với sự hỗ trợ cho văn bản, thị giác và âm thanh. Hai mô hình lớn hơn của chúng tôi được thiết kế cho các tác vụ phức tạp hơn và tác vụ suy luận (reasoning tasks) với sự hỗ trợ cho quy trình làm việc của tác nhân (agent workflows) và viết mã (coding). Điều này đưa chúng ta đến câu hỏi: bạn có thể làm gì với JAMA hôm nay và làm thế nào để bắt đầu? Có hai lựa chọn chính để bắt đầu với JAMA. Bạn có tùy chọn tải xuống và tự lưu trữ (download and self-host) tất cả các mô hình của chúng tôi. Các mô hình này có sẵn trên Hugging Face, Kaggle và olamma. Chúng tôi cũng có các tùy chọn lưu trữ trên đám mây (Claude hosted options) cho các mô hình lớn hơn của chúng tôi, 31B và 26B, và chúng có thể được truy cập thông qua AI Studio và Vertex. Điều này sẽ cho phép bạn bắt đầu ngay lập tức với việc tạo mẫu (prototyping), xây dựng quy trình làm việc của tác nhân và thử nghiệm gọi hàm (function calling) trong các mô hình lớn hơn này. Cảm ơn và tôi sẵn lòng trả lời mọi câu hỏi về JAMA.
TL;DR
- Gemma 4 ra mắt một loạt mô hình mã nguồn mở mới, bao gồm các phiên bản nhỏ gọn cho thiết bị di động và các mô hình lớn, đa phương thức hiệu suất cao, đặt ra tiêu chuẩn mới cho khả năng của các mô hình nhỏ.
- Kiến trúc được cải tiến với cơ chế chú ý lai (cục bộ và toàn cục), cơ chế chú ý truy vấn nhóm (GQA), và mô hình Mixture of Experts (MOE) 26B đầu tiên giúp tăng cường hiệu quả và hiệu suất đáng kể.
- Các mô hình Gemma 4 hỗ trợ đa phương thức nguyên bản, cải thiện khả năng xử lý hình ảnh với tỷ lệ khung hình và độ phân giải thay đổi, đồng thời giấy phép Apache 2.0 mới giúp tăng tính tiếp cận và dễ dàng tích hợp.
Điểm chính
- Gemma 4 cung cấp các mô hình hiệu quả (2B, 4B) được tối ưu hóa đặc biệt cho ứng dụng trên thiết bị, có khả năng chạy cục bộ trên điện thoại và máy tính xách tay mà không cần gọi API đắt tiền.
- Mô hình Dense 31B là mô hình đa phương thức hiện đại nhất, được thiết kế cho suy luận nâng cao, gọi hàm và đầu ra JSON có cấu trúc, với độ dài ngữ cảnh 256K, lý tưởng cho các quy trình làm việc tự động.
- Mô hình Mixture of Experts (MOE) 26B là phiên bản MOE đầu tiên của Gemma, sử dụng 128 chuyên gia nhưng chỉ yêu cầu 8 chuyên gia được kích hoạt mỗi lượt truyền tiến, mang lại hiệu suất đáng kinh ngạc với tài nguyên thấp.
- Gemma 4 tích hợp cơ chế chú ý cải tiến với sự xen kẽ giữa các lớp cục bộ (sử dụng cửa sổ trượt) và lớp toàn cục, cùng với cơ chế chú ý truy vấn nhóm (GQA) để nâng cao hiệu quả và giảm chi phí bộ nhớ.
- Các mô hình hiệu quả sử dụng Phép nhúng theo từng lớp (PLE) được lưu trữ trong bộ nhớ flash thay vì VRAM, giúp giảm đáng kể hạn chế bộ nhớ trên thiết bị và cải thiện hiệu suất suy luận.
- Khả năng đa phương thức của Gemma 4 được cải tiến để xử lý tỷ lệ khung hình và độ phân giải hình ảnh thay đổi, cho phép các nhà phát triển linh hoạt phân bổ ngân sách mã thông báo cho hình ảnh tùy theo nhu cầu tác vụ (ví dụ: OCR cần độ phân giải cao).
- Giấy phép Apache 2.0 mới giúp các mô hình Gemma 4 dễ tiếp cận hơn, tạo điều kiện thuận lợi cho việc tích hợp vào vòng đời phát triển của lập trình viên từ thử nghiệm đến triển khai.
Từ vựng
open-source models— mô hình mã nguồn mởon-device applications— ứng dụng trên thiết bịmixture of experts model(MOE) — mô hình mixture of experts (MOE)parameters— tham sốApache 2.0 license— giấy phép Apache 2.0multimodal— đa phương thứcgrouped query attention(GQA) — cơ chế chú ý truy vấn nhóm (GQA)Per Layer Embeddings(PLE) — Phép nhúng theo từng lớp (PLE)flash memory— bộ nhớ flashvariable aspect ratios/resolutions— tỷ lệ khung hình/độ phân giải thay đổi
Nội dung chi tiết
Xin chào mọi người, tôi là Cassidy, một nhà nghiên cứu tại Google DeepMind. Hôm nay, tôi rất vui mừng được chia sẻ với các bạn về một số cải tiến kỹ thuật và kiến trúc mà chúng tôi có với Gemma 4.
Giới thiệu Gemma 4 và Giấy phép mới
Tuần trước, chúng tôi đã ra mắt Gemma 4, phiên bản mới nhất trong dòng mô hình mã nguồn mở (open-source models) của chúng tôi. Gemma 4 đã mang lại những cải tiến đáng kinh ngạc ở một quy mô chưa từng thấy trước đây. Chúng tôi có một dòng các mô hình rất nhỏ với hiệu suất đáng kinh ngạc, tạo ra một tiền lệ mới về những gì có thể đạt được với các mô hình mã nguồn mở nhỏ.
Gemma 4 có bốn kích thước. Chúng tôi có hai mô hình effective nhỏ hơn, được thiết kế cho các ứng dụng trên thiết bị (on-device applications). Các mô hình này đã được điều chỉnh và cải tiến để cung cấp hiệu suất đáng kinh ngạc ở quy mô nhỏ, có khả năng chạy cục bộ trên điện thoại, iPad và máy tính xách tay.
Chúng tôi có hai mô hình lớn hơn, bắt đầu với mô hình mixture of experts (mixture of experts model) 26B, đây là MOE (MOE) Gemma đầu tiên. Mô hình này đã được điều chỉnh để có hiệu suất đáng kinh ngạc trong khi chỉ yêu cầu 3,9 tỷ tham số (parameters) hoạt động. Và mô hình lớn nhất của chúng tôi là mô hình dense (dense model) 31B. Mô hình này có hiệu suất vượt trội, một cải tiến lớn so với những gì tồn tại trong Gemma 3, tạo ra một tiền lệ mới chưa từng thấy trước đây.
Nhìn vào các mô hình lớn hơn của chúng tôi, 31B và 26B, cả hai mô hình này đều nằm trong top sáu của tất cả các mô hình mã nguồn mở trên LM arena. Một trong những cải tiến thú vị nhất mà chúng tôi đã ra mắt cùng với Gemma 4 là việc chuyển sang giấy phép Apache 2.0 (Apache 2.0 license). Điều này được thực hiện một cách có chủ đích để làm cho các mô hình của chúng tôi dễ tiếp cận hơn đối với mọi lập trình viên. Bạn sẽ dễ dàng tích hợp Gemma vào vòng đời phát triển (life cycle of development) của mình, từ thử nghiệm ban đầu cho đến triển khai và xây dựng trong vũ trụ Gemma.
Các Mô hình Gemma 4 và Trường hợp sử dụng
Bây giờ, hãy cùng xem xét từng mô hình này là gì và một số trường hợp sử dụng (use cases) mà chúng tôi đã điều chỉnh cho chúng.
Mô hình Dense 31B
Bắt đầu với mô hình dense 31B của chúng tôi. Đây là một mô hình đa phương thức (multi-modal model) hiện đại nhất (state-of-the-art), được xây dựng có mục đích cho khả năng suy luận nâng cao. Mô hình này xếp thứ ba trên bảng xếp hạng AI (AI leader board) toàn cầu. Điều này vượt trội hơn các mô hình có kích thước lớn hơn 20 lần. Đây là một cải tiến lớn.
Gemma 31B có độ dài ngữ cảnh (context length) 256K, được xây dựng có mục đích cho quy trình làm việc tự động (autonomous workflows) với hỗ trợ nguyên bản cho suy luận (thinking), gọi hàm (function calling) và đầu ra JSON có cấu trúc (structured JSON outputs).
Mô hình Mixture of Experts 26B
Chúng tôi cũng có một mô hình 26B nhỏ hơn một chút. 26B này là phiên bản đầu tiên của mô hình mixture of experts trong gia đình Gemma. Chỉ yêu cầu 3,8 tỷ tham số trong bất kỳ lượt truyền tiến (forward pass) nào, mô hình này nhỏ và hiệu quả. Sử dụng tổng cộng 128 chuyên gia (experts) trong khi chỉ yêu cầu 8 chuyên gia trong bất kỳ suy luận (inference) nào, điều này rất hiệu quả để chạy trong khi vẫn duy trì một số hiệu suất đáng kinh ngạc mà chúng tôi đã thấy với mô hình 31B của mình.
Mô hình Effective 2B và 4B
Ở phía nhỏ hơn, chúng tôi đã giới thiệu hai mô hình effective. Các mô hình này được thiết kế cho ứng dụng trên thiết bị (on-device applications) với hỗ trợ bổ sung âm thanh (audio). Đây là các mô hình đầu vào thị giác, văn bản và hình ảnh, thị giác, văn bản và âm thanh (vision, text, and image, vision, text, and audio input models) trong khi vẫn là các mô hình đầu ra chỉ văn bản (text-only output models). Tương tự, chúng tôi có mô hình effective 2B của mình.
Trên nhiều điểm chuẩn (benchmarks) khác nhau, các mô hình này đều đáng kinh ngạc. Nhìn vào hiệu suất của chúng tôi trên các khả năng tác nhân (agentic capabilities), viết mã (coding), đa phương thức (multi-modal), đa ngôn ngữ (multilingual), chúng tôi đã thực sự đặt ra một ranh giới mới cho những gì có thể đạt được với các mô hình Gemma. Điều này vượt trội đáng kể so với mọi thứ chúng tôi có với gia đình mô hình Gemma 3.
Cải tiến Kiến trúc trong Gemma 4
Bây giờ, hãy cùng xem xét những gì thực sự mới trong Gemma 4, chúng tôi đã làm gì và làm thế nào chúng tôi thực sự có thể đạt được hiệu suất đáng kinh ngạc này, bắt đầu từ phía kiến trúc.
Cơ chế Chú ý
Chúng tôi có mô hình dense tiêu chuẩn của mình. Đây là mô hình 31B của chúng tôi cũng như các mô hình effective 2B và 4B nhỏ hơn của chúng tôi. Chúng tôi có khối bộ giải mã (decoder block) tiêu chuẩn của mình. Những gì chúng tôi đã làm với Gemma 4 là chúng tôi đã thực hiện một số cải tiến trong cơ chế chú ý (attention).
Chúng tôi đã giới thiệu tỷ lệ 5:1 của việc xen kẽ lớp cục bộ (local layers) với lớp toàn cục (global layers), trong đó mô hình effective 2B nhỏ hơn của chúng tôi có tỷ lệ 4:1. Điều này có nghĩa là trong các lớp cục bộ của chúng tôi, chúng tôi có một cửa sổ trượt (sliding window) về số lượng mã thông báo (tokens) mà chúng tôi đang chú ý. Và cuối cùng, với các lớp toàn cục của chúng tôi, chúng tôi hiện đã đảm bảo rằng lớp cuối cùng luôn là một lớp toàn cục, nghĩa là lớp cuối cùng của chúng tôi đang chú ý đến tất cả các mã thông báo trước đó.
Trong thực tế, điều này trông như thế nào là các lớp toàn cục của chúng tôi đang chú ý đến mọi mã thông báo được đưa ra trước đó, trong khi các mô hình cục bộ của chúng tôi chỉ chú ý đến một số lượng mã thông báo trước đó cụ thể. Trong các mô hình nhỏ hơn của chúng tôi, chúng tôi có một cửa sổ trượt gồm 512 mã thông báo, trong khi trong các mô hình lớn hơn của chúng tôi, chúng tôi có một cửa sổ trượt gồm 1.024 mã thông báo. Cửa sổ trượt này đã mang lại những cải tiến đáng kể về hiệu quả (efficiency) và tối ưu hóa của các lớp cục bộ của chúng tôi trong khi vẫn duy trì việc truyền thông tin đến các lớp trước đó.
Tuy nhiên, các lớp toàn cục của chúng tôi vẫn khá tốn kém. Mặc dù có sự xen kẽ giữa các lớp cục bộ và lớp toàn cục này, tất cả các lớp toàn cục của chúng tôi vẫn được yêu cầu chú ý đến tất cả các mã thông báo trước đó, điều này làm cho nó khá tốn bộ nhớ (memory intensive) và tốn kém để chạy.
Cơ chế Chú ý Truy vấn Nhóm (GQA)
Và đây là lúc chúng tôi tìm hiểu về việc giới thiệu cơ chế chú ý truy vấn nhóm (grouped query attention). Trong các lớp cục bộ của chúng tôi, chúng tôi nhóm hai truy vấn (queries) lại với nhau để chia sẻ cùng đầu khóa và giá trị (key and value heads). Tuy nhiên, trong các lớp toàn cục của chúng tôi, chúng tôi nhóm tám truy vấn lại với nhau để chia sẻ cùng đầu khóa và giá trị. Vì việc giảm số lượng đầu khóa và giá trị có thể có tác động lớn đến hiệu suất, chúng tôi đã tăng gấp đôi độ dài của đầu khóa và giá trị trong các lớp toàn cục của chúng tôi lên 512 thay vì 252 mã thông báo.
Cơ chế chú ý truy vấn nhóm này đã mang lại những cải thiện hiệu suất đáng kể mà không tốn quá nhiều chi phí bộ nhớ (memory costs) và tăng chi phí suy luận (inference increases) trong việc phục vụ các mô hình này. Tỷ lệ tám truy vấn trên một khóa giá trị (key value) trên tất cả các mô hình của chúng tôi đã mang lại những cải tiến đáng kể về hiệu quả của các lớp toàn cục của chúng tôi.
Những thay đổi cơ chế chú ý (attention changes) này có mặt trên tất cả các mô hình của chúng tôi, nhưng chúng tôi cũng đã giới thiệu một kiến trúc mới với Gemma 4, đó là MOE của chúng tôi.
Kiến trúc Mixture of Experts (MOE)
MOE của chúng tôi có một chuyên gia định tuyến chia sẻ (shared router expert) với tổng số 128 chuyên gia tổng cộng, với tám chuyên gia được kích hoạt trên mỗi lượt truyền tiến. Tất cả các chuyên gia này đều là các mạng nơ-ron truyền thẳng (feed-forward neural networks) nhỏ. Tương tự như kiến trúc mà chúng tôi có với mô hình dense của mình, giờ đây chúng tôi đã thay thế mạng nơ-ron truyền thẳng tiêu chuẩn đó bằng một MOE.
Trong thực tế, điều này trông như thế nào là có chuyên gia chia sẻ cố định (constant shared expert) của chúng tôi, được kích hoạt trên mỗi lượt truyền của mô hình. Chuyên gia chia sẻ này có kích thước gấp ba lần so với các chuyên gia thông thường của chúng tôi. Sau đó, chúng tôi có 128 chuyên gia, mỗi chuyên gia được bộ định tuyến (router) chọn trong bất kỳ lượt truyền nào của mô hình.
Mô hình Effective Dense và Phép nhúng theo từng lớp (PLE)
Và cuối cùng, về phía kiến trúc, chúng tôi đi sâu vào các mô hình effective dense của mình. Vậy effective 2B, effective 4B nghĩa là gì khi chúng tôi nói về mô hình của mình? Đây là lúc chúng tôi xem xét sự khác biệt về số lượng tham số được yêu cầu để vận hành mô hình so với tổng số tham số biểu diễn (representational parameters) hiện có. Mô hình 2B của chúng tôi là hiệu quả (effectively) 2,3 tỷ tham số trong khi có độ sâu biểu diễn (representational depth) là 5,1 tỷ tham số.
Các mô hình này đã được chỉ định và tối ưu hóa đặc biệt để có hiệu suất trên thiết bị (on-device performance) tốt nhất. Chúng được thiết kế để chạy trên điện thoại, chạy trên máy tính xách tay mà không yêu cầu các cuộc gọi API (API calls) đắt tiền đến mô hình được phục vụ ở nơi khác trên thế giới.
Những tiến bộ này được thực hiện nhờ PLE (PLE). Đây là phép nhúng theo từng lớp (per layer embeddings) của chúng tôi, trong đó trong mỗi lớp của chúng tôi, giờ đây chúng tôi có một bảng nhúng (embedding table) chuyên dụng. Trước khi đi sâu vào chính xác bảng nhúng theo từng lớp của chúng tôi trông như thế nào, hãy cùng xem cách lớp nhúng mã thông báo (token embedding layer) hoạt động. Điều này chưa được thay thế trong các mô hình effective của chúng tôi.
Chúng tôi vẫn có bảng nhúng tiêu chuẩn của bạn, nơi bạn xem xét ánh xạ của một ID cho một mã thông báo đến vector nhúng (embedding vector) của nó. Trong E2B của chúng tôi, chúng tôi có kích thước vector nhúng (embedding vector size) là 1.536. Và trong E4B lớn hơn của chúng tôi, chúng tôi có kích thước vector nhúng là 2.560. Đây là nơi chúng tôi lưu trữ phép nhúng vector (vector embeddings) của mỗi mã thông báo này.
Bây giờ, chúng tôi cũng có một bảng nhúng theo từng lớp (per layer embedding table). Đây là nơi, tương tự, chúng tôi có toàn bộ kích thước từ vựng (vocabulary size) và có một biểu diễn nhúng (embedding representation) cho mỗi mã thông báo này. Nhưng bây giờ, chúng tôi cũng có một cái cho mỗi lớp.
Tiến bộ lớn ở đây là việc chúng tôi lưu trữ PLE, bảng nhúng theo từng lớp của chúng tôi, trong bộ nhớ flash (flash memory) thay vì VRAM. VRAM là một trong những hạn chế (constraints) lớn nhất trên thiết bị. Đó là nơi bạn nhanh chóng hết bộ nhớ (memory) trên điện thoại và máy tính xách tay. Vì vậy, bằng cách yêu cầu chúng tôi không cần phải lưu trữ bảng nhúng bổ sung này trong VRAM nữa, và chúng tôi có thể lưu trữ nó trong bộ nhớ flash, chúng tôi có thể đạt được những cải tiến đáng kinh ngạc về phía suy luận (inference side) mà không phải chịu chi phí đắt đỏ của lưu trữ (storage) và bộ nhớ bổ sung này.
Sự khác biệt lớn trong bảng nhúng PLE của chúng tôi, so với bảng nhúng tiêu chuẩn, là chiều nhúng (embedding dimension) của chúng tôi hiện chỉ là 256. Vì vậy, điều này giảm đáng kể so với kích thước của mô hình đầy đủ. Đối với mỗi mã thông báo, ví dụ, "high", chúng tôi hiện có một phép nhúng cho mã thông báo này ở mỗi lớp riêng biệt trong mô hình. Và khi bạn tiến qua các lớp của các mô hình (35 cho 2B và 42 cho mô hình lớn hơn của chúng tôi), bạn sẽ thấy tiến triển (progression) và những cải tiến trong biểu diễn nhúng cho mỗi mã thông báo này ở lớp tiếp theo.
Và điều này hoạt động như thế nào trong thực tế? Bây giờ, ở cuối khối bộ giải mã của chúng tôi, chúng tôi có thể tra cứu phép nhúng theo từng lớp cho mỗi mã thông báo của chúng tôi. Và đây là nơi chúng tôi có thể tra cứu chiều (dimension) 256 và chiếu nó lên kích thước nhúng (embedding size) đầy đủ được mong đợi cho mỗi mô hình của chúng tôi. Cuối cùng, những cải tiến với PLE này cho phép E2B và E4B của chúng tôi vượt trội đáng kể so với các thế hệ mô hình nhỏ Gemma trước đây.
Cải tiến Đa phương thức
Ngoài mọi thứ chúng tôi đã làm về phía kiến trúc, chúng tôi cũng thực sự đã đặt ra một ranh giới mới cho những gì có thể đạt được với đa phương thức (multimodality). Trong Gemma 3, chúng tôi đã giới thiệu thị giác (vision) lần đầu tiên. Chúng tôi đã thêm thị giác vào Gemma 3, thêm hỗ trợ trên tất cả các kích thước của chúng tôi. Và trong mô hình Gemma 3N, chúng tôi đã ra mắt mô hình âm thanh, thị giác và văn bản mã nguồn mở (open-source audio vision and text model) lần đầu tiên. Điều này thực sự đã mở đường cho Gemma 4 trở thành các mô hình đa phương thức nguyên bản. Đa phương thức đã được tích hợp ngay từ đầu trên tất cả các mô hình này với hiệu suất khá đáng kinh ngạc.
Bộ mã hóa thị giác và Tỷ lệ khung hình/Độ phân giải thay đổi
Bắt đầu từ phía thị giác, mô hình 31B và mô hình 26B của chúng tôi đều sử dụng bộ mã hóa thị giác (vision encoder) 550 triệu tham số. Mô hình effective 2B và effective 4B của chúng tôi có một bộ mã hóa (encoder) nhỏ hơn, gọn hơn, được thiết kế tốt hơn với 150 triệu tham số.
Chúng tôi đã đạt được những bước tiến lớn và cải thiện từ Gemma 3 bằng cách giới thiệu tỷ lệ khung hình thay đổi (variable aspect ratios) và độ phân giải thay đổi (variable resolutions). Điều này có nghĩa trong thực tế đối với các lập trình viên là giờ đây bạn có lựa chọn khi chạy một mô hình Gemma để chọn độ phân giải (resolution) và ngân sách mã thông báo mềm (soft token budget) mà bạn muốn phân bổ cho hình ảnh (images). Điều này có sẵn ở năm độ phân giải khác nhau trên tất cả các mô hình của chúng tôi.
Hãy dành một chút thời gian để xem lại cách bộ mã hóa thị giác của chúng tôi hoạt động. Điều chúng ta muốn hiểu ở đây là chúng ta nhận được một hình ảnh ban đầu và hình ảnh này được chia thành các mảng nhỏ (patches), các mảng nhỏ 16x16 điểm ảnh (pixels). Các mảng nhỏ này sau đó được làm phẳng (flattened) và chiếu tuyến tính (linear projected) thành phép nhúng mảng nhỏ (patch embeddings). Các phép nhúng này sau đó được biến đổi để tính đến mã hóa vị trí (positional encodings) của chúng và đây là những gì cuối cùng được hiển thị cho mô hình của chúng tôi.
Với điều này trong tâm trí, hãy cùng nhìn lại tỷ lệ khung hình thay đổi (variable aspect). Chúng ta có thể có các hình ảnh với các tỷ lệ khung hình thay đổi khác nhau, nơi chúng ta có một hình ảnh 4x2 và một hình ảnh 3x3. Điều quan trọng cần hiểu ở đây là mảng nhỏ 4 giờ đây ở một vị trí hoàn toàn khác. Nếu chúng ta mã hóa (encoding) cả hai hình ảnh này theo cùng một cách, chúng ta cần mô hình của mình hiểu rằng mảng nhỏ 4 trong hình ảnh bên trái nằm ở hàng thứ hai. Nó nằm ngay dưới mảng nhỏ đầu tiên của chúng ta so với mảng nhỏ 4 trong hình ảnh bên phải giờ đây nằm ở cuối cùng. Vì vậy, một phát triển quan trọng (critical development) ở đây là chúng ta cần đảm bảo rằng mã hóa vị trí không gian (spatial positional encoding) này cũng được truyền đến mô hình của chúng ta. Ngoài tỷ lệ khung hình thay đổi, chúng tôi cũng phải giới thiệu độ phân giải thay đổi.
Xử lý Hình ảnh Đa độ phân giải
Mặc dù cả hai hình ảnh của chúng ta đều có tỷ lệ 3:2, nhưng chúng lại có độ phân giải rất khác nhau. Hình ảnh bên phải có độ phân giải cao hơn, trong khi hình ảnh bên trái có độ phân giải thấp hơn. Đây là lúc chúng tôi giới thiệu tính năng đa độ phân giải (variable resolutions), cho phép bạn chọn số lượng hình ảnh và mã thông báo bạn muốn phân bổ cho mỗi hình ảnh. Điều này rất quan trọng vì nó cho phép bạn quyết định mức ngân sách mã thông báo muốn chi cho hình ảnh. Đối với các tác vụ như OCR (Nhận dạng ký tự quang học), nhận dạng vật thể không gian (spatial object recognition), bạn nên phân bổ ngân sách cao hơn nhiều để đảm bảo xử lý hình ảnh chất lượng cao, độ phân giải cao. Nếu ứng dụng của bạn hoàn toàn dựa trên văn bản và không sử dụng một số khả năng đa phương thức (multimodal capabilities), bạn có thể phân bổ một ngân sách mã thông báo nhỏ hơn và thấp hơn nhiều. Điều quan trọng cần hiểu ở đây là đây là một cải tiến lớn so với Jumma 3. Trong Jumma 3, chúng tôi phải sử dụng kỹ thuật pan and scan. Khi đó, bạn sẽ cung cấp một hình ảnh có độ phân giải và tỷ lệ khung hình thay đổi, và chúng tôi sẽ chia nó thành một chuỗi các ô vuông và đệm (padded) bất cứ thứ gì cần thiết. Sau đó, một hình ảnh của bạn được chuyển đến mô hình dưới dạng hai, ba, hoặc bốn hình ảnh khác nhau, mỗi hình ảnh được xử lý tuần tự. Giờ đây, với những tiến bộ về độ phân giải và tỷ lệ khung hình thay đổi, chúng tôi có thể xử lý các hình ảnh với số lượng patches khác nhau, tùy thuộc vào hình ảnh thực tế do người dùng cung cấp.
Xử lý và Mã hóa các Miếng Ảnh (Patches)
Điều tiếp theo cần hiểu là làm thế nào chúng ta thực sự lấy các patches hình ảnh này và chuyển chúng qua mô hình. Ở đây, chúng tôi lấy các lưới patches 3x3 và chúng trở thành một phép nhúng (embedding) duy nhất. Phép nhúng duy nhất này sau đó được chuyển tiếp đến một mô hình. Vì vậy, nếu bạn đang chạy một mô hình Jumma với ngân sách mã thông báo là 280, điều này thực sự tương đương với 2.520 patches khác nhau, sẽ được xây dựng từ mỗi hình ảnh của bạn. Đối với bất kỳ thứ gì không vừa trong một chuỗi patches 16x16 hoặc pixel 16x16 cho mỗi patch, chúng tôi sẽ cung cấp thêm phần đệm (padding). Để minh họa về các hình ảnh vuông với năm ngân sách mã thông báo mềm (soft token budgets) và độ phân giải khác nhau được hỗ trợ với Jumma, đây là một ví dụ về độ phân giải, patches và các phần tử được tổng hợp (pooled elements) trong phép nhúng, sẽ tồn tại ở mỗi kích thước khác nhau này. Và đây là lúc bạn thực sự thấy rằng nếu bạn đang thực hiện một tác vụ như phát hiện đối tượng (object detection), OCR, bạn thực sự muốn chạy với độ phân giải và ngân sách mã thông báo chất lượng cao hơn, và đây là nơi chúng tôi có các tùy chọn 560 và 1120 mã thông báo cho các trường hợp sử dụng này. Tổng hợp lại, chúng ta bắt đầu với một hình ảnh có N patches. Mỗi patch này được biến thành N phép nhúng patch (patch embeddings). Sau đó, chúng tôi tổng hợp chúng lại với nhau để tạo ra N/9 mã thông báo mềm (soft tokens) và các mã thông báo mềm này được chiếu tuyến tính (linear projected) thành những gì thực sự được hiển thị cho các mô hình của chúng tôi.
Xử lý Âm thanh và Mô hình Conformer
Bây giờ về phía âm thanh. Khả năng xử lý âm thanh đã được thêm vào E2B và E4B với mục tiêu hỗ trợ dịch thuật (translation) và nhận dạng giọng nói (speech recognition). Điều này được thực hiện thông qua sự kết hợp của một bộ mã hóa âm thanh (audio tokenizer) và một mô hình conformer. Đây là một mô hình conformer với 305 triệu tham số, hoạt động như một bộ mã hóa âm thanh xử lý phép nhúng (embeddings) thay vì mã thông báo (tokens). Về phía bộ mã hóa âm thanh, chúng ta bắt đầu với âm thanh thô (raw audio). Âm thanh thô này được xử lý qua một male spectrogram có khả năng trích xuất các tính năng (features) từ các tệp âm thanh thô. Male spectrogram này sau đó được chia thành các N-mell chunks, được lấy mẫu giảm (down sampled) qua hai lớp tích chập (convolutional layers). Điều này cuối cùng tạo ra N/4 mã thông báo mềm (soft tokens). Những phép nhúng âm thanh (audio embeddings) này là những gì được chuyển tiếp vào mô hình conformer. Mô hình conformer của chúng tôi tuân theo kiến trúc tương tự như những gì chúng ta đã thấy trong các mô hình dày đặc (dense models) và kiến trúc MOE (Mixture of Experts), mặc dù lần này chúng tôi bổ sung thêm một lớp tích chập.
Giới thiệu Dòng Mô hình JAMA và Cách Bắt đầu
Quay trở lại với chủ đề chúng ta bắt đầu hôm nay, dòng mô hình JAMA có bốn mô hình mà chúng tôi đã phát hành công khai vào tuần trước. Chúng tôi có hai mô hình nhỏ hơn được thiết kế cho các ứng dụng trên thiết bị (on-device applications) với sự hỗ trợ cho văn bản, thị giác và âm thanh. Hai mô hình lớn hơn của chúng tôi được thiết kế cho các tác vụ phức tạp hơn và tác vụ suy luận (reasoning tasks) với sự hỗ trợ cho quy trình làm việc của tác nhân (agent workflows) và viết mã (coding). Điều này đưa chúng ta đến câu hỏi: bạn có thể làm gì với JAMA hôm nay và làm thế nào để bắt đầu? Có hai lựa chọn chính để bắt đầu với JAMA. Bạn có tùy chọn tải xuống và tự lưu trữ (download and self-host) tất cả các mô hình của chúng tôi. Các mô hình này có sẵn trên Hugging Face, Kaggle và olamma. Chúng tôi cũng có các tùy chọn lưu trữ trên đám mây (Claude hosted options) cho các mô hình lớn hơn của chúng tôi, 31B và 26B, và chúng có thể được truy cập thông qua AI Studio và Vertex. Điều này sẽ cho phép bạn bắt đầu ngay lập tức với việc tạo mẫu (prototyping), xây dựng quy trình làm việc của tác nhân và thử nghiệm gọi hàm (function calling) trong các mô hình lớn hơn này. Cảm ơn và tôi sẵn lòng trả lời mọi câu hỏi về JAMA.