LFM3-1.7B di vLLM: Sembilan Hari Berlalu, Dukungan Native Masih Berupa Dua PR Terbuka

Liquid AI LFM3-1.7B dirilis pada 27 Oktober 2026 dengan kartu model yang mencantumkan vllm serve "LiquidAI/LFM3-1.7B" seolah-olah itu perintah biasa. Sembilan hari kemudian, vLLM upstream tidak memiliki arsitektur Lfm3ForCausalLM untuk menjalankannya. Yang ada sebagai gantinya adalah permintaan fitur yang dibuka pada 30 Oktober, satu pull request kernel yang menjadi landasan bagi semua yang lain, dan enam PR model yang masih terbuka — dua di antaranya mengimplementasikan model teks LFM3-1.7B yang sama dengan dua cara berbeda, dan keduanya belum di-merge.

Celah itulah inti ceritanya di sini, dan celahnya sempit. Modelnya nyata dan dapat diunduh; dukungan runtime-nya masih berupa antrean. Ini adalah tulisan tentang apa yang sejauh ini kita ketahui mengenai antrean tersebut: apa yang sedang berjalan, apa yang benar-benar berjalan saat ini, dan apa yang harus terwujud sebelum "works with vLLM" pada kartu model menjadi kenyataan dalam pengertian yang dibutuhkan oleh rencana deployment.

Kartu tersebut bertuliskan vLLM. Tabel model yang didukung bertuliskan LFM2.

Dokumentasi model yang didukung vLLM sendiri mencantumkan tiga arsitektur Liquid AI: Lfm2ForCausalLM, Lfm2MoeForCausalLM, dan Lfm2VlForConditionalGeneration. Tidak ada entri LFM3. Sementara itu, kartu LFM3-1.7B menyatakan bahwa checkpoint tersebut "bekerja dengan vLLM, SGLang, dan build llama.cpp yang kompatibel dengan LFM3" dan memberikan perintah serving tanpa flag apa pun.

Rekonsiliasinya ada dalam konfigurasi checkpoint itu sendiri. LFM3-1.7B membawa auto_map yang menunjuk ke modeling_lfm3.py bawaannya, jadi kode di sisi Hugging Face tersedia dan mengkloning dirinya ke loader yang mengizinkan kode remote. Issue pelacakan vLLM untuk port tersebut, #64645 — "[Feature]: Support LiquidAI LFM3 models", dibuka pada 30 Oktober oleh abhijithneilabraham — blak-blakan tentang konsekuensinya: "vLLM tidak memiliki Lfm3ForCausalLM." Alternatif yang dicantumkannya adalah jalan keluar yang akan akhirnya digunakan banyak orang bulan ini: "Jalankan LFM3 melalui kode remote checkpoint dengan backend Transformers. Itu berarti melepaskan paged attention dan cache status conv."

Pertukaran itu layak dinyatakan secara gamblang, karena "berjalan di vLLM" dan "berjalan di backend transformers vLLM" adalah produk yang berbeda. Paged attention adalah mekanisme yang memungkinkan vLLM mem-batch request dengan panjang yang sangat berbeda tanpa membuang memori KV; cache state conv adalah ide yang sama yang diterapkan pada lapisan short-convolution arsitektur ini. Hilangkan keduanya dan Anda memiliki endpoint yang berfungsi tetapi telah melepaskan dua alasan vLLM ada. Untuk model 1,7B yang dilayani pada konkurensi rendah, itu mungkin dapat diterima sebagai proyek akhir pekan, bukan sebagai bentuk produksi yang dapat diterima.

Mengapa model 1,7B sama sekali memerlukan pekerjaan kernel

LFM3-1.7B bukanlah penyetelan ulang sederhana dari keluarga LFM2 yang sudah didukung oleh vLLM. Ini adalah hibrida dua puluh empat lapis dengan tiga jenis lapisan, bukan dua: 13 lapisan konvolusi pendek bergerbang, 5 lapisan attention jendela geser dengan jendela 256 token, dan 6 lapisan attention penuh. Konfigurasi checkpoint tersebut menjabarkan geometrinya secara eksplisit — conv_L_cache: 7, sliding_window: 256, kosakata 128K — dan daftar perbedaan dari issue vLLM itu sendiri menambahkan QK RMSNorm, gerbang keluaran attention sigmoid per kepala, normalisasi sandwich, dan RoPE parsial (partial_rotary_factor: 0.5) pada lapisan attention penuh, yang disusun dalam bentuk zero-tail yang sama seperti yang digunakan Gemma 4.

Angka yang menggagalkan port tersebut adalah tujuh. Konvolusi pendek LFM2 selebar tiga tap; LFM3 melebarkannya menjadi tujuh. Kernel causal_conv1d Triton milik vLLM meng-unroll sekumpulan lebar yang tetap, dan seperti yang diungkapkan dalam issue pelacakan: "Kernel prefill causal_conv1d Triton meng-unroll lebar 2 hingga 4 dan kernel decode 2 hingga 6, sehingga model dengan lebar 7 tidak dapat berjalan di CUDA saat ini."

Jadi PR pertama dalam tumpukan itu sama sekali bukan model. #64647, "[Kernel] Dukungan causal conv1d lebar-7", dibuka pada 30 Oktober oleh abhijithneilabraham, menyentuh dua berkas dan 186 baris tambahan: PR ini memperluas kernel prefill dari lebar 2–4 menjadi 2–7 dan kernel decode dari 2–6 menjadi 2–7, serta membuat kedua pembungkus memunculkan ValueError untuk apa pun di luar rentang tersebut. Deskripsi PR itu sendiri menjelaskan mengapa penolakan sama pentingnya dengan perluasan: sebelum perubahan, "bobot yang lebih lebar berjalan tanpa cabang yang cocok dan mengembalikan nilai yang salah." Korupsi numerik senyap adalah kegagalan yang lebih buruk daripada penolakan, dan itulah jenis hal yang hanya muncul pada model yang kebetulan Anda coba.

Ada satu catatan penting yang perlu menyertai PR itu. Penulisnya menyatakan secara terus terang bahwa mereka tidak memiliki mesin CUDA: jalur referensi CPU lulus 96 tes, kernel Triton diperiksa melalui analisis statis atas AST kernel, dan validasi GPU diserahkan kepada CI. Itu adalah pengungkapan yang jujur, bukan cacat, tetapi itu berarti satu perubahan yang menjadi tumpuan setiap PR LFM3 lainnya belum dijalankan pada perangkat keras yang akan digunakan oleh sebagian besar pembaca untuk menjalankannya.

Dua implementasi dari model teks yang sama

Dalam enam hari, dua kelompok terpisah menulis dukungan native LFM3 untuk vLLM. Keduanya bukan varian dari satu patch; keduanya adalah desain independen yang kebetulan memasang nama arsitektur yang sama.

PR #64959, "[Model] Add LiquidAI LFM3 (Lfm3ForCausalLM)", dibuka pada 1 November oleh atmikshetty, adalah yang konservatif: tujuh file, dan menurut deskripsinya sendiri ia menggunakan kembali ShortConv pada lebar 7, Lfm2MLP, pemetaan bobot LFM2, dan RoPE proporsional yang sudah ada, tanpa mengubah komponen inti apa pun. Ia mendaftarkan model tersebut di registry, menambahkannya ke set pengujian model hibrida dan tabel model yang didukung, dan — berguna bagi siapa pun yang berhasil menjalankannya — mendokumentasikan flag serving yang telah divalidasi: --reasoning-parser qwen3 --tool-call-parser qwen3_coder --enable-auto-tool-choice. Bagian validasinya melaporkan 324 tes kernel lulus pada A100-SXM4-40GB dalam BF16, tes registry dan inisialisasi lulus, serta perbandingan log-probabilitas terhadap referensi remote-code Hugging Face.

PR #65826, "[Model] Add LFM3-Text", dibuka pada 5 November oleh paulpak58 — yang merupakan Liquid AI — adalah versi milik vendor itu sendiri: sepuluh berkas dan 829 baris tambahan, termasuk kelas konfigurasinya sendiri di transformers_utils/configs/lfm3.py dan modul pengujiannya sendiri. PR ini dibuka sebagai "[Model] Add LFM3" dan judulnya diubah pada hari yang sama ketika keluarga model tersebut dipecah menjadi empat PR bertumpuk: #65826 untuk teks, #65827 untuk vision-language, #65828 untuk audio, dan #65829 untuk omni, yang masing-masing dibangun di atas PR sebelumnya.

Keduanya tidak begitu banyak bertentangan melainkan berjalan paralel, dan diskusi itu menunjukkan jaring ketergantungannya dengan jelas. Pada PR kernel, paulpak58 menulis pada 4 November: "Kami memiliki PR internal sendiri untuk model LFM3, tetapi ini adalah tambahan yang bersih yang dapat kami dukung." Pada PR teks komunitas, abhijithneilabraham menyarankan bahwa merge mungkin perlu pekerjaan transformers dari Liquid di-merge terlebih dahulu — "Saya yakin merge PR ini memerlukan PR transformers dari @paulpak58" — yang dijawab atmikshetty bahwa Lfm3Config belum ada dalam rilis transformers, sehingga branch tersebut "memuat konfigurasi melalui trust_remote_code dari checkpoint, dan eksekusi menggunakan model vLLM native." Itulah gerbang kedua yang tidak akan terpikirkan oleh sebagian besar pembaca: bahkan PR vLLM yang sudah di-merge memerlukan kelas konfigurasi yang disertakan di suatu tempat.

Di sisi transformers, PR yang setara adalah #50322, "[Model] LFM3 Family: LFM3-Text", yang dibuka pada 3 November dan masih terbuka, dipisahkan dari PR keluarga yang lebih besar. Catatannya sendiri tentang konvolusi cocok dengan isu vLLM: konv pendeknya "torch-only di LFM3 (kernel causal_conv1d di Hub melayani lebar 2-4, LFM3 menggunakan 7)".

Vision-language juga terduplikasi. Selain #65827 dari Liquid, PR LFM3-VL independen (#65450, dibuka 3 November) masih terbuka dan bergantung pada PR teks komunitas. Jadi, per hari ini, ada enam PR LFM3 yang terbuka di dua kubu dan belum ada satu pun yang di-merge.

Apa yang sebenarnya berjalan hari ini

Singkirkan spekulasi, dan gambaran praktis pada 5 November tampak seperti ini.

• vLLM, native — tidak mungkin pada build standar. Tidak ada Lfm3ForCausalLM di registry, tidak ada baris LFM3 di tabel model yang didukung, dan PR yang akan menambahkannya belum di-merge.

• vLLM, backend transformers — solusi sementara yang didokumentasikan, menggunakan kode jarak jauh bawaan checkpoint dan trust_remote_code. Anda kehilangan paged attention dan cache status conv; Anda tetap mempertahankan server yang kompatibel dengan OpenAI.

• SGLang — jalur server milik vendor itu sendiri. Pos peluncuran Liquid mengukur angka throughput-nya pada satu NVIDIA B300 dalam BF16 dengan SGLang, termasuk 3,6 miliar token per hari pada 1.024 permintaan bersamaan. vLLM hanya muncul dalam pos tersebut sebagai runtime yang digunakan untuk menyajikan model-model pesaing.

• llama.cpp — kartu tersebut merujuk pada "build llama.cpp yang kompatibel dengan LFM3", yang merupakan kualifikasi nyata, bukan sekadar boilerplate; angka on-device Liquid menggunakan llama.cpp pada Q4_0 dengan konteks 32K.

• MLX — catatan rilis 0.33.0 proyek vLLM-Metal yang terpisah mencantumkan checkpoint MLX teks LFM3, di balik --trust-remote-code. Itu adalah basis kode yang berbeda dari vLLM upstream dan tidak menyiratkan dukungan CUDA.

• Dihostingkan — API dan playground milik Liquid sendiri. Kartu ini tidak menyertakan daftar tarif, jadi biaya per token bukan sesuatu yang dapat Anda anggarkan dari materi publik.

Dua angka menempatkan kasus self-hosting dalam perspektif. Bobotnya cukup kecil sehingga memori bukan kendala — Liquid mengklaim sekitar 1 GB pada 4-bit — dan vendor mengatakan konteks 128K token memakan sekitar 1,6 GB KV cache. Kendalanya adalah stack serving, bukan GPU.

Apa yang akan mengubah ini, secara berurutan

Rantai dependensinya {{1}}luar biasa bersih{{/1}}, yang membuat hal yang layak diperhatikan menjadi {{2}}luar biasa spesifik{{/2}}. Pertama #64647 harus di-merge, karena setiap PR LFM3 lainnya entah menyertakan commit itu atau ditumpuk di atasnya. Lalu salah satu dari dua PR teks harus memenangkan review — yang dari komunitas memiliki catatan validasi yang lebih lengkap, yang Liquid memiliki penulis yang juga memegang sisi transformers. Lalu Lfm3Config harus masuk ke rilis transformers, atau setiap deployment akan terus meneruskan trust_remote_code. Baru setelah itu LFM3-VL-2B, LFM3-Audio-2B dan LFM3-Omni-2B menjadi realistis, dan semua itu berada di balik PR-PR lanjutan yang mengasumsikan model teks sudah masuk.

Tidak satu pun dari ini boleh dibaca sebagai kritik terhadap kecepatannya. Sembilan hari dari peluncuran hingga rangkaian PR kernel-dan-model yang lengkap dan teruji itu cepat, dan fakta bahwa dua tim independen menghasilkan implementasi yang berfungsi dalam waktu kurang dari sepekan lebih menunjukkan betapa dekatnya LFM3 dengan LFM2 daripada tentang adanya keterlambatan apa pun. Namun kartu model adalah klaim kompatibilitas, dan pembacaan yang jujur atas LFM3-1.7B hari ini adalah "kompatibel dengan vLLM melalui backend transformers", bukan "didukung oleh vLLM".

Jika Anda membutuhkan model kecil yang dapat memanggil alat minggu ini

LFM3-1.7B adalah hal yang menarik untuk diinginkan. Angka yang dilaporkan vendor-nya kuat tepat di area yang biasanya menjadi kelemahan model kecil — 71.39 pada BFCL V4, 80.36 pada ToolSandbox, 96.66 pada IFEval, 43.40 pada SWE-bench Verified — dibandingkan rata-rata keseluruhan 49.37 yang menurut Liquid berada di depan LFM2.5-2.6B miliknya sendiri pada 31.55. Itu adalah evaluasi milik vendor sendiri, dijalankan oleh perusahaan yang membangun model tersebut, tanpa reproduksi independen dan tanpa entri Artificial Analysis yang dapat kami temukan per hari ini; anggap urutan tersebut sebagai hipotesis dan angka-angka individualnya sebagai klaim. Peringatan pendampingnya berasal dari sumber yang sama: kartu model menyarankan untuk tidak menggunakan agentic coding dan penalaran multi-langkah yang kompleks, dan benchmark pengetahuan mendukung saran tersebut — 63.37 pada GPQA Diamond dan 65.56 pada RULER di 128K bukanlah angka-angka seorang generalis.

Jadi keputusannya sebenarnya bukan tentang modelnya. Keputusannya adalah tentang apakah Anda sanggup membangun di atas jalur serving yang saat ini masih berupa pull request terbuka. Jika Anda dapat menjalankan SGLang atau llama.cpp, Anda dapat menggunakan LFM3-1.7B hari ini dan pertanyaan vLLM menjadi akademis. Jika stack Anda adalah vLLM karena kebijakan, Anda memilih antara paged attention yang tidak ada di backend transformers dan menunggu.

Ada opsi ketiga yang layak disebutkan untuk beban kerja yang tidak bisa menunggu: rutekan ke sesuatu yang lain. OrcaRouter tidak membawa LFM3-1.7B — pemeriksaan katalog kami hari ini mengembalikan lebih dari 200 id model dan tidak satu pun milik Liquid — jadi ini bukan promosi untuk memanggilnya melalui kami. Ini poin yang lebih sederhana: PR kernel yang belum di-merge adalah titik kegagalan tunggal yang buruk bagi jalur produksi. Menempatkan model yang di-hosting di balik satu API dengan failover otomatis hanya memerlukan satu perubahan konfigurasi, dan memungkinkan Anda menggantinya dengan LFM3-1.7B pada hari dukungan native-nya di-merge, bukan pada hari Anda selesai bertaruh padanya. Jika Anda memodifikasi model alih-alih sekadar memanggilnya, rilisLFM3-1.7B-abliterated milik kami adalah ablasi arah penolakan dari checkpoint yang sama, dan mewarisi secara persis situasi penyajian ini.

Versi singkatnya

LFM3-1.7B sudah dirilis, berukuran kecil, dan sangat cocok untuk tugas pemanggilan alat satu putaran yang menjadi fokus pelatihannya. Dukungan vLLM-nya sedang ditulis saat ini, oleh dua tim, di atas ekstensi kernel yang belum pernah dijalankan di CUDA oleh orang yang menulisnya. Pantau #64647 dulu — ketika konvolusi lebar-7 digabungkan, sisa stack bergerak cepat, dan "works with vLLM" di kartu model berhenti menjadi pernyataan tentang kode jarak jauh dan mulai menjadi pernyataan tentang paged attention dan batching. Sampai saat itu, siapa pun yang mengutip "day-one vLLM support" untuk model ini sedang mengutip sesuatu yang belum ada di repositori.