Meta phát hành Muse Glimmer, một mô hình Agent đa phương thức với khoảng 30B tham số, hỗ trợ ngữ cảnh cấp 128K và có thể chạy trên thiết bị có 24GB VRAM. Mô hình này được phát hành dưới giấy phép Apache 2.0, sử dụng GQA để giảm dung lượng KV Cache, kết hợp kiến trúc Attention lai Local và Global nhằm giảm chi phí tính toán cho ngữ cảnh dài, đồng thời cung cấp hai phiên bản lượng tử hóa phù hợp với các thiết bị có dung lượng VRAM khác nhau. Mô-đun thị giác được trang bị ViT Perception Encoder độc lập để xử lý ảnh chụp màn hình và thông tin màn hình; trong giai đoạn huấn luyện, On Policy Distillation được giới thiệu để bao phủ các trạng thái lệch khỏi nhiệm vụ dài. Thành phần tăng tốc suy luận DFlash sử dụng Block Diffusion để dự đoán Token song song, đạt tốc độ giải mã tăng khoảng 3 lần trên RTX 5090. Mô hình thể hiện hiệu suất xuất sắc trên các bộ benchmark Agent như MCP Atlas và DeepSearch QA, nhưng vẫn còn tiềm năng cải thiện trong các cảnh huống thuần GUI như OSWorld Verified.

Tác giả bài viết, nguồn: LeFengwang

Hôm qua, Meta đã ra mắt Muse Glimmer. Đây là mô hình Agent đa phương thức với khoảng 30 tỷ tham số, hỗ trợ ngữ cảnh lên đến 128K, có thể gọi công cụ, thực thi mã và xử lý hình ảnh cũng như thông tin màn hình.

Mô hình này được phát hành dưới giấy phép Apache 2.0, đồng thời cung cấp hai phiên bản lượng tử hóa 4bit, bộ mã hóa hình ảnh độc lập và thành phần tăng tốc suy luận DFlash, cùng với các phương pháp triển khai cục bộ như llama.cpp, MLX, ExecuTorch.

Mặc dù quy mô tham số 30B và ngữ cảnh 128K hiện nay không phải là điều hiếm thấy, nhưng vấn đề nằm ở chỗ Meta muốn nó thực hiện không phải là cuộc trò chuyện thông thường, mà là xây dựng một mô hình vận hành Agent cục bộ hoàn chỉnh.

Muse Glimmer dành cho các Agent địa phương chạy dài hạn phải đối mặt với các ràng buộc kỹ thuật khắt khe: nó phải xử lý các ảnh chụp màn hình liên tục được tạo ra trong khi duy trì logic nhiệm vụ kéo dài hàng chục bước, tất cả trong phạm vi bộ nhớ GPU giới hạn 24GB. Sau khi một nhiệm vụ chạy qua hàng chục bước, các kết quả công cụ, nhật ký mã, trạng thái trang và quá trình suy luận từ các bước trước đó sẽ liên tục được giữ lại trong ngữ cảnh.

Lúc này, nhiều vấn đề không rõ ràng trong các tình huống trò chuyện sẽ nhanh chóng trở nên nghiêm trọng. Làm thế nào để nhét 128K ngữ cảnh vào bộ nhớ GPU hạn chế, làm thế nào để quản lý trạng thái lịch sử khi ảnh chụp màn hình ngày càng nhiều, mô hình sẽ tiếp tục như thế nào sau khi gọi công cụ thất bại, và hàng loạt token suy luận sẽ làm chậm quá trình giải mã đến mức nào.

Thiết kế kỹ thuật của Muse Glimmer cơ bản xoay quanh những vấn đề này. Nó không dựa vào một kiến trúc mới nổi bật nào để giải quyết tất cả, mà đã thực hiện những sự đánh đổi triệt để trên Attention, KV Cache, cách huấn luyện, lượng tử hóa và Decode.

Nếu các mô hình cục bộ trước đây chỉ nhằm "chạy được", thì mục tiêu của Muse Glimmer là "sử dụng mượt như trên đám mây và hoạt động liên tục".

Xem các phần này cùng nhau sẽ giúp hiểu rõ hơn tại sao Meta lại thiết kế nó thành dạng hiện tại, thay vì chỉ xem riêng 30B hoặc 128K.

Làm thế nào để nén 128K ngữ cảnh vào bộ nhớ GPU 24GB

Muse Glimmer sử dụng 52 lớp Dense Transformer, Kích thước Ẩn là 6656, với 32 đầu Query nhưng chỉ có 2 đầu KV.

Attention cũng không xử lý ngữ cảnh đầy đủ ở mỗi lớp, mà sử dụng cách lặp lại ba Local Attention xen kẽ một Global Attention.

Local Attention chỉ xử lý 2048 token gần nhất, trong khi Global Attention mới chịu trách nhiệm trao đổi thông tin ở khoảng cách xa hơn.

Hai thiết kế này thực chất đang đồng thời làm tăng chi phí xử lý ngữ cảnh dài. Khi mô hình tạo ra Token mới, nó sẽ lưu trữ Key và Value của các Token trước đó, tức là KV Cache. Ngữ cảnh càng dài, phần này càng chiếm nhiều dung lượng hơn.

Muse Glimmer mỗi lớp chỉ có 2 KV Head, mỗi Head Dimension là 128. Theo tính toán sơ bộ với BF16, một Token trong một lớp sẽ chiếm khoảng 1024 Byte KV.

Nếu tất cả 52 lớp được lưu trữ đầy đủ 128K Context, KV Cache sẽ cần khoảng 6,5 GiB. Tuy nhiên, Muse Glimmer thực tế có 39 lớp Local và 13 lớp Global. Các lớp Local chỉ cần duy trì cửa sổ trượt khoảng 2048 Token, chỉ các lớp Global mới cần lưu trữ ngữ cảnh dài đầy đủ.

Theo cách ước tính tương tự, KV Cache có thể giảm xuống mức khoảng 1,7 GiB. Đây không phải là bộ nhớ GPU thời gian chạy được công bố chính thức, mà chỉ là ước tính lý thuyết dựa trên các tham số kiến trúc công khai, nhưng đã đủ để giải thích lý do tại sao kiến trúc này được thiết kế như vậy.

Nếu nó không sử dụng 2 KV Head, mà giữ KV độc lập cho cả 32 Head như MHA truyền thống, thì trong cùng điều kiện, KV Cache lý thuyết sẽ tăng thêm khoảng 16 lần, trực tiếp lên hơn 20 GiB.

KV Cache riêng lẻ đã vượt quá một card GPU 24GB. Ở đây thực tế đã sử dụng hai phương pháp. GQA giảm số lượng KV cần lưu cho mỗi token, trong khi Local Attention giảm số lớp cần lưu trữ KV đầy đủ trong thời gian dài.

Sau khi hoàn thành bước này, việc lượng hóa trọng số mới có ý nghĩa. Trọng lượng của Muse Glimmer K Quant 17GB khoảng 16,8 GB, mô-đun thị giác khoảng 1,4 GB, DFlash khoảng 1,6 GB, tổng cộng các phần này đã gần 20 GB. Phiên bản này hướng đến các thiết bị có bộ nhớ GPU 24 GB, trong khi bộ trọng lượng Dynamic K Quant khoảng 20 GB khác dành cho các thiết bị 32 GB.

Hai bộ lượng hóa không chỉ khác nhau về kích thước tệp. Trong 15 tiêu chí đánh giá độ chính xác trung bình do Meta cung cấp, Dynamic K Quant mất khoảng 0,2%, trong khi K Quant 17GB mất khoảng 1,0%.

Nói cách khác, phiên bản 24GB tiếp tục giảm dung lượng bộ nhớ đồ họa, chiếm ít không gian hơn, nhưng bạn cần chấp nhận sự suy giảm khả năng hơi rõ rệt hơn. Phiên bản 32GB thì nỗ lực giữ nguyên hiệu suất của mô hình gốc.

Muse Glimmer với ngữ cảnh 128K được thực hiện thông qua sự kết hợp này. Attention giảm khối lượng tính toán, GQA giảm KV Cache, sau đó sử dụng lượng tử hóa để nén trọng số mô hình.

Giải pháp này cũng có chi phí. 39 lớp Local chỉ có thể truy cập trực tiếp 2048 token gần nhất, thông tin ở khoảng cách xa cần được truyền qua lớp Global. Do đó, khả năng nhập vào 128K vẫn không giống với khả năng ổn định sử dụng toàn bộ 128K.

Kết quả Beam128K của Meta cho thấy cấu trúc hỗn hợp Local và Global vẫn có khả năng tận dụng thông tin khoảng cách xa, nhưng nó giải quyết vấn đề Long Context, không phải Long-term Memory. Những thông tin nào nên được lưu giữ, những thông tin nào đã lỗi thời, và khi nào nên cập nhật trạng thái, vẫn cần được Agent Runtime xử lý.

Vấn đề này sẽ trở nên rõ ràng hơn khi đến với Visual Agent.

128K cũng không phải là không gian vô hạn

Muse Glimmer còn đi kèm một trình mã hóa nhận thức ViT G 14 với khoảng 1,8 tỷ tham số, dùng để xử lý ảnh chụp màn hình, trang web, biểu đồ và tài liệu. Một hình ảnh có thể được chuyển đổi thành tối đa 4096 Visual Token.

Hiện tại nó là đầu vào văn bản và hình ảnh, đầu ra văn bản, chứ không phải đưa tất cả các modalities vào cùng một mô hình sinh.

Trong luồng làm việc của Agent, khả năng trực quan này chủ yếu chịu trách nhiệm đọc trạng thái môi trường. Agent Sử Dụng Máy Tính sẽ nhìn thấy màn hình hiện tại, xác định vị trí của trang, nút và văn bản, sau đó thực hiện một thao tác. Sau khi trang thay đổi, nó sẽ đọc ảnh chụp màn hình mới và tiếp tục quyết định bước tiếp theo.

Do đó, đầu vào hình ảnh sẽ liên tục được đưa vào Context. Nếu tất cả các ảnh chụp màn hình trong nhiệm vụ gồm vài chục bước đều được giữ nguyên, ngay cả khi có 128K, context cũng sẽ nhanh chóng bị các Visual Token chiếm đầy. Các ảnh chụp màn hình cũ có thể xung đột với trạng thái hiện tại. Trang web đã thay đổi, nhưng các nút và cửa sổ trước đó vẫn còn tồn tại trong Context, khiến mô hình cần thêm bước xác định cái nào là trạng thái mới nhất.

Meta cũng không lưu trữ vô hạn Lịch sử Màn hình trong đánh giá của OSWorld Verified, mà chỉ giữ lại một phần gần đây nhất của các ảnh chụp màn hình. Điều này cho thấy Perception Encoder và Context Management là hai vấn đề khác nhau.

Người đầu tiên chịu trách nhiệm chuyển đổi màn hình hiện tại thành thông tin mà mô hình có thể hiểu, người thứ hai phải quyết định những trạng thái lịch sử nào vẫn còn giá trị và những trạng thái nào nên xóa. Do đó, 128K giống như cung cấp cho Agent một không gian làm việc lớn hơn, thay vì loại bỏ quản lý trạng thái.

Và khi Agent liên tục tương tác với môi trường, vấn đề bắt đầu chuyển từ việc mô hình đã thấy gì sang việc mô hình vừa làm gì.

Bây giờ bước vào phần đào tạo của Muse Glimmer.

Sau khi đại lý đi lệch hướng, làm thế nào để tiếp tục

Muse Glimmer được chưng cất từ Muse Spark lớn hơn.

Meta chia quá trình huấn luyện thành Pre Training, Mid Training và Post Training. Pre Training sử dụng Logit Distillation, Mid Training bổ sung thêm dữ liệu ngữ cảnh dài, Reasoning Trace và Agent, Post Training sau đó thêm SFT, On Policy Distillation và RL.

Logit Distillation có một chút khác biệt so với việc sử dụng câu trả lời từ mô hình lớn để huấn luyện mô hình nhỏ. Khi mô hình Teacher dự đoán Token tiếp theo, nó sẽ cung cấp một phân phối xác suất cho toàn bộ Từ vựng. Mô hình Student không chỉ học được Token cuối cùng được chọn, mà còn thấy được sự đánh giá tương đối của Teacher đối với các ứng cử viên khác.

Điều này rất hữu ích cho Agent, vì nhiều tình huống không có hành động duy nhất. Trước một trang web, mô hình có thể tiếp tục tìm kiếm, mở một kết quả cụ thể hoặc chuyển sang công cụ khác. Phân phối xác suất của Teacher sẽ bao gồm sở thích của nó đối với các hành động này, chứ không chỉ là đoạn văn bản đầu ra cuối cùng.

Đến giai đoạn Mid Training, việc huấn luyện bắt đầu chuyển từ việc trả lời đơn lẻ sang toàn bộ hành trình nhiệm vụ. Sau khi thực hiện công cụ, môi trường sẽ thay đổi. Tìm kiếm sẽ trả về kết quả mới, chạy mã thất bại sẽ xuất hiện lỗi, và sau khi nhấp sai trên GUI, trang web cũng sẽ thay đổi. Nói cách khác, đầu ra của Agent sẽ trực tiếp thay đổi đầu vào cho bước tiếp theo.

Giả sử quỹ đạo đúng của Teacher là từ A đến B, rồi đến C, cuối cùng đến D. Nếu Student chỉ học dữ liệu của Teacher, nó sẽ liên tục thấy từ A đến B, rồi B đến C. Nhưng khi chạy thực tế, Student có thể bước đầu tiên đã đi đến một trạng thái B khác.

Từ thời điểm này, bối cảnh đã thay đổi, việc học từ B đến C trong bộ dữ liệu huấn luyện không còn có thể trực tiếp chỉ dẫn cho nó cách xử lý hiện tại. On Policy Distillation phát huy tác dụng tại đây. Student tự thực hiện Rollout, tiến vào các trạng thái mà nó thực sự sẽ tạo ra, sau đó nhận sự giám sát từ mô hình mạnh hơn trên các trạng thái này.

Do đó, dữ liệu huấn luyện không chỉ bao gồm lộ trình lý tưởng của Teacher, mà còn bắt đầu bao phủ các trạng thái lỗi do Student tự tạo ra. Điều này liên quan trực tiếp đến Failure Recovery mà Muse Glimmer nhấn mạnh.

Sau khi điền sai tham số, nếu mô hình có thể hiểu được lỗi và thực hiện lại một lần gọi công cụ, nhiệm vụ vẫn có thể tiếp tục. Khi đi nhầm trang web, chỉ cần nhận ra trạng thái hiện tại không đúng, có thể quay lại hoặc chọn con đường khác. Vấn đề thực sự phức tạp là khi mô hình không nhận thức được lỗi và tiếp tục thực thi dựa trên trạng thái sai lệch, khiến sự sai lệch tích lũy ngày càng lớn.

Vì vậy, khả năng của Agent không chỉ được đánh giá dựa trên việc một lần gọi Tool có chính xác hay không, mà còn phải xem xét liệu toàn bộ nhiệm vụ có được hoàn thành cuối cùng hay không, cũng như liệu nó có thể phục hồi sau các lỗi xảy ra trong quá trình thực hiện hay không. Điều này cũng giải thích tại sao Muse Glimmer lại thể hiện tốt hơn trên một số bộ kiểm tra Agent có quy trình dài.

Tuy nhiên, việc hoàn thành nhiệm vụ không có nghĩa là việc chạy cục bộ đã không còn vấn đề. Nếu một nhiệm vụ phức tạp cần tạo ra một lượng lớn Reasoning Token, điểm nghẽn mới sẽ nhanh chóng trở thành Decode.

Hai câu hỏi liền kề nhau

Muse Glimmer hỗ trợ bốn mức độ Reasoning Strength: low, medium, high, xhigh. Cài đặt này có thể được hiểu là ngân sách suy luận khi chạy.

Các cấp độ cao hơn thường khiến mô hình tạo ra nhiều Token suy luận hơn, có thể mang lại tỷ lệ thành công cao hơn trong các nhiệm vụ mã hóa và agent phức tạp, nhưng chi phí cũng rất trực tiếp: Context tăng nhanh hơn và thời gian giải mã lâu hơn.

Meta sử dụng high Reasoning Strength trong Benchmark công khai. Điều này dẫn đến DFlash.

Giải mã của Transformer là tự hồi quy. Token thứ hai phải chờ token thứ nhất, token thứ ba lại phụ thuộc vào token thứ hai. Đối với câu trả lời gồm vài trăm token thì vẫn chấp nhận được, nhưng một tác vụ của Agent có thể tích lũy tạo ra hàng nghìn乃至 hàng vạn token.

Phương pháp Speculative Decoding là thêm một Drafter nhỏ hơn. Drafter sẽ dự đoán trước một đoạn Token, sau đó mô hình chính xác minh toàn bộ một lần. Nếu có nhiều ứng cử viên liên tiếp được chấp nhận, số lần mô hình 30B thực hiện bước Decode sẽ được giảm đi.

Vấn đề với các giải pháp truyền thống là Drafter thường cũng là mô hình tự hồi quy. Nếu nó cần tạo ra 16 token, vẫn phải tạo từng cái một.

DFlash đã thay đoạn này bằng Block Diffusion.

Kích thước khối DFlash của Muse Glimmer là 16, cho phép dự đoán song song một nhóm token ứng cử. Tuy nhiên, Drafter chỉ nhanh thôi là chưa đủ. Nếu dự đoán không chính xác, mô hình chính sẽ từ chối đa số các token ứng cử, và lợi thế về tốc độ trước đó sẽ nhanh chóng biến mất.

Do đó, DFlash còn trực tiếp đọc các Tính năng Ẩn ở các tầng 1, 13, 25, 37 và 49 của Muse Glimmer, sau đó truyền các biểu diễn trung gian này đến Drafter chỉ có 5 tầng. Như vậy, Drafter không cần tự mình hiểu lại toàn bộ Context, mà trực tiếp tận dụng các biểu diễn nội bộ đã được hình thành bởi mô hình chính 30B.

Các Feature này không chỉ được sử dụng một lần ở đầu vào, mà còn được liên tục bổ sung vào Key và Value của các lớp trong Drafter để tránh suy yếu dần khi mạng trở nên sâu hơn.

Có một chi tiết khác trong quá trình huấn luyện. Trong một khối 16 Token, các Token ở đầu quan trọng hơn các Token ở cuối. Nếu Token đầu tiên sai, ngay cả khi các Token sau được đoán đúng, độ dài chuỗi được chấp nhận liên tiếp cũng sẽ rất ngắn.

Do đó, DFlash sẽ gán trọng số tổn thất cao hơn cho các token nằm trước Block và giảm dần về sau. Nó tối ưu hóa tiền tố có thể chấp nhận được dài nhất, thay vì đơn thuần theo đuổi độ chính xác trung bình trên 16 vị trí. Trong bộ dữ liệu K Quant 17GB do Meta cung cấp, tốc độ Decode trên RTX 5090 đã tăng từ khoảng 74,9 token/giây lên 233,4 token/giây.

Nếu một Agent Task tích lũy tạo ra 10.000 Token, chỉ tính riêng phần Decode,前者 khoảng 134 giây,后者 khoảng 43 giây. Các nhiệm vụ thực tế còn bao gồm Prefill, thực thi công cụ và chờ mạng, nhưng đối với các Agent có Reasoning Strength cao, sự khác biệt này đã rõ ràng ảnh hưởng đến trải nghiệm toàn bộ nhiệm vụ.

High Reasoning Strength sẽ tăng số lượng Token được tạo ra, DFlash chịu trách nhiệm rút ngắn thời gian này. Context dài sẽ làm tăng KV Cache, GQA và Local Attention giúp giảm bộ nhớ. Lượng tử hóa tiếp tục kiểm soát trọng số mô hình trong phạm vi mà các card đồ họa tiêu dùng có thể chịu được.

Ngoài ra, Muse Glimmer cũng thể hiện hiệu suất tốt trên các bộ đánh giá Agent như MCP Atlas, DeepSearch QA và Gaia2. Các nhiệm vụ này đều yêu cầu chuỗi thực thi dài.

MCP Atlas yêu cầu mô hình chọn và gọi công cụ giữa nhiều MCP Server. DeepSearch QA cần liên tục tìm kiếm, mở trang, tìm thông tin, rồi tiếp tục thực hiện dựa trên các kết quả mới. Gaia2 mô phỏng các ứng dụng có trạng thái như email, lịch, danh bạ, và môi trường chính nó sẽ thay đổi trong quá trình thực hiện nhiệm vụ.

Các nhiệm vụ này phù hợp với cách huấn luyện Muse Glimmer. Tuy nhiên, khi đến OSWorld Verified, TerminalBench và SWE Bench Verified, nó không còn duy trì lợi thế tương tự. Ví dụ, trên OSWorld Verified, Muse Glimmer đạt 65,9, trong khi Qwen3.6 27B đạt 75,6. Trên TerminalBench 2.1, Muse Glimmer đạt 51,7, trong khi đối thủ đạt 60,7.

Do đó, khả năng của nó được phân bố khá rõ ràng. Research Agent, sự phối hợp công cụ và các nhiệm vụ trạng thái dài có sức mạnh hơn, trong khi các cảnh huống thuần GUI, terminal và một phần Coding Agent vẫn còn nhiều không gian để cải thiện. Những điểm số này cũng không thể hoàn toàn được hiểu theo bảng xếp hạng mô hình truyền thống.

Kết quả của Agent Benchmark còn bị ảnh hưởng bởi System Prompt, Định nghĩa Công cụ, Scaffold, số bước thực thi tối đa, tham số Sampling và thậm chí là Model Đánh giá. Meta cũng đã chỉ rõ rằng các Công cụ Agent và System Prompt được sử dụng bởi các mô hình bên thứ ba có thể không được tối ưu hóa tốt nhất cho chúng.

Vì vậy, đến giai đoạn Agent, việc so sánh riêng lẻ các Checkpoint ngày càng khó để phản ánh đầy đủ tình hình. An toàn cũng là một vấn đề tương tự.

Việc chạy tại chỗ thực sự giúp giảm việc gửi tệp, ảnh chụp màn hình và Context riêng tư lên đám mây thường xuyên, nhưng điều này chỉ giải quyết vấn đề đường dẫn dữ liệu. Các rủi ro như Prompt Injection, gọi Tool sai, vượt quyền và các thao tác không thể hoàn tác vẫn tồn tại. Meta cũng đã đánh giá riêng biệt về Agentic Risk, Privacy và Prompt Injection, và khuyến nghị rằng trong quá trình triển khai thực tế, cần tiếp tục tăng cường các biện pháp Guardrail và tích hợp Human in the Loop khi cần thiết.

Một lộ trình năng lực rõ ràng

Toàn bộ lộ trình kỹ thuật của Muse Glimmer cuối cùng có thể tạo thành một chuỗi rõ ràng.

Kiểm soát quy mô mô hình ở khoảng 30B, GQA và Local Attention giảm chi phí bộ nhớ GPU cho ngữ cảnh 128K, lượng tử hóa giúp mô hình chạy trên các thiết bị 24GB và 32GB, Perception Encoder chịu trách nhiệm đọc môi trường hình ảnh, On Policy Distillation xử lý các trạng thái lệch trong nhiệm vụ dài, Reasoning Strength cho phép nhà phát triển kiểm soát ngân sách suy luận, DFlash xử lý độ trễ giải mã do lượng lớn Reasoning Token gây ra.

Muse Glimmer chưa chứng minh được mô hình 30B tại chỗ có thể thay thế mô hình Frontier trên đám mây, nhưng nó đã chứng minh rằng tương lai của mô hình 30B tại chỗ không nằm ở quy mô thuần túy, mà nằm ở thiết kế hệ thống nhằm cân bằng tổng thể các ràng buộc cứng. Nó đã tích hợp bốn ràng buộc khó xử lý nhất trong Agent tại chỗ—bộ nhớ GPU, ngữ cảnh, nhận thức trạng thái môi trường và tốc độ suy luận—vào cùng một thiết kế hệ thống.

Muse Glimmer dù chưa thể thay thế toàn bộ các mô hình hàng đầu trên đám mây, nhưng đã mở ra một con đường có thể triển khai ở quy mô công nghiệp cho mục tiêu "mỗi người đều có Agent riêng".