Tencent発!295Bの推論特化MoEモデル「Hy3」
最近、インフラエンジニアの同僚たちと話すと、決まって「LLMの推論コストをどう叩くか」という泥臭い話題に行き着く。いくらベンチマークで人間超えを達成しようが、GPUリソースを湯水のように食らい尽くすモデルを実プロダクトの裏側で動かし続けることは、ビジネスとして成立しないからだ。
「デカくて賢い」は、もはや当たり前。「巨大な知識を持ちながら、いかに燃費良く動くか」が現在のLLM開発における最大の主戦場になっている。そんな中、TencentのHunyuanチームから非常に興味深い一手が投じられた。「Hy3-preview」である。
MoEの極北を攻める21Bのアクティブパラメータ
昨今の軽量化トレンドにおいて、MoE(Mixture-of-Experts)アーキテクチャの採用自体は珍しくない。しかし、Hy3が提示したパラメータのバランスはなかなかに攻めている。総パラメータは295Bと堂々たるサイズだが、推論時に実際に動くアクティブパラメータはわずか21Bに抑えられているのだ。
中国発のトップティアモデルたちとベースモデルの構成を比較してみよう。
| モデル | 総パラメータ数 | アクティブパラメータ数 |
|---|---|---|
| Hy3 preview-Base | 295B | 21B |
| DeepSeek-V3 BASE | 671B | 37B |
| Kimi-K2 BASE | 1043B | 32B |
| GLM-4.5 BASE | 355B | 32B |
表を見れば一目瞭然だ。DeepSeek-V3やKimi-K2といった名だたる強力なモデル群と比べても、Hy3のアクティブパラメータの少なさは群を抜いている。192個もの専門家(Expert)ネットワークを内部に抱えながら、一度の推論で叩き起こすのは上位8つのみ。この極端なスパース性が、APIとしての運用や自社インフラへのデプロイにおける圧倒的なコスト競争力を生み出す。
さらに見逃せないのが、3.8BのMTP(Multi-Token Prediction)レイヤーを搭載している点だ。次の1トークンだけでなく、先のトークンまで並行して予測することで生成速度を劇的に引き上げるこのアプローチは、次世代LLMのデファクトスタンダードになる匂いが色濃く漂っている。
「賢いチャットボット」から「自律するAgent」への舵切り
極限まで軽くした分、能力が犠牲になっているかといえばそうではない。むしろTencentは、このモデルを徹底して「推論(Reasoning)」と「Agent」のタスクに特化させて鍛え上げている。
READMEの端々から透けて見えるのは、実ビジネスの現場における強い課題感だ。彼らは既存の一般的なベンチマークに満足せず、自社の実際のビジネスシナリオから抽出した「CL-bench」という独自のコンテキスト学習用評価指標まで構築している。現実の業務で直面する「乱雑で長大なドキュメント」や「複雑に絡み合ったルール」を正確に読み解けなければ、真のAgentにはなり得ないからだ。256Kというロングコンテキスト対応も、この思想を裏付けている。
また、強化学習(RL)のインフラを根本から再構築したという記述も生々しい。より大規模な訓練タスクを回せるようになった結果、SWE-bench Verifiedなどのコーディング領域や、検索Agentのベンチマークにおいて、劇的なスコア向上を見せている。もはやモデル単体での対話能力ではなく、外部ツールを叩き、コードを書き、自律的に思考する「システムの中核」としての役割を完璧に見据えている。
冷徹なまでの実用主義
vLLMやSGLangでのデプロイが初日からサポートされていることからも、Tencentがこのモデルを「研究室のトロフィー」ではなく「現場の即戦力」として位置づけていることがわかる。
単なるパラメータ数の暴力から脱却し、いかに安く、いかに実務で自律的に動かすか。巨大テック企業の実利的な冷徹さが詰まったアーキテクチャだ。「安くて賢いAI」を巡る果てしないチキンレースは、いよいよ面白くなってきた。
参考リポジトリ: Tencent-Hunyuan/Hy3-preview
Photo by Igor Omilaev on Unsplash