Hugging Faceのモデル実行ライブラリに、テキスト・画像・音声・動画をまとめて入力できるMetaのモデルと、外部コードを許可せずに読み込めるInclusionAIのモデルが追加された。モデルをサービスに組み込む開発者は、入力の種類を広げたり、個別のモデル実装に依存していた読み込み手順を減らしたりできる。

1. 入力の拡張と読み込みの統合は別の変化だ

2026年10月15日に公開されたTransformers v5.20.0のリリースノートは、2つのモデルへの対応を新機能として紹介している。これはライブラリでモデルを読み込んで使う経路が追加されたという意味であり、両モデルの速度がともに改善されたという発表ではない。

MetaのMuse Spark Openは、4種類の入力を受け取りテキストを生成する。複数ファイルの修正、デバッグ、ツール呼び出しなどのコーディング作業向けに学習された。例えば、コードとともにスクリーンショットや画面録画を入力する作業に使える。

InclusionAIのLing 3.0 Flashは、入力の断片ごとに複数の計算ネットワークから一部を選んで使う混合エキスパート言語モデルだ。今回の変更の要点は、外部リポジトリのモデルコードを実行するための信頼設定を有効にせず、ライブラリに含まれる実装で読み込めることだ。

2. Lingは読み込みと最適化を分けて確認する

文書が示すモデルクラスはBailingHybridForCausalLMだ。使用例は、AutoModelForCausalLMで保存済みモデルを読み込み、対話形式で入力を作ってから回答を生成する流れになっている。

モデル内部の一部の計算には、PyTorchだけで動作する代替実装が含まれている。別途最適化パッケージを用意しなくても、その計算を実行できるようにした経路だ。

flash-linear-attentionとcausal-conv1dをインストールすると、NVIDIAのGPU向けCUDA環境で最適化された計算コードが自動的に使われる。これは任意の最適化経路であり、モデルを読み込むための必須手順ではない。

3. Museは入力の準備も統合する

MuseSparkProcessorは、テキストをモデルの入力単位であるトークンに分割する処理と、画像・動画・音声の前処理、対話形式への変換をまとめる。開発者は異なる入力を対話形式で準備し、モデルに渡せる。

コンテキストウィンドウは、モデルが一度に扱える入力の範囲で、最大1,048,576トークンだ。テキストだけでなく画像・動画・音声から作られたトークンもこの範囲を共有するため、この数値をテキスト専用の空き容量として計算してはいけない。

ブログによると、動画からはデフォルトで毎秒2フレーム、最大96フレームを抽出する。残すフレームを増やすと出来事の間の情報を見逃しにくくなるが、メモリ使用量と、回答生成前に入力を処理する時間も増える。

4. 計算量の削減は少ないメモリを意味しない

Museは各層の256個のエキスパートから8個を選び、全体の8160億パラメータのうちトークン当たり420億個をアクティブにする。パラメータは学習によって決まるモデルの数値だ。

この構造の利点は一部の計算ネットワークだけを実行することにあるが、展開時のメモリはモデル全体の規模をまかなう必要がある。ブログはBF16の重みファイルが約1.5TBと説明している。入力処理のインターフェースが統合されても、大規模モデルを動かす機器の負担までなくなるわけではない。

以前の入力の計算結果を保持するキャッシュも別途考慮する必要がある。ブログのBF16基準の計算ではトークン当たり約250KBで、最大コンテキストを埋めると約266GBになる。これは重みファイルのサイズとは別のコストだ。

5. 低精度の重みと並列実行は別途点検する

NVFP4は、重みを低精度で保存してメモリ要件を減らす形式だ。ただし、モデル開発文書は対応デバイスと別途インストール用のブランチを要求している。文書のインストール例は次のとおりだ。

pip install git+https://github.com/huggingface/transformers.git@finegrained-per-scheme-demo

リリースノートは、エキスパートを複数のデバイスに分けて実行するエキスパート並列推論で速度低下があると警告している。低下幅と測定条件は示されていない。この経路を使って展開する場合、実際の作業でレイテンシを確認する必要がある。

今回の対応の価値は入力処理とモデル読み込みの統合にあり、導入の判断では対応の有無と実際の展開リソースを分けて考える必要がある。