「Hy Memory 2.0」という見出しの生成タイトルカードには、サブタイトル「3つの層、同日にオープンソース化。」が付いている。3枚のカードには「モデル — Hy-Memory-30B-A3B、合計30B/アクティブ約3B、262,144トークンのコンテキスト、Apache 2.0」、「エンジン — PyPI上のhy-memory 2.0.1、チャット/作業/コーディングのシーン、3つのモード:lite、pro、ultra」、「アプリ — MemHub、CLIに加えてmacOSおよびLinuxランタイム、1つのローカルメモリを共有する10個のAIツール」と書かれており、フッターには、すべてのベンチマーク数値はTencent自身によるもので、再現されていないと注記されている。
Guides & Insights

Hy Memory 2.0が登場:Tencent、メモリライター、フレームワーク、Macアプリを一挙にオープンソース化

著者

Elias Hawthorne

公開日

最新モデル · 20すべてのモデルを見る →
ベンチマーク:Artificial Analysis · 毎日更新
すべての記事に戻る

Tencent Hunyuanは今週、一度に3つをリリースしたが、今日インストールできるのはそのうち2つだけだ。Hy-Memory-30B-A3Bは、300億パラメータのMixture-of-Expertsモデルで、その仕事はメモリを書くことに尽きる——エージェントが何を保持し、それをどう表現し、新しい証拠が古い情報をどう上書きするかを決める。Hy Memory 2.0はそれを取り巻くフレームワークだ。Pythonパッケージのhy-memoryが、チャット、ワーキング、コーディングのメモリをカバーする。そしてMemHubはアプリだ——ローカルファーストのCLI兼macOS製品で、10種類の異なるAIツールから会話履歴とコーディングのトレースを引き出し、自分のディスク上にある1つのメモリストアにまとめる。発表記事の見出しは、Hy-Memory-30B-A3BがClaude Opus 5を主要なメモリフレームワーク全体で上回る、というものだ。それはその範囲では事実であり、興味深いのはそれがどこまで当てはまるかだ。4つのフレームワークのうち3つでは差は0.6ポイント未満で、比較全体は各ベンチマークの5分の1で行われている。私たちが追跡してきたプロバイダーの障害とロールバックはすべて、Orca AI Incident Archiveに記録されている。このアーカイブには、このインシデントの隣接エントリとともに完全な記録セットが収められている。

以下はすべて、Tencent 自身のリポジトリ、パッケージレジストリ、技術レポートから読み取ったものか、Tencent 自身の主張として示されているものです。ここにあるものはどれも、他の誰かによって再現されたものではありません。というのも、本稿執筆時点では他の誰もそれを実行していないからです。

実際にリリースされたものと、その時期

3つのレイヤーは約24時間以内に相次いで登場し、リリースノートには、そのうちどれが完成しているかについて異例なほど具体的に記されている:

• モデル — tencent/Hy-Memory-30B-A3B は 2026年10月15日(09:52 UTC)に Apache 2.0 の下で Hugging Face に公開され、技術レポート arXiv 2610.22196 も同日に提出されました。

• このフレームワーク — hy-memory==2.0.1 は 2026年10月15日 17:24 UTC に PyPI へアップロードされ、モノレポは同日にオープンソース化されました。GitHub の v1.0.0 リリースタグは 10月16日 08:44 UTC に切られました。

• アプリ — MemHubのリリースアセットは存在します:GitHubの集計で303 MBの公証済みmacOS arm64ディスクイメージに加え、245 MBと251 MBのLinux arm64およびx64ランタイムバンドル。Windowsは非対応として記載されています。

• このギャップ — プロジェクト自身の変更履歴には、MemHubは「まだ公開リリースがない」こと、そのソースバージョンは1.0.0(ビルド4)であること、そしてnpmでの公開とGitHub Releaseの成果物がいずれもまだ保留中であることが記載されています。使用する予定のnpmパッケージであるmemhub-cliは、レジストリから404を返します。ディスクイメージはリリースに添付されていますが、それらを取得するはずのコマンドラインインストーラーは公開されていません。

その最後の点は二度読む価値がある。なぜなら、それは正式リリースとリリース候補の違いだからだ。Apple版は署名と公証が済んでおり、それは実際の作業だ。リリースページにはわずかながらダウンロード数が積み上がっている。しかし、文書化されたインストール手順は、執筆時点では存在しないnpmパッケージから始まっている。今週MemHubを試すつもりなら、ワンラインインストールではなく、ソースをチェックアウトする前提で見積もっておいてほしい。

A screenshot of the GitHub release page for Tencent-Hunyuan/Hy-Memory, showing the v1.0.0 release titled "Hy Memory and MemHub v1.0.0", a commit hash, a description stating that the initial release assets include the notarised macOS arm64 DMG and validated Linux x64 and arm64 runtime bundles with further macOS and manifest assets to follow, and an assets list of five entries: MemHub-1.0.0-macos-arm64.dmg at 303 MB, memhub-runtime-linux-arm64.zip at 245 MB, memhub-runtime-linux-x64.zip at 251 MB, plus the source code zip and tar.gz.A screenshot of the Hugging Face model card for tencent/Hy-Memory-30B-A3B, showing the Tencent org header, the apache-2.0 licence badge, the arxiv:2610.22196 tag, the hy_v3 architecture tag, the 30B parameter count with BF16 and F32 tensor types, the Text Generation pipeline tag, English and Chinese language tags, and a library listing of Transformers and Safetensors.

Hy-Memory-30B-A3B、そのモデル

設定ファイルは、リリース全体の中で最もロマンチックとは言えず、最も役に立つ文書です。それは、何か珍奇なものではなく、標準的でよく理解されたMoEの形状を記述しています:

• パラメータ — 合計30B、トークンあたり約3Bがアクティブで、これがA3Bという接尾辞の意味です。

• アーキテクチャ — 48層。うち1つは密(dense)層、47はスパースMoE。各ブロックあたり128エキスパートで、top-8ルーティングと1つの共有エキスパートを備える。隠れサイズ2,048、エキスパート中間幅768、クエリキー正規化付きの32アテンションヘッド対4キーバリューヘッド、エキスパートバイアス項とスケーリング係数2.826を備えたシグモイドルーター。

• コンテキスト — 262,144ポジション、RoPEベースは11,158,840。

• フットプリント — safetensorsシャード51個、BF16で約60.1 GB。Tencentが提供したのはこの精度のみです。

• サービング — このカードは vLLM を中心に書かれており、v0.31.0 に対してテスト済みで、OpenAI 互換エンドポイントの背後に置かれ、さらに SGLang と Docker Model Runner も対応ランタイムとして挙げています。どの推論プロバイダーによってもデプロイされておらず、Hugging Face の検索インデックスにも GGUF、FP8 や NVFP4 のビルド、ファインチューンは見つかりません。

その不在が実用的な障害だ。60 GB の BF16 チェックポイントだけを出荷しているベンダーは、モデルをどこで動かすことを想定しているかを示している。そしてその答えは、あなたがすでに所有しているか、データセンターで借りているマシンだ。ワークステーションで評価できる量子化版の兄弟は存在しない。

モデルは Tencent 自身のクイックスタートで、reasoning_effort: "no_think" と temperature 0.0 を指定して駆動される。メモリライターは会話の各ターンで起動し、何を保持するかを決めるため、熟考するのは誤ったトレードオフである。決定論的で、短い出力で、安価である必要がある。この設計上の選択は、そもそもこのモデルが存在する最大の根拠でもある。なぜなら、それはフロンティアのチャットモデルが最も無駄を生む、まさにそのワークロードだからだ。

55.49を、本来あるべき読み方で読む

Tencentは、Mem0、MemOS、そして自社のHy-Memoryという3つのメモリーフレームワークにわたってライターを訓練し、その後、訓練から完全に除外されていた4つ目のEverMemOSで評価した。1つのハーネスを保留しておくことは、転移の主張を検証する正しい方法であり、フレームワーク間転移はこの論文の中心的主張そのものである。

その結果はTencent自身によるもので、再現されていない:

• Hy-Memory-30B-A3B — 4つのハーネスにわたるマクロ平均は55.49。

• Claude Opus 5 — 54.62。

• DeepSeek V4.1 Flash — 53.64

• Tencent Hy3 — 51.63

• Qwen3.6-35B-A3B — 50.37.

• Hy3-A3B Base — 47.66。メモリ特化トレーニング前の同じモデルであり、注目の7.8ポイントのトレーニング向上はここから生まれている。

• Qwen3-30B-A3B — 44.37.

ハーネス別に分解すると、その勝利の幅は狭まる。Claude Opus 5 に対する差は、Mem0 では 54.02 対 53.43、Hy-Memory では 60.55 対 60.53、MemOS では 50.51 対 50.50、EverMemOS では 56.89 対 54.04 である。その4つのうち3つは、月桂冠をまとった統計ノイズにすぎない——Hy-Memory ハーネスにおける0.02ポイントのリードは、リードではない。3Bアクティブの専門モデルとフロンティアモデルの間の隔たりはすべて、訓練から除外された唯一のハーネスにあり、そこでは差が2.85ポイントで、その主張がチューニングによって合わせ込まれている可能性も最も低い。

設計上の詳細も2つあり、これらは数字と同じくらい重要です。メインマトリックスのすべての数値は、ベンチマーク全体ではなく、固定された20%のサブサンプルで実行されており、評価ではライターだけを変化させ、ハーネス、プロンプト、検索設定、回答モデル、ジャッジは固定しています。この2つ目の選択は、検証対象の変数を切り分けるという点で優れた実験作法ですが、それはTencentのハーネスであり、Tencentのジャッジです。この表は、リポジトリが添付された仮説として扱ってください。これは、大半のリリース当日の主張が伴うものより多く、結果よりは少ないものです。

フレームワークの数字の方が、より大きな主張だ

モデル比較のほうは、Tencentがその投稿に載せた引用文だ。フレームワーク比較のほうは、それが成り立つなら読者のアーキテクチャを変えることになるものだ。

同社の自社サイトでは、Hy Memory 2.0 はオープンソースのメモリフレームワークの中で4つのベンチマークにおいて第1位にランクされており、Mem0、MemOS、EverOS、OpenViking、RepoMemory、および単純なスライディングウィンドウ RAG ベースラインを上回っています。これらは、対応する3つのシーンすべてにわたるものです。

• チャット — LoCoMoで72.6%、1,527件の非敵対的質問において。

• 動作中 — MemoryArena(旅行計画とまとめ買いのスイート)で平均55.31%、次点のフレームワークを10.2ポイント上回る。

• コーディング — CodeMemoryBench の質問応答では 64.2%、解決率 35.6%、さらに SWE-ContextBench では解決率 28.3%。

• フットプリント — 入力トークンの6.06%のメモリ保存量で、比較対象のフレームワークにおける31.9%から41.2%に対して。

A generated scoreboard headed "Hy Memory 2.0 — the framework scoreboard", showing six rows: Chat memory on LoCoMo at 72.6%, Working memory on MemoryArena at 55.31%, Coding memory on CodeMemoryBench at 64.2% question answering and 35.6% solve rate, Repository context on SWE-ContextBench at 28.3% solve rate, Memory bank size at 6.06% of input tokens against 31.9% to 41.2% for the compared frameworks, and Evaluation on a fixed 20% subsample with DeepSeek V4.1 Flash as the writer and GPT-5.6-sol as judge; the first four rows are marked first among open-source frameworks, with a footer noting every figure is Tencent's own and unreproduced.

フットプリントの数値こそ、盗む価値のあるものだ。メモリシステムが本番環境で失敗するのは2つの理由による。すなわち、忘れるべきでないものを忘れてしまうこと、そして際限なく肥大化することだ。要約対象の会話の6パーセントのコストで済むバンクは、40パーセントかかるバンクとは運用上の位置づけが異なる。そして、精度の順序づけが精査に耐えるかどうかにかかわらず、ルーティングとコストに関心を持つ読者が気にすべき次元はまさにそこである。評価プロトコルも併せて公開されている。メモリモデルは DeepSeek V4.1 Flash、回答および判定モデルは GPT-5.6-sol、ストレージは入力トークンに対するバンクのトークン数として測定され、バンクは生成されたメモリのみをカウントする。

Tencentはまた、金融、ニュース、ナレッジマネジメント、オフィスエージェント、ソーシャル、ゲーミングにまたがる社内導入事例も列挙している——40ポイントのマルチホップ改善を達成した株式アシスタントのリコールテスト、ナレッジベースプラグイン、100点満点で平均91.68点のニュースアプリ選好評価——。これらは同社自身の製品指標であり、ベンチマークではない。何かに勝っている証拠としてではなく、実際にどこかで稼働している証拠として読むべきだ。

MemHub は、ほとんどの読者が実際に使える部分だ

モデルにはGPUが必要だ。フレームワークにはエンジニアチームが必要だ。MemHubにはノートパソコンが必要だ。

これはローカルファーストのデスクトップおよびコマンドラインプロダクトで、すでに許可したAIツールの履歴を単一の管理されたランタイムと単一のデータディレクトリに統合します — そのため、あるコーディングエージェントで設定した好みを次のエージェントでも利用できます。Tencentは10のサポート対象統合を挙げています: WorkBuddy、Cursor、Codex、Claude Code、OpenCode、OpenClaw、Qwen Code、Pi、Hermes、DeepSeek Harness。記載されているデータパスは ~/.one-memory で、作業およびコーディングのメタデータにはSQLite、デフォルトのストアとしてChromaDBとKuzuを使用し、セキュリティドキュメントでは、本製品が画面内容、アクセシビリティツリー、OCR、クリップボード、バックグラウンド音声を収集しないことが明記されています。

懐疑的に見るべき主張は、削除に関するものだ。CLI は三つのレベルを区別している。npm パッケージをアンインストールすると CLI だけが削除され、memhub uninstall はサービス、管理されたランタイム、CLI リンクを削除するがメモリは保持し、別個の memhub delete-data コマンドだけがストアを削除する——ランタイムを停止し、正確なパスを確認した後に。これはこのカテゴリのほとんどのツールより優れた設計であり、インストーラーがまだ公開されていないリリースにおける意図された動作の説明でもある。重要な作業に採用する人は、保持されたくないものを任せる前に、削除パスを自分で確認すべきだ。

まだ未確認のもの、はっきり言えば

• いかなる種類の独立したベンチマークも存在しない。サードパーティ製ハーネスの実行も、アリーナへの掲載もなく、Tencent以外で再現されたものは一切ない。

• クロスハーネス表の再現はなく、とりわけ、単一のベンダー実行だけで転移仮説全体を支えている、ホールドアウトされたEverMemOSの結果については再現されていない。

• 量子化を行っていないため、60 GB 未満の実測メモリフットプリントも、ワークステーション規模の評価パスも存在しない。

• ホスト型エンドポイントなし、モデルカードに記載された推論プロバイダーもなし。

• MemHub の npm パッケージは公開されていないため、ドキュメントに記載されたインストール手順はまだエンドツーエンドでは機能しません。

• 会話あたりのコスト数値がない。メモリ書き込みは高頻度・短出力のワークロードであり、書き込みあたりのトークン数や、メモリ対応アシスタントをユーザー1人あたり月々実際に運用するのにいくらかかるかを公表した者は誰もいない。

ルーターが適する場合と、適さない場合

これについては正確に述べてください。誇張するのは簡単だからです。Hy-Memory-30B-A3BはOrcaRouterのカタログにはなく、当社はそれをホストしていません。書き手に至る経路は、Hugging Face上のチェックポイントとご自身のハードウェアです。ルーティングレイヤーがあっても、そのことに変わりはありません。

ルーターが担う範囲は、ハーネスの残り半分にあたる。メモリシステムは書き込みパスと読み取りパスからなり、Tencentが公開した評価は、読み取りパスが通常どのようなものかを明言している。つまり、書き手が何を保存するかを決め、別のフロンティアモデルがそのバンクを読み戻して回答する。Tencent自身の構成では、メモリモデルがDeepSeek V4.1 Flash、回答とジャッジがGPT-5.6-solだ。OrcaRouterは両方を1つのキーで、定価のまま、マークアップなしで提供する。そのため、ベンダーの価格変更は、次の契約更新時ではなく当日に私たちの側で反映される。

ルーティングDSLは、このアーキテクチャに特に適合する部品です。それは、セルフホスト型エンドポイントとホスト型エンドポイントを単一の呼び出しに組み合わせます。これはまさにメモリシステムの形です — 自分で運用する書き込みパス上の安価な専門特化モデルと、借用する読み取りパス上のフロンティアモデル。同じ構成により、危険な部分も生き残らせることができます。ライターを自分の Hy-Memory-30B-A3B デプロイに向け、汎用モデルを自動フェイルオーバーの背後に置けば、書き込みパスが不調でもアプリケーションを落とす代わりに回答が劣化するだけです。このパターンは、ライターを稼働させる前に構築する価値があります。書き込みパスが専門チェックポイントでも、メモリプロンプト付きの汎用モデルでも同じだからです。

誰が行動すべきで、誰が待つべきか

長期記憶を持つエージェントを運用していて、すでにGPUを持っているなら、1週間を費やすのに正直な場所は書き込みパスだ。チェックポイントはApache 2.0で、メモリライターは、誰かのベンチマーク表ではなく自分のトラフィック上で価値を測れるまれなモデルだ。運用者ではなくユーザーなら、MemHubが興味深いものであり、インストーラーが存在し、T​encentの外の誰かが削除パスを試すまでは待つべきものでもある。そして、発表の強みでモデルを選ぶなら、正しい姿勢はリリース自体が招いている姿勢だ。55.49対54.62は3つのハーネスでは引き分けで、4つ目では実際の差であり、その4つ目こそ誰も確認していないものだ。

この記事で比較したモデル2

この記事から検出 · ベンチマーク:Artificial Analysis · 毎日更新