Tencent Hy4とは？770B/49B MoEの性能や料金、GLM-5.3・Kimi K3との違いを解説

Tencent Hy4（テンセント・ハイフォー）は、Tencentによれば同社のフロンティア級モデルとして初めて自らの訓練最適化と推論チューニングに参加したオープンMoEモデルです。
テンセント混元チームが2026年8月28日に、770B総パラメータ／49BアクティブのMoE構成でHugging Faceに公開し、Apache 2.0でモデルウェイトを配布しました。

本記事では、Hy4の自己改善ループの中身、770B/49B MoEのアーキテクチャ、公開ベンチマーク、料金体系、API・OpenRouter・セルフホスティングの使い方、GLM-5.3/Kimi K3/DeepSeek V4-Proとの使い分け、既知の制約までを2026年8月時点の公式ドキュメントと発表内容で整理します。

Tencent Hy4とは？モデル自身が訓練最適化に関わったオープンMoE

Tencent Hy4 preview のブランドキービジュアル（出典：Tencent）

Tencent Hy4（テンセント・ハイフォー）とは、Tencentによれば同社のフロンティア級モデルとして初めて、モデル自身が自らの訓練最適化と推論チューニングに参加したオープンMoEモデルです。

正式名称は「Tencent Hy4 preview」で、テンセントの混元（Hunyuan）チームが2026年8月28日に、770B総パラメータ／49BアクティブのMoE構成でHugging Face公式リポジトリにApache 2.0ライセンスで公開しました。

Hy4が他のオープンMoEと根本的に違うのは、「モデル自身が自らの訓練方法・データ戦略・評価フレームワーク・低レベル演算子の自動最適化に参加した」とテンセントが公式に明言している点です。

さらに推論システムのボトルネックをモデル自身が自律分析し、演算子融合や通信最適化を複数回にわたって施した結果、ベースライン比でエンドツーエンド31.8%のスループット向上を実測したと公式発表で報告されています。

Hy4の「再帰的自己改善ループ」——訓練・推論の自己最適化

Hy4の技術的な独自性は、単なるパラメータ数や新アーキテクチャではなく、モデル自身が自らの開発工程に関与した点にあります。

テンセントはこれを「early-stage recursive self-improvement loop（初期段階の再帰的自己改善ループ）」と呼び、Hy4 preview発表の主軸メッセージに据えています。ここではその中身を、担当領域・実測効果・業界インパクトの3層で分解します。

モデルが担った4領域——訓練方法・データ戦略・評価FW・低レベル演算子

テンセント公式発表によれば、Hy4は次の4領域で自らの開発工程に関与しました。

• 訓練方法（training methods）の自動最適化
  訓練手続きの改善案をモデル自身が提案し、実験を実行して結果を反復する。
  
  

• データ戦略（data strategies）の自動最適化
  どのデータをどう扱うかの戦略設計をモデルが担い、提案・実験・反復を通じて改善する。
  
  

• 評価フレームワーク（evaluation frameworks）の自動最適化
  評価パイプラインの改善もモデル自身が対象として、提案・実験・反復を回す。
  
  

• 低レベル演算子（low-level operators）の自動最適化
  実装層のオペレータについても、モデルによる提案と実験の反復対象になっている。

4領域すべてで、モデルが提案 → 実験を実行 → 結果を反復する、というループを回した点が新しい部分です。ループから得られたコード・ログ・フィードバックがそのまま次の訓練ラウンドに戻る設計で、テンセントはこれを「recursive（再帰的）」と表現しています。

推論スタックの31.8%スループット改善——演算子融合と通信最適化

自己改善ループの成果として最も具体的な数値が、推論スタックのエンドツーエンド31.8%スループット向上です。

Hy4は自らの推論システムのボトルネックを解析し、演算子融合（複数のGPUカーネルを1つに統合してメモリ帯域を節約する最適化）と通信最適化を複数回にわたって施しました。

以下の表で、この31.8%改善の性質を整理しました。

この数値は「軽微なチューニング」の範疇を超えており、モデル自身が推論スタックの高速化に有意な貢献を果たしたことを示しています。

同一モデルウェイトでもインフラ最適化が効くと31.8%変わるという事実は、後段の「セルフホスティング」セクションで扱う自社デプロイ時のコスト計算にも直結する重要な数値です。

モデルが自己改善に関わる意味

recursive self-improvement（再帰的自己改善）という概念自体は、AI安全性研究では長年議論されてきたテーマです。

Tencentは、Hy4がこの再帰的自己改善ループを同社モデルとして初めて限定的に運用した事例と説明しています。

実務側から見た意味は、次の3点に集約されます。

• 開発サイクルの短縮
  人間の研究者だけが担っていた「実験計画→検証→反復」の一部をモデル自身が回すことで、新モデル世代の開発速度が上がる可能性
• アーキテクチャ探索の民主化
  少人数チームでも、モデル自身に探索を任せることで大規模な実験空間を扱えるようになる
• 業界競争の加速
  中国系オープンMoE勢（DeepSeek・GLM・Kimi・Qwen・Hunyuan）がすでに月次単位で世代交代しているなか、自己改善ループを回せる陣営がさらにペースを引き上げる

Hy4 previewは、この recursive self-improvement loop を「宣伝コピー」ではなく**測定可能な数値（31.8%）**として提示した点で、他社モデルと明確に線を引く存在になっています。

Hy4の770B/49B MoEアーキテクチャ

Hy4のアーキテクチャは、Hugging Face公式リポジトリのモデルカードで詳細に公開されています。

ここからは、エキスパートプールの構成・注意機構・推論最適化レイヤーの3つに分解して読み解きます。

78レイヤー・256エキスパート——MoE構成の全体像

Hy4のMoE構成は、直近のオープンMoE勢と比べても大規模な部類に入ります。

以下の表で、Hy4の主要ハイパーパラメータを整理しました。

256エキスパート中、1トークンにつき有効になるのは8つのRouted Expertsと1つのShared Expertで、実効49Bパラメータで推論が回ります。総パラメータ770Bに対してアクティブは6.4%という設計で、推論コストを抑えつつ表現力を確保する典型的なMoE設計を踏襲しています。

MoEの基礎概念や他モデルとの比較は、MoE（Mixture of Experts）とは？仕組みや主要モデル、選び方を徹底解説で詳しく扱っています。

Gated DeepSeek Sparse Attention（Gated DSA）とIndexCache

Hy4の注意機構は、DeepSeek-V3.2で提案されたDeepSeek Sparse Attentionを拡張した「Gated DeepSeek Sparse Attention（Gated DSA）」を採用しています。

Sparse Attentionは、全トークン間で総当たり計算を行う密注意（dense attention）ではなく、意味的に関連するトークンだけを選んで計算する方式です。1Mトークン級の長文コンテキストで密注意を回すと計算量が現実的でなくなるため、Sparse Attentionは長文モデルの事実上の標準になりつつあります。

Hy4はさらに「IndexCache」という機構を組み合わせ、注意インデックスをレイヤー間で再利用する設計を採用しています。

これにより、次のような効果が期待できます。

• インデクサ計算の削減
  各レイヤーで注意インデックスを再計算せず、レイヤー間でキャッシュを再利用することで、インデクサ計算の重複を減らす狙い
• 1M+コンテキストの高速化を狙う設計
  長文コンテキスト推論の高速化を狙う設計だが、Hy4固有の実測スループット値は公表されていない
• セルフホスティングの推論効率を支える技術要素
  同じGPU構成での実効スループットを高める土台になり得るが、実効値は自社ワークロードでの実測が前提

Gated DSAとIndexCacheの組み合わせは、Hy4の1M+コンテキスト推論を高速化する設計を支える技術要素です。

iHC・MTPによる推論最適化——FP8量子化版の公式デプロイ例

Hy4はさらに2つの推論最適化機構を組み込んでいます。

• iHC（identity Hyper-Connections）
  レイヤー間の情報流路を強化する残差経路の拡張機構。深いネットワークでも情報が薄まらず伝わるため、78レイヤーという深い構造を機能させる基盤になる
• MTP（Multi-Token Prediction）レイヤー
  Speculative Decoding（投機的デコーディング、複数トークンを先読みして正解確率が高いものを採用する高速化手法）用の追加レイヤー。バックボーン770Bとは別に10B（アクティブ0.7B）が乗っており、生成高速化に利用される

デプロイ用途では、フル精度版の tencent/Hy4-preview と、FP8量子化版の tencent/Hy4-preview-FP8 の2バリアントが公開されており、Hugging Faceの公式デプロイ例ではFP8版が採用されています。

Tensor Parallel構成は、SGLang公式のHy4 Preview CookbookでGPU世代ごとに複数案内されています。B200はMXFP8をTP=8、B300／GB300はMXFP8をTP=4、H200はBF16をTP=16という構成で、目安コンテキスト長はB200 TP=8で約262K、H200 BF16 TP=16で約131Kと案内されています。

推論時の推奨パラメータは temperature=0.9、top_p=1.0で、reasoning modeはデフォルトで "high"（Deep Chain-of-Thought）に設定されています。直接応答が必要な場合は extra_body={"chat_template_kwargs": {"reasoning_effort": "no_think"}} で切り替える設計です。

Hy4のベンチマーク性能

Hy4の性能評価は、公開ベンチマークとテンセント社内のブラインド評価の2軸で公表されています。ここでは両方を並べ、他モデルとの比較を含めて読み解きます。

公開ベンチマーク——GPQA 92.3、SWE-Bench 82.9%、Terminal-Bench 85.4

Hugging Face公式モデルカードと公式発表で公表された主要スコアは、以下のチャートで一覧化されています。

Hy4 preview と主要7モデルの12ベンチマーク比較——Terminal-Bench 2.1で85.4、DeepSWE 64.3、Humanity's Last Exam 43.4 など（出典：Tencent Hy Team on Hugging Face）

Hy4 preview（青濃色）はTerminal-Bench 2.1で85.4を記録し、TencentがDeepSeek V4-Proを同条件で再評価した値（チャート内80.3）を上回っています。特に大きな差が出ているのはDeepSWEで、Hy4の64.3はHy3の28.0から2倍以上のジャンプを見せており、Tencentが「生産性モデル」と位置づける根拠になっています。一方Humanity's Last Exam（テキストのみ・ツール不使用）ではHy4は43.4にとどまり、閉じモデル勢との差が残っています。他モデルの数値はTencentによる同条件再評価であり、各モデルの自社公表値とは食い違うことがある点も踏まえて、単一ベンチマークで順位を確定させず、自社ワークロードに近い指標で個別に評価するのが実務的です。

代表指標を表で整理すると以下のとおりです。

特に注目すべきはTerminal-Bench 2.1の85.4で、ターミナル操作を含むエージェントワークフローで現行トップ水準のオープンMoEに位置します。

DeepSWEでの28.0→64.3というHy3から2倍以上のジャンプは、テンセントが「productivity（生産性）モデル」として位置づける根拠になっています。

Tencent社内ブラインド評価——163専門家×203タスクでGLM-5.3・Kimi K3にわずかに勝利

公開ベンチマークとは別に、テンセントは社内で163名の専門家に対する203のエンジニアリングタスクでブラインド評価を実施しました。

公式発表で公表された結果は以下のとおりです。

数値上はHy4が僅差でトップですが、Hy4のGLM-5.3戦勝率が46.8%（＝ほぼ半々）という点から、実務レベルではほぼ互角と読み解くべき水準です。

Tencent社内表でもDeepSWE（GLM-5.3 68.1 vs Hy4 64.3）やTerminal-Bench 2.1（GLM 88.3 vs Hy4 85.4）ではGLM-5.3がHy4を僅差で上回っており、社内ブラインド評価と公開ベンチマークの間には評価軸の違いが存在します。

「単一ベンチマークで序列を決めない」というのが実務での取り扱いになります。

Hy3からHy4への飛躍——DeepSWE 28→64、コーディング系で大幅改善

Hy3からHy4への進化を最もよく表すのが、DeepSWEのスコア変動です。

• Hy3: 28.0
• Hy4: 64.3

これは同一系列モデルの世代交代としては異例の大きさで、テンセントが「Hy4は生産性タスクに特化した」と位置づける根拠になっています。

コード生成・エージェント型SWE・ターミナル操作といった「AIエージェントが実務で走らせる」タスクで大幅にスコアを伸ばしており、汎用チャット用途というよりも開発・運用ワークフローに組み込むオープンMoEというポジション取りが明確です。

このスコア推移は、Hy4選定を検討する際の判断軸としても機能します。汎用の質問応答用途なら旧来のフロンティア閉じモデルで足りるケースも多い一方、エージェント型SWEタスクを大量に回す用途では、Hy3世代と比べてHy4は明確に価値が上がっています。

Hy4の料金体系

Hy4はオープンMoEとしてウェイトが無料公開されていますが、テンセント公式のマネージドAPIとOpenRouterでの利用時には従量課金が発生します。

セルフホスティングと従量APIの3経路それぞれのコスト構造を整理します。

Tencent Cloud TokenHubとOpenRouterの単価

Hy4の従量API単価は、テンセント公式のTencent Cloud TokenHubと、サードパーティルーターのOpenRouterの2経路で提供されます。

以下の表で、100万トークンあたりの単価を整理しました（2026年8月時点）。

Cacheヒット単価が入力単価の20分の1（$0.042 vs $0.834）に設定されている点が特徴的で、同一プロンプトを繰り返し呼び出すエージェントワークフローで大幅なコスト圧縮が効きます。

Tencent Cloud側は中国元建て、OpenRouter側はUSD建てで、為替換算を除けばおおむね同水準の価格帯です。

DeepSeek V4-Pro・GLM-5.3・Kimi K3との単価比較

同世代のオープンMoEと比較すると、Hy4は中間帯の価格設定に位置します。

以下の表で、主要オープンMoEの100万トークンあたりのAPI単価（OpenRouter表示・2026年9月1日時点）を比較しました。

単価はプロバイダーと時間帯によって変動する点に注意が必要です。DeepSeek V4-ProはAlibaba経由のオフピーク時間帯（UTC 14:00〜00:00）で$0.5808／$1.742、Alibaba経由の通常時間帯では$1.122／$3.366です。他プロバイダーではDeepSeek公式の$0.66／$1.98、StreamLakeの$1.1154／$3.3462、DeepInfraの$1.30／$2.60など、それぞれ別価格が設定されています。GLM-5.3はio.net経由の割引価格、Kimi K3はMakora経由の最安価格を示しており、Moonshot AI公式や他プロバイダーではKimi K3が$3.00/$15.00になるケースもあります。

DeepSeek V4-Proのオフピーク帯基準ではHy4はDeepSeek V4-Proの約1.4倍の入力単価ですが、通常時間帯基準ではHy4のほうが約3割安くなります。GLM-5.3のおよそ7割水準、Kimi K3の約3分の1という位置づけは変わらず、性能ベンチマークで拮抗するGLM-5.3より安く、Kimi K3よりは大幅に安い立ち位置です。プロバイダーと時間帯を固定できるならDeepSeek V4-Proが最安、それ以外の運用や汎用ワークロードならHy4が扱いやすい選択軸になります。

2週間無料枠と実際の運用コスト目安

WorkBuddyとCodeBuddyでは、Hy4 preview公開から2週間の無料利用枠が提供されました。この期間は自社ワークフローでの試験導入コストを大幅に下げる機会になっています。

実際の運用コストを試算すると、たとえば1日100万トークンを消費するエージェントワークフローの場合、入力8割・出力2割の比率で回すと1日あたりの費用は次のようになります（2026年9月1日時点のOpenRouter表示価格・時間帯変動除く）。

• Hy4（OpenRouter）: 入力80万×$0.834/M + 出力20万×$2.501/M ≒ $1.17/日
• Kimi K3（OpenRouter・Makora）: 入力80万×$2.55/M + 出力20万×$12.75/M ≒ $4.59/日

Cacheヒットが5割乗る条件（エージェントで同一プロンプトが繰り返される想定）なら、Hy4側は$1.17がさらに$0.85程度まで下がります。コスト差は月次で$100前後になり、大規模エージェント運用では単価差が実務判断に直結します。

Hy4の使い方——API・OpenRouter・セルフホスティング

Hy4は3経路で利用できます。従量APIで即使い始めるパターン、グローバルルーター経由で他モデルと並列運用するパターン、自社インフラでウェイトをホストするパターンの3つです。

Tencent Cloud TokenHub経由での利用

テンセント公式のマネージドAPIを使う場合、Tencent Cloud TokenHubからAPIキーを発行し、OpenAI互換のエンドポイントに接続します。

Base URLは中国本土向けが tokenhub.tencentmaas.com、シンガポール等は別リージョンのURLが割り当てられるため、APIキーの開通地域と一致するBase URLを指定します。

基本的なリクエスト形式は次のとおりです。

from openai import OpenAI

client = OpenAI(
    base_url="https://tokenhub.tencentmaas.com/v1",
    api_key="YOUR_API_KEY"
)

response = client.chat.completions.create(
    model="hy4-preview",
    messages=[
        {"role": "user", "content": "こんにちは。自己紹介してください。"},
    ],
    temperature=0.9,
    top_p=1.0,
)
print(response.choices[0].message.content)

このアプローチの利点は複数あります。

利点1: テンセント公式の最新版が即使える
モデル更新はテンセント側で行われるため、常に最新のHy4を追いかけられます。セルフホスティングのようなアップデート運用が不要です。

利点2: 中国本土向け接続先が用意されている
Tencent Cloud経由なら広州リージョンなど中国本土向けの接続先を選べ、中国市場向けサービス構築で有利です。

OpenRouter経由での利用

OpenRouter経由なら、Hy4を含む複数のフロンティアモデルを1つのAPIキーで切り替えて使えます。既に他モデルをOpenRouterで運用している場合、追加の連携作業は最小限で済みます。

基本的なリクエスト形式は次のとおりです。

from openai import OpenAI

client = OpenAI(
    base_url="https://openrouter.ai/api/v1",
    api_key="YOUR_OPENROUTER_KEY"
)

response = client.chat.completions.create(
    model="tencent/hy4-preview",
    messages=[
        {"role": "user", "content": "Hello! Please introduce yourself briefly."},
    ],
    temperature=0.9,
    top_p=1.0,
)

OpenRouter経由なら、OpenRouter Fusion APIを使って複数モデルの合議推論に組み込むことも可能です。Hy4・GLM-5.3・Kimi K3を並列で走らせて合意形成する構成も選べます。

vLLM・SGLangでのFP8セルフホスティング

自社インフラでHy4を動かす場合、Hugging Faceの公式デプロイ例はtencent/Hy4-preview-FP8 をvLLMまたはSGLangでTP=8構成で動かす形です。

SGLang Cookbookでは、B200はMXFP8/TP=8、B300／GB300はMXFP8/TP=4、H200はBF16/TP=16と、GPU世代ごとに複数構成が案内されています。

vLLMでの起動コマンドは次のとおりです。

docker run --gpus all \
  -p 8000:8000 \
  --ipc=host \
  -v ~/.cache/huggingface:/root/.cache/huggingface \
  vllm/vllm-openai:hy4-preview tencent/Hy4-preview-FP8 \
    --tensor-parallel-size 8 \
    --speculative-config '{"num_speculative_tokens":3,"method":"mtp"}' \
    --attention-backend FLASHMLA_SPARSE \
    --tool-call-parser hy_v4 \
    --reasoning-parser hy_v4 \
    --enable-auto-tool-choice \
    --port 8000 \
    --served-model-name hy4-preview

SGLangでの起動コマンドはこちらです。

docker run --gpus all --ipc=host -p 8000:8000 lmsysorg/sglang:hy4-preview \
  python3 -m sglang.launch_server \
    --model tencent/Hy4-preview-FP8 \
    --tp-size 8 \
    --reasoning-parser auto \
    --tool-call-parser auto \
    --speculative-algorithm NEXTN \
    --speculative-num-steps 3 \
    --speculative-eagle-topk 1 \
    --speculative-num-draft-tokens 4 \
    --port 8000 \
    --served-model-name hy4-preview

Speculative Decoding（MTPまたはNEXTN）を有効化する設定が公式サンプルに含まれている点が特徴で、生成高速化を狙う設計になっています。

セルフホスティングの利点は次のとおりです。

• データが自社インフラから出ない
  プロンプト・出力がテンセント側やOpenRouter側に送信されず、機密データを扱うワークロードでも導入可能
• 単価がスケール次第で安くなる可能性
  損益分岐点はGPU構成・稼働率・電力・運用費の前提で大きく変わるため、まず実測トークン量と自社の想定GPU構成で試算するのが実務的
• モデルの挙動を細かく制御
  Speculative Decodingのステップ数・draft-token数・reasoning parser／tool-call parserなど、公式APIでは意識しないパラメータまで自由に調整できる

ただしFP8経路はBlackwell世代（B200/B300/GB300）、BF16経路はH200 16GPU（Multi-Node）と、いずれもハイエンドGPU構成が必要で、初期インフラコストは大規模になります。「まず試す」段階ではOpenRouter経由が現実的で、規模が見えてからセルフホスティングに切り替える運用が推奨です。

WorkBuddy・CodeBuddy・Yuanbao・imaへのプロダクト統合

Hy4はAPI公開と同時に、テンセントが提供する複数のプロダクトに統合されました。これは「Day-one product co-design」と呼ばれる、モデル開発とプロダクト開発を並行する設計思想の現れです。

日本の読者にとっては馴染みの薄いプロダクトも含まれるため、それぞれの性格を補足します。

WorkBuddyとCodeBuddy——業務・開発向けアシスタント

WorkBuddyは、テンセントが提供する企業向けの生産性AIアシスタントです。日本のCopilot for Microsoft 365やGoogle Workspaceのアシスタント機能に近い位置づけで、企業のドキュメント作成・データ分析・タスク自動化を支援します。国内版と国際版の両方でHy4を利用できると公式発表されています。

CodeBuddyは、開発者向けのAIアシスタントで、コード生成・レビュー・デバッグを担当します。VS Code拡張やJetBrains系IDEとの統合を持ち、GitHub CopilotやClaude Codeと競合するポジションです。

WorkBuddyとCodeBuddyについては、Hy4 preview公開から2週間の無料利用枠が公式に案内されており、テンセントが「まず触ってほしい入口」として位置づけていることがわかります。

Yuanbao——テンセント消費者向けAIアシスタント

Yuanbao（元宝）は、テンセントが提供する中国市場向けの消費者AIアシスタントです。日本でいうChatGPT・Gemini・Claude.aiの位置づけで、テンセントのスーパーアプリWeChatと連携した一般消費者向けサービスです。

Yuanbaoは、Hy4公開と同時にHy4が利用可能になったプロダクトの1つとして公式に案内されており、テンセント公式のWeb・モバイルUIから体験できます。

ima——テンセントの学習・ノートAI

imaは、テンセントが提供するAI駆動の学習・ノート管理アプリで、日本でいうNotebookLMやObsidian＋AI統合系プロダクトに近い位置づけです。文献の要約・概念間の関連整理・長文の質問応答などを担当します。

imaは1Mトークンの長文コンテキストと相性がよく、Hy4の1M+コンテキスト仕様を活かすユースケースになっています。学術文献・書籍・法令などの長文を丸ごと投入して、対話ベースで学習を進める使い方が想定されています。

Yuanbaoとimaは中国市場向けが主戦場のため、日本企業として直接利用する機会は限定的です。ただし、Hy4のAPIを使って日本市場向けに類似機能を独自実装する参考にはなります。テンセント側が「オープンMoEをどうプロダクトに載せるか」の実例を公開しているとも読めます。

Hy4を選ぶべきケース——GLM-5.3・Kimi K3・DeepSeek V4-Proとの使い分け

Hy4は同世代のオープンMoE勢と直接競合します。ここでは、それぞれの得意領域とHy4を選ぶべきケースを、AI総研の導入支援経験も踏まえて整理します。

DeepSeek V4-Proとの使い分け——Alibaba経由のオフピークならDeepSeek

DeepSeek V4-Proは、1.6T総パラメータ／49BアクティブのMoEで、OpenRouter価格ではAlibaba経由のオフピーク時間帯（UTC 14:00〜00:00）でHy4より入力単価がおよそ3割安く（$0.5808 vs $0.834）、出力単価も約3割安く抑えられます。Alibaba経由の通常時間帯では$1.122／$3.366と、逆にHy4より高くなります（DeepSeek公式は$0.66／$1.98、StreamLakeは$1.1154／$3.3462、DeepInfraは$1.30／$2.60など、プロバイダーごとに別価格）。

使い分けの目安は次のとおりです。

• DeepSeek V4-Proが優位: バッチ処理・ログ要約・大量文書分析など、単価が効くワークロード。Alibaba経由のオフピーク時間帯限定でHy4より単価が3割ほど安く、通常時間帯は逆転してHy4のほうが安い
• Hy4が優位: エージェント型SWEタスク（DeepSWE 64.3）・ターミナル操作（Terminal-Bench 85.4）といった、開発ワークフローへの組み込み。DeepSeek V4-Proはこれらのスコアで一段下

DeepSeekのHarnessエコシステムと組み合わせる用途ならDeepSeekが第一候補、テンセント公式のCodeBuddy/WorkBuddyに乗せる想定ならHy4が自然な選択になります。

GLM-5.3との使い分け——長文コーディングならGLM、汎用生産性ならHy4

Zhipu AIのGLM-5.3は、Coding Plan向けの主力モデルとして設計されており、Tencent社内ベンチマーク表ではDeepSWEやTerminal-Bench 2.1でHy4を僅差で上回るスコアを示します。

使い分けの目安は次のとおりです。

• GLM-5.3が優位: DeepSWE（68.1 vs Hy4 64.3）とTerminal-Bench 2.1（88.3 vs Hy4 85.4）で、Tencent社内表ではGLMが僅差で上回る
• Hy4が優位: SWE-Bench Pro（Hy4 65.7 vs GLM 64.6）などのソフトウェア修正タスク。テンセント社内ブラインド評価の総合平均でも僅差で上回る

料金面ではHy4の入力単価がGLM-5.3のおよそ7割水準（io.net割引価格ベース、$0.834 vs $1.188）なので、汎用ワークロードならHy4の方がコストパフォーマンスが良好です。GLMシリーズのGLM-5.3-Flash（320B）はさらに軽量ですが、フロンティア級の性能を求めるならGLM-5.3本家またはHy4を選ぶことになります。

Kimi K3との使い分け——マルチモーダル・長タスクならKimi

Moonshot AIのKimi K3は、マルチモーダル（画像・動画入力対応）と長期タスクエージェントに特化しています。2.8Tの総パラメータで、テキスト以外の入力を扱える点でHy4と差別化されます。

使い分けの目安は次のとおりです。

• Kimi K3が優位: マルチモーダル入力（画像・動画）が必要な用途、Long-horizon agent（長時間にわたるタスク）
• Hy4が優位: テキストベースのコード生成・SWE・エージェント。単価がKimi K3の入力約1/3・出力約1/5で大幅に安い

Kimi K3のAPI単価はMakora経由で$2.55入力／$12.75出力（Moonshot AI公式は$3.00/$15.00）、Hy4の3〜5倍で、テキストのみのワークロードにKimi K3を使うのは明らかにオーバースペックです。マルチモーダル要件がなければHy4を選ぶ経済合理性が明確です。

Hy4を選ぶべき3つのケース

ここまでの比較を踏まえると、Hy4を第一候補にすべきケースは次の3つに集約されます。

• エージェント型SWEタスクを大量に回す用途
  Terminal-Bench 85.4・DeepSWE 64.3という公開ベンチマーク、Cacheヒット20倍割引の料金設計から、開発ワークフローへの組み込みで最もコストパフォーマンスが良い
• オープンMoEで最新の技術スタックを取り込みたい用途
  Gated DSA・IndexCache・iHC・MTP・FP8量子化と、直近のオープンMoE勢が採用している技術スタックを網羅している。Apache 2.0で自社カスタマイズも自由
• テンセントのエコシステム連携を活かしたい用途
  Tencent Cloud TokenHubから広州リージョンの接続先を選べ、WorkBuddy/CodeBuddyとの連携も公式で提供されている。中国市場向けサービス提供でも第一候補になる

別モデルが優位なケース

一方、次のケースではHy4以外のモデルが優位です。

• 単価が最優先: DeepSeek V4-Proが特定プロバイダー・オフピーク時間帯で入力・出力ともに約3割安くなる（通常時間帯はHy4より高い場合あり）
• 画像・動画などマルチモーダル入力が必要: Kimi K3またはQwen 3.8-Maxを検討
• 多言語のバランスを重視: Hy4は自然言語別の公開評価がないため、日本語・欧州言語の実タスクではQwen系も並行検証の候補になる
• セルフホスティングでリソース制約がある: FP8経路はB200(TP=8)／B300・GB300(TP=4)、BF16経路はH200 16GPU(Multi-Node)が公式デプロイ例の前提。より軽量なMoEが必要ならGLM-5.3-Flash（320B）やDeepSeek V4-Flashが現実的

AI総研の支援現場でも、「まずOpenRouterでHy4・GLM-5.3・DeepSeek V4-Proを並列で試し、自社ワークロードに合った1本を選ぶ」という導入ステップが最も打率が高い進め方になっています。ベンチマーク数値だけで判断せず、自社の代表タスクで比較検証してから本採用する流れが現実的です。

Hy4の制約と留意点

Hy4は高性能ですが、テンセント自身が公表している制約や、実運用で見えてくる留意点も存在します。導入判断で見落としがちな観点を整理します。

ハイエンドGPU前提のインフラ要件

Hy4の公式デプロイ例はHugging FaceがFP8・TP=8で提示しています。

SGLang Cookbookでは、B200はMXFP8をTP=8、B300／GB300はMXFP8をTP=4、H200はBF16をTP=16と、GPU世代ごとに構成が示されており、目安コンテキスト長はB200 TP=8で約262K、H200 BF16 TP=16で約131Kと案内されています。より小規模なGPUクラスタでの運用は追加の量子化・分割最適化が必要になり、実質的にセルフホスティングは大手企業・研究機関向けの選択肢になります。

小規模チームがHy4を試す場合の現実的な導線は次の3段階です。

• フェーズ1: OpenRouter経由の従量課金で試験導入（初期投資ゼロ）
• フェーズ2: WorkBuddy/CodeBuddyの無料期間で業務適合を確認
• フェーズ3: 継続的な運用量とレイテンシ・データ持ち出し要件を踏まえ、セルフホスティングへの切り替えを検討

テンセント自己開示の「過剰検証」と「冗長reasoning」

Hugging Face公式モデルカードのKnown Limitationsは、Hy4 previewの既知の弱点として以下を自己開示しています。

• 過剰検証（over-verification）
  シンプルなタスクに対しても、モデルが自己検証を過剰に行う傾向がある。結果として出力までの時間が長くなる場合がある
• 冗長reasoning（verbose reasoning）
  Chain-of-Thoughtがデフォルトで "high" に設定されており、直接回答を求めるユースケースでは reasoning_effort を "no_think" に切り替える運用が推奨される

これらは「バグ」ではなく、モデルが「preview」段階であることを反映した既知の挙動です。運用時は、直接回答が必要な用途で reasoning_effort を "no_think" に落とすなど、タスクの性質に応じたパラメータ選択を行うのが実務的です。

自然言語別の公開評価がない——日本語ワークロードは要検証

Hy4のモデルカードには自然言語別の評価は掲載されていません。SWE-bench Multilingualはソフトウェア修正タスクの評価であり、日本語・韓国語・欧州言語などの自然言語での性能を直接示すものではありません。

多言語ワークロードで採用する場合、次の観点で事前検証が推奨されます。

• 対象言語での実タスクを10件程度用意し、Hy4・Qwen 3.8-Maxなどで並列比較する
• 出力の自然さ・専門用語の正確性・長文一貫性を3軸で評価する
• コード生成用途なら、コメント・変数名の言語適合性も確認する

日本語を含む多言語ワークロードでは、公開評価だけで採否を決めず、自社の代表タスクで並列比較する運用が現実的です。

「preview」段階のバージョン更新リスク

モデル名に「preview」が付いている通り、Hy4は将来的にGA版で仕様が変わる可能性があります。テンセントは過去のHy3も同様に "preview → 正式版" の段階リリースを行っており、以下の変更が想定されます。

• パラメータ数・アーキテクチャの微調整
• API単価の変更（無料枠終了後の値上げ・値下げの両方向）
• ライセンス条件（現行はApache 2.0、GA版でも同条件かどうかは公表待ち）

本番運用に組み込む場合は、モデル切替の運用設計（バージョン固定・A/Bテスト・段階移行）を最初から準備しておくのが実務的です。GA版リリース時は、モデルカードのライセンス表記・料金・アーキテクチャを改めて確認する運用が確実です。

オープンMoE世代を業務Agent基盤に載せるなら

Hy4のような高性能オープンMoEが3か月ごとに登場する時代では、モデル選定単独では業務が動きません。Hy4・GLM-5.3・Kimi K3・DeepSeek V4-Proが月次で世代交代する状況では、モデル層の下に「Agent実行層・権限管理・監査ログ」を切り離して整えておかないと、モデル切替のたびに業務プロセスが崩れます。

このレイヤーを担うのが、自社Azureテナント内で動くエンタープライズAIエージェント基盤です。AI総合研究所のAI Agent Hubは、Teamsから呼び出せる業務特化Agent群を1つのダッシュボードで統合管理し、Hy4級のモデル切替を吸収しながら業務プロセスに載せる運用基盤として機能します。

• モデル世代交代を吸収する管理層
  Hy4 → 次期Hy5、GLM-5.3 → GLM-6のように短サイクルで世代交代しても、業務Agent側の設計は不変。特定モデル依存のワークフロー陥落を回避できます。
  
  

• オープンMoEをセルフホスティング環境から呼び出せる
  Hy4 FP8をvLLMで社内デプロイした場合でも、Teams上のAgentから同じインターフェイスで呼び出せる設計。データが自社インフラから出ない業務にHy4を組み込めます。
  
  

• Agent単位でセキュリティ統制を1画面統制
  コード生成Agent・ドキュメント要約Agentごとにアクセス範囲を設計。誰がどのAgentで何を照会したかを不変ログで残し、監査対応をそのまま提出できる形で保管します。
  
  

• データは100%自社Azureテナント内に保持
  プロンプト・出力・添付ファイルはAIの学習対象から完全除外。Azure Managed Applicationsとして自社テナント内で動作が完了する設計です。

AI総合研究所の専任チームが、Hy4級オープンMoEの選定からAgent基盤の統合設計まで一貫して支援します。AI Agent Hubのサービスページで、モデル世代交代を前提としたAgent基盤の実装例をご確認ください。

オープンMoE世代を業務Agent基盤に載せるなら

Hy4級モデルの世代交代を吸収する運用層を先に整える

Hy4のように高性能なオープンMoEが3か月ごとに登場する時代では、モデル選定単独では業務が動きません。AI Agent Hubは自社Azureテナント内で動く業務特化Agent群を1つのダッシュボードで統合管理し、モデル世代交代を吸収する運用層として機能します。

▶ ▶ AI Agent Hubの詳細を見る

まとめ

本記事では、Tencent Hy4について、自己改善ループの中身・770B/49B MoEアーキテクチャ・公開ベンチマーク・料金体系・API/OpenRouter/セルフホスティングの使い方・GLM-5.3/Kimi K3/DeepSeek V4-Proとの使い分け・既知の制約までを、2026年8月時点の公式情報で解説しました。

2026年8月時点で押さえておくべきポイントは次の3つです。

• Hy4はTencentが「同社モデルとして初めて」と説明する再帰的自己改善ループを運用したオープンMoEで、推論スタックのベースライン比31.8%スループット改善、Terminal-Bench 2.1で85.4、DeepSWEでHy3の28.0から64.3への大幅ジャンプを達成した
• API単価は入力$0.834・出力$2.501（100万トークン）、Cacheヒット20倍割引でエージェントワークフロー向け。GLM-5.3の入力7割・出力6割水準、Kimi K3の入力約1/3・出力約1/5で性能と価格のバランスが良い
• Apache 2.0でHugging Face公開、FP8経路はB200(TP=8)／B300・GB300(TP=4)、BF16経路はH200 16GPUがSGLang Cookbookのデプロイ例。自然言語別評価は未公開のため日本語ワークロードは事前検証必須、DeepSeek V4-Proはオフピーク帯のコスト・Kimi K3はマルチモーダルで使い分ける
  
  

Hy4は「オープンMoEが月次で世代交代する時代の入口」に立つモデルで、モデル選定単独よりも、Hy4級モデルを業務Agentに組み込む運用層の設計が本質的な論点になります。まずはOpenRouter経由でHy4・GLM-5.3・DeepSeek V4-Proを自社ワークロードで並列検証し、性能・単価・レイテンシの3軸で自社に合う1本を選ぶのが現実的な第一歩になります。