MemOS: AIシステム向けのメモリOS

ベンチマーク結果

MemOSは、主要なメモリベンチマーク（PrefEval-0t, PrefEval-10t, PersonaMem, LongMemEval, LoCoMo）において、最先端の性能を達成しており、Mem0、Zep、MemBase、MIRIX、およびSupermemoryを上回る結果を示しています。

6

ベンチマーク — 全てにおいてNo.1

Figure 1: MemOS benchmark comparison — 図1：MemOSは、PrefEval、PersonaMem、LongMemEval、およびLoCoMoの各ベンチマークにおいて、最先端の性能を達成しており、常にすべてのベースラインモデルを上回る結果を示しています。

PrefEval-0t#1

PersonaMem#1

LongMemEval#1

LoCoMo#1

1. 序文

Transformerアーキテクチャの登場と自己教師あり事前学習の成熟により、大規模言語モデル（LLMs）は現代のAIの中核となっています。膨大なデータセットで訓練されたこれらのモデルは、そのパラメータに膨大な世界の知識をエンコードし、驚くべきタスク間の汎化能力を示します。

しかし、依然として根本的な課題が残っています。LLM（大規模言語モデル）は本質的にステートレス（状態を持たない）です。各セッションは最初から始まり、過去のやり取り、ユーザーの好み、または進化する知識といった、永続的な記憶を持っていません。LLMがツールから、時間と空間をまたいで動作する持続的なエージェントへと移行するにつれて、この制限は重大なボトルネックとなります。

既存のアプローチ、例えばRetrieval-Augmented Generation (RAG) は、メモリを後付けの機能として扱います。これは、ライフサイクル管理や永続的な表現との統合が欠けている、ステートレスな回避策です。RAGは外部知識をプレーンテキストで導入しますが、異種メモリタイプの統合や、時間経過に伴うメモリの進化を管理することはできません。

この問題を解決するために、我々はMemOSを提案します。これは、AIシステム向けのメモリオペレーティングシステムです。MemOSは、プレーンテキスト、アクティベーションベース、およびパラメータレベルのメモリの表現、スケジューリング、および進化を統合し、コスト効率の高いストレージと検索を可能にします。コアとなるユニットであるMemCubeは、メモリの内容と、プロヴェナンスやバージョン情報などのメタデータをカプセル化します。

Figure 2: LLM knowledge categorization — 図2: LLMの知識の分類 - Transformer回路は、抽象的な知識と具体的な知識を生成し、それらはメモリ階層（暗黙的情報、明示的情報、および外部情報）に対応します。抽象的な知識は最終的にモデルパラメータにフィードバックされます。

2. 大規模言語モデルにおけるメモリ

LLM（大規模言語モデル）のメモリに関する研究は、4つの主要な段階を経て発展してきました。初期の暗黙的メモリと明示的メモリの定義から始まり、人間の記憶アーキテクチャに似たものへと進み、現在では体系的なメモリオペレーティングシステムが主流となっています。

Figure 3: Evolution of LLM memory systems — 図3：LLMにおけるメモリシステムの進化 - 第1段階（メモリの定義）、第2段階（人間のようなメモリ）、第3段階（ツールベースのメモリ管理）、を経て、MemOS（第4段階：体系的なメモリ管理）に至る。

Stage 1

メモリの定義と探求

初期の研究では、暗黙的なメモリ（事前学習を通じてモデルの重みにエンコードされるもの）と、明示的なメモリ（テキストやキー・バリューペアとして外部に保存されるもの）との区別が探求されました。代表的なシステムには、RAG、kNN-LMs、およびprefix tuningなどがあります。

Stage 2

人間のような記憶システム

海馬（短期記憶）と新皮質（長期記憶の定着）に触発された研究者たちは、持続的な知識の保存のために、マインドマップのような構造を持つ、複数の構成要素からなるメモリアーキテクチャを開発しました。

Stage 3

ツールベースのメモリ管理.

Mem0やZepのようなシステムは、メモリ操作のための明示的なAPI（追加、変更、更新、削除）を導入しました。しかし、これらは依然として独立したものであり、異なる種類のメモリを単一のフレームワークで統合することができません。

Stage 4

体系的なメモリ管理 (MemOS)

MemOSは、LLM（大規模言語モデル）のメモリに対して、OSレベルのリソース管理の原則を導入します。具体的には、統合されたスケジューリング、ライフサイクル制御、ガバナンスポリシー、および異なる種類のメモリ間の移行機能を提供します。これは、メモリをOSのリソースとして扱う初のシステムです。

3. MemOS の設計思想

3.1 ビジョン：Mem-trainingを次世代のスケーリング則として

AGIが、複数のタスク、役割、およびモダリティを含む、ますます複雑なシステムへと進化するにつれて、LLMは単に「世界を理解する」というだけでなく、経験を蓄積し、好みを保持し、時間とともに進化する必要があります。

モデルの性能は、従来のスケール則によって予測される上限に近づきつつあります。現在の研究パラダイムは、データとパラメータ中心の前学習から、強化学習による調整（後学習、例えば、GPT-O1、DeepSeek-R1）へと移行していますが、この変化は収穫逓減の段階に入っています。

MemOSは、次世代の技術としてMem-training Scalingを提案します。これは、LLM（大規模言語モデル）が、展開環境全体で継続的にメモリを蓄積・改善することで、事前学習後の性能限界を突破できるという考え方に基づいています。数千もの異種モデルインスタンスが、MemOSインフラストラクチャを通じて、その場で経験を蓄積し、互いに共有することができます。

Figure 4: Scaling law phases — 図4：モデルの性能向上における段階的な変化。事前学習 (GPT-3.5/4.0) → ポスト学習 (GPT-O1/DeepSeek-R1) → メモリ学習のスケーリング (MemOS, 2026年以降)。各段階は、前の段階が頭打ちになった後、新たな性能向上をもたらします。

3.2 コンピューターのOSからメモリOSへ

従来のコンピューティングシステムでは、OSがハードウェアリソース（CPU、メモリ、ストレージ）を集中管理し、効率的なアプリケーションの実行をサポートします。MemOSは、この同じ原則をLLM（大規模言語モデル）のメモリリソースに適用します。

以下の表は、従来のOSコンポーネントと、それに対応するMemOSのコンポーネントとの関連性を示しています。OSがハードウェアをアプリケーションから抽象化するように、MemOSはLLMアプリケーション向けに、異種メモリタイプ（パラメータ、アクティベーション、プレーンテキスト）を抽象化します。

Traditional OS	MemOS Module	Function
Registers / Microcode	Parameter Memory	Long-term ability
Cache / I/O Buffer	Activation Memory	Fast working state
Main Memory	Plaintext Memory	External episodes
Scheduler	MemScheduler	Prioritise ops
File System	MemVault	Versioned store
System Call	Memory API	Unified access
Device Driver	MemLoader / Dumper	Move memories
Package Manager	MemStore	Share bundles
Auth / ACLs	MemGovernance	Access control
Syslog	Audit Log	Audit trail

4. MemOSにおけるメモリモデル

4.1 メモリの3つの種類

MemOSは、LLM（大規模言語モデル）のメモリを、3つの主要なタイプに体系化し、それらが連携して、揮発性の推論状態から持続的なパラメータ知識まで、知識表現のフルスペクトルを反映するように設計されています。

📄

プレーンテキストメモリ

明示的に保存された、構造化/非構造化テキストデータ。これには、会話履歴、ユーザーの好み、エピソードノートなどが含まれます。解釈の容易性が最も高く、統合コストが最も低いです。高速アクセスを可能にする、メインメモリに類似した機能を提供します。

⚡

アクティベーションメモリ

推論と関連付けられた活性化状態 — KVキャッシュ、隠れ状態制御ベクトル。プレーンテキストとパラメータメモリを接続します。フルファインチューニングなしで、高速な動作状態の注入を可能にします。

🧠

パラメータメモリ

モデルの重みに含まれる暗黙的な知識 — LoRAアダプター、重みパッチ、ファインチューニングされたモジュール。最も深い統合レベルと耐久性を持つ。長期的なスキルと知識の定着に使用されます。

3種類のメモリについて、わかりやすく説明します： AIアシスタントをコンピューターだと考えてみましょう。プレーンテキストメモリは、テキストファイルのようなものです。読みやすく、更新も簡単です。アクティベーションメモリは、RAM（メモリ）のようなものです。アクセスは高速ですが、コンピューターが起動している必要があります。パラメータメモリは、ファームウェアのようなものです。深く組み込まれており、変更するには手間がかかりますが、永続的に保存されます。MemOSは、これら3つを統合的に管理します。

Figure 5: Memory transformation paths — 図5：3種類のメモリ間での変換パス。固定化パス（上）：ファインチューニングは、プレーンテキストをパラメータにエンコードします。キャッシュは、アクティベーションに変換します。アクティベーションパス（下）：パラメトリックデコーディングは、知識をプレーンテキストまたはアクティベーション状態として取得します。

なぜMemCubeが重要なのか： 異なる種類のメモリ（テキスト、アクティベーション、重み）は、完全に異なるデータ形式を持っています。通常、それぞれを管理するために個別のシステムが必要になります。MemCubeは、標準化された輸送コンテナのようなものです。中身が何であれ（プレーンテキスト、KVテンソル、LoRA重み）、外側のインターフェースは同じです。ライフサイクルタイムスタンプ、アクセス制御、優先度、ストレージモードなどです。これにより、異種メモリのスケジューリング、移行、および構成が可能になります。

4.2 MemCube: コアメモリユニット

MemCubeは、3種類のメモリすべてにおいて、メモリの表現、ライフサイクル管理、およびスケジューリングを標準化する、統一された抽象化レイヤーです。

各MemCubeは、メタデータヘッダー（ライフサイクルタイムスタンプ、アクセス制御リスト、ストレージプロファイル）とメモリペイロード（プレーンテキストコンテンツ、アクティブ化状態、またはパラメータパッチ）で構成されます。MemCubesは、時間経過とともに構成、移行、および統合することができます。

MemSchedulerは、コンテキストを考慮したマッチング、優先順位に基づいたロード、メモリのライフサイクル制御、および実行時メモリの注入を処理します。これにより、適切なMemCubesを、適切なLLMに、適切なタイミングで割り当てることができます。

MemCube Structure

"meta": {
  "created": "2025-04-10",
  "source": "session_3894",
  "model": "LLaMA3-8B",
  "priority": "mid",
  "expires": "2025-06-01",
  "access": ["user_483", "admin"]
}
"payload": {
  "type": "explicit",
  "format": "text",
  "content": "You are a helpful assistant..."
}

5. MemOSのアーキテクチャ

MemOSは、複雑なメモリタスクの効率的な実行、動的なスケジューリング、および適切なガバナンスをサポートするために、モジュール式の3層アーキテクチャを採用しています。

インターフェース層

MemReader — ユーザーからの問い合わせのセマンティック解析：意図、メモリの種類、および出力先を特定します。
Memory API — すべてのメモリ操作（追加、検索、更新、削除）に対する統一されたCRUDインターフェース。
Memory Pipeline — 複雑なクエリに対応するための、複数のステップからなるメモリ処理ワークフローを調整します。

Operation Layer

MemOperator — あらゆる種類のメモリを、適切なバックエンドを使用してエンコード、取得、および保存します。
MemScheduler — コンテキストに応じた優先度付きスケジューリング、きめ細やかなアクセス制御、実行時メモリ注入.
MemLifecycle — メモリの作成、昇格、降格、破棄、およびガベージコレクションを管理します。

インフラストラクチャ層

MemGovernance — アクセス制御リスト、プライバシー保護、およびすべてのメモリ操作におけるコンプライアンスポリシー。
MemVault — バージョン管理された永続ストレージで、トレーサビリティ機能とロールバック機能をサポートします。
MemStore — 共有可能なメモリバンドルマーケットプレイス — モデルインスタンス間でメモリの転送を可能にします。

MemScheduler: ディスパッチャのたとえ話。 オペレーティングシステム（OS）において、プロセススケジューラはどのプロセスにCPU時間を割り当てるかを決定します。MemSchedulerは、メモリに対して同様の役割を果たします。具体的には、推論時にどのMemCubesをLLMのコンテキストにロードするかを決定します。この決定は、現在のクエリとの意味的な関連性、優先度スコア、アクセス権限、および利用可能なコンテキストウィンドウの予算に基づいて行われます。そのため、MemOSは、すべての人々のメモリを一度にロードすることなく、数千人の同時ユーザーに対して、パーソナライズされたメモリを提供することができます。

Figure 7: MemOS full architecture — 図7：MemOSフレームワークの概要 — メモリAPIプレーン、MemOperator、MemScheduler、MemLifecycle、およびインフラストラクチャ（MemGovernance、MemVault、MemStore、MemLoader/Dumper）を含む、完全な3層アーキテクチャを示しています。

Figure 8: Execution flow — 図8：MemOSのアーキテクチャとメモリインタラクションの流れ。入力 → 意味解析 → MemCube抽出 → 3層処理 → メモリ拡張出力。

5.2 実行パスとインタラクションフロー

ユーザーがメッセージを送信すると、MemReaderは意図を解析し、MemoryQueryを生成します。MemOperatorは、MemVaultから一致するMemCubesを取得し、MemSchedulerは関連するメモリをLLMのコンテキストに注入します（プレーンテキスト、アクティベーションバイアス、またはパラメータパッチとして）。その後、モデルは、メモリを付加した応答を生成します。この一連の操作はすべて、MemGovernanceによって監査ログに記録されます。

6. 評価

私たちは、MemOSの機能を、包括的な実験とコンポーネントレベルの実験を通じて体系的に評価します。具体的には、長文コンテキストのメモリ性能、パーソナライゼーションの理解、チャンクサイズの感度、検索の堅牢性、およびKVベースの高速化といった、システム全体のパフォーマンスをベンチマークします。

6.1 長いコンテキストメモリに対するエンドツーエンド評価

MemOSは、LoCoMoおよびLongMemEvalのベンチマークにおいて、MIRIX、Zep、MemBase、Mem0、およびSupermemoryと比較評価されています。MemOS-1031は、最高平均スコア（75.80）を達成し、これは以前最高だったMemBase（72.01）と比較して5%の改善に相当します。

Method	Memory Size	LiftAge ↑	F1 ↑	ROUGE-L ↑	BLEU ↑	Avg ↑	LoCoMo ↑
No Memory	—	68.22	54.26	68.54	46.88	64.33	28.10
MIRIX	1,172	73.33	58.75	52.34	45.83	64.57	43.46
Zep	2,701	66.23	52.12	54.82	33.33	59.22	41.23
MemBase	2,102	73.12	64.65	81.20	53.12	72.01	50.18
Mem0	617	66.34	63.12	27.10	50.01	56.55	35.15
Supermemory	500	67.30	51.12	31.77	42.67	55.34	34.87
MemOS-1031	1,589	81.09	67.49	75.18	55.90	75.80	45.27

6.2 パーソナライズとユーザーの好みの理解に関する評価

MemOSは、個人化の品質を評価するために、PrefEvalおよびPersonaMemのベンチマークで評価されます。MemOSは、ゼロターン設定と10回の無関係なターン設定の両方において、最も優れたパーソナライズされた応答性能を達成し、同時に、最も低いPreference Unaware Rate（ユーザーの好みを考慮しない割合）を示しており、これはMemOSが、無関係なコンテキストに惑わされることなく、常にユーザーの好みを記憶し、適用していることを意味します。

PersonaMemベンチマークにおいて、MemOSは最高の精度を達成し、同時に許容可能なコンテキスト長を維持しました。これは、広範囲なインタラクション履歴にわたって、ユーザーの嗜好の変化を効果的に処理する能力の高さを示しています。

LiftAgeとは何ですか？ LiftAgeは、メモリシステムが、異なる時間的な距離を置いて保存された関連情報をどれだけ適切に検索できるかを測定する指標です。（つまり、「記憶がどれだけ古いか」を評価します）。高いLiftAgeスコアは、システムが、最近の記憶だけでなく、古い記憶も正しく想起できることを意味します。これは、長期的なパーソナライゼーションにとって重要な指標です。MemOS-1031は、81.09のLiftAgeを達成し、記憶を持たないベースラインの68.22と比較して、大幅な改善を示しています。

6.3チャンクサイズとトップKに対する感度

複数の指標にわたって、MemOSのパフォーマンスに与える影響について、取得されたメモリチャンクの数（Top-K）とチャンクサイズの影響を分析します。パフォーマンスは、Top-K=3およびチャンクサイズが約512トークンの場合に安定し、コンテキストウィンドウの使用量と検索品質の最適なバランスを提供します。

Figure 9: Performance trends — 図9：さまざまなメモリ構成におけるMemOSのパフォーマンス動向。Top-K=3およびチャンクサイズ≈512の場合、LiftAge、F1、ROUGE-L、BLEU、METEOR、BERTScore、およびTracing Similarityといった指標において最適なパフォーマンスが得られます。

6.4 メモリ検索の堅牢性の評価

我々は、ネットワークAPIを介したメモリ検索の効率性と堅牢性を、1秒あたりのクエリ数（QPS）が異なる状況下で評価する、集中的な評価を実施します。評価指標には、メモリへの挿入（add）および検索（search）操作の両方について、P99、P90、および平均遅延時間、ならびに成功率が含まれます。

MemOSは、すべてのQPSレベルにおいて100%の成功率を達成し、同時に最も低いレイテンシを維持しました。これは、高い同時実行状況下でも、堅牢な本番環境レベルのメモリ検索パフォーマンスを発揮することを示しています。

TTFT（Time to First Token：最初のトークンを生成するまでの時間）とは？ TTFTは、言語モデルが応答の最初のトークンを生成するまでにかかる時間を測定します。長いメモリコンテキスト（数千のトークン）の場合、アテンション計算は二乗的に増加するため、TTFTが非常に遅くなります。KVベースのメモリインジェクションは、この問題を回避するために、メモリコンテンツのアテンションキーと値のペアを事前に計算し、それらをKVキャッシュに直接注入することで、推論時の二乗アテンションコストを省略します。

6.5 KVに基づくメモリ高速化

KVベースのメモリインジェクションは、メモリの内容からキー・バリューキャッシュを事前に計算し、推論時に繰り返されるアテンション計算を省略します。ここでは、モデルサイズ（3B、7B、72B）、コンテキスト長（短い/中間の/長い）、およびクエリ長において、標準的なアテンションと比較して、最初のトークンまでの時間（TTFT）を比較します。

Figure 10: TTFT comparison — 図10：モデルサイズとコンテキスト長におけるTTFTの比較。KVベースのメモリ注入（緑色）は、標準的なアテンション（青色）と比較してTTFTを大幅に削減し、特に長いコンテキストと大きなモデル（72B）においてその効果が顕著です。

7. アプリケーションとアーキテクチャの革新

MemOSは、永続的なメモリがモジュール化され、管理可能なリソースとなるAIアプリケーションのための新しいパラダイムを提供します。主な応用シナリオは以下の通りです：

7.1 MemOSによって実現されるアーキテクチャの革新

MemOSは、メモリをシステムのリソースとして第一に扱い、複数の形式でのメモリの統合的なライフサイクル管理とオーケストレーションを可能にします。この抽象化は、以下の2つの主要なアーキテクチャ的革新をサポートします。

💎

有料メモリをモジュール式でインストール可能にする

ドメインの専門家は、MemStoreを通じて、構造化された経験的な知識を公開できます。これは、知識のプラグインのようなものです。ユーザー（学生、企業担当者、アシスタントモデルなど）は、これらの知識モジュールを購読し、ダウンロードし、アクティブ化することで、ファインチューニングなしに、すぐに特定の分野の専門知識を獲得できます。

🔧

容易なメモリ管理

ユーザーと開発者は、標準化されたタスクレベルのMemory APIコールを通じてメモリにアクセスします。これにより、ローレベルのベクトルインデックス処理、KVキャッシュ、またはコンテキストオーケストレーションを扱う必要がありません。Memoryは、従来のOSにおけるストレージサブシステムと同様に、普遍的で、長期間利用可能で、共有可能なインフラストラクチャリソースです。

7.2 応用シナリオ

💬

マルチターン対話とタスク間の連続性

MemOSは、セッションやモダリティを越えて、会話履歴、ユーザーの好み、タスクのコンテキストを維持します。これにより、コンテキストウィンドウの制限なしに、シームレスな長期的なインタラクションが可能になります。

🔄

知識の進化と継続的な更新.

ドメイン知識は、完全な再学習なしに、MemCubeの注入によって継続的に更新することができます。新しい情報は、プレーンテキストまたは活性化レベルで統合され、その後、時間の経過とともにパラメータメモリに統合されます。

👤

パーソナライゼーションとマルチロールモデリング

ユーザー固有の好み、コミュニケーションスタイル、および役割定義は、MemCubesとして保存され、推論時に注入されます。これにより、多様なユーザープロファイルに対して、真にパーソナライズされた体験を提供することが可能になります。

🌐

クロスプラットフォームメモリマイグレーション

MemCubesは、MemStoreを通じて、モデルインスタンスやプラットフォーム間でエクスポート、インポート、および転送が可能です。これにより、ユーザーが自身のAIメモリを所有できる、分散型のメモリマーケットプレイスが実現します。

8. 結論

今回、LLM（大規模言語モデル）向けに設計されたメモリオペレーティングシステム「MemOS」をご紹介します。MemOSは、次世代のLLMのために、基盤となるメモリインフラを共同で構築することを目的としています。MemOSは、パラメータメモリ、アクティベーションメモリ、および明示的なプレーンテキストメモリなど、異種メモリタイプに対して、統一された抽象化と統合された管理フレームワークを提供します。

MemCubeという抽象化技術は、制御可能で、柔軟性があり、進化可能なメモリ管理を可能にし、大規模な継続学習とパーソナライズされたモデリングのための基盤を築きます。MemOSは、評価されたすべてのベンチマークにおいて最先端のパフォーマンスを達成し、KVベースのメモリアクセラレーションによって、最初のトークンまでの時間を大幅に短縮します。

今後の展望として、私たちは、モジュール式のメモリリソースを中心とした、インテリジェントなエコシステムを構想しており、これは分散型のメモリマーケットプレイスによって支えられます。このパラダイムシフトは、ステートレスなツールから、メモリが豊富な持続的なエージェントへと移行するものであり、これはAIシステム設計における次のフロンティアを意味します。

参考文献（クリックして展開）

Li, Z. et al. (2025). Memory3: Language Modeling with Explicit Memory. arXiv:2407.01178
Vaswani, A. et al. (2017). Attention Is All You Need. NeurIPS 2017
Brown, T. et al. (2020). Language Models are Few-Shot Learners (GPT-3). NeurIPS 2020
Ouyang, L. et al. (2022). Training language models to follow instructions with human feedback (InstructGPT). NeurIPS 2022
Kwon, W. et al. (2023). Efficient Memory Management for Large Language Model Serving with PagedAttention (vLLM). SOSP 2023
Edge, D. et al. (2024). From Local to Global: A Graph RAG Approach to Query-Focused Summarization. arXiv:2404.16130
Hu, E. et al. (2022). LoRA: Low-Rank Adaptation of Large Language Models. ICLR 2022
Meng, K. et al. (2022). Locating and Editing Factual Associations in GPT (ROME). NeurIPS 2022