Hugging Faceに新しいLFM2.5エンコーダー、長文コンテキストのCPU推論でModernBERTに挑む

Hugging Faceは、8,192トークンの入力を処理し、長文コンテキストにおけるCPU速度でModernBERTに挑むLiquid AIのエンコーダーモデル2種を追加した。このリリースは、文書規模の言語処理に必ずしもGPUや生成モデルが必要とは限らない、という具体的な主張を検証の対象にしている。

Liquid AIによると、2億3,000万パラメーターのエンコーダーは、テストしたCPUで8,192トークンのフォワードパスを約28秒で完了する。同社の比較では、ModernBERT-baseは90秒以上を要したという。この報告上の差は、LFM2.5とModernBERTの比較を、ベンチマーク精度だけでなくデプロイコストをめぐる競争にしている。

この結果が重要なのは、エンコーダーが分類、ルーティング、抽出、モデレーション、個人情報検出といった継続的なワークロードを目立たない形で担っているためだ。こうしたシステムは、受信するすべての文書やメッセージを確認することが多い。そのため、個々の処理が小規模に見えても、遅いモデルは大きなインフラ負荷を生み出しうる。

Liquid AIは、モデルウェイト、評価ハーネス、モデルカード、CPU専用のデモを公開している。ただし、注目を集める性能は依然としてベンダー自身が実施した結果だ。プロセッサ構成や最適化済みランタイムのサポートを含む重要なデプロイ詳細については、より広範な独立検証が必要である。

Hugging FaceがオープンウェイトのLFM2.5エンコーダー2種を追加

このリリースでは、Liquid AIのデコーダーアーキテクチャを、長文書と一般的なコンピューティングハードウェア向けに設計した2つのタスク特化型エンコーダーへと転換している。

Liquid AIは2026年7月28日、Hugging Face上でLFM2.5-Encoder-230MとLFM2.5-Encoder-350Mを公開した。両モデルは最大8,192トークンのコンテキストをサポートし、同社のLFM2ハイブリッドアーキテクチャを採用している。

エンコーダーは入力を読み込み、分類、検索、抽出、トークン単位の判断に用いる文脈表現を生成する。因果言語モデルとは異なり、主目的は左から右へ次のトークンを生成することではない。

この違いは、コストと振る舞いの両方を左右する。サポートチケットのルーターに必要なのは転送先の選択であり、回答の作成ではない。プライバシーフィルターに必要なのは機密性の高い箇所の特定であり、流暢な段落の生成ではない。

Liquid AIは、既存の230Mおよび350Mのデコーダーバックボーンを、こうしたより限定的な用途向けに適応させた。因果的なアテンションマスクを双方向アテンションに置き換え、各トークンが前後両側のテキストを考慮できるようにした。また、対称パディングにより、アーキテクチャの短い畳み込みを非因果的なものにしている。

学習には、選択したトークンを隠し、周囲の文脈から予測させるマスク言語モデリングを用いた。Liquid AIは、学習時にトークンの30パーセントをマスクしたとしている。

同社は2段階のスケジュールを採用した。初期学習では大規模なWebコーパス上で1,024トークンのシーケンスを扱い、第2段階では事実性、法務、多言語性能の強化を意図したデータを使ってコンテキストを8,192トークンへ拡張した。

230Mのモデルカードによると、パラメーター数は約2億2,970万。350M版は約3億5,450万パラメーターを含む。いずれも隠れ層サイズは1,024で、語彙数は65,536である。

モデルカードによると、15言語をサポートする。対象言語には英語、スペイン語、フランス語、アラビア語、ヒンディー語、日本語、ベトナム語、中国語が含まれる。

Liquid AIは、小型モデルをより厳しいレイテンシーとメモリ制約向けに位置付けている。大型版は精度重視の選択肢として提示する。どちらも、本番の分類器、ルーター、抽出システムとして使う前に、タスク固有のファインチューニングが必要だ。

この条件は、LFM2.5エンコーダーをすぐに使えるアプリケーションとして説明する際に重要になる。ベースモデルは言語表現を提供するが、組織は出力ヘッドを追加し、対象タスク向けに学習させなければならない。

モデルはLiquid AIのLFM Open License v1.0を使用している。オープンウェイトと呼ばれることは、開発者が学習済みパラメーターをダウンロードして実行できることを意味する。標準的な寛容型ソフトウェアライセンスで公開されていることを意味するわけではない。

Hugging Faceは配布基盤、モデルカード、コミュニティディスカッション、デモを提供する。Liquid AIはアーキテクチャ、ウェイト、評価、実装を提供する。この構成により実験は容易になる一方、中心的な性能主張の責任はモデル開発元に残る。

したがって、直近の変化は具体的だ。開発者は、GPU優先の生成ではなくCPUデプロイを軸に設計された、ダウンロード可能な長文コンテキスト対応エンコーダーを2種利用できるようになった。

長文コンテキストのCPU推論こそが本当の価値

中心的な機会は小型チャットボットではなく、完全な業務文書を確認できる、より低コストな判断レイヤーにある。

本番の言語システムは、文章生成を必要としない多くのタスクを実行する。リクエストのラベル付け、ポリシー違反の検出、感情の分類、エンティティの識別、パッセージの順位付け、より大きなモデルに送るプロンプトの選択などだ。

これらの処理は、ユーザーに見えるチャットボットの応答よりもはるかに頻繁に実行される場合がある。エージェントプラットフォームでは、生成前にプロンプトを複数の安全ルールで評価し、配信前に結果を再分類することもある。

すべての段階を大規模生成モデルで実行すると、レイテンシーとハードウェア需要が増す。また、予測可能なラベルやトークン範囲を必要とするタスクに、出力のばらつきを持ち込む可能性もある。

ファインチューニング済みエンコーダーは異なる道筋を提供する。関連テキストを1回のフォワードパスで読み込み、タスク固有のスコアを返す。各文書を外部サービスへ送信するのではなく、モデルをローカルプロセス内に保持できる。

コンテキスト長は、その処理が完全な原文を見られるかどうかを決定する。古いエンコーダーは短いシーケンスを中心に設計されていることが多く、開発者は契約書、文字起こし、サポートスレッドを分割する必要があった。分割によって、判断と意味を変える証拠が切り離されることがある。

8,192トークンのウィンドウですべての長文書を網羅できるわけではない。しかし、従来の512トークンBERTデプロイメントよりも大幅に多くのテキストを扱える。この差により、チャンク化と周辺の集約ロジックを減らせる可能性がある。

Liquid AIは、CPU専用のHugging Face Spacesでこのアプローチを示している。デモは、プロンプトルーティング、ポリシーリンティング、スペルチェック、個人識別情報の検出を扱う。

PIIデモは、16言語で40種類の情報を検出すると報告されている。ポリシーリンティングは、自由記述で与えられたルールに対してトークンを採点する。プロンプトルーティングは、プロンプト全体をユーザー定義のルーティングカテゴリと比較する。

これらのデモは、Liquid AIが獲得を目指すワークロードを示している。出力が限定され、インフラコストが継続的に発生する、高頻度の理解タスクである。

ローカルのポリシーフィルターは、特にエージェントシステムに関連性が高い。フィルターはアプリケーションと同じ環境内で動作でき、内部テキストを別のリモートエンドポイントへ公開する必要性を減らせる。

同じ論理はローカルの技術文書にも当てはまる。検索可能なナレッジベースを構築するチームは、生成された回答が現れる前に、分類、抽出、検索の段階を必要とする。

CPUデプロイにより、こうした段階を実行できる場所が広がる。開発者のノートPC、アプリケーションサーバー、エッジデバイスで、専用アクセラレーターを確保することなくモデルを実行できる。

ただし、「CPUで動作する」ことが、あらゆる規模で即時かつ低コストであることを自動的に意味するわけではない。28秒のパスは1件の契約書には実用的でも、対話型インターフェースには不向きかもしれない。バッチスループットと単一文書のレイテンシーも異なる。

より強い主張は、運用上の柔軟性にある。チームは、データがすでに存在する場所に特化した言語処理を配置し、本当に生成を必要とするタスクのためにGPUやリモートモデルを確保できる。

この役割分担は、あらゆる言語処理に汎用推論を販売するベンダーに圧力をかける。また、より小型のエンコーダーで要件を満たせるか測定する前に大規模言語モデルを標準的に選ぶチームにも圧力をかける。

LFM2.5とModernBERTの差はアーキテクチャにある

Liquid AIが報告する速度優位は、ハイブリッドバックボーンがすべての層で完全なアテンションを適用しないため、入力長が増えるほど大きくなる。

ModernBERTは、8,192トークンのコンテキストで効率的な双方向エンコーディングも狙っているため、最も明確な比較対象となる。2024年後半に公開され、長い入力、現代的なハードウェア、改善された学習に向けてBERT設計を更新した。

元のBERT研究は、双方向事前学習を言語理解の基盤として確立した。その後ModernBERTは、このアプローチに、現在のデプロイニーズを狙ったアーキテクチャおよび学習上の更新を組み合わせた。

Liquid AIは別の経路を取る。LFM2は、グループドクエリアテンションとゲート付き短畳み込みブロックを交互に配置する。アテンションはシーケンス全体の情報を結び付ける一方、短い畳み込みは計算オーバーヘッドを抑えつつ近傍トークンに焦点を当てる。

このハイブリッド構造は、入力が長くなるほど重要になる。完全な自己アテンションはシーケンス全体の位置を比較するため、その計算負荷は長さとともに急速に増加する。畳み込み層は、より多くの処理を局所的な近傍に限定する。

Liquid AIはアテンションを排除しているわけではない。アーキテクチャがその完全なコストを負担する頻度を減らしている。多くの層をより低コストな局所処理で進めつつ、モデルは離れた位置の情報を依然として交換できる。

エンコーダー用途では、Liquid AIはこうした局所処理を双方向化した。対称パディングにより、畳み込みは現在のトークンの前後にある近傍を取り込める。完全アテンション層にも双方向マスクが適用される。

この仕組みが、LFM2.5とModernBERTを比較する中心的な根拠となる。Liquid AIは、ハイブリッドなシーケンス処理が競争力のある理解性能を維持しながら、長い入力におけるレイテンシーの増加を抑えられると見込んでいる。

リリース結果によると、LFM2.5-Encoder-230Mは、すべてのCPUシーケンス長でテスト対象モデル中最速だった。その優位性は、8,192トークンの上限で最も明確になった。

Liquid AIは、この長さで小型LFM2.5モデルが約28秒だったと報告している。ModernBERT-baseは90秒以上を要し、同社が示す3.7倍の優位性につながったとしている。

同社はApple GPU上ではより限定的な傾向を確認した。ModernBERT-baseはおよそ1,000トークン未満で優位だったと報告されている。Liquid AIのエンコーダーは約2,000トークンから先行した。

この逆転はトレードオフを示す。長い入力向けに最適化されたアーキテクチャの選択が、短い入力での優位性を保証するわけではない。本番の分類リクエストの多くは、依然として2,000トークンを大きく下回る。

パラメーター数も単純な速度比較を複雑にする。ModernBERT-baseは約1億4,900万パラメーターであるのに対し、Liquid AIの小型エンコーダーは約2億3,000万パラメーターを持つ。LFM2.5モデルはより大きいが、長いCPUシーケンスではより高速だと報告されている。

したがって、このベンチマークが検証するのはパラメーター数だけではない。カーネルの挙動、メモリアクセス、シーケンス長、ランタイム構成、プロセッサ特性はすべて、測定されるレイテンシーに影響する。

この仕組みを通して説明されるLFM2.5エンコーダーは、アテンションベースモデルの万能な代替ではない。混在したシーケンス処理が、長文コンテキストのCPUワークロードにより適しているという主張である。

開発者は、実際の入力分布に対してベンチマークを行うべきだ。短いメッセージが大半を占めるシステムでは、法的合意書や長い文字起こしを処理するシステムとは異なるアーキテクチャ選択が有利になる可能性がある。

ファインチューニング後のパイプライン全体の所要時間も測定すべきです。トークナイゼーション、バッチ処理、出力ヘッド、後処理、データ転送は、モデル単体のフォワードパスで見られる優位性を変え得ます。

ベンチマークの品質は競争力があるが、証拠には限界がある

Liquid AIは信頼できる再現性パッケージを提示しているものの、その結果だけでCPU、ランタイム、特化タスク全般における本番性能が決着するわけではありません。

同社は、GLUE、SuperGLUE、多言語分類スイートから抽出した17タスクで14モデルを評価しました。各モデルには、各タスク向けの完全な教師ありファインチューニングが実施されました。

Liquid AIは、ホールドアウトした5つのランダムシードによる平均値を報告しています。複数のシードを用いることで、特に好条件だった学習実行が順位を左右するリスクを抑えられます。

同社の350Mエンコーダは、報告された17タスク平均81.02で4位に入りました。これを上回ったのはXLM-R XL、ModernBERT-large、XLM-R largeでした。

XLM-R XLは83.06で首位に立ち、35億パラメータを備えています。ModernBERT-largeは3億9,500万パラメータで81.68を記録しました。XLM-R largeは5億6,000万パラメータで81.34に達しました。

LFM2.5-Encoder-230Mは79.29で6位、ModernBERT-baseは78.19で7位でした。これらの平均値は、Liquid AIのエンコーダがその規模に対して競争力を維持しているという同社の主張を裏付けます。

ただし、すべてのタスクで一貫して優位であることを示すものではありません。ModernBERT-baseは複数の個別ベンチマークで230MのLFM2.5モデルを上回る一方、Liquid AIが優勢なものもありました。

集約された順位には、異なる評価タイプも混在しています。タスクには自然言語推論、言い換え検出、感情分析、意味的類似性、多言語分類が含まれます。

平均値は一般的な能力の比較に役立ちますが、特定の導入で重要となる指標を隠してしまう可能性があります。ポリシーシステムにとって重要なのは、無関係な感情分析タスクでの順位ではなく、偽陰性率とキャリブレーションです。

Liquid AIはevaluation harnessを公開しており、再現の機会を高めています。このリポジトリには、報告された比較に関連するダウンストリームのファインチューニングコードと設定が含まれています。

とはいえ、コードが公開されていることは独立した検証と同義ではありません。Liquid AIは学習手順、比較設定、集約方法、推論環境を選定しています。

CPUレイテンシーの主張には、最も大きな未解決の疑問が残ります。公開記事はシーケンス長と経過時間を説明していますが、テストしたCPU構成を明確には示していません。

この欠落は解釈に影響します。ノートPC向けプロセッサ、クラウドサーバーのCPU、メモリチャネル、命令セット、スレッド数、電力制限によって、挙動は大きく異なり得ます。

現在の読み込み手順ではtrust_remote_code=Trueも使用されており、リポジトリ提供のコードがTransformersライブラリを通じて実行されます。厳格なソフトウェア統制を持つ組織は、導入前にそのコードを確認する必要があります。

モデルカードには、成熟したONNXまたはOpenVINOのデプロイパスが提示されていません。これらのランタイムは、CPU推論、量子化、クロスプラットフォーム配信を最適化するチームにとって重要になることが多いものです。

量子化後の性能も未解決の論点です。公開された比較では、低精度変換後にLFM2.5がどのように振る舞うか、あるいは同じ相対的優位性が維持されるかは明らかになっていません。

このリリースには、持続的な同時実行性をカバーする本番環境の証拠もありません。長いシーケンスを1件処理することはレイテンシーを測定しますが、常時稼働の分類器にはスループット、テールレイテンシー、メモリ使用量、負荷下での安定性が必要です。

精度についても同じ注意が必要です。ベンチマークのファインチューニングは、組織固有の契約書、安全ルール、顧客の言語、プライバシーカテゴリでの性能を裏付けるものではありません。

LFM2.5とModernBERTを評価するチームは、同一ハードウェアと最適化済みの設定で両モデルを再現すべきです。実際のワークロードから、短い文書、中央値の文書、最悪ケースの文書をテストする必要があります。

評価には失敗コストも含めるべきです。現在のシステムが検出できる機密識別子を見逃すなら、より高速なPII検出器の価値はほとんどありません。ルーティングモデルも、リクエストを不適切な下流ツールへ送らないようにする必要があります。

こうした限界は、このリリースの価値を損なうものではありません。むしろ、有望なアーキテクチャ上の成果と導入判断との違いを明確にするものです。

Hugging Face開発者が次に注視すべきこと

このリリースが実用的なCPU標準となるのか、それとも興味深いベンダー・ベンチマークにとどまるのかは、3つのシグナルによって決まります。

1つ目のシグナルは、独立したハードウェアでの再現です。開発者には、開示されたスレッド数とメモリ構成の下で、Appleシリコン、主流のx86ノートPC、サーバープロセッサにまたがる結果が必要です。

再現では、8,192トークンのエンドポイント以上を測定すべきです。実際のデータセットにはさまざまな長さの文書が含まれるため、パーセンタイル別レイテンシーと1時間あたりの処理文書数の方が、運用面をより明確に示します。

独立テストでも大きな長文コンテキストの優位性が維持されれば、Liquid AIのアーキテクチャ上の主張は強まります。同等のランタイム最適化後に差が縮小するなら、見出しとなった性能差の多くは実装上の選択で説明される可能性が高いでしょう。

2つ目のシグナルは、最適化済みランタイムのサポートです。ONNXエクスポート、OpenVINO統合、安定した量子化レシピ、ネイティブライブラリのサポートがあれば、実験的なPython環境を超えてモデルを運用しやすくなります。

これらの追加は、このハイブリッドバックボーンが広く導入されたCPUツールチェーンに適しているかどうかも検証します。カスタムのeager executionに依存するモデルは、優れたベンチマーク結果があっても導入時の摩擦に直面する可能性があります。

8ビットまたはそれ以下の精度での導入が成功すれば、ローカル推論を支持する主張は強まります。許容範囲内のタスク精度を維持しながら、メモリを削減し、スループットを高められる可能性があります。

逆の結果は比較を弱めます。ModernBERTや他の確立されたエンコーダは成熟した最適化パスの恩恵を受けているため、生のアーキテクチャ速度が最良の導入済みシステムを保証するわけではありません。

3つ目のシグナルは、タスクレベルでの採用です。Hugging Faceのダウンロード数は初期の指標になりますが、公開されたファインチューニングと再現可能なケーススタディの方が重要です。

有用な証拠には、組織のルールで測定されたポリシーフィルター、現実的な識別子に対してテストされた多言語PIIシステム、持続的なアプリケーショントラフィック下で稼働するルーターなどが含まれます。

開発者は、偽陽性率、偽陰性率、キャリブレーション、メモリ使用量、テールレイテンシーを確認すべきです。これらの指標は、モデルがリーダーボード上の順位ではなく、システム自体を改善しているかを明らかにします。

Liquid AIのファインチューニング例は、チームに分類の出発点を提供します。次の段階は、アーキテクチャを設計していないユーザーからの証拠です。

競合他社の対応も、これらのシグナルの中で別の手掛かりとなります。ModernBERTの実装は最適化されたカーネルを得る可能性があり、他の長文コンテキスト向けエンコーダもハイブリッド処理やスパース処理を採用できるでしょう。

生成モデルのベンダーにも、より安価な分類エンドポイントで対応する余地があります。しかしリモートサービスは、オンデバイスのエンコーダが回避できるデータ転送、接続性、ローカル制御上の制約に依然として直面します。

ナレッジワーカーにとって、この開発はローカルでの文書整理をより高速かつプライベートにする可能性があります。契約書、議事録、ノート、サポート履歴は、テキストが管理された環境を出る前に分類できます。

エンタープライズの購買担当者にとって、このリリースは調達上の問いをより明確にします。各言語タスクに生成的推論は必要なのか、それとも特化型エンコーダがより低いインフラ需要で必要な判断を提供できるのか、という問いです。

開発者にとって、正しい対応は測定です。代表性のあるテストセットを構築し、精度の閾値を定義し、入力長の分布を記録し、導入先ハードウェア上で完全なパイプラインを比較してください。

LFM2.5の両バリアントと関連資料が1か所で利用できるため、Hugging Faceはその実験を行いやすくしています。ただし、利用しやすさが検証の代わりになるべきではありません。

Liquid AIは明確な技術的提案を示しました。アーキテクチャが反復的なフルアテンション処理を抑制できれば、長文コンテキストの理解はCPU上にとどめられるという提案です。そのベンチマークは、この提案に対する信頼できる初期の裏付けを与えています。

未解決の問題は、すべてのモデルに同等の最適化を施した後でも、独立した導入環境がその優位性を再現できるかどうかです。この問いが、次のテスト、ファインチューニング、本番レポートの波を導くべきです。

チームが長い文書を継続的に処理しているなら、LFM2.5を現在のワークロードで使っているエンコーダと比較してください。実際の文書、開示されたハードウェア、タスク固有のエラー指標を使用します。

最も重要な成果は、もう1つの平均ベンチマークスコアではありません。小規模なエンコーダが完全な作業コンテキストを調べ、精度要件を満たし、データが存在する場所で予測可能に動作できることを示す証拠です。