はじめに

2026年8月28日、Tencent が次世代の大規模言語モデル Hy4 preview を公開しました。総パラメータ 770B、1トークンあたりに動くのは 49B、コンテキスト長は 100万トークン。そしてライセンスは Apache-2.0 です。重みは Hugging Face・ModelScope・GitCode・CNB の4か所に置かれています。

数字だけ見ると「また大きいモデルが出た」で流れていきますが、この公開には二つ、追いかける価値のある変化が入っていました。

一つはライセンスです。Tencent の Hunyuan 系モデルは、少し前まで自社の独自ライセンスで公開されていました。それが Hy3 世代から Apache-2.0 に変わり、今回の Hy4 preview もそれを引き継いでいます。

もう一つは、Tencent が公式リリースの中で書いている「このモデルは自分自身の開発に参加した」という主張です。訓練手法や評価枠組みの自動最適化に初めて参加し、さらに自分の推論システムのボトルネックを自律的に解析して、エンドツーエンドのスループットをベースライン比31.8%改善した——と書かれています。

この記事では、まず前提（Hunyuan とは何か・MoE の読み方・オープンウェイトとは何か・100万トークンとは何か）を押さえてから、価格・ライセンス・そしてこの「自己最適化」の主張を、一次情報で裏を取れた範囲に絞って整理します。

🗓️ この記事の時点（2026年8月31日）と姿勢

本記事は 2026年8月31日時点で到達確認できた Tencent 公式リリース・Hugging Face のモデルカード・GitHub 公式リポジトリにもとづきます。性能に関する数値はすべて Tencent の発表値として帰属させ、「最強」「他を上回った」といった断定はしません。価格は変動するため時点を明記します。

X（旧Twitter）の投稿は根拠に使っていません。 そのため、いま SNS で広く流れている「Hy4 が複数の Codex セッションを並列に指揮し、8つのベンチマークで単体の Codex を上回った」という話は、本記事では事実として書いていません。理由は §6 に書きます。

🏢 1. Hunyuan（Tencent Hy）とは — これまでの系譜

Hunyuan（混元） は Tencent の大規模モデル群のブランドです。モデルカードの表記は現在「Tencent Hy Team」で、モデル名も Hunyuan-A13B から Hy3 Hy4 preview へと短くなっています。

Hugging Face の各モデルカードで確認できる範囲では、系譜はこうなっています。

モデル 総パラメータ アクティブ コンテキスト ライセンス
Hunyuan-Large（A52B） 389B 52B 128K／256K（版による） 独自（tencent-license）
Hunyuan-A13B 80B 13B 256K 独自（tencent-hunyuan-a13b）
Hy3 295B 21B 256K Apache-2.0
Hy4 preview 770B 49B 1M Apache-2.0
timeline title Tencent Hy のオープン公開とライセンス Hunyuan 世代 : 2024年 Hunyuan-Large 389B/A52B : 2025年6月 Hunyuan-A13B 80B/A13B : 独自ライセンス Hy3 世代 : 2026年4月下旬 Hy3 preview : Hy3 295B/A21B 256K : Apache-2.0 へ Hy4 世代 : 2026年8月28日 Hy4 preview : 770B/A49B コンテキスト1M : Apache-2.0

注目したいのはライセンス列です。Hunyuan-Large と Hunyuan-A13B のモデルカードは、いずれも license: other で、Tencent 独自のライセンス文書へリンクしています。それが Hy3 でも Hy4 preview でも license: apache-2.0 になっている。同じベンダーが、世代をまたいで配布条件そのものを緩めたわけです。ここは §3 で詳しく見ます。

Tencent は公式リリースで、この preview 先行という出し方自体を方針として説明しています。preview を先に出して実利用のフィードバックを取り込み、その後に正式版を出す。Hy4 シリーズの次のモデルも近く投入予定、とも書かれています。

🧩 2. 「総770B・アクティブ49B」とは何か — MoE の読み方

Hy4 preview を語るときにいちばん誤解されやすいのが、この二つの数字です。

💡 ワード解説：MoE（Mixture-of-Experts）と、総パラメータ／アクティブパラメータ

MoE（混合エキスパート） は、モデルの中に「専門家（エキスパート）」と呼ばれる小さなネットワークを多数用意しておき、入力トークンごとに、そのうちのごく一部だけを起動するアーキテクチャです。

  • 総パラメータ：モデル全体が持っている重みの量。ディスクとメモリに載せる必要がある量
  • アクティブパラメータ：1トークンを処理するときに実際に計算に参加する量。推論のたびに走る計算量

つまり総パラメータは「置き場所のコスト」、アクティブパラメータは「一回あたりの走行コスト」に近い。大きさは 770B、走るのは 49B というのは、「巨大な知識を持たせつつ、1回の推論は中規模モデル並みの計算量で済ませる」ための設計です。この「大きいのに安い」構図は、DeepSeek V4-Flash の価格破壊で扱ったスパースMoEとまったく同じ考え方です。

Hy4 preview のモデルカードは、その中身をかなり細かく開示しています。

  • バックボーンは 78層。うち最初の1層だけが通常の密なFFNで、残り77層が MoE
  • MoE 層は ルーテッド専門家256個＋共有専門家1個。1トークンあたり上位8個のルーテッド専門家と、共有専門家が起動する
  • バックボーンとは別に、MTP層を1つ内蔵（総10B・アクティブ0.7B）。投機的デコーディング（speculative decoding）用
  • アテンションは Gated DSA（DeepSeek Sparse Attention）＋IndexCache、残差経路は iHC（identity Hyper-Connections）。モデルカードは「DeepSeek と GLM に着想を得た」と明記しています
flowchart TD T["入力トークン 1個"] --> R["ルーター
どの専門家に送るか決める"] R --> E1["ルーテッド専門家
256個のうち上位8個だけ起動"] R --> E2["共有専門家 1個
常に起動"] E1 --> S["この1トークンで実際に動くのは
770B のうち 49B"] E2 --> S S --> O["出力トークン"]

「256個のうち8個」という比率が、そのまま総パラメータとアクティブパラメータの差になっています。ここが MoE の効きどころで、価格の話（§5）にも直結します。

なお、「DeepSeek と GLM に着想を得た」と自ら書いているのは、地味ですが読みどころだと思います。当サイトではGLM-5.3 が2,436件の脆弱性を見つけた話やDeepSeek V4-Flashを個別に扱ってきましたが、公開された設計が次の公開モデルに取り込まれていくという流れが、モデルカードの一文として残っている形です。

🔓 3. オープンウェイトとオープンソースは違う — Apache-2.0 の意味

ここは毎回きちんと線を引いておきたいところです。

💡 ワード解説：オープンウェイトとオープンソース

オープンウェイトは、学習済みモデルの重みが公開され、ダウンロードして自分の環境で動かせる形態です。当サイトではDeepSeek V4-FlashやKimi K3でも同じ定義を使っています。

一方オープンソースは、本来はソフトウェアのソースコードが公開され、改変・再配布が自由であることを指します。モデルの場合、学習データや学習コードまで公開されることは稀で、公開されるのはたいてい重みと推論コードだけです。だから「オープンソースモデル」と呼ばれていても、再現できるのは推論であって、学習ではない。この区別は残しておく価値があります。

Tencent 自身は公式リリースで “open-source” と書いていますが、実際に配布されているのは重み（Hy4 preview と FP8量子化版）と推論・微調整の手順です。本記事ではオープンウェイトと呼びます。

そのうえで、今回の Apache-2.0 です。モデルカードとリポジトリはどちらも「Apache License 2.0」と明記しており、独自の追加条項の記載は見当たりません。

Apache-2.0 が MIT などと比べて実務で効くのは、特許条項が明文で入っている点です。貢献者が持つ関連特許について利用者へライセンスを与えることが書かれており、特許訴訟を起こした側はそのライセンスを失う、という構造になっています。何かを製品に組み込む立場からすると、「重みが手に入る」ことと同じくらい、あとから特許で止められないと明文で書いてあることに意味があります。

当サイトではSpaceXAI の Grok Build が Apache-2.0 で公開された件でも同じライセンスを扱いました。独自ライセンスから Apache-2.0 へという Tencent の移動は、地味ですが「使ってよい範囲を読者側が読み解かなくて済む」方向への変化です。

📏 4. 100万トークンのコンテキストで何が変わるか

Hy4 preview のコンテキスト長は 1M（100万トークン）。Hy3 の 256K から約4倍です。

コンテキスト長は「一度に読ませられる長さ」ですが、長いほど偉いという話ではありません。効くのは、分割して渡すと壊れる種類の作業です。

  • 複数ファイルにまたがるコードベース：呼び出し元と呼び出し先が別ファイルにあるとき、片方だけ渡すと辻褄の合わない修正が返ってくる
  • 長い仕様書やデータシート：「この章の記述が、あの章の表と矛盾している」という指摘は、両方が同じ文脈に入っていないと出てこない
  • 長時間の対話や作業ログ：途中経過を捨てずに持ち回れる

Tencent 公式リリースは、この長さを長期スパンの開発タスク（long-context development tasks）や、多数のファイルに散らばった文脈をドキュメント・表計算・プレゼンにまとめ上げる作業に結びつけて説明しています。数字そのものより、「分割しなくて済む」ことが何を可能にするかで読むほうが実感に近いはずです。

ただし正直に書いておくと、1M トークンを実際に埋めて使えるかどうかは別の話です。長文になるほど推論は遅く、高くなります。筆者はまだ Hy4 preview で長文コンテキストを試していないので、実効的な使い勝手については断定しません。

💰 5. 価格 — 入力 $0.834・出力 $2.501、キャッシュヒットは $0.042

Tencent 公式リリースが示す API 価格は次のとおりです（100万トークンあたり・USD・公式発表時点）。

項目 価格（100万トークンあたり）
入力 USD 0.834
出力 USD 2.501
キャッシュヒット USD 0.042

API の口は Tencent Cloud TokenHub と OpenRouter。加えて、Tencent 自身の製品である WorkBuddy・CodeBuddy・Yuanbao・ima からも使えます。公開時点で WorkBuddy と CodeBuddy では2週間無料、さらに前世代の Hy3 の無料開放は9月30日まで延長されると公式リリースに書かれています。

比較のために、当サイトで以前扱った価格を並べておきます。測定条件も時点も違うので、順位づけではなく桁の感覚として読んでください。

モデル 入力（$/1Mトークン） 出力（$/1Mトークン） 出典・時点
Hy4 preview 0.834 2.501 Tencent 公式リリース（2026-08-28）
DeepSeek V4-Flash-0731 0.14 0.28 DeepSeek 公式（当サイト過去記事・2026-08時点）

Hy4 preview は、格安帯の DeepSeek V4-Flash よりは一桁高いが、フロンティア級のクローズドモデルよりは安いという位置に置かれています。キャッシュヒットが入力の約1/20という設計も、同じ前提を何度も投げる使い方——コードベースを読ませ続ける、長い仕様書を毎回参照する——に効く形です。

🔁 6. Tencent が主張する「自分の開発に参加したモデル」

ここが今回いちばん面白い部分で、同時にいちばん慎重に書くべき部分でもあります。

Tencent 公式リリースに書かれていること（すべて Tencent の主張として読んでください）:

  • Hy4 preview は、訓練手法・データ戦略・評価枠組み・低レベル演算子の自動最適化に初めて参加した
  • モデルが手法を提案し、実験を走らせ、結果にもとづいて反復した。生成されたコード・ログ・フィードバックが次の探索へ流れ込む。Tencent はこれを「初期段階の再帰的自己改善ループ」と表現している
  • さらに、自分の推論システムのボトルネックを自律的に解析し、operator fusion（演算子融合）や通信の最適化を複数回にわたって実施した
  • その結果、エンドツーエンドのスループットがベースライン比で31.8%向上。異なるコンテキスト長・並列度でも一貫した改善が見られた

つまり「モデルが賢くなった」だけでなく、モデルが自分を動かすインフラ側のコードに手を入れて、自分を速くしたという主張です。これは推論エンジンの話で、operator fusion は複数の演算をひとつのカーネルにまとめてメモリ往復を減らす、いわば地味で泥臭い最適化です。

⚠️ SNS で流れている「Codex を並列指揮」の話を、本記事が書かない理由

公開直後から「Hy4 preview が複数の Codex セッションを並列に指揮し、結果を評価して研究方針を修正し、8つのベンチマークで単体の Codex を上回った」という話が広く流れています。

筆者は、この記述の出どころを Tencent 公式リリース・Hugging Face のモデルカード・GitHub 公式リポジトリの3つで探しましたが、いずれにも見当たりませんでした。 モデルカードの本文には “Codex” も “agentic research” も出てきません。たどれた範囲では、発信源は X の投稿と、それを引用した二次記事でした。

当サイトは X の投稿を根拠に採用しない方針です（記録が編集・削除され得る／開示責任が伴わない／文脈が切り取られやすい）。したがって、この主張は本記事では事実として書きません。今後 Tencent が公式に技術レポートを出して裏が取れたら、そのとき追記します。

一方、上に挙げた自己最適化ループと31.8%の改善は、Tencent 公式リリースに明記されている主張です。同じ「エージェント的な研究能力」の話でも、裏の取れる側と取れない側がある——今回はそこがきれいに分かれました。

📊 7. ベンチマークをどう読むか — 163人・203タスクの社内ブラインド評価

Tencent が公式リリースとモデルカードの両方で挙げている評価は、社内のブラインド比較です。

  • 163人の社内エキスパートが、203件のエンジニアリングタスクの出力を評価
  • Hy4 preview の平均スコアは 4.00点満点で2.99
  • GLM-5.3 は 2.92（Hy4 の勝ち46.8%・引き分け12.8%・負け40.4%）
  • Kimi K3 は 2.94（勝ち51.2%・引き分け7.9%・負け40.9%）

読むときに押さえておきたい点が二つあります。

一つは、これが自社による自社モデルの評価だということ。ブラインドとはいえ、タスクの選び方も評価者も Tencent 側です。差も 2.99 対 2.92／2.94 と小さく、勝率で見れば4割前後は負けている。Tencent 自身も “slightly ahead”（わずかに上回る）という控えめな書き方をしています。

もう一つは、Tencent が弱点を自分から書いていることです。モデルカードの Known Limitations には、これが Hy4 の早期版であり、事前学習・事後学習ともに伸びしろが残っていること、そして既知の問題として 複雑なタスクで必要以上に長く考え込む、自分の作業を検証しすぎる傾向があることが挙げられています。「早く出して壊れる箇所を聞くほうがよい、それが Hy3 を良くしたやり方だ」とも書かれています。

比較対象として名前が挙がっている GLM-5.3 と Kimi K3 は、どちらも当サイトで扱ってきたモデルです（GLM-5.3 と Akrites／Kimi K3 が GitHub Copilot に載った件）。オープンウェイト勢が、いまや互いを基準線にして競っているという構図そのものが、この1年の変化だと思います。

🖥️ 8. 手元で動かせるのか — 現実的な話

「重みが公開された」と聞くと自分の環境で動かせそうに思えますが、770B は率直に言って個人の機材の外側です。

公式が示している動かし方は次のとおりです。

  • 推論は vLLM または SGLang を推奨。どちらも公式のビルド済み Docker イメージ（vllm/vllm-openai:hy4-preview / lmsysorg/sglang:hy4-preview）が用意されている
  • 例として示されているコマンドは FP8量子化版（Hy4-preview-FP8）を --tensor-parallel-size 8 で8GPUに分割する構成
  • MTP による投機的デコーディングを有効にするオプションが最初から例に入っている
  • 微調整のパイプラインと、量子化ツール AngelSlim も公開されている

FP8 は1パラメータあたり1バイトなので、770B の重みだけで単純計算しても数百GB規模になります（この見積もりは筆者の概算です）。8GPU 前提の推奨構成も、そのオーダーを裏づけています。したがって現実的な入口は、API（Tencent Cloud TokenHub / OpenRouter）か、Tencent 製品（CodeBuddy・WorkBuddy・Yuanbao・ima）になります。

とはいえ、重みが Apache-2.0 で置かれていることの意味は消えません。将来もっと小さい派生や蒸留版が出たときに、それを誰が作ってもよいという状態が確保されている、ということだからです。配布の中枢が誰の持ち物になるのかという論点は、NVIDIA が Hugging Face を買収と報じられた件でも扱いました。今回の Hy4 preview がHugging Face だけでなく ModelScope・GitCode・CNB にも同時に置かれているのは、その意味でも見ておく価値があります。

🧑‍💻 9. 筆者の見方

📌 筆者の見方（学習させる側ではなく、使う側から）

筆者は電子工作・組み込みが本業で、モデルを学習させる側ではありません。ESP32 の基板を起こし、ESP-IDF を Claude Code のスキルから回して実機に焼く——そういう使い方をしている側です。事実は上の節まで、ここから先は意見として読んでください。

今回いちばん手が止まったのは、ベンチマークの数字ではなく、モデルが operator fusion と通信最適化に手を入れて自分のスループットを31.8%上げたという部分でした。これは「賢い答えを返した」話ではなく、自分が乗っている実行系のボトルネックを見つけて潰した話です。筆者の手元でいえば、書いたファームウェアの中身ではなく、書き込みが遅い原因が USB シリアルのボーレートなのか、ビルドの依存解決なのかを切り分ける側の作業にあたります。正直、そちらのほうが人間でも面倒で、地味で、後回しになりがちな仕事です。そこに手を入れたと主張しているのが引っかかりました。

もう一つ受け止めたのは、Known Limitations に「必要以上に長く考え込む」「自分の作業を検証しすぎる」が並んでいたことです。これは自分がエージェントを回していて実際に感じている摩擦とまったく同じで、しかもベンダーが弱点として先に書いている。31.8%のような気持ちのいい数字と、この二つの弱点が同じモデルカードに同居しているのを見て、筆者はむしろ数字のほうを少し信じる気になりました。都合のいい面だけ並べる資料には、こういう記述は載らないからです。

そして今回は、書けなかったことのほうが記憶に残りました。「Codex を並列に指揮した」という一番おいしい話は、公式のどこにも見つけられませんでした（§6）。一番面白い主張ほど、一次で見つからないときに書かない判断が要る——今回それを一度きちんとやったので、記録として残しておきます。

まとめ

  • Tencent が 2026年8月28日、Hy4 preview をオープンウェイト公開。総770B・アクティブ49BのMoE、コンテキスト 100万トークン、Apache-2.0
  • 配布は Hugging Face・ModelScope・GitCode・CNB の4か所。FP8量子化版も同時公開
  • 構造は 78層（1層が密なFFN＋77層がMoE）／ルーテッド専門家256個＋共有専門家1個／1トークンで上位8個が起動。MTP層を内蔵し投機的デコーディングに使う。モデルカードは DeepSeek と GLM に着想を得たと明記
  • 旧 Hunyuan（Hunyuan-Large・A13B）は Tencent 独自ライセンスだったが、Hy3 世代から Apache-2.0 に。特許条項が明文で入るライセンスへ移った意味は小さくない
  • API 価格は 入力 $0.834／出力 $2.501／キャッシュヒット $0.042（100万トークンあたり・公式発表時点）。WorkBuddy・CodeBuddy で2週間無料、Hy3 の無料開放は 9月30日まで延長
  • Tencent は、モデルが自分の訓練・評価・推論の最適化に参加し、スループットを31.8%改善したと主張。一方、SNS で流れている Codex 並列指揮の話は一次情報で確認できなかったため本記事では書いていません
  • 社内ブラインド評価は 163人・203タスクで 2.99 対 GLM-5.3 2.92／Kimi K3 2.94。自社評価であり差は小さい。Known Limitations には考えすぎ・検証しすぎが挙げられている

オープンウェイト勢の動きは、DeepSeek V4-Flash の価格破壊、Kimi K3 が GitHub Copilot に載った件、GLM-5.3 と OSS 脆弱性、NVIDIA による Hugging Face 買収報道と続けて追ってきました。Hy4 preview は、そこに「巨大なモデルを、緩いライセンスで、そこそこの価格で」という一手を重ねてきた形です。

よくある質問（FAQ）

Q. 770B と 49B は、どちらがモデルの「大きさ」ですか？

A. 両方です。770B は総パラメータで、ディスクとメモリに載せる必要がある量。49B はアクティブパラメータで、1トークンを処理するときに実際に計算に参加する量です。MoE は256個の専門家のうち上位8個＋共有1個だけを起動するため、この差が生まれます。置き場所のコストは 770B、走行コストは 49B に近い、と考えると読みやすくなります。

Q. Apache-2.0 だと何が嬉しいのですか？

A. 改変・再配布・商用利用が広く認められることに加え、特許条項が明文で入っている点が実務では大きいです。貢献者の関連特許について利用者へライセンスが与えられ、特許訴訟を起こした側はそれを失う構造になっています。旧来の Hunyuan-Large や Hunyuan-A13B は Tencent 独自ライセンスだったので、利用者が条文を自分で読み解く必要が減ったという変化です。

Q. オープンウェイトとオープンソースは同じですか？

A. 違います。オープンウェイトは学習済みの重みが公開されて動かせる状態、オープンソースは本来ソースコードが公開され改変・再配布が自由な状態を指します。モデルの場合、学習データや学習コードまで公開されることは稀で、再現できるのは推論であって学習ではありません。Tencent 自身は “open-source” と表現していますが、実際に配布されているのは重みと推論・微調整の手順です。

Q. 「Hy4 が Codex を並列に指揮して上回った」と読みましたが、本当ですか？

A. 本記事では確認できませんでした。 Tencent 公式リリース・Hugging Face のモデルカード・GitHub 公式リポジトリのいずれにも “Codex” や “agentic research” の記述はなく、たどれた発信源は X の投稿とその引用記事でした。当サイトは X の投稿を根拠に採用しない方針のため、事実としては書いていません。一方、モデルが自分の訓練・評価・推論の最適化に参加し、スループットを31.8%改善したという主張は公式リリースに明記されています。

Q. 個人の PC で動かせますか？

A. 現実的ではありません。公式が示す推奨構成は FP8量子化版を8GPU に分割（--tensor-parallel-size 8）する形で、FP8 でも重みだけで数百GB規模になります（この見積もりは筆者の概算です）。入口としては API（Tencent Cloud TokenHub / OpenRouter）か、CodeBuddy・WorkBuddy・Yuanbao・ima といった Tencent 製品を使う形になります。

Q. この記事の情報はどこまで確定していますか？

A. 2026年8月31日時点で、Tencent 公式リリース・Hugging Face のモデルカード・GitHub 公式リポジトリで到達確認できた内容です。性能に関する数値はすべて Tencent の発表値で、独立した第三者による検証ではありません。価格は変動し得ます。Tencent 自身も「これは Hy4 の早期版であり、Hy4 シリーズの次のモデルが近く出る」としているため、仕様や価格は今後変わり得ます。

参考