セルフホストした Kimi K3 にメモリがない理由
オープンウェイトが実際に提供するもの
手に入るのは、モデル（重み）、推論サーバー（vLLM、SGLang など）、そしてエンドポイントです。これは「トークンを入力し、トークンを出力する」という関数にすぎません。人々が比較対象にするコンシューマー向け製品（ChatGPT、Claude）は、アカウント、会話履歴の保存、メモリ機能、リトリーバルといった製品レイヤー全体でモデルを包み込んでいます。これらはウェイトには同梱されていません。セルフホストするということは、車ではなくエンジンだけを受け取るようなものです。
ステートレスである技術的な理由
推論は設計上、ステートレスです。モデルは目の前にあるリクエストのコンテキストのみを保持します。それがコンテキストウィンドウです。Kimi K3 の1Mトークンというウィンドウは巨大であるため、誤解を招きやすいです。コードベース全体や1年分のメモを1つのリクエストに収めることができるため、まるでメモリがあるかのように感じられます。しかし、そうではありません。リクエストを閉じれば状態は消え去り、次の呼び出しは何も知りません。大きなウィンドウは1つのタスクのための作業メモリ（ワーキングメモリ）であり、タスク間をまたぐ永続性ではありません。
これによるコスト
毎回、すべてを再送信する必要があります。「会話」を継続するには、ターンごとに全履歴を再再生（リプレイ）しなければならず、履歴が長くなるにつれてコストとレイテンシが上昇し、最終的にはウィンドウの上限に達して切り捨て（トランケーション）が始まります。マルチユーザー展開ではユーザーごとのプロファイルがないため、構築しない限りパーソナライズは不可能です。そして、何も蓄積されません。セルフホストしたエージェントはセッションをまたいでプロジェクトを学習することができません。学習内容を保存する場所がないからです。
メモリを自作する（とそのコスト）
DIYスタック
標準的なアプローチは本格的な開発作業であり、多くのチームがこれを行っています。ベクトルデータベースを立ち上げ、埋め込み（embeddings）パイプラインを構築し、チャンキングロジックを書き、何を記憶すべきかを決定する抽出処理を追加し、関連性ランキングを伴うリトリーバルを実装します。これはよく踏み固められた道であり、完全な制御を可能にします。そもそも人々がセルフホストを選ぶのと同じ理由です。
率直なコスト：うまく機能するまでに数週間のエンジニアリングが必要であり、さらに永続的な保守運用が発生します。抽出の品質、重複排除、2つのセッションで矛盾が生じた場合の競合処理、関連性のチューニングなど、それぞれが独自のチューニング課題であり、放置すると静かに劣化していきます。
データベース内の会話ログ
ベクトルスタックよりも安価な方法として、会話の書き起こしを Postgres に保存して再再生する方法があります。これはデータ量が増えるまでは機能しますが、増えすぎると送信量が多すぎる状態になるか、独自の要約処理を書くことになります。そして、要約は最も保持したかった具体的な詳細を失ってしまいます。
1Mトークンのウィンドウに詰め込む
特に Kimi K3 では魅力的です。すべてをプロンプトに詰め込むだけです。しかし、リクエストごとにすべてのトークンに対して計算コストが発生し、入力サイズに比例してレイテンシが大きくなり、詰め込まれたウィンドウ内でのリトリーバル品質は低下します。モデルは理解を深めるのではなく、より多くの情報を選別しなければならなくなるからです。また、リクエストの終了時にはやはりリセットされます。
共通の壁：これら3つのアプローチはすべて、インフラを自ら構築することを意味します。メモリ自体が構築している製品であるなら、それは正しい選択です。しかし、メモリが実際の製品に至るまでの配管（インフラ）にすぎない場合、それは回り道です。これは memory for stateless MCP servers（ステートレスな MCP サーバーのためのメモリ）と同じトレードオフです。
解決策：セルフホストスタックに永続メモリを追加する
より迅速なアプローチは、モデルはそのままにして、その横にメモリレイヤーを配置することです。MemoryLake は、抽出、競合検出、バージョン管理、リトリーバルを代わりに処理します。ドキュメントや会話を入力すると、構造化された検索可能なメモリが出力され、セルフホストした Kimi K3 がリクエストごとにそれをクエリします。ウェイトは自前のハードウェア上に留まり、メモリレイヤーはエンドツーエンドで暗号化されているため、コンテンツを読み取られる心配もありません。
ステップ 1: API キーを作成する
MemoryLake にサインインし、キーを生成して、最初のリクエストを送信します。約30秒で完了します。
ステップ 2: 最初のメモリをアップロードする
プロジェクトのドキュメント、仕様書、製品知識、ユーザーごとの事実など、デプロイメントが永続的に知っておくべき情報を投入します。ドキュメント、画像、その他のファイルすべてに対応しています。リクエストごとに再送信するのではなく、一度だけパースされてインデックスに登録されます。
ステップ 3: AI とエージェントを接続する
推論エンドポイントの手前で API を呼び出します。リクエストに関連するメモリを取得し、システムメッセージやプロンプトに含めることで、各 Kimi K3 の呼び出しが白紙状態ではなく、情報を持った状態で開始されるようにします。エージェントフレームワークが MCP に対応している場合は、そこで接続してください。同じメモリが Claude、Codex、OpenClaw、その他のエージェントでも利用可能になり、セルフホストしたモデルと商用ツールが1つのコンテキストを共有できるようになります。
ステートレス推論の実際のコスト
リプレイ税
メモリレイヤーがない場合、継続性を維持するには、呼び出しのたびに履歴を再再生する必要があります。セルフホストしたハードウェアでは、APIの請求書ではなく、GPU時間とレイテンシとしてコストを支払うことになります。しかし、無駄であることに変わりはありません。すでにモデルに伝えた内容を再読するために計算資源が消費され、ターンを重ねるごとにその無駄は膨らみ、最終的にはウィンドウの制限によって切り捨てを余儀なくされます。
リプレイではなくリトリーバル
モデルの横にメモリを配置することで、各リクエストは履歴全体ではなく、関連する部分（事実、決定事項、一節など）のみを保持するようになります。入力が短くなり、応答が速くなり、実際の作業に使えるウィンドウの余裕が増えます。自前のデプロイメントと並行して商用 API も実行している場合、MemoryLake の Token Saving Calculator（トークン節約計算ツール）でその効果を予測できます。
セルフホストメモリのベストプラクティス
ウィンドウは作業用に、レイヤーは知識用に
Kimi K3 の1Mトークンは、現在のタスクが本当に必要とするもののために使用してください。永続的な知識はメモリレイヤーに属し、オンデマンドで取得されるべきです。これにより、プロンプトが無限に肥大化するのを防ぐことができます。
生の書き起こしではなく、事実と決定事項を保存する
完全なログは保存コストは安いですが、使用コストは高くなります。抽出された事実、決定事項、ドキュメントは、会話履歴の壁よりもはるかに優れたリトリーバル結果をもたらします。
ユーザーごと、またはプロジェクトごとにメモリのスコープを分ける
マルチテナント展開では、初日から分離が必要です。ユーザーまたはプロジェクトごとに1つのスコープを設定することで、リトリーバルの関連性を維持し、コンテキストが相互に漏洩するのを防ぎます。
結論
Kimi K3 のオープンウェイトは真の変革です。自前で実行できるフロンティアクラスの実力であり、コンテキストの問題が解決されたかのように感じさせるほど巨大なウィンドウを備えています。しかし、実際は解決していません。ウェイトはステートレスなエンジンであり、メモリは追加しなければならないレイヤーです。メモリ自体が製品であるなら自作してください。そうでなければ、エンドポイントの横に既製のメモリレイヤーを配置し、エンジニアリングリソースを実際に提供する製品の開発に集中させましょう。モデルはあなたのハードウェアで動作します。メモリはただそこに存在すればよいのです。