Hugging FaceがAIモデルライブラリの新バージョンに、文書の文字認識、音声合成、テキスト生成モデルへの対応を追加した。文書処理や音声サービスを開発する際、入力の準備から結果の生成まで、ライブラリが提供する方法で接続できる。リリースノート

1. 文書画像認識にMiniCPM-OCRを追加

OpenBMBのMiniCPM-OCRは、スキャン文書、スクリーンショット、レシート、表など、文字の多い画像を読み取る。画像から抽出した視覚情報を言語モデルに渡す構造で、文字認識とページのMarkdown変換を要求できる。モデルのドキュメント

デフォルトのチャットテンプレートは、モデルがページを解釈する思考過程を先に出力する構成だ。認識結果だけを受け取りたい場合は、入力の準備時に思考過程の出力を無効にできる。使用例

視覚情報の縮小方式は4倍と16倍の2種類だ。デフォルトの4倍は、文書や画面の文字認識に必要な視覚トークンを多く残す。16倍は自然画像を強く縮小してトークン数を減らし、推論を速める選択肢だ。ドキュメントの同じページの例では、4倍で1260個、16倍で315個のトークンを使った。4倍を基準に視覚トークンが75%減ったのであり、実際の処理時間やメモリが75%減ったという測定値ではない。設定はプロセッサーと生成呼び出しの両方に渡す。縮小モードとコード原文

inputs = processor.apply_chat_template(
    messages, add_generation_prompt=True, tokenize=True,
    return_dict=True, return_tensors="pt",
    processor_kwargs={"downsample_mode": "4x"},
).to(model.device, dtype=model.dtype)

output = model.generate(**inputs, max_new_tokens=512, downsample_mode="4x")
print((inputs["input_ids"] == model.config.image_token_id).sum().item())
# 1260 visual tokens; the same page in `"16x"` mode is 315 instead

表：同じ文書ページの縮小モード別視覚トークン数

条件：MiniCPM-OCR-1.0、同じ文書ページ1枚、縮小モードをプロセッサーと生成呼び出しの両方に指定したドキュメントの例

単位：視覚トークン数

文書画像認識にMiniCPM-OCRを追加
縮小モード視覚トークン数
4倍（デフォルト・基準値）1260
16倍315

チャート：同じページの視覚トークン数（0個を起点とし、4倍モードの1260個を比較基準とする）

4倍  ████████████████████ 1260
16倍 █████                315

表・チャート原文

小さい画像を拡大するかどうかも選べる。以下は同じレシートを処理したドキュメントの例で、デフォルト方式は学習時のサイズまで拡大し、原寸維持方式は画像を小区画に分けるパッチグリッドにだけ合わせる。小さい画像の処理例

表：小さいレシート画像の拡大方式別処理グリッド

条件：MiniCPM-OCR-1.0プロセッサー、原文のレシート画像を224×224に調整した入力、ドキュメントの出力例

単位：パッチ数

文書画像認識にMiniCPM-OCRを追加
拡大方式グリッドの一辺
常に拡大（デフォルト）32
原寸維持16
文字密度に応じて決定32

適応型方式も、このレシートでは文字が密集していると判断して拡大した。小さいスクリーンショットを扱う際は、元の解像度を維持する選択肢も検討したい。小さい画像の処理例

2. 音声合成は録音と保存済みの声から開始

KyutaiのPocket TTSは、パラメーター数1億の音声合成モデルだ。Hugging Faceの発表によると、CPUで音声の再生時間より短い時間で結果を生成する。モデル概要

モデルは音を圧縮して表現した潜在値を毎秒12.5回生成し、プロセッサーがこれを24kHzの音声波形に復元する。音声変換の構造

声は録音を複製するか、事前計算した潜在値や音声プロンプトを処理済みのキャッシュで指定する。標準提供の声もキャッシュに格納されており、毎回再エンコードする必要はない。同じ声で複数の文を読み上げるサービスなら、この再利用経路を活用できる。声の指定方法

長い文はプロセッサーで分割して処理できる。生成長のデフォルトの上限はテキスト長に応じて決まり、モデルが発話の終了を判断すると生成を止める。使用のヒント

3. Flintは入力ごとに一部のエキスパートを選択

RecursiveのFlintは、入力ごとに一部のエキスパートモジュールを選んで計算する混合エキスパート言語モデルだ。エキスパートを選択する各層では、256個中6個と共有エキスパートを使用する。モデル構造

大部分の層では現在のトークンと先行する512個のトークンを参照し、残りの層では入力全体を見る方式を組み合わせる。注意の範囲

リリースに掲載された同社の発表は、Flintの重みを異なる数値形式のBF16とNVFP4で保存したチェックポイントを比較している。チェックポイントはモデルの重みを保存した実行用ファイルだ。コード修正能力を評価するSWE-bench Pro v2のスコアはBF16が89.7%、NVFP4が88.5%で、BF16を基準に1.2%ポイントの差だ。これは評価スコアの差であり、処理時間改善やメモリ削減の実測値ではない。同社は類似ハードウェアで動くモデルを比較対象とし、この評価項目は内部測定と明記した。ベンチマーク原文

同じ評価でQwen 3.8は94.9%、Qwen 3.6は73.8%だ。Flintの両形式とも、この比較ではQwen 3.8より低く、Qwen 3.6より高い。比較図

表：SWE-bench Pro v2のモデル・重み形式別スコア

条件：同社の発表図、類似ハードウェアで動くモデルの比較、該当評価に内部測定（†）の表示

単位：スコア（%、高いほど良い）

Flintは入力ごとに一部のエキスパートを選択
モデル・形式スコア
Flint BF16（形式比較の基準値）89.7
Flint NVFP488.5
Qwen 3.894.9
Qwen 3.673.8

チャート：SWE-bench Pro v2スコア（0%を起点とする、0~100%範囲の概算バー）

Flint BF16  ██████████████████  89.7%
Flint NVFP4 ██████████████████  88.5%
Qwen 3.8    ███████████████████ 94.9%
Qwen 3.6    ███████████████     73.8%

表・チャート原文

デフォルトの実行は、注意分布の基準となる学習済み補正値のアテンションシンクを反映し、スコアを32ビット浮動小数点で計算する。注意計算の実装であるSDPAはシンクを処理できないため、ドキュメントは長い入力にシンク対応の別のアテンションカーネルを使うよう案内している。実行時の注意事項

4. デバイス分割の変更とユーザーの確認事項

モデルの計算を複数のデバイスに分けるテンソル並列化では、入力をベクトルに変換する埋め込みもデフォルトで分割する。専用の方式が追加され、幅が並列数で割り切れなくても対応する。従来の列・行ベースの方式を埋め込みに適用したカスタムプランは、新方式へ移行する必要がある。並列化プランの変更

混合エキスパートモデルの並列化プランも、エキスパートをデバイスごとに分けるよう変更された。各デバイスが全エキスパートを重複して保持しないためメモリの浪費を減らせる一方、カスタムプランにもエキスパート分割を反映する必要がある。並列処理の標準経路は整理されるが、直接構成していたチームには設定の移行作業が生じる。エキスパート分割の変更

アップグレード環境を準備する際は、Pythonの最小サポートバージョンが3.11に上がった点も確認したい。サポートバージョンの変更

5.21.0は、OCR・音声合成・混合エキスパートモデルを標準のTransformers経路に拡張すると同時に、既存の並列設定の確認を求めるリリースだ。