# Liquid AI ra mắt LFM2.5-VL-DSpark: Tăng tốc suy luận mô hình thị giác ngôn ngữ lên tới 3,13 lần - Nguồn: Liquid AI Mô hình và Blog kỹ thuật (Web) - Thời gian phát hành: 2026-09-24 21:42 (giờ Việt Nam) - Điểm AI: 57/100 - Link AIHOT.vn: https://aihot.vn/items/2d67601ce8a83419 - Nguồn dữ liệu AI HOT: https://aihot.news/items/cmufn4r2z069kro8w8bcw2jet - Link gốc: https://www.liquid.ai/blog/lfm2-5-vl-dspark ## Tóm tắt AI Liquid AI giới thiệu mô hình drafter LFM2.5-VL-DSpark với 280 triệu tham số, giúp tăng tốc độ giải mã trên thiết bị biên lên 3,13 lần và trên GPU lên 2,66 lần mà chỉ tốn thêm 8,9% tài nguyên. ## Thân bài ![LFM2.5-VL-DSpark: Accelerating vision-language models on edge and beyond](https://aypchzzf9pftwuto.public.blob.vercel-storage.com/DSpark-Vision-Hero-4-oZshFjGHCdXh8hn2nvHqopWfY94S8W.gif) Hôm nay, chúng tôi phát hành mô hình dự thảo DSpark thử nghiệm cho mô hình ngôn ngữ-hình ảnh (VLM) [LFM2.5-VL-3B](https://www.liquid.ai/blog/lfm2-5-vl-3b). Tương tự như các [mô hình dự thảo LFM2.5-DSpark vừa ra mắt](https://www.liquid.ai/blog/lfm2.5-dspark) dành cho các Mô hình Nền tảng Liquid (LFM) dựa trên văn bản, nó đánh đổi một lượng nhỏ bộ nhớ để đạt tốc độ giải mã nhanh hơn đáng kể mà không làm thay đổi chất lượng đầu ra. Chúng tôi đạt được mức cải thiện thông lượng giải mã lên tới 2,66 lần trên GPU và 3,13 lần trên các thiết bị biên, với mức tăng thông lượng tổng thể (end-to-end) lần lượt là 2,27 lần và 2,62 lần. Bài viết này đề cập đến cách chúng tôi huấn luyện mô hình dự thảo ngôn ngữ-hình ảnh, tốc độ cải thiện mà nó mang lại, và những giới hạn của giải mã suy đoán (speculative decoding) đối với các tác vụ thị giác trên phần cứng biên. Mô hình DSpark thị giác hiện đã có sẵn trên [Hugging Face](https://huggingface.co/LiquidAI/LFM2.5-VL-3B-DSpark), với sự hỗ trợ trong [llama.cpp](https://github.com/ggml-org/llama.cpp/pull/29339), [SGLang](https://github.com/sgl-project/sglang/pull/40651) và [MLX-VLM](https://github.com/Blaizzy/mlx-vlm/pull/2280). ### Cách thức hoạt động của giải mã suy đoán cho các mô hình ngôn ngữ-hình ảnh Mô hình dự thảo thị giác được xây dựng dựa trên [cùng một khái niệm như các mô hình dự thảo LFM2.5-DSpark đã phát hành trước đó](https://www.liquid.ai/blog/lfm2.5-dspark#how-dspark-works) [1]. Chúng tôi sử dụng các trạng thái ẩn (hidden states) của mô hình tại các lớp khác nhau để suy đoán k token tiếp theo bằng một mô hình dự thảo gọn nhẹ. Từ góc độ của mô hình dự thảo, phương thức đầu vào (input modality) không quan trọng vì khi các token đến được các lớp ẩn, văn bản và các mảng hình ảnh (image patches) đều được biểu diễn dưới dạng tensor đa chiều. Việc các trạng thái đó mã hóa một đoạn văn hay một hình ảnh không tạo ra sự khác biệt cho quá trình tính toán dự thảo. Điều này cho phép chúng tôi áp dụng chính xác thuật toán suy luận tương tự cho các mô hình ngôn ngữ-hình ảnh như đối với các mô hình dựa trên văn bản. ### Huấn luyện Chúng tôi đã thực hiện các thử nghiệm cắt bỏ (ablations) để chọn hỗn hợp dữ liệu huấn luyện cho các mô hình dự thảo của mình. Hỗn hợp cuối cùng kết hợp dữ liệu tinh chỉnh có giám sát (SFT) bao gồm các tác vụ ngôn ngữ-hình ảnh phổ biến, được ưu tiên cho các khối lượng công việc mà chúng tôi dự kiến mô hình sẽ phục vụ. Đối với kiến trúc dự thảo, chúng tôi tuân theo công thức từ bản phát hành DSpark văn bản: các mô hình dự thảo chỉ sử dụng attention được đơn giản hóa, với số lượng lớp và kích thước khối (block size) được chọn thông qua các thử nghiệm cắt bỏ trên một tập con dữ liệu huấn luyện. Chúng tôi huấn luyện trên tập dữ liệu trong 10 epoch và báo cáo tỷ lệ chấp nhận trên các tiêu chuẩn thị giác mục tiêu. Dựa trên các thử nghiệm trên phần cứng mục tiêu, chúng tôi đã chọn mô hình dự thảo với 4 lớp và kích thước khối là 9. Tại thời điểm suy luận, chúng tôi khuyến nghị sử dụng kích thước khối là 8 hoặc 9, tùy thuộc vào phần cứng (xem phần Suy luận). Mô hình dự thảo thu được có khoảng 280 triệu tham số (Bảng 1) và chỉ làm tăng 8,9% số lượng tham số của mô hình được triển khai. Tất cả các thử nghiệm cắt bỏ và quá trình huấn luyện đều được thực hiện độc quyền trên phần cứng AMD sử dụng khung huấn luyện của Liquid AI. | Thành phần | LFM2.5-VL-3B | | --- | --- | | Ngăn xếp giải mã (4 lớp) | 193,0 triệu | | Chiếu trạng thái ẩn | 21,0 triệu | | Đầu Markov | 65,5 triệu | | Chuẩn hóa + đầu tin cậy | 6,4 nghìn | | Tổng cộng | 279,5 triệu | Bảng 1: Kích thước mô hình dự thảo. Embedding và đầu LM được gắn với mô hình mục tiêu, không nằm trong mô hình dự thảo. ### Suy luận Mô hình dự thảo DSpark cho LFM2.5-VL-3B được hỗ trợ ngay từ ngày đầu trên toàn bộ hệ sinh thái suy luận: - [llama.cpp](https://github.com/ggml-org/llama.cpp) — Các checkpoint GGUF cho suy luận biên hiệu quả - [MLX-VLM](https://github.com/Blaizzy/mlx-vlm) — Suy luận tối ưu cho Apple Silicon - [SGLang](https://github.com/sgl-project/sglang) — Khung phục vụ GPU hiệu năng cao Tất cả các con số suy luận được trình bày đều sử dụng xử lý 16-bit cho cả bộ mã hóa (encoder) và khung ngôn ngữ (language backbone). Việc tăng tốc các mô hình đã lượng tử hóa vẫn nằm ngoài phạm vi của bản phát hành này. Tất cả các lần chạy được thu thập trên [Pipette](https://pipette.liquid.ai/), cùng một cơ sở hạ tầng đo kiểm đứng sau dữ liệu hiệu năng thiết bị công khai của Liquid AI. Cả hai cấu hình đều được đánh giá trên sáu tác vụ dựa trên thị giác đa dạng, tuân theo tiêu chuẩn MMSpec (VQA tổng quát, VQA văn bản, Chú thích hình ảnh, VQA biểu đồ, Suy luận phức tạp, Hội thoại đa lượt) [2]. Suy luận trên thiết bị. Chúng tôi đo lường thông lượng trên thiết bị với MLX-VLM trên MacBook Pro M5 Max và llama.cpp trên M3 Ultra sử dụng trọng số FP16 với kích thước batch là 1, nhiệt độ 0, kích thước khối 8 và tối đa 2.048 token đầu ra (độ dài câu trả lời trung bình 90 token). Suy đoán cải thiện thông lượng trên cả sáu danh mục tác vụ trên cả hai ngăn xếp. Với MLX trên M5 Max, quá trình giải mã nhanh hơn từ 2,30 đến 3,13 lần tùy theo tác vụ, và độ trễ tổng thể cải thiện từ 1,56 đến 2,62 lần. Với llama.cpp trên M3 Ultra, quá trình giải mã cải thiện từ 1,57 đến 2,14 lần và tổng thể từ 1,30 đến 1,77 lần. Tỷ lệ chấp nhận nằm trong phạm vi tương tự trên cả hai ngăn xếp, khoảng 3,2 đến 4,5 token mỗi lượt xác minh, phản ánh rằng sự chấp nhận phụ thuộc vào mô hình dự thảo và khối lượng công việc thay vì phần cứng hoặc thời gian chạy. Suy luận GPU. Chúng tôi đo lường thông lượng GPU với SGLang trên một card H100 80GB ở định dạng BF16 với kích thước batch là 1 và nhiệt độ 0 với kích thước khối là 9. Cùng một mô hình dự thảo mang lại tốc độ giải mã nhanh hơn từ 2,04 đến 2,66 lần trên H100, với cải thiện tổng thể từ 1,64 đến 2,27 lần. Tỷ lệ chấp nhận dao động từ 3,46 đến 4,57 token mỗi lượt xác minh. ### Tính tương tác Những lợi ích của DSpark không chỉ dừng lại ở kích thước batch 1 mà còn duy trì ở mức độ đồng thời cao hơn. Chúng tôi đánh giá biên thông lượng-tương tác, nắm bắt sự đánh đổi giữa thông lượng hệ thống tổng hợp và tốc độ tạo văn bản mà mỗi người dùng trải nghiệm khi mức độ đồng thời thay đổi. Khi chúng ta tăng mức độ đồng thời, cường độ tính toán số học cao hơn dần chuyển giai đoạn giải mã từ bị giới hạn bởi bộ nhớ sang bị giới hạn bởi tính toán. Vì DSpark xác minh nhiều token dự thảo trong mỗi lượt của mô hình mục tiêu, cường độ tính toán số học được tăng tỷ lệ thuận với kích thước khối. Như Hình 5 cho thấy, DSpark duy trì lợi thế về thông lượng ở tất cả các mức độ đồng thời được đo lường, mặc dù khoảng cách thu hẹp khi mức độ đồng thời tăng lên. Tất cả các thử nghiệm được chạy trong SGLang trên một card H100 sử dụng cửa sổ xác minh cố định. ### Tác động của lấy mẫu đến tốc độ và chất lượng Ở nhiệt độ khác không, mô hình dự thảo lấy mẫu một token từ phân phối của nó, và mô hình mục tiêu sẽ chấp nhận hoặc đưa ra một thay thế đã được sửa lỗi. Trong các cài đặt lấy mẫu khớp nhau, giải mã suy đoán tương đương về phân phối với việc lấy mẫu trực tiếp từ mô hình mục tiêu [3], và do đó, đầu ra được tạo ra là không mất dữ liệu (lossless). Khi chúng ta tăng nhiệt độ, điều bị ảnh hưởng là tỷ lệ chấp nhận và do đó là thông lượng. Ở nhiệt độ thấp hơn, mô hình dự thảo và mô hình mục tiêu có xu hướng tập trung vào cùng các token hàng đầu. Khi nhiệt độ tăng, khối xác suất lan sang các token ứng viên có thứ hạng thấp hơn, nơi các mô hình có nhiều khả năng không đồng ý với nhau hơn. Trong các thử nghiệm của chúng tôi, việc tăng nhiệt độ dẫn đến giảm tỷ lệ chấp nhận và kết quả là tác động tiêu cực đến thông lượng. ### Những hạn chế của suy đoán đối với các tác vụ thị giác trên thiết bị biên Trong suy luận Mô hình Ngôn ngữ Lớn (LLM), giai đoạn prefill phần lớn bị giới hạn bởi tính toán, và chi phí của nó tăng (gần như) theo bình phương với độ dài của prompt. Suy luận VLM làm tăng chi phí prefill: hình ảnh trước tiên phải đi qua bộ mã hóa thị giác, sau đó khung ngôn ngữ phải xử lý hàng trăm token thị giác mà nó tạo ra cùng với prompt văn bản. Điều này trở nên khó khăn hơn trên các thiết bị biên (edge devices), nơi lưu lượng tính toán thấp hơn đáng kể so với các GPU trung tâm dữ liệu. Kết quả là, giai đoạn prefill chiếm tỷ trọng lớn hơn trong độ trễ tổng thể (end-to-end latency). Điều này thể hiện rõ nhất qua các phép đo time-to-first-token và decode trên Apple silicon và H100. Các dòng Apple silicon mới hơn đã thu hẹp một phần khoảng cách này bằng cách bổ sung bộ tăng tốc thần kinh (neural accelerator) vào mỗi nhân GPU M5 [4]. Speculative decoding chỉ tăng tốc giai đoạn decode của quá trình suy luận LLM. Vision encoding và prefill vẫn không thay đổi. Khi các giai đoạn này đã chiếm một phần đáng kể trong tổng thời gian thực hiện (wall time), thì ngay cả khi tốc độ decode tăng mạnh cũng chỉ mang lại sự cải thiện khiêm tốn về độ trễ tổng thể. Đây là ví dụ điển hình của định luật Amdahl, trong đó tốc độ tăng tổng thể bị giới hạn bởi phần khối lượng công việc không được tăng tốc. ### Bắt đầu Mô hình dự thảo DSpark vision của chúng tôi hiện đã có sẵn trên Hugging Face ở định dạng [Safetensors](https://huggingface.co/LiquidAI/LFM2.5-VL-3B-DSpark) và [GGUF](https://huggingface.co/LiquidAI/LFM2.5-VL-3B-DSpark-GGUF). Với LFM2.5, chúng tôi đang hiện thực hóa tầm nhìn về AI có thể chạy ở bất cứ đâu. Các mô hình này bao gồm: - Open-weight — Tải xuống, tinh chỉnh và triển khai không giới hạn. - Nhanh chóng ngay từ đầu — Hỗ trợ ngay từ ngày đầu cho llama.cpp, MLX và SGLang. - Một hệ sinh thái hoàn chỉnh — Từ các mô hình cơ sở để tùy chỉnh đến các biến thể chuyên biệt về âm thanh và hình ảnh, một kiến trúc duy nhất đáp ứng đa dạng các trường hợp sử dụng. Chúng tôi rất nóng lòng được thấy những gì bạn sẽ xây dựng. Tải xuống trên Hugging Face Bạn tò mò về hiệu suất của các mô hình nhỏ trên thiết bị? Hãy xem qua Pipette. _Bài gốc còn tiếp._ Xem tiếp tại: