LFM2.5-VL-3B-DSpark vs LFM2.5-VL-3B: Anda Tidak Memilih Salah Satu, Anda Melampirkan Salah Satu

Pencarian yang membawa orang ke sini adalah sebuah perbandingan, tetapi jawaban jujurnya adalah bahwa LFM2.5-VL-3B-DSpark dan LFM2.5-VL-3B bukanlah dua hal yang harus Anda pilih di antara keduanya. Yang kedua adalah model visi-bahasa 3,1B yang dapat Anda unduh dan sajikan. Yang pertama adalah model draf berparameter 279,5M yang hanya ada untuk berada di depan model kedua dan membuatnya melakukan dekode lebih cepat. Keluarkan drafter dari stack dan ia tidak menghasilkan apa pun; Anda tidak dapat melakukan benchmark terhadapnya secara mandiri, karena "secara mandiri" bukanlah konfigurasi yang didukungnya. Perbandingan yang sebenarnya adalah LFM2.5-VL-3B yang berjalan sendirian versus model yang sama yang berjalan dengan drafter terpasang.

Baca seperti itu, dan keputusannya menyusut menjadi satu pertanyaan: apakah memori tambahan dan kompleksitas runtime tambahan memberi Anda latensi yang cukup untuk berdampak pada beban kerja Anda? Angka Liquid AI sendiri mengatakan ya untuk pekerjaan yang berat dalam decode dan secara eksplisit mengatakan tidak ketika prefill mendominasi. Tidak ada satu pun dari kedua sisi itu yang telah direproduksi di luar perusahaan.

Dua pos pemeriksaan, berdampingan

Yang membedakan keduanya adalah inti persoalannya, jadi ada baiknya menempatkan kedua repositori itu berdampingan sebelum argumen kecepatan dimulai.

• Peran — LFM2.5-VL-3B menghasilkan teks dan jawaban tentang gambar; LFM2.5-VL-3B-DSpark mengusulkan token untuk diverifikasi olehnya dan tidak menghasilkan apa pun yang dapat digunakan oleh dirinya sendiri

• Parameter — 3,1B untuk target, 279,5M BF16 untuk drafter, yang menurut Liquid merupakan peningkatan 8,9% pada jumlah parameter yang diterapkan

• Arsitektur — targetnya adalah model hibrida yang dibangun di atas tulang punggung LFM2.5-2.6B dengan encoder visi SigLIP2 NaFlex; drafternya adalah 4 lapisan attention penuh pada ukuran tersembunyi 2,048 dengan grouped-query attention plus kepala Markov dan kepala keyakinan

• Jendela konteks — 32.768 token untuk target; penyusun draf tidak membawa konteksnya sendiri dan mewarisi konteks milik target

• Encoder visi — SigLIP2 NaFlex 400M pada target; drafter tidak memilikinya dan tidak pernah melihat gambar secara langsung

• Kosakata — 128.000, dan embedding serta LM head drafter ditautkan ke target alih-alih diduplikasi, itulah sebabnya beban memorinya lebih kecil daripada yang disiratkan oleh 279,5 juta parameter

• Lisensi — keduanya dirilis di bawah lisensi LFM1.0 milik Liquid, yang di Hugging Face dikategorikan sebagai "other", bukan lisensi OSI, jadi bacalah ketentuannya sebelum deployment komersial

• Format — target dikirim sebagai kuantisasi safetensors, GGUF, ONNX, dan MLX; drafter dikirim sebagai safetensors dan satu GGUF F16 berukuran sekitar 567 MB

Satu baris dalam daftar itu perlu ditekankan karena itulah alasan mekanis mengapa pemasangan ini bisa bekerja sama sekali: drafter bukan model visi kecil. Ia tidak memiliki encoder visi dan tidak pernah menyentuh gambar. Pada saat token mencapai lapisan tersembunyi yang menjadi sumber penyusunan drafnya, patch gambar dan token teks keduanya hanyalah tensor, sehingga modalitas tidak terlihat oleh komputasi penyusunan draf. Itulah yang memungkinkan Liquid memindahkan teknik yang dikembangkan untuk model teks ke VLM tanpa merancang ulang VLM tersebut.

Apa yang diubah oleh penyusun, dan apa yang dibiarkannya apa adanya

Model target tidak berubah. Itu bukan pemasaran — melainkan properti kebenaran dari speculative decoding. Dalam greedy decoding, setiap token draf diverifikasi oleh target, sehingga outputnya persis seperti yang akan dihasilkan target sendirian. Dalam pengaturan sampling yang disamakan pada suhu bukan nol, distribusi outputnya sesuai dengan milik target. Drafter menukar memori dengan waktu dan tidak menyentuh hal lain.

Yang berarti setiap angka kualitas yang dapat Anda temukan untuk LFM2.5-VL-3B berlaku tanpa perubahan pada konfigurasi berpasangan. Dalam evaluasi Liquid sendiri, target ini mencetak 80,7 pada ScreenSpot-v2, 61,5 pada BLINK, 58,3 pada MuirBench, 73,1 pada MME, 63,3 pada MMStar, 81,3 pada ChartQA dan 88,7 pada POPE — semuanya dilaporkan vendor, tidak satu pun direproduksi secara independen, dan semuanya sama benarnya terlepas dari apakah drafter dipasang atau tidak. Tidak ada trade-off antara kualitas dan kecepatan yang perlu ditimbang di sini, dan halaman perbandingan apa pun yang menyajikannya telah salah membaca model ini.

Yang berubah adalah biaya sebuah token dalam waktu wall-clock. Liquid mengukur percepatan dekode dari 2,04× hingga 2,66× pada satu H100 dalam BF16 melalui SGLang pada ukuran blok 9, 2,30× hingga 3,13× pada Apple M5 Max melalui MLX-VLM pada ukuran blok 8, dan 1,57× hingga 2,14× pada M3 Ultra melalui llama.cpp. Secara end-to-end, proses yang sama menghasilkan 1,64×–2,27×, 1,56×–2,62×, dan 1,30×–1,77× secara berturut-turut. Pasangan angka itu adalah keseluruhan argumennya: dekode meningkat kira-kira dua kali lebih besar daripada end-to-end, dan selisihnya adalah bagian dari beban kerja yang tidak dapat disentuh oleh drafter.

Masalah prefill, sebagaimana dinyatakan oleh vendor

Kalimat paling berguna dalam pengumuman Liquid sendiri adalah kalimat yang berargumen menentang pembacaan tanpa batas atas judul utamanya. Inferensi visi-bahasa membayar biaya prefill yang tidak dibayar oleh inferensi teks: gambar melewati encoder visi, lalu backbone bahasa memproses ratusan token visual yang dihasilkan encoder tersebut. Pada perangkat edge, prefill itu merupakan porsi besar dari latensi end-to-end. Speculative decoding hanya mempercepat decode — encoding visi dan prefill tidak berubah. Ketika prefill mendominasi, percepatan decode 3× berubah menjadi keuntungan end-to-end yang jauh lebih kecil.

Itu adalah hukum Amdahl yang diterapkan oleh vendor pada produk vendor itu sendiri, dan hal itu seharusnya memengaruhi siapa yang membaca halaman ini. Transkripsi panjang dari satu halaman hasil pindai, sebuah keterangan gambar, percakapan multi-giliran yang membawa satu gambar ke depan — berat decode, dan drafter membuat 279,5 juta parameternya terbayar. Pertanyaan singkat tentang gambar besar beresolusi tinggi — berat prefill, dan drafter tidak. Tempatkan target yang sama di server dengan konkurensi tinggi dan gambaran berubah lagi: Liquid mengukur frontier throughput-interaktivitas alih-alih satu angka, dan melaporkan bahwa DSpark mempertahankan keunggulannya pada setiap tingkat konkurensi yang diuji sementara selisihnya menyempit seiring naiknya konkurensi.

Dua catatan cakupan yang lebih kecil dari sumber yang sama. Semua pengukuran menggunakan pemrosesan 16-bit untuk encoder visi dan backbone bahasa, dan akselerasi model terkuantisasi berada di luar cakupan rilis ini. Jika rencana Anda adalah memasangkan ekspor target 4-bit dengan drafter karena daya tarik utama VLM 3B adalah muat dalam beberapa gigabita, kombinasi itu bukan yang diukur.

Apa sebenarnya yang Anda keluarkan untuk melampirkannya

Memori adalah biaya yang terlihat dan kartu ini mengukurkannya: 8,9% lebih banyak parameter di stack yang diterapkan. Kompleksitas runtime adalah yang tak terlihat. SGLang memerlukan v0.5.19 atau lebih baru dan baris peluncuran yang membawa --speculative-algorithm DSPARK, jalur model draf dan ukuran blok; contoh dari kartu itu sendiri juga menonaktifkan cache radix dan menyematkan fraksi memori statis, yang merupakan keputusan penyajian yang kini harus Anda pertimbangkan. MLX-VLM memerlukan v0.7.2 atau lebih baru dan meneruskan drafter melalui --draft-model, tetapi decoding DSpark di sana saat ini menggunakan greedy sampling, sehingga temperature harus dipaksa ke 0 — batasan nyata jika aplikasi Anda mengandalkan keragaman sampling. llama.cpp bekerja melalui drafter GGUF yang dipasangkan dengan target GGUF, bukan dengan checkpoint safetensors asli.

Ada satu biaya lagi yang muncul di produksi, bukan di benchmark: drafter dan target harus bergerak bersama. Ketidaksesuaian versi di antara keduanya adalah mode kegagalan yang tidak ada dalam penerapan model tunggal, dan merilis salah satunya secara independen kini menjadi masalah dua artefak.

Ini adalah pairing yang di-hosting sendiri. OrcaRouter tidak merutekan LFM2.5-VL-3B atau drafter-nya — Anda mengunduh keduanya dan menyajikannya sendiri — jadi pertanyaan perutean berkaitan dengan semua hal yang diserahkan oleh model kecil tersebut. Sebagian besar deployment yang memasangkan VLM edge 3B dengan drafter tetap memiliki kueri yang tidak seharusnya dijawab oleh model kecil, dan mengirim kueri tersebut ke satu endpoint yang mencakup 200+ model dengan harga daftar masing-masing penyedia, dengan failover otomatis jika penyedia mengalami penurunan performa, berarti satu integrasi alih-alih satu per vendor. Ini juga berarti begitu penyedia memangkas harga, tarif Anda langsung mencerminkannya pada hari yang sama, bukan pada pembaruan kontrak berikutnya.

Yang mana yang harus diunduh

Jika beban kerja Anda berat pada decode dan perangkat keras Anda adalah salah satu dari tiga yang diuji Liquid, pasang drafter — kerugiannya terbatas, karena keluarannya terbukti merupakan keluaran target dan biaya memorinya di bawah sepersepuluh model. Jika latensi Anda didominasi prefill, atau Anda menjalankan target terkuantisasi, atau Anda bergantung pada sampling non-greedy di runtime yang belum mencabut pembatasan itu, jalankan LFM2.5-VL-3B saja. Model ini cepat dengan caranya sendiri: 228 token per detik pada M5 Max, 116 pada AMD Ryzen AI Max+ 395, dan 20 pada Galaxy S26 Ultra, semuanya angka dari vendor, dalam memori sekitar 3 GB.

Apa yang belum bisa diberitahukan siapa pun kepada Anda adalah apakah angka-angka Liquid tetap berlaku di perangkat keras Anda. Drafter tersebut memiliki 37 unduhan di Hugging Face pada saat penulisan ini dan belum ada reproduksi independen atas angka apa pun dalam tabelnya. Rekayasanya solid dan argumen kebenarannya adalah bukti, bukan klaim, tetapi besarannya adalah hasil pengukuran — dan pengukuran dari satu lab pada satu set mesin adalah justru jenis angka yang perlu Anda verifikasi sendiri sebelum memasukkannya ke dalam rencana kapasitas.

OrcaRouter menjangkau 200+ model melalui satu kunci, dengan harga daftar setiap penyedia diteruskan langsung pada markup 0% dan failover otomatis antar penyedia. harga daftar penyedia diteruskan pada markup 0% Pemasangan di halaman ini dihosting sendiri dalam kedua skenario - router ini ditujukan untuk semua yang dialihkan oleh model kecil, dan ini berarti pemotongan harga dari penyedia langsung tercermin pada tarif Anda di hari yang sama.