Hy-SimulMT 対 NLLB-200：ストリーミング通訳は200言語翻訳機ではない

2つのベンチマーク名は1文字だけ異なり、その1文字が記事のすべてだ。 Hy-SimulMTは、Tencent Hunyuanが2026年10月26日に公開した中国語↔英語のリアルタイム通訳モデルで、FLEURSと呼ばれるベンチマークで90.3というスコアを公表している。 NLLB-200は、Meta AIが2022年7月に発表した200言語対応のテキスト翻訳モデルで、FLORES-200と呼ばれるもので評価されている。両者は関連している——FLEURSはFLORESの文を音読して作られている——が、同じテストではなく、同じ方法で採点されるものでもなく、この2つのモデルを互いに競わせた人はこれまで誰もいない。この対決を検索しても、一方のモデルの発表報道と他方のドキュメントが出てくるだけで、その間には何もない。この不在こそが正直な出発点だ。両者は競合相手ではなく、有用な問いは、それぞれが実際にどの仕事に向いているのかということである。

1文字、2つのベンチマーク

FLORES-200はテキストのベンチマークです。Metaは「No Language Left Behind」プロジェクトの一環としてこれを構築しました。200言語にわたる専門的に翻訳された文で構成され、翻訳システムが書かれたテキストをある言語から別の言語へどれだけうまく移せるかを測るために使われます。主要な指標はspBLEUで、固定された言語バランスの取れたトークナイザー上で計算されるBLEUの変種であり、異なる文字体系を使う言語間でもスコアを比較できるようにしています。NLLBの論文ではchrF++と、XSTSと呼ばれる人手評価も報告されています。

FLEURSは音声版の兄弟です。FLORESの文セットを取り、母語話者にそれを音読してもらい、音声翻訳を評価します——音声入力、テキスト出力です。対象言語は200ではなく102です。TencentがHy-SimulMTについてFLEURSで90.3を報告するとき、その数値にはパイプライン全体が含まれます。音声を聞き取り、単語を認識し、それを翻訳するまでです。MetaがNLLB-200についてFLORES-200でspBLEUを報告するとき、テキストはすでに正しくトークン化されており、測定されているのは翻訳ステップだけです。

その2つの数値を並べても、2つのモデルを比較したことにはならない。あなたが比較したのは、異なるデータ、異なる評価指標、異なる言語における、エンドツーエンド音声システムとテキスト翻訳器だ。これが一文字類似度が招く誤りであり、この記事における他のどの比較よりも先に名指しする価値がある。

NLLB-200とは実際に何なのか、4年を経て

NLLB-200は2022年7月にリリースされ、それ以降改訂されていません。今日ダウンロードするチェックポイントは2022年のチェックポイントです。これは批判ではありません——これは、これがどのような種類の成果物なのかについての説明です。ベンチマークとデータセットを定義し、そこで止まった研究リリースなのです。

このファミリーは5つのサイズを展開しており、その幅広さこそがポイントです：

• NLLB-200-distilled-600M — 実用的な最小のチェックポイントで、ラップトップクラスのGPUでも扱えるほど小さいです。

• NLLB-200-distilled-1.3BとNLLB-200-1.3B — 中規模のペアで、一方は速度のために蒸留され、もう一方は直接トレーニングされています。

• NLLB-200-3.3B — 高密度な主力モデルで、実際に多くの人がデプロイするサイズです。

• NLLB-200-54.5B — フラッグシップとなるスパースモデル：128個のエキスパートとトップ2ゲーティングを備え、4つおきのトランスフォーマーブロックに混合エキスパート層を配置し、トークンあたりの計算量は3.3Bの密モデルとほぼ同等です。同世代で最大のオープン翻訳モデルであり、今なおこのファミリーが引用される理由となっています。

学習セットは約180億の並列文ペアで、論文の主要な主張は、4万以上の翻訳方向で測定したところ、従来の最先端手法と比べてBLEUが44%改善したというものだった。アーキテクチャは、単文翻訳向けに構築されたエンコーダ・デコーダ型Transformerである。ストリーミングモードはなく、音声入力もなく、部分出力という概念もない。文を受け取り、文を返す。

ライセンスはCC-BY-NC 4.0で、モデルカードはその意図について率直に述べている。本番環境への配備向けに公開されたものではなく、ドメイン固有の用途、文書全体にわたる長さ、長文入力、認定翻訳を対象としたものでもない。重みの周辺のコードはMITだが、重み自体はMITではない。これが、このリリースに4年間つきまとってきた混乱である。

今週時点で、Hy-SimulMT が実際に何なのか

Hy-SimulMTは、ほぼあらゆる次元で正反対の形をした成果物です。これは音声モデルであり、音声は16 kHzで30秒のウィンドウ単位でストリーミング入力され、話者がまだ話している間にモデルが翻訳テキストを出力します。アーキテクチャは、トークンあたり約30億パラメータがアクティブになる304億パラメータの疎な混合エキスパートで、24層の音声エンコーダを取り囲んでいます。文書化されている言語ペアは中国語と英語で、双方向です。

その中心的な主張はカバレッジではなくレイテンシだ。Tencentは、長尺のRealSI音声で約3秒のStreamLAALを報告しており、比較したシステムの中で最も低いと述べている。これはNLLB論文のどの主張とも種類が異なる。同論文には測定すべきものが何もないため、レイテンシ測定が一切ない。バッチ型テキスト翻訳器には話者に対する遅れが存在しないからだ。

リリースはApache-2.0でゲートなし、6つのチェックポイントが2種類の出力形式（翻訳のみと原文＋翻訳）をカバーし、それぞれフル精度、FP8、GGUFで提供されます。フル精度ビルドは約61 GB、GGUF Q4_K_Mビルドは19.7 GBです。音声出力とボイスクローニングには別途TTSサービスが必要で、モデル自体はテキストを生成します。

そしてNLLB-200と同様、ホスト型APIも公開価格もありません。テンセントの消費者向け窓口はHy Translateアプリで、無料枠があります。それ以外はすべて、モデルの重みを実行することを意味します。

スコアが同じ列を共有できない理由

Hy-SimulMTの4つのスコアを、手近にあるNLLB-200の数値と並べて比べたくなる。しかし、それに抗うべきだ。FLEURS/FLORESの違いだけが理由ではない。この2つのモデルは、異なる問いを投げかけられているのだ。

• 入力モダリティ — Hy-SimulMTは音声を受け取るため、そのスコアには認識誤差が含まれます。NLLB-200は認識誤差がすでに取り除かれたテキストを受け取ります。同じ文に対する音声モデルとテキストモデルは、同じスタートラインに立っているわけではありません。

• 指標 — Hy-SimulMT は音声翻訳セットで BLEU 系のスコアを報告し、NLLB-200 は FLORES-200 で spBLEU、chrF++、XSTS を報告します。spBLEU のトークナイザーは、言語間の比較を公平にするために特に存在しており、そのため、どちらも BLEU と呼ばれていても、単なる BLEU の数値と互換性があるわけではありません。

• 作業単位 — NLLB-200は整列済みテキスト上で文単位に評価される。Hy-SimulMTはストリーミング音声上で評価され、そこでの興味深い失敗は、誤訳された単語ではなく、役に立つには遅すぎて届く文である。

• 方向数 — NLLB-200の4万以上もの翻訳方向は、その代表スコアに平均化されている一方、Hy-SimulMTの4つのベンチマークは中国語↔英語のみを対象としている。ロングテール全体の平均と、1つの高リソース言語ペアでのスコアは、異なる種類の成果を表している。

Hy-SimulMTは、自社の比較表の中でも一様にリードしているわけではない。CoVoST2では75.5で、Qwen3.8-LiveTranslateの82.1に及ばない。また、FLEURS（90.3対92.4）とACL6060（81.2対82.6）ではGemini3.5-LiveTranslateに後れを取っている。最も明確な勝利はRealSI-Sentenceの84.7だ。これらの数値はすべてベンダーが実施したもので、Tencentが選んだハーネス上で得られたものであり、独立に再現されたものではない。モデルカードには、2つの出力バリアントのどちらがこれらの数値を出したのかも記載されていない。

レイテンシは、NLLBには存在しない単位で測定されます。

これはデプロイを左右する部分であり、ベンチマークスコアとは一切関係ありません。

同時通訳者は、バッチ翻訳者には決してないトレードオフを迫られる。より長く待ってより良く翻訳するか、より早く話して間違うリスクを取るかだ。StreamLAALはそのトレードオフを測る——おおよそ、出力が平均して入力よりどれだけ遅れるかを。Hy-SimulMTの3秒は、そのトレードオフに関する主張だ。それは明示的に最初の音声出力までの時間と同じではない、とTencentはモデルカードで述べている。外部のTTSサービスを追加すると、聴取者の体験にはそのサービスのレイテンシも含まれるが、3秒という数字にはそれが含まれていない。

NLLB-200にはストリーミング経路がないため、同等の数値は存在しません。後付けすることはできます。音声を分割し、音声認識を実行し、文の断片をNLLBに渡し、完成した翻訳を随時出力するのです。そのアーキテクチャは機能し、実際に構築したチームもあります。しかし分割は、文単位の翻訳器が依存する文脈を破壊し、結果として得られる品質は、完全で整った文を用いてFLORES-200で測定される品質ではありません。「NLLB-200はFLORESでXを記録する」と「分割されたライブパイプライン内のNLLB-200はYのように聞こえる」の間のギャップこそ、実際のエンジニアリング作業の大半が費やされる場所です。

これが本当の非対称性だ。Hy-SimulMTはストリーミングのケース向けに設計され、その代償として言語カバレッジと30Bクラスのフットプリントを犠牲にしている。NLLB-200は広範さ向けに設計され、その代償としてバッチ専用インターフェースを抱えている。どちらも劣っているわけではない。両者は異なる制約に最適化されている。

深度に対するカバレッジ

NLLB-200 の揺るぎない強みはロングテールにある。200 言語を備え、その中には 2026 年のほとんどのモデルがまったく扱えない低リソース言語も含まれ、600M のチェックポイントから 54.5B の Mixture of Experts までスケールするファミリーを成している。話者数が数百万程度の言語で書かれた文書を扱う必要があり、それをカバーする商用 API が存在しないなら、NLLB-200 は依然として数少ないオープンな選択肢の一つであり、3.3B の dense チェックポイントは手頃な GPU 1 台で動作する。

Hy-SimulMTはその役割をまったく果たせません。ドキュメント化されているのは中国語と英語のみです。Hugging Faceのメタデータには36言語のタグが付いていますが、残り34言語のリストは公開されておらず、リポジトリ内のすべての例がen-zhまたはzh-enを使用しています。そのタグだけを根拠に多言語展開を計画するのは誤りです。

ハードウェア面の計算は逆になる。NLLB-200の3.3B密モデルはFP16で数GBであり、16～24 GBのカードに余裕で収まる。その54.5BのフラッグシップはFP16で約108 GBであり、マルチGPU構成が前提となる。Hy-SimulMTはBF16で約61 GBで、出荷時のまま提供するには80 GBのアクセラレータが必要だが、llama.cppのサポートがまだ本家に取り込まれていないGGUF経路を使えばQ4_K_Mで19.7 GBになる。したがってNLLB-200は小規模側で安く、最上位では同程度だ。Hy-SimulMTのコストは中間に集中しており、その代わりにストリーミングを手に入れる。

ライセンスは互いに反対方向を指している

これは比較の主軸ではない——主軸はモダリティだ——が、商用製品向けにそのどちらか一方を失格させるには最速の方法ではある。

NLLB-200の重みはCC-BY-NC 4.0です。非商用です。周辺のコードはMITで、混乱はそこから来ていますが、実際に提供するのは重みであり、Metaのカードにはモデルが本番環境への導入向けに公開されていないことが明記されています。商用導入には別のモデルかライセンス契約が必要です。

Hy-SimulMTはApache-2.0で、ゲートなし、商用利用、改変、再配布が許可されています。Tencentは推論サーバーと併せてトレーニングツールキットを提供しているため、継続的なトレーニングは想定された用途です。ライセンスだけの二択であれば、差は歴然としています。

同じスタック内でそれらが属する場所

この対戦（比較）が検索され続ける理由は、チームが同じ製品で両方の問題に直面するからだ。中国語と英語の拠点を持つ企業には、会議用のライブ通訳者と、メール・契約書・サポートチケットで届く200言語の文書トラフィックを処理するテキストパイプラインの両方が必要になる。これは二つの別の仕事であり、誠実なアーキテクチャは二つの別のモデルを使う。

NLLB-200、あるいはその現代的な後継モデルは、オフラインのテキスト経路を担う。すなわち、バッチ翻訳、言語識別、コーパスのトリアージ、ロングテールである。Hy-SimulMTは、ライブの中国語↔英語音声経路を担う。そこではレイテンシが支配的であり、室内に2言語しかないためカバレッジは問題にならない。両者の境界はルーティング判断であり、アプリケーションにファイル種別から推測させるのではなく、明示的に述べておく価値がある。

どちらのモデルもOrcaRouterのカタログには含まれていないため、当社はどちらへの経路でもありません。ルーターが提供するのは、それらを囲む継ぎ目です：200以上のホスト型モデルの前に置かれた、マークアップ0%の単一API、プロバイダーの定価を何も上乗せせずにそのまま通し、そしてリクエストがどの経路をたどるかを決めるルーティングDSL。後者は地味で役に立つものです — テキストリクエストはホスト型の汎用モデルに流れ、音声リクエストはお客様のセルフホスト型インタープリターに送られ、アプリケーションはどちらがどちらかを知る必要がありません。自動フェイルオーバーは、ホスト型の経路が利用できず、それでもリクエストが何かを返さなければならない場合をカバーします。

ホスト型の部分はプロバイダーの定価で何も上乗せせずに価格設定されているため、テキスト側でベンダーが値下げすると、その当日に当社側でも反映されます。これは些細なことですが、大量のドキュメントトラフィックをルーティングするようになると話は別で、そうでなければプロバイダーが料金表を変更するたびに契約を再交渉することになります。

どちらを選ぶ前に何を尋ねるべきか

問題はどちらのモデルが優れているかではない。それは二つの問いであり、それぞれ答えは異なる。

入力がまだ到着中の音声で、言語が中国語と英語なら、答えはHy-SimulMTであり、導入上の問いはその6つのチェックポイントのどれを使うかになる。これは品質ではなく、出力形状と精度に関する判断だ。入力がまだ特定していない言語のテキストで、低資源言語を含む集合にまたがる場合、NLLB-200は4年経った今でも妥当なオープンベースラインであり続ける。ただし非商用ライセンスが適合し、バッチインターフェースを受け入れることが条件だ。

誰も公表していないのは、その橋渡しだ。音声認識が中国語↔英語の音声でNLLB-200に供給し、Hy-SimulMTと同じストリーミングベンチマークで評価され、レイテンシと品質が併記される。その実験なら、2026年のストリーミングハーネスに包んだ2022年のテキスト翻訳器が、専用設計の通訳器と競争できるかが分かる。それはまた、これら2つのモデルの初めての誠実な比較にもなるが、まだ存在しない。

最後に、はっきり言っておく価値があることが一つある。一文字違いのベンチマーク名の類似性が、これからも誤った比較を生み続けるからだ。FLEURSで勝つモデルは、特定の評価ハーネスの下での音声翻訳について何かを示したにすぎない。FLORES-200で高いスコアを出すモデルは、200言語にわたるテキスト翻訳について何かを示したにすぎない。どちらの結果も他方のタスクには当てはまらない。そして、同じ音声、同じ指標、同じレイテンシ計上で両方を公開するベンダーが、初めてこの比較を意味のあるものにするだろう。