Muse Spark — khi "multimodal" không chỉ là ghép module

Meta vừa tung model multimodal đầu tiên từ Superintelligence Labs. Nhưng điều đáng xem không phải điểm benchmark — mà là cách họ đo.

72.2 điểm — và câu chuyện đằng sau con số

Hầu hết model AI "multimodal" trên thị trường hiện tại đều xử lý ảnh theo cùng một công thức: train một language model trước, rồi gắn thêm vision module vào sau — giống bác sĩ đa khoa chỉ đọc kết quả xét nghiệm mà không bao giờ tự khám bệnh nhân. Meta Superintelligence Labs vừa tung Muse Spark với một tuyên bố ngược lại: model này được train từ đầu để xử lý đồng thời text và image, không có chuyện "ghép module".

Con số đáng chú ý: trên benchmark ScreenSpot Pro — yêu cầu model xác định vị trí UI elements trong screenshot — Muse Spark đạt 72.2 điểm (84.1 nếu dùng Python tools), trong khi Claude Opus 4.6 Max đạt 57.7 (83.1 với Python) và GPT-5.4 Xhigh ở mức 39.0 (85.4 với Python).

Nhưng khoan — nhìn kỹ hơn, khi có Python tools hỗ trợ, khoảng cách giữa ba model gần như biến mất. GPT-5.4 Xhigh thậm chí vượt lên dẫn đầu. Vậy "natively multimodal" thật sự mang lại lợi thế gì?

Thật ra chuyện phức tạp hơn "ai nhiều điểm hơn"

Điểm mấu chốt nằm ở chỗ: Muse Spark mạnh nhất khi model phải tự xử lý visual reasoning mà không có external tools hỗ trợ. Khi pipeline inference chạy trực tiếp — không wrapper, không Python sandbox — thì kiến trúc natively multimodal tạo ra sự khác biệt rõ rệt.

Hình dung thế này: team bạn đang build hệ thống quality control cho e-commerce, cần model tự nhận diện sản phẩm lỗi từ ảnh chụp trên dây chuyền. Không có thời gian chạy thêm Python script xử lý từng frame. Giả sử mỗi ngày 50.000 ảnh cần scan — latency từ việc gọi thêm tool giữa mỗi inference sẽ cộng dồn thành hàng giờ. Trong trường hợp này, một model "nhìn thẳng" mà không cần phụ kiện sẽ chiếm lợi thế.

Nhưng nếu workflow của bạn đã có sẵn tool pipeline phong phú (code interpreter, search, API calls), thì lợi thế "native" bị san bằng đáng kể. Đây là điều mà headline benchmark không kể cho bạn nghe.

Ba trục scaling — cái mà developer nên đọc kỹ hơn điểm số

Meta mô tả Muse Spark dựa trên ba trục: pretraining, post-training, và test-time compute. Mỗi trục là một nấc thang riêng.

Ở phía pretraining, Meta tuyên bố đã tối ưu stack đến mức đạt cùng capability với lượng compute giảm hơn một bậc so với trước. Dịch sang ngôn ngữ production: nếu trước đây train model tầm này tốn X GPU-hours thì giờ họ chỉ cần khoảng X/10. Không chỉ tiết kiệm tiền — iteration cycle nhanh hơn, model mới ra nhanh hơn.

Phần đáng chú ý nhất là Contemplating mode — cho nhiều agent lý luận song song rồi tổng hợp kết quả. Đạt 58% trên Humanity's Last Exam và 38% trên FrontierScience Research. Kiểu thi đấu tiếp sức: thay vì một vận động viên chạy marathon một mình, bạn chia thành nhiều chân chạy, mỗi người sở trường một đoạn, rồi ghép kết quả lại.

Tuy nhiên, Contemplating mode đang rollout dần — chưa available cho tất cả. Và Muse Spark hiện chỉ có private API preview cho select users. Chưa open-source, chưa self-host được.

Multimodal RAG — bài toán thật đang chờ lời giải

Nếu bạn đang xây RAG pipeline cần xử lý cả ảnh và video, đây là lúc mọi thứ thú vị. Alibaba Tongyi Lab vừa release VimRAG — framework multimodal RAG dùng memory graph để điều hướng visual context lớn.

Ví dụ cụ thể: giả sử team bạn 5 người đang xây hệ thống hỗ trợ kỹ thuật cho sản phẩm phần cứng. Khách hàng gửi ảnh hoặc video thiết bị lỗi, hệ thống cần tìm đúng tài liệu hướng dẫn sửa. RAG truyền thống (text-only) sẽ bỏ lỡ thông tin visual. RAG kiểu naive — nhét raw image tokens vào context — thì context phình tới gần 16.000 tokens mà accuracy trên video tasks chỉ đạt khoảng 30%. Như cho sinh viên y khoa đọc cả ngàn trang giáo trình trước kỳ thi nhưng không highlight chỗ nào quan trọng — thông tin tràn ngập mà kiến thức thì lọt sàng.

VimRAG giải quyết bằng graph-based memory: thay vì giữ toàn bộ history, nó tóm tắt và liên kết observations thành graph, giảm search lặp. Quan trọng: đây là open-source và chạy được với Qwen3VL. Như mình đã chia sẻ trong các bài trước về RAG, context window lớn hơn không tự động nghĩa là kết quả tốt hơn — cách quản lý context mới là yếu tố quyết định.

Bẫy "chạy theo benchmark" — câu chuyện hai tuần rollback

Mình từng thấy một team dành cả sprint migrate pipeline sang model mới chỉ vì thấy điểm benchmark cao hơn 5 điểm trên leaderboard. Kết quả? Model mới fast hơn trên academic benchmark nhưng hallucinate nhiều hơn trên domain-specific data của họ. Hai tuần rollback, cả team mệt mỏi.

Plot twist: model "tệ hơn" trên bảng xếp hạng lại phù hợp hơn cho use case cụ thể của team.

Với Muse Spark cũng vậy — 72.2 trên ScreenSpot Pro nghe ấn tượng, nhưng câu hỏi đúng phải là: data domain của bạn có giống ScreenSpot Pro không? Model xử lý tiếng Việt ra sao? Latency và cost khi chạy production thế nào? Đừng để điểm số trên giấy biến thành quyết định kiến trúc trên production.

Bốn việc làm được ngay — không cần chờ API

1. Audit pipeline multimodal hiện tại: Nếu đang dùng model kiểu "LLM + vision adapter", thử đo latency khi tắt tool-use. Gap giữa có-tools và không-tools cho bạn biết model thật sự "hiểu" visual đến đâu.

1. Clone VimRAG, chạy thử trên 50 mẫu: Repo mới release, hỗ trợ Qwen3VL. Chuẩn bị 50 ảnh sản phẩm kèm câu hỏi, so sánh với pipeline ReAct đang có. Một buổi chiều là đủ để có kết quả sơ bộ.

1. Xây benchmark nội bộ: Lấy 100 mẫu thật từ production, chạy qua model hiện tại, ghi nhận accuracy. Khi Muse Spark API available, chạy cùng 100 mẫu đó. So sánh trên data thật — không trên leaderboard.

1. Khám phá multimodal embedding: Google vừa ra Gemini Embedding 2 — natively multimodal, map text-image-video-audio vào cùng embedding space. Kết hợp multi-vector search (Qdrant vừa ra khóa học miễn phí), bạn có thể xây retrieval pipeline multimodal production-grade mà không phụ thuộc vào bất kỳ vendor đơn lẻ nào.

Cuộc đua multimodal đang chuyển từ "model nào nhìn được ảnh" sang "model nào hiểu ảnh mà không cần chống gậy". Muse Spark là tín hiệu rõ ràng từ Meta. Nhưng với developer đang build production system, câu trả lời không nằm ở press release — mà ở 100 mẫu data thật bạn chạy chiều nay.

Kiến trúc tốt thì phải ở mới biết — benchmark đẹp thì phải test mới tin.

---

Bụi Wire — nghiện đọc release notes lúc 2 giờ sáng