vLLM上のLFM3-1.7B：9日経っても、ネイティブサポートは依然として2つのオープンPRのまま

Liquid AIのLFM3-1.7Bは、2026年10月27日に、あたかも通常のコマンドであるかのように vllm serve "LiquidAI/LFM3-1.7B" を記載したモデルカードとともにリリースされた。それから9日後、上流のvLLMには、これを実行するためのLfm3ForCausalLMアーキテクチャが存在しない。代わりにあるのは、10月30日に起票された機能リクエスト、ほかすべてがその上に積み重ねられている1件のカーネルPR、そして6件のオープンなモデルPRだ。そのうち2件は同じLFM3-1.7Bテキストモデルを2つの異なる方法で実装しており、どちらもまだマージされていない。

その隔たりこそがここでの核心であり、しかもそれはごく狭いものだ。モデルは実在し、ダウンロードもできる。だがランタイム対応は待ち行列にすぎない。これはその待ち行列について、現時点で分かっていることをまとめた記事だ。何が進行中なのか、今日実際に動くのは何なのか、そしてモデルカードの「vLLMで動作」が、デプロイ計画が必要とする意味で真になる前に、何が実現していなければならないのか。

カードには vLLM と書かれています。サポート対象モデルの表には LFM2 と書かれています。

vLLM 自体のサポートモデルドキュメントには、Liquid AI のアーキテクチャが 3 つ記載されています。Lfm2ForCausalLM、Lfm2MoeForCausalLM、Lfm2VlForConditionalGeneration です。LFM3 の項目はありません。一方、LFM3-1.7B のモデルカードには、そのチェックポイントが「vLLM、SGLang、および LFM3 互換の llama.cpp ビルドで動作する」と記載されており、フラグを一切付けないサービングコマンドが示されています。

その整合はチェックポイント自身の設定にある。LFM3-1.7B は同梱の modeling_lfm3.py を指す auto_map を備えているため、Hugging Face 側のコードは存在し、リモートコードを許可するローダーへと自身を複製する。vLLM の移植に関する追跡 issue #64645 —「[Feature]: Support LiquidAI LFM3 models」、10月30日に abhijithneilabraham が起票 — は、その結果について率直だ。「vLLM には Lfm3ForCausalLM がない」。そこに挙げられている代替手段は、今月ほとんどの人が結局使うことになる逃げ道だ。「Transformers バックエンドで、チェックポイントのリモートコードを通して LFM3 を実行する。ただし、PagedAttention と conv 状態キャッシュは諦めることになる」。

そのトレードオフは率直に言っておく価値がある。なぜなら「vLLM 上で動く」と「vLLM の transformers バックエンド上で動く」は別の製品だからだ。Paged attention は、長さが大きく異なるリクエストを KV メモリを無駄にせずバッチ処理できるようにする仕組みであり、conv state cache は同じ発想をこのアーキテクチャの短畳み込み層に適用したものだ。両方を取り除けば、vLLM が存在する二つの理由を放棄した、一応動作するエンドポイントが残るだけだ。低並列度で提供される 1.7B モデルなら、それは許容できる週末の遊びかもしれないが、許容できる本番構成ではない。

なぜ1.7Bモデルにそもそもカーネルの作業が必要なのか

LFM3-1.7B は、vLLM がすでに提供している LFM2 ファミリーを単純に再チューニングしたものではない。これは2種類ではなく3種類の層タイプを持つ24層のハイブリッドである。13のゲート付きショートコンボリューション層、256トークンウィンドウのスライディングウィンドウアテンション層5つ、フルアテンション層6つで構成されている。チェックポイントの設定はその幾何構造を明記している——conv_L_cache: 7、sliding_window: 256、128K語彙——。さらに vLLM の issue 自体の差分リストには、QK RMSNorm、ヘッドごとのシグモイド注意出力ゲート、サンドイッチ正規化、およびフルアテンション層における部分 RoPE（partial_rotary_factor: 0.5）が追加されており、これらは Gemma 4 が用いるのと同じゼロテール形状で配置されている。

ポートを壊したのは7という数だ。LFM2のショート畳み込みはタップ幅が3で、LFM3はそれを7に広げた。vLLMのTriton causal_conv1dカーネルは固定された幅のセットをアンロールしており、追跡イシューが次のように述べている：「Tritonのcausal_conv1dプリフィルカーネルは幅2〜4を、デコードカーネルは2〜6をアンロールするため、幅7のモデルは現時点ではCUDA上で実行できない」。

つまり、スタック内の最初のPRはモデルですらない。#64647「[Kernel] Support width-7 causal conv1d」は、10月30日にabhijithneilabrahamがオープンしたもので、2つのファイルと186行の追加に及び、prefillカーネルを幅2–4から2–7へ、decodeカーネルを2–6から2–7へ拡張し、どちらのラッパーもその範囲外にはValueErrorを送出するようにします。PR自体の説明が、拡張と同じくらい拒否が重要である理由を説明しています。変更前は「より広い重みが一致する分岐を持たないまま実行され、誤った値を返していた」からです。静かな数値破壊は拒否よりも悪い失敗であり、たまたま試したモデルでしか現れない類のものです。

そのPRには、ひとつ注意書きを添えておくべきだ。作者は、自分にCUDAマシンがないことを率直に述べている。CPU参照パスは96件のテストに合格し、TritonカーネルはカーネルASTに対する静的解析で確認され、GPUでの検証はCIに委ねられている。これは欠陥ではなく正直な開示だが、それによって、他のすべてのLFM3 PRが依存する唯一の変更が、大多数の読者がそれを実行するハードウェア上でまだ試されていないことになる。

同じテキストモデルの2つの実装

6日以内に、2つの別々のグループがvLLM向けのネイティブLFM3サポートを書きました。それらは1つのパッチの変種ではなく、たまたま同じアーキテクチャ名を登録する独立した設計です。

PR #64959「[Model] LiquidAI LFM3（Lfm3ForCausalLM）を追加」は、atmikshettyによって11月1日にオープンされた、保守的な方針のPRです。ファイル数は7つで、自身の説明によれば、幅7のShortConv、Lfm2MLP、LFM2の重みマッパー、既存の比例RoPEを再利用しており、コアコンポーネントは一切変更していません。モデルをレジストリに登録し、ハイブリッドモデルのテストセットとサポート対象モデルの表に追加し、さらに——これを動作させた人にとって有用なことに——検証に使用したサービングフラグを文書化しています: --reasoning-parser qwen3 --tool-call-parser qwen3_coder --enable-auto-tool-choice。検証セクションでは、A100-SXM4-40GB上でBF16により324件のカーネルテストが成功したこと、レジストリと初期化のテストが成功したこと、Hugging Faceのリモートコードリファレンスに対する対数確率の比較が報告されています。

PR #65826「[Model] Add LFM3-Text」は、Liquid AI の paulpak58 によって11月5日にオープンされた、ベンダー自身によるバージョンです。10個のファイルと829行の追加からなり、transformers_utils/configs/lfm3.py 配下の独自の設定クラスと、独自のテストモジュールを含んでいます。当初は「[Model] Add LFM3」としてオープンされ、同日、ファミリーが4つの積み重ね PR に分割された際にタイトルが変更されました。すなわち、テキスト用の #65826、視覚言語用の #65827、音声用の #65828、オムニ用の #65829 で、それぞれがその前のものを基に構築されています。

両者は対立しているというより並行して進んでおり、議論は依存関係の網目を明確に示している。カーネルPRについて、paulpak58は11月4日にこう書いた。「LFM3モデル用の社内PRは別途ありますが、これは後押しできるクリーンな追加です」。コミュニティテキストPRについて、abhijithneilabrahamは、マージにはLiquidのtransformers側の作業が先にマージされる必要があるかもしれないと示唆した――「このPRのマージには@paulpak58によるtransformers PRが必要だと思います」――これに対してatmikshettyは、Lfm3Configはまだtransformersのリリースに含まれていないため、このブランチは「チェックポイントからtrust_remote_code経由で設定を読み込み、実行にはネイティブのvLLMモデルを使用する」と返答した。これが、ほとんどの読者が考えもしなかった第2の関門だ。マージされたvLLM PRであっても、どこかで提供される設定クラスが必要なのである。

Transformers側では、同等のPRは#50322「[Model] LFM3 Family: LFM3-Text」で、11月3日にオープンされ、現在もオープンのままで、より大きなファミリーPRから分割されたものです。畳み込みに関するそのPR自身の注記はvLLMのissueと一致しています。short convは「LFM3ではtorchのみ（Hubのcausal_conv1dカーネルは幅2〜4に対応し、LFM3は7を使用）」です。

ビジョン言語も重複しています。Liquidの#65827に加えて、独立したLFM3-VL PR（#65450、11月3日作成）がまだオープンで、コミュニティのテキストPRに依存しています。したがって、今日時点で、2つの陣営にまたがる6つのオープンなLFM3 PRがあり、マージ済みのものはありません。

実際に今日動いているのは何か

憶測を除けば、11月5日の実際の状況は次のとおりだ。

• vLLM ネイティブ — 標準ビルドでは不可能です。レジストリに Lfm3ForCausalLM はなく、サポート対象モデルの表に LFM3 の行もなく、追加する PR は未マージです。

• vLLM、transformers バックエンド — チェックポイントに同梱されたリモートコードと trust_remote_code を使用する、ドキュメント記載の回避策です。PagedAttention と conv ステートキャッシュは失われますが、OpenAI 互換サーバーは維持されます。

• SGLang — ベンダー自身のサーバーパス。Liquidのローンチ投稿では、SGLangを使用し、単一のNVIDIA B300上でBF16でスループット数値を測定しており、1,024件の同時リクエストで1日あたり36億トークンを含みます。vLLMはその投稿では、競合モデルが提供されていたランタイムとしてのみ登場します。

• llama.cpp — このカードは「LFM3互換のllama.cppビルド」に言及していますが、これは定型文ではなく実際の条件を示すものです。Liquidのオンデバイス数値は、32KコンテキストでのQ4_0によるllama.cppのものです。

• MLX — 別個の vLLM-Metal プロジェクトの 0.33.0 リリースノートには、--trust-remote-code を指定した場合に LFM3 text MLX チェックポイントが記載されています。これは上流の vLLM とは別のコードベースであり、CUDA サポートを意味するものではありません。

• Hosted — Liquid 自身の API とプレイグラウンドです。このカードには料金表が示されていないため、公開情報からトークンあたりのコストを見積もることはできません。

2つの数字が、セルフホスティングの位置づけを明確にする。重みは十分に小さく、メモリは制約にならない——Liquidは4ビットで約1GBと主張している——そしてベンダーによれば、128Kトークンのコンテキストには約1.6GBのKVキャッシュが必要になる。制約となるのはGPUではなく、サービングスタックだ。

これを変えるには、順番に何を変えればよいか

依存関係の連鎖は異例なほどクリーンで、そのおかげで注目すべき点は異例なほど具体的になっている。まず #64647 がマージされる必要がある。他の LFM3 の PR はすべて、そのコミットを含むか、その上に積まれているからだ。次に、2つのテキスト PR のどちらかがレビューを通過しなければならない。コミュニティ版はより完全な検証記録を持ち、Liquid 版は transformers 側も担当する作者を持っている。その後、Lfm3Config が transformers のリリースに入らなければ、どのデプロイも trust_remote_code を渡し続けることになる。それが済んで初めて、LFM3-VL-2B、LFM3-Audio-2B、LFM3-Omni-2B が現実的になり、これらはテキストモデルがすでに取り込まれていることを前提とするさらなる PR の後ろに控えている。

これはどれも、ペースへの批判として読むべきではない。ローンチから、完全かつテスト済みのカーネル＋モデルのPRスタックまで9日というのは速いし、2つの独立したチームが1週間足らずで動作する実装を生み出したという事実は、遅れについてよりも、LFM3がどれほどLFM2に近いかを物語っている。しかしモデルカードは互換性の主張であり、LFM3-1.7Bの現状を正直に読み取るなら、「transformersバックエンド経由でvLLMと互換」であって、「vLLMにサポートされている」ではない。

今週、小さなツール呼び出しモデルが必要なら

LFM3-1.7Bは、欲しくなるのも納得の魅力的な存在だ。ベンダー報告の数値は、小規模モデルが通常つまずくまさにその領域で強い——BFCL V4で71.39、ToolSandboxで80.36、IFEvalで96.66、SWE-bench Verifiedで43.40——総合平均49.37は、Liquidが自社のLFM2.5-2.6B（31.55）を上回ると位置づけている。これらはモデルを開発した企業自身による評価であり、独立した再現も、本日時点で我々が確認できた限りArtificial Analysisの登録もない。順位付けは仮説、個々の数値は主張として扱うべきだ。付随する注意点も同じ出所から来ている。モデルカードはエージェント型コーディングと複雑な多段階推論を推奨しておらず、知識系ベンチマークもこの助言と一致している——GPQA Diamondで63.37、128KでのRULERで65.56というのは、汎用モデルの数値ではない。

つまり、判断の焦点はモデルそのものではありません。現在オープンなプルリクエストにすぎないサービング経路の上に構築する余裕があるかどうかです。SGLang や llama.cpp を実行できるなら、今日から LFM3-1.7B を使えるので、vLLM の問いは机上の話になります。ポリシー上スタックが vLLM なら、transformers バックエンドに欠けている paged attention を取るか、待つかを選ぶことになります。

待てないワークロード向けに、名前を挙げる価値のある第三の選択肢があります。別の何かにルーティングする、というものです。OrcaRouter は LFM3-1.7B を取り扱っていません — 本日の当社カタログを確認したところ、200 を超えるモデル ID が返り、そのいずれも Liquid のものではありません — つまり、これを当社経由で呼び出そうという売り込みではありません。より単純な話として、未マージのカーネル PR は本番経路にとって悪い単一障害点だということです。ホスト型モデルの前面に単一の API と自動フェイルオーバーを置くには、設定変更が一つあれば済み、ネイティブ対応がマージされた日に LFM3-1.7B に差し替えられます。それを賭け終える日を待つ必要はありません。モデルを単に呼び出すのではなく改変する場合は、当社独自の LFM3-1.7B-abliterated リリースは同じチェックポイントの拒否方向アブレーションであり、まさにこのサービング状況を引き継ぎます。

短いバージョン

LFM3-1.7Bがリリースされた。小規模で、それがトレーニングされた単一ターンのツール呼び出し業務に非常によく適している。そのvLLMサポートは今まさに、2つのチームによって、書いた本人がまだCUDAで実行したことのないカーネル拡張の上に書き進められている。まず#64647を注視せよ。幅7の畳み込みがマージされれば、残りのスタックは素早く進み、モデルカードの「vLLMで動作する」はリモートコードについての記述ではなくなり、paged attentionとバッチ処理についての記述になる。それまでは、このモデルについて「初日からvLLMサポート」と引用している人は誰であれ、リポジトリがまだ含んでいないものを引用しているのだ。