AI News

Liquid AI は、LFM2.5-Encoder-230M と LFM2.5-Encoder-350M という 2 つの新しい小型エンコーダーモデルを Hugging Face で公開し、GPU を多用するより大規模なデプロイを必要とせず、CPU 上で文書規模のワークロードを処理できる長文コンテキストNLPモデルとして位置づけている。同社の Hugging Face Blog の発表によると、新モデルは 8,192 トークン入力をサポートし、分類、ポリシーチェック、ルーティング、PII 検出などの本番タスク向けに設計されている。

この発表が重要なのは、多くの企業向け NLP 業務が、いまも現在の大規模言語モデルの注目領域の外で動いているからだ。安全フィルター、受付分類器、意図ルーター、コンプライアンスツールは、長い文書を継続的に低マージンで処理することが多く、チャットボット型の生成品質よりもハードウェアコストと遅延の方が重要になる。Liquid AI の主張は、こうしたエンコーダーワークロードを既存の CPU インフラに移しつつ、ModernBERT のようなより大きい、あるいはよりよく知られた代替と競争できるというものだ。

Liquid AI が何を公開し、どこに位置づけられるのか

今回の公開は 2 つのモデル、LFM2.5-Encoder-230M と LFM2.5-Encoder-350M を含む。Liquid AI はこれらを狭い検索専用モデルではなく汎用エンコーダーと説明しているが、以前の LFM2.5-Retrievers と同じファミリーに属する。新モデルはマスク付き言語目的で事前学習されており、テキスト分類、トークンラベリング、検索など、より幅広いタスクにファインチューニングできるようにしたと同社は述べている。

この区別は、埋め込み、リトリーバー、エンコーダーのどれを選ぶかを判断するプロダクトチームにとって重要だ。検索モデルは多言語検索には十分かもしれないが、企業のワークフローでは文書全体やトークン単位での判断が必要になることが多い。たとえば、サポートチケットの振り分け、ポリシー違反の確認、個人識別情報の発見などだ。Liquid AI の例はこうした用途に強く寄っている。発表では、ゼロショットのプロンプトルーティング、ゼロショットのポリシー linting、多言語 PII 検出、さらにはマスク付き拡散テキスト生成の実験まで、すべて CPU のみの Hugging Face Spaces で動かしたデモが強調された。

これらのモデルは Liquid AI の LFM2 アーキテクチャから派生している。同社によると、LFM2.5-230M と LFM2.5-350M のデコーダーバックボーンからエンコーダーを初期化し、その後、アテンションマスクを変更し、短い畳み込みを非因果にし、マスク付き言語モデリングで学習することで、因果デコーダーを双方向エンコーダーに変換した。Liquid AI はまず 1,024 トークンで短文脈の言語能力を学習し、その後、より広いデータミックスで 8,192 トークン文脈へ適応させ、事実性、法務、多言語性能を強化したとしている。

なぜ CPU 性能が主題なのか

見出し級の主張は、ベンチマーク品質だけでなく長いシーケンスでのスループットにある。Liquid AI によれば、同社のエンコーダーは CPU で特に強く、長文脈のレイテンシが導入コストを左右する場面で優位性が出るという。社内比較では、LFM2.5-Encoder-230M はテストした全シーケンス長で ModernBERT-base より高速で、8,192 トークンでは約 3.7 倍高速だった。

Hugging Face Blog に掲載された具体例が注目されるのは、ベンチマーク速度を運用メッセージに変換しているからだ。完全な契約書、文字起こし、長いサポートスレッドを、同じコンテキスト長で ModernBERT-base だと 1 分半以上かかるところ、ノート PC の CPU で 30 秒未満で処理できる可能性がある。多くの企業チームにとって、これは長文書分類を日常運用できるほど安価にできるかどうかを変える。

GPU では、Liquid AI はより小さな優位性を報告している。同社によると、Apple GPU ではおよそ 1,000 トークン未満で ModernBERT-base が依然として優勢だが、LFM2.5-Encoder モデルは 2,000 トークン前後から上回る。これは意図された市場ポジションを強く示している。つまり、短い入力ワークフローすべてに対して最速というわけではないが、CPU 経済性が重要な長文脈・常時推論向けとして売り出されている。

この位置づけは、AI インフラのより広い分断も反映している。生成モデルが依然として注目の大半を集める一方で、多くの本番システムは、大規模モデル呼び出しの前後でテキストを採点、分類、フィルタリング、ルーティングする小型モデルに依存している。これらのモデルがローカルまたは一般的な CPU で動かせるなら、ビルダーはコストを下げ、データ常駐性の選択肢を改善し、GPU 可用性への依存を減らせる。

アーキテクチャの話は、より広い長文脈設計トレンドと一致している

Liquid AI の発表はエンコーダーモデルに焦点を当てているが、このクラスターのもう一つの情報源である NVIDIA Developer Blog の長文脈アテンション設計に関する投稿が、なぜ今この発表が出たのかを説明する助けになる。NVIDIA は、エージェント型および長文脈ワークロードが一般化するにつれて、アテンションが推論コストをますます支配するようになり、モデルアーキテクチャの選択が性能の大きな決定要因になると論じている。

NVIDIA の投稿は Liquid AI についてではなく、CPU 優先デプロイではなく GPU 推論に焦点を当てている。それでも核心は直接関連している。長文脈の性能は、カーネルエンジニアリングだけでなく、グループサイズ、ヘッド次元、KV ステート管理といったアーキテクチャ上の決定によって形作られる。投稿では、デコード効率のためのより高いグループサイズ、GPU メモリとタイルサイズに合わせたヘッド次元、圧縮やスパース/ハイブリッドアテンションによる実効 KV ステート削減など、ハードウェアを意識したアテンション設計を推奨している。NVIDIA は TensorRT-LLM や NVIDIA Nemotron 3 などのアーキテクチャを、この協調設計アプローチの例として挙げている。

このより広い文脈により、Liquid AI の発表は単なるモデルのアップロード以上の意味を持つ。同社は、GPU の協調設計を駆動するのと同じアテンション効率の論理が、CPU 依存のエンコーダーワークロードにも実用上の利益をもたらしうると実質的に主張している。Liquid AI によると、LFM2.5-Encoders は LFM2.5 バックボーンの「入力長が増えてもコストの増加が緩やか」という性質を受け継いでいる。企業 AI システムを評価するユーザーにとって、それは短い合成タスクでのピーク性能よりもしばしば価値が高い。

証拠、ベンチマーク、そしてベンダー報告のまま残るもの

この話で最も強い性能主張はベンダー報告だ。品質結果と速度比較は、独立したベンチマーク研究所や第三者の企業導入調査ではなく、Liquid AI 自身の Hugging Face Blog 投稿に由来する。Liquid AI は、各モデルを各タスクで完全にファインチューニングし、GLUE、SuperGLUE、多言語分類の 17 タスクにわたって 14 モデルを評価し、5 つの保留シードの平均を報告したとしている。また、評価フレームワーク全体と生データをオープンソース化したとも述べている。

これらの結果によると、LFM2.5-Encoder-350M は試験した 14 モデルの中で 4 位で、先行したのは 3.5B モデルを含む、より大きなモデルだけだった。Liquid AI はまた、LFM2.5-Encoder-230M が報告セットアップにおいて ModernBERT-base とすべての EuroBERT モデルを上回り、しかもそれらの大半より小さいと主張している。重要な主張ではあるが、外部の再現が現れるまでは、読者は企業報告として扱うべきだ。

NVIDIA Developer Blog は、Liquid AI のモデルを独立に検証するのではなく、技術的背景を提供している。その分析もまたベンダー執筆であり、FP8 アテンション計算や KV キャッシュを用いた測定カーネル挙動など、NVIDIA のハードウェア前提に基づいている。これは長文脈アテンション設計がなぜ重要かを理解するのに役立つが、Liquid AI の CPU におけるベンチマーク優位性を第三者が確認したものとして読むべきではない。

実務上の不明点もある。ソース資料には、詳細な企業向け価格、サポート条件、本番事例は示されていない。また、実世界の文書ノイズ、マルチテナント環境でのレイテンシ制約、ドメインシフトした法務・コンプライアンスデータセットでの挙動も明らかになっていない。導入に関心のあるビルダーは、おそらく自社のコーパスとサービスレベル目標に対して LFM2.5-Encoder-230M と LFM2.5-Encoder-350M をテストする必要がある。

ビルダーと企業バイヤーにとっての意味

AI ビルダーにとっての即時の魅力はワークフロー設計だ。CPU で 8,192 トークンまで使える小型エンコーダーは、そうでなければ切り詰め、チャンク分割、高価な GPU 推論を必要とするシステムに組み込める。契約書レビューのパイプライン、カスタマーサポートのトリアージ、Trust and Safety のスクリーニング、多言語受付、ポリシー適用に関係する。さらに、小型モデルがより大きなモデルを呼ぶ前にリクエストをフィルタリングまたはルーティングするハイブリッドスタックにも関連する。

企業 AI チームにとっては、コストの話がランキングの順位よりさらに重要かもしれない。CPU で扱いやすい推論は、規制された環境や予算制約のある環境でのデプロイを簡素化できる。特に GPU 容量が限られていたり、データを既存のオンプレミス基盤内に留めなければならない場合だ。長文脈エンコーダーは、文書を多数のチャンクに分割して下流で結果を再構成する必要をなくせば、エンジニアリングの複雑さも減らせる。

モデル開発者にとって、この発表は、市場がフロンティア・チャットモデルを超えて特化型の推論プリミティブへ広がっていることのさらに一つの兆候だ。ModernBERT は依然として重要な比較対象だが、Liquid AI はより具体的な約束で競争しようとしている。つまり、小さなモデルサイズでより良い長文脈経済性だ。この主張が実運用で通用するなら、ビルダーはエンコーダーをコモディティなユーティリティではなく、レイテンシ予算とシステムコストに直接影響するアーキテクチャ判断として扱うようになるかもしれない。

次に注目すべき点

次の重要なシグナルは独立した再現だ。外部開発者が、特に一般的な CPU と実際の文書ワークロードにおいて、Liquid AI が報告した ModernBERT-base との差を確認すれば、この発表は低コストの企業向け NLP システムをどう設計するかに影響を与える可能性がある。

もう一つのシグナルは Hugging Face エコシステム内での採用だ。LFM2.5-Encoder-230M と LFM2.5-Encoder-350M が本番デモ、ファインチューニング済み分類器、企業評価スタックに登場し始めれば、強い社内ベンチマークを示しているだけでなく、実際の運用課題を解決していることを示唆する。

Liquid AI が LFM2 ファミリーをさらに拡張するかどうかも注目に値する。LFM2.5-Retrievers とこれら新しいエンコーダーの関係は、検索、ルーティング、ラベリング、フィルタリングといったワークフロー層ごとに、小型で効率的な長文脈モデルを軸にした、より広い戦略を示している。インフラ面では、NVIDIA が示し TensorRT-LLM に実装されている原則が、より長いコンテキスト窓でどのアーキテクチャが実用的かを今後も左右していくだろう。

Creati.ai の視点

このリリースが興味深いのは、最大級のモデルを打ち負かそうとしているからではなく、スタックの中で見過ごされがちな部分、つまり常時かつ低コストで動作しなければならない長文書理解を狙っているからだ。多くの実システムでは、その層が高価なモデル呼び出し自体を行うかどうかを決める。Liquid AI の CPU 主張が裏付けられるなら、LFM2.5-Encoders は、長文脈カバレッジを失わずに推論コストを抑えたい企業 AI チームにとって有用な構成要素になるかもしれない。

より大きな教訓はアーキテクチャにある。市場は「より大きいモデル = より良い製品」という単純な物語を超えつつある。LFM2.5-Encoder-230M を CPU で使う場合でも、NVIDIA の協調設計ガイダンスによって形作られた GPU スタックでも、性能はますますモデル構造をワークロードとハードウェアに合わせることにかかっている。ビルダーにとっては、競争優位は基盤モデルを持つことよりも、正しい場所で正しい小型モデルを選ぶことから生まれるのかもしれない。」},

フィーチャー

Liquid AI が Hugging Face で LFM2.5-Encoders を公開、CPU優先の長文コンテキストNLPが大規模モデルを上回れるかに賭ける

Liquid AI は Hugging Face で LFM2.5-Encoder モデルを公開し、大型ハードウェアなしで文書規模の NLP に対して高速な長文コンテキスト CPU 推論を提案した。