長いコンテキストのLLM推論、KVキャッシュをディスクに逃がすべきかGPUで再計算すべきか、実は「常に正解」は存在しません。それを定量的に判断する仕組みを作った論文です。 タイトル: Building py-kvcache: A Performance Characterization of External KV Caching for vLLM with NVMe SSDs URL: 📝 概要 vLLM向けの外部KVキャッシュシステム「py-kvcache」を提案。io_uringによる非同期I/OでPython実装ながらSSDの読取帯域13.5GB/sをほぼフルに引き出します。 ❗ 解決する課題 既存の外部KVキャッシュ（LMCacheなど）は「いつ使うべきか」の判断基準を持たず、短いプリフィクスや高速GPUでは再計算の方が速いのに無条件にディスクから読み込んでしまう問題がありました。 ⚙️ 方法論 リクエストの待機時間中にディスク読込を先行させる「スケジューラ認識プリロード」と、TTFT改善が見込めない場合はロードを拒否する「ブレークイーブンゲート」を導入しています。 📊 実験結果 LongBenchのマルチ文書QAでGPU再計算比6.02〜7.43倍、LMCache比2.77〜3.64倍高速化。マルチターンのSCBenchでは、ネイティブvLLMのディスク読取3.4TBに対しpy-kvcacheは85GBに抑え、完了時間も1200秒超から480秒へ短縮しました。 🖥️ ユースケース H100のような高性能GPUでは外部キャッシュなしでも十分高速なのに対し、RTX 4000 Adaのような手元のGPUでは外部キャッシングが明確に有効という、ハードウェア次第の判断指針も提供しています。 #LLM推論# #vLLM#

# AIエージェントをソフトウェアに組み込むプラクティス # Adaptive Timeout & Budget-Bounded Retry｜適応タイムアウト＋予算律速リトライ 🎯 リトライ3回で固定していませんか？LLMリトライ1回で数千トークン消費する世界では、回数でなく予算で律速すべきです。 固定タイムアウト・固定回数リトライは、エージェント時代のエラー処理には力不足です。 🔥 解決する課題 エージェント実行ではツール呼び出し（数秒）とLLM推論（数十秒〜分）でレイテンシ特性が全く異なります。同じタイムアウトで括ると、前者は待ちすぎ・後者は早すぎで切れます。さらに固定3回リトライでも、LLMリトライは1回あたり数千トークンを消費して予算を突き破りえます。429（レート制限）とスキーマ不適合を同じリトライで処理しても、後者は同じプロンプトでは直りません。 💡 提案パターン Adaptive Timeout & Budget-Bounded Retry（適応タイムアウト＋予算律速リトライ）は、操作クラス（ツール呼び出し・LLM推論・セッション全体）ごとにタイムアウトを分けます。リトライは固定回数でなく残りトークン予算で打ち切ります。エラーを一時障害・コンテンツ起因・コンテキスト長超過の3種に分類し、それぞれ指数バックオフ・self-correction・要約分割と対応戦略を切り替えます。予算を一定割合消費したら縮退（軽量モデルへのフォールバック）に移行し、尽きたらfail-fastで停止します。 ✅ 選定条件 使うとき： - LLM・ツール・外部APIなどレイテンシ特性の異なる操作を組み合わせている - リトライ1回あたりのコストが無視できない（LLM推論を含む） - ネットワーク一時障害とコンテンツ起因エラーの両方が発生しうる 使わないとき： - 単発LLM呼び出しのみで固定タイムアウトで十分な場合 - 非冪等な書込のみでリトライ自体が禁止される環境 ⚠️ 落とし穴 - 429応答のRetry-Afterヘッダを無視して自前バックオフだけで攻めると、プロバイダ側でさらに絞られます。必ずRetry-Afterを尊重してください - 非冪等書込のリトライには冪等キーが必須です。冪等キー無しのリトライは二重実行を招きます - self-correctionでエラー文をそのまま詰めすぎるとコンテキストが膨張してコンテキスト長超過に遷移します。エラー要約は200トークン以内に切り詰めましょう 🔧 実装方針 - タイムアウトを操作クラス別に定義します。ツール呼び出しは概ね10〜30秒、LLM推論は全体60〜120秒（ストリーミング時はトークン間5〜15秒）、セッション全体はdeadlineで律速します - エラーを3種に分類し、一時障害（429/5xx/timeout）は指数バックオフ＋ジッタで再送、コンテンツ起因（スキーマ不適合等）はエラー要約をコンテキストに追加してself-correction、コンテキスト長超過は要約・分割で対処します - リトライ上限は固定回数でなく残りトークン予算で判定します。一時障害は予算の90%まで、self-correctionは70%までを上限とします - プロバイダごとに独立したサーキットブレーカ（Closed/Open/Half-Open）を設置し、連続失敗が閾値に達したら遮断して縮退ラダー（軽量モデル→キャッシュ応答→静的フォールバック→fail-fast）を降ります - 全プロバイダが共通インターフェースを実装するプロバイダ抽象化層を設け、フォールバック先の切り替えを呼び出し元に対して透過的にします #AIエージェント# #ソフトウェアアーキテクチャ#

# AIエージェント開発の意思決定ポイント # タイムアウト｜Timeout 🎯 ポイント 「全部30秒」のタイムアウト、まだ使っていませんか？ AIエージェントでは、ツール呼び出しは数秒、LLM推論は数十秒、セッション全体は数十分。レイテンシ特性が全く異なる操作が組み合わさるため、一律のタイムアウトでは機能しません。層ごとに分けるのが第一歩です。 📋 概要 タイムアウトは、エージェントが特定の操作の完了を待つ最大時間を制御するダイヤルです。従来のWebサービスではHTTPリクエストに30秒程度を設ければ済みましたが、AIエージェントでは1リクエストが長く、レイテンシのばらつきが大きく、プロバイダの可用性も不安定です。 タイムアウトが短すぎると一時的な遅延で正常な処理を殺し、長すぎると障害を隠蔽してリソースを無駄に占有します。操作クラスごとにタイムアウトを分け、さらに観測データに基づいて動的に調整する仕組みが理想です。 🔍 意思決定のポイント タイムアウトの値はlatency_budget（ユーザーや下流システムがどれだけ待てるか）を最も強く反映します。少なくとも3層に分けて設定するのが基本です 📐 1. ツール呼び出し層 — 外部API・DB・ファイル操作。ツール種別ごとにさらに細分化も 2. LLM推論層 — 入力トークン数とモデル負荷で大きく変動。小型/大型モデルで応答時間が10倍異なることも 3. セッション全体層 — 「ユーザーがこのタスクに何分待てるか」から逆算 各操作のP99（99パーセンタイル）を観測し、安全係数1.5〜2.0倍を掛けた値が出発点です。P99がまだない立ち上げ初期は目安値から始め、1〜2週間の運用データで切り替えます。 💡 要点と詳細 目安値 📊 - ツール呼び出し（一般） → 10〜30秒。DBクエリは5秒でも長い場合あり - LLM推論（全体） → 60〜120秒。長文生成タスクは上限引き上げ - LLM推論（トークン間） → 5〜15秒。ストリーミング時のプロバイダ障害早期検出に有効 - LLM推論（TTFT） → 15〜30秒。入力が長いほど延びる - セッション全体 → 数分〜数十分。対話型は短く、調査・分析型は長く ストリーミングを使う場合は、全体タイムアウトよりトークン間タイムアウトの方が本質的な監視指標です 🔍 正常な推論では数百ミリ秒〜数秒間隔でトークンが返るため、15秒の無応答はプロバイダ側の異常を強く示唆します。 ⚖️ トレードオフ タイムアウトが短すぎると、複雑な推論タスクでLLMが高品質な回答を生成している途中で処理が中断されます ⏱️ Chain of Thoughtが深くなる正当なケースや、大量コンテキストの入力処理中にタイムアウトすることも。ピーク時のプロバイダ遅延で断続的に失敗し、リトライの連鎖が始まります。 タイムアウトが長すぎると、プロバイダが応答しないまま数分間スレッドが占有され、他のリクエストが詰まります 🚫 ハングしたツール呼び出しが放置され、ユーザーは「いつ終わるか分からない」最も苦痛な状態に。障害の検出も遅れます。 タイムアウト値の変更はリトライ戦略に直結します。短くすれば発火頻度が上がり、リトライが増えます。リトライ予算やセッション全体の予算と一体で調整する必要があります。 🛠️ ユースケース 対話型チャットアシスタント 💬 ユーザーが数秒以内の応答を期待。ツール3〜5秒、LLM推論15〜30秒（ストリーミングで即座にトークンを返し始める）、セッション全体60〜120秒。体感レイテンシの短縮にストリーミングが効果的です。 調査・分析エージェント 🔬 数分の処理が許容される。ツール10〜60秒、LLM推論60〜180秒、セッション全体5〜30分。タイムアウトよりコスト・ステップ数の予算が主要な制約に。 自動コードレビューエージェント 💻 大きな差分では入力トークンが数万に達し、TTFTが延びる。入力トークン数に応じてTTFTタイムアウトを動的に調整する仕組みが有効です。 タイムアウトとキャンセルは異なります ⚠️ タイムアウトはクライアント側で待つのを止めるだけで、プロバイダ側の処理は続行されている可能性があります。課金はプロバイダ側の処理量に基づくため、キャンセルリクエストも送信することを推奨します。 #AIエージェント# #ソフトウェアアーキテクチャ#

💾 TL;DR: 別ノードのGPUが計算したKVキャッシュを、CXLメモリ経由でそのまま使い回して最大36.6倍高速化。SeagateがKubernetesネイティブな共有CXLメモリの仕組みを提案しました。 タイトル: Composable CXL Memory as a Kubernetes-Native Shared Memory for LLM Serving URL: 📌 ポイント 🧩 Kubernetes DRAドライバでCXLリージョンをスケジュール可能なリソース化 🗂 Redis等の外部調整なし、リージョン内蔵のスロットディレクトリでKV管理 🚀 32Kトークンのプレフィックスでクロスノード再利用が再計算比36.6倍高速 🎯 ヒット率は95.4〜99.5%を達成 ⚖️ クロスノードと同一ノードの遅延差はわずか1〜4% 🐢 同一ノードのGPU VRAMキャッシュと比べると1.15〜1.70倍のペナルティあり 🔧 実測帯域は5.8GB/sでファブリック上限27GB/sの一部、ゼロコピーDMAに伸びしろ 複数GPUノードでプレフィックスを使い回したいときの、地味だけど効く実用的な選択肢だと思います。 #LLM推論# #Kubernetes#

🔁 「じっくり考えるほど賢くなる」AIを、勾配爆発を起こさずに学習させる方法が見つかりました。 タイトル: Thinking with Looped Flows URL: 再帰的に隠れ状態を更新して「考える」ループモデルは、これまでBPTT（時間方向の逆伝播）の不安定さに悩まされてきました。Looped Flowsは拡散モデルの学習原理を借りることでこれを解決した手法です。注目ポイントを3つ紹介します。 🧠 BPTTなしで再帰計算を学習 ノイズレベルを徐々に減らしながら各ステップをローカルな損失で学習することで、勾配消失・爆発を起こさずに「考え続ける」状態を安定して学習できます。 ⏱ 推論時に計算量を後から増やせる 学習時より細かい時間刻みで推論するだけで性能が伸び、Sudokuでは8ステップの74.5%から128ステップで97.9%まで向上します。 🏆 ARC-AGIで既存手法を上回る ARC-AGI-1で58.8%、ARC-AGI-2で12.2%を達成し、いずれも従来のループモデル手法を上回りました。 推論時にじっくり計算するほど賢くなる、というテスト時スケーリングの新しい実現方法として興味深い研究です。 #LLM推論# #機械学習#

LLMは数学の問題で人間より高い正解率を出せるようになりました。でもそれは「きちんと積み上げて理解している」からでしょうか？ タイトル: Do LLMs Exhibit Coherent Knowledge Structures in Mathematical Reasoning? A Perspective from Knowledge Space Theory URL: ❓ LLMは前提知識をきちんと積み上げて正解しているの？ 💡 正解率自体は人間79.6%に対しLLM最高92.5%（Qwen3-80B）と上回りますが、前提を完全に満たした上での正解の割合は人間72.7%に対しLLMは48.16%にとどまります。正解していても土台が抜けているケースが多いということです。 ❓ 前提知識をヒントとして教えてあげれば改善する？ 💡 実は前提に基づくヒントを与えても、無関係な例を与えた場合とほとんど差が出ませんでした。構造的な前提推論ではなく、表層的なパターンマッチングに頼っている可能性が高いです。 ❓ 賢いモデル同士なら、似たような知識の持ち方をしているはず？ 💡 人間の学習者グループ間では知識の重なりが0.9以上と高いのに対し、LLM同士では0.38〜0.6程度しか重なりません。強いモデルほど人間から離れていく傾向も見られました。 ❓ つまりこの研究が示しているのは？ 💡 精度という指標だけでは、LLMの「理解の仕方」のズレは見抜けないということです。知識空間理論という新しい評価レンズを使うことで、正解率の裏にある断片的な知識構造が浮かび上がります。 #LLM評価# #数学的推論#

⚙️ 月125兆トークンを捌くLLM推論基盤は、どう信頼性とコストを両立しているのか。リクエスト数ではなく「モデルユニット」でコストを測り、GPUコストを80%削減しつつ安定運用を実現したDatabricksの実戦知です。 タイトル: Reliable LLM Inference at Scale URL: 📝 概要 本記事は、大規模なLLM推論を信頼性高く・コスト効率よく運用するための、Databricksのアーキテクチャと手法を解説します。GPUインフラの不安定さや、予測困難なリクエストコストといった本番特有の課題に、具体的な仕組みで対処しています。 ❓ 解決する課題 ・GPUインフラはCPUより本質的に不安定で、prefill/decodeを分離した構成では単一障害が複数ノードに波及します ・リクエストコストは事前推定が難しく、出力トークン生成がレイテンシを支配する一方、その時間は予測困難です ・高負荷時には、リクエストの組み合わせ次第で健全なサーバが突然不健全状態に陥ります 💡 方法論と提案手法 ・コストを「α×入力トークン＋β×出力トークン＋γ×マルチモーダル」とモデル化する「モデルユニット」抽象を導入し、係数はモデル/ハードウェアごとの自動ベンチマークで決定します ・自動シャーダーDicerが、キュー長でなくモデルユニットで測ったサーバ負荷でルーティングし、ステートフルセッションでキャッシュヒット率を高めます ・保留リクエスト数でなく「モデルユニット利用率」でオートスケールし、ピーク閾値に近づくと増設します ・ブラックボックスのヘルスチェックでサイレントハングを検知し、ヘルスチェックを最高優先度にして誤検知を防ぎます 🎯 ユースケース Superhumanやコーディングエージェント、サポートボットなど、トラフィックが数時間で急増するマルチテナントのエージェント型アプリを支えます。LLMアプリが単一テナントから共有本番環境へ移る局面に直結します。 📊 実験結果 ・コスト認識オートスケーリングで、静的なピーク見込みプロビジョニング比のGPUコストを80%超削減しました ・ヘルスチェックの誤検知を週数件からゼロへ、サイレント障害の検知・回復は5分未満に収めました ・画像処理をTorchvisionへ切り替え、OMP_NUM_THREADSをコンテナ上限に正しく設定し、同じレプリカ・負荷でスループットを3倍超に跳ね上げました ・月125兆トークンをマルチテナントで処理しています #LLM# #MLOps#

# AIエージェント開発の意思決定ポイント 🎯 **ポイント** LLMプロバイダの429エラー、5回リトライしていませんか？ネットワークリトライは「保険」のように見えて、やりすぎるとコスト6倍・二重決済・リトライストームという地雷原に変わります。従来のWebサービスとは異なり、LLM呼び出しの1回あたりのコストが高いからこそ、リトライ戦略は慎重に設計する必要があります。 📋 **概要** ネットワーク/5xxリトライは、一時的な障害（429 Too Many Requests、5xxサーバーエラー、タイムアウト、DNS解決失敗など）に対して同じリクエストを再送する回数と間隔を制御するダイヤルです。対象は「同じリクエストをそのまま送り直せば成功する見込みがある」エラーのみ。スキーマ不適合や低品質出力のようなコンテンツ起因のエラーは自己修正リトライという別の仕組みで扱います。この2つを混同すると、リトライ戦略が根本から崩壊します。 🔍 **意思決定のポイント** このダイヤルは2つの駆動変数で決めます。 🔹 **失敗コスト（failure_cost）** — 失敗コストが高い環境ではリトライ回数を少なく（2回程度）し、早めにサーキットブレーカへ移行します。誤ったリトライによる二重実行のリスクの方が、リトライしないことによる失敗よりも深刻だからです。 🔹 **コスト感度（cost_sensitivity）** — LLM呼び出しのリトライは1回あたり数千トークンを消費します。5回リトライすればコストは6倍。コスト感度が高い場合はリトライ回数を下限寄りに設定します。 最も重要な判断は**冪等性の確認**です。読取操作のリトライは安全ですが、決済・データ更新・メール送信などの副作用を伴う書込操作を冪等キー無しでリトライすると二重実行が発生します。操作のリトライ可否はツール定義時に静的に決めておくべきで、LLMに判断させてはいけません。 💡 **要点と詳細** 基本方針は**指数バックオフ＋ジッタ**です。リトライ間隔を1秒→2秒→4秒と指数的に増やし、ジッタ（乱数による揺らぎ）を加えます。ジッタにより複数クライアントのリトライタイミングが分散し、リトライストームを防ぎます。 📊 目安値: - リトライ回数: 2〜4回 - 初回バックオフ: 1〜2秒（429の場合はRetry-Afterヘッダを優先） - バックオフ上限: 30〜60秒（これ以上待つなら縮退に移行） - ジッタ: フルジッタ（0〜バックオフ値の乱数） - 非冪等書込のリトライ: 冪等キー無しでは**禁止** 429応答にRetry-Afterヘッダが含まれる場合は、自前のバックオフ計算より優先しましょう。プロバイダの指示を無視するとさらに厳しいレート制限を受けるリスクがあります。 リトライ上限に達したらサーキットブレーカを開き、縮退ラダー（軽量モデルへのフォールバック、キャッシュ応答、静的フォールバック）に移行します。 ⚖️ **トレードオフ** 📉 リトライが少なすぎると — プロバイダの429は数秒待てば解消されることが多いのに、即座にエラーを返してしまいます。ネットワークの瞬断で数十秒かけたLLM推論結果が無駄になり、本来リトライ1〜2回で回復する軽微な障害がセッション全体の失敗に連鎖します。 📈 リトライが多すぎると — コスト増幅に加え、複数エージェントが同時にリトライするリトライストームでプロバイダへの負荷が雪だるま式に増大し、障害を悪化させます。レイテンシも分単位に膨張。最も危険なのは非冪等操作の二重実行です。 🛠️ **ユースケース** 🔄 **LLMプロバイダの429** — 最も頻繁に遭遇するケース。Retry-Afterヘッダを最優先で使い、2〜3回のリトライで回復しなければサーキットブレーカを開いて別プロバイダへフォールバック。 🖥️ **一時的な502/503/504エラー** — 初回バックオフ1〜2秒、最大3回リトライ。3回失敗したら15〜60秒の遮断期間を設け、Half-Open状態で1リクエスト試行して復帰判定。 💳 **決済APIへの書込** — 冪等キー付きならリトライ可。冪等キー無しなら**リトライ禁止**。代わりに状態確認API（GET）で完了状態を確認し、未完了なら再実行します。 🌐 **複数プロバイダ構成** — 1回目は同一プロバイダに再送（一時的障害の高速回復）、2回目以降は別プロバイダにフォールバック。プロバイダごとに独立したサーキットブレーカを設置するのが鉄則です。 リトライ発生率の監視も忘れずに。急上昇はプロバイダ障害か自システムの負荷超過の兆候です。 #AIエージェント# #ソフトウェアアーキテクチャ#

# AIエージェントをソフトウェアに組み込むプラクティス # Synchronous Edge Agent｜同期エッジ 🎯 キャッチーなメッセージ LLMエージェント、まず「同期で返せないか？」を考えていますか？ 非同期キューやチェックポイントに飛びつく前に、シンプルな同期HTTPで完結できないか検討しましょう。実際のユースケースの大半は、それで十分です。 🔥 解決する課題 エージェントアーキテクチャの議論はすぐに非同期キュー・チェックポイント・オーケストレータへ進みがちです。しかし多くのタスクは「LLM1回＋軽いツール」で済みます。軽量タスクに重い実行基盤を持ち込むと、運用コスト・デプロイ複雑性・デバッグ難度が不必要に跳ね上がります。 💡 提案パターン Synchronous Edge Agent（同期エッジ）は、単発のLLM推論と軽量ツール0〜2回を1つの同期HTTPリクエスト内で完結させる、最もシンプルな実行方式です。状態はインコンテキストのみで、チェックポイントもキューも不要です。テキスト分類・情報抽出・単純Q&A・要約・構造化出力生成など「数秒で終わる確実な処理」に最適です。タイムアウトはLLM呼び出し単位でp99実測値に基づいて設定し、モデル選択もレイテンシ予算の関数として決定します。迷ったらまずここから始めてください。 ✅ 選定条件 使うとき： - 処理が概ね5〜10秒以内に終わる（対面）、またはAPI連携で30秒以内 - LLM呼び出しは1回、ツール呼び出しは0〜2回の軽量処理 - 途中再開や人間承認が不要 使わないとき： - 処理が30秒を超えうる、または所要時間が読めない場合 - 複数ツールの多段呼び出しや計画・反省ループが必要な場合 - 不可逆な副作用（決済・データ削除等）を伴う場合 ⚠️ 落とし穴 - タイムアウトはHTTPサーバ全体でなくLLM呼び出し単位で設定すること。全体タイムアウトだけではLLMがハングしてワーカースレッドを占有し続けます - 同期枠内でのリトライは0〜1回に限ること。リトライを重ねるとクライアントが先にタイムアウトします - サーバーレス環境ではコールドスタートがレイテンシ予算を食うため、Provisioned Concurrencyやウォームアップで対処が必要です 🔧 実装方針 - クライアントからのHTTPリクエストをAPI Gateway経由でハンドラが受け取り、1つのリクエスト-レスポンスサイクル内で処理を完結させます。外部キューやチェックポイントストアは登場しません - タイムアウトはHTTPサーバ全体ではなくLLM呼び出し単位で設定し、その値はlatency_budgetから導出します。p95/p99の実測値に基づいて調整します - モデル選択もレイテンシ予算の関数として決定します。分類・抽出には軽量モデル、生成にはミッド〜フラグシップを選びます - 構造化出力（JSON Schema等）を使い、レスポンスの軽量検証を常にONにします。意味検証はレイテンシに余裕がある場合のみ追加します - 対面UIで生成が長文になる場合はSSEストリーミングを併用し、体感レイテンシを短縮します #AIエージェント# #ソフトウェアアーキテクチャ#

# Hermes Agentの機能と実践的な使い方 🚀 事実を覚えるだけでなく、「この人はどういう人か」を対話から推論し続けるメモリです。使うほど提案が的中する「自分を理解しているエージェント」を実現します。 📌 タイトルと機能のURL タイトル: Honcho Memory URL: 📝 概要 HonchoはAIネイティブなメモリバックエンドで、単純なキー・バリュー保存を超えます。会話のたびに「対話推論（dialectic reasoning）」を行い、ユーザーの好み・コミュニケーションスタイル・目標・行動パターンを自動的に導出して、時間とともに深まるユーザーモデルを構築します。 🔧 機能の説明 ・対話推論は多段解析です。Pass 0で初期評価、Pass 1で自己監査による抜け漏れの特定、Pass 2で矛盾を最終統合へ調整します（深さ1〜3）。 ・新規ユーザーには好みや目標を探るコールドスタート問い合わせ、既存ユーザーには現在の文脈を優先するウォームセッション問い合わせを使い分けます。 ・組み込み記憶が静的な事実の手動管理であるのに対し、Honchoはサーバー側プロファイルで自動推論を行い、結論に対するセマンティック検索やマルチエージェントのピア分離を可能にします。 ・honcho_profile（ピアの識別カード読み書き）、honcho_search（記憶・結論のセマンティック検索）、honcho_context（要約を含むセッション文脈の取得）、honcho_reasoning（指定深さでの統合推論）、honcho_conclude（結論の作成・削除、PII管理に有用）の5ツールが統合されます。 🛠 実践的な使い方 ・`hermes memory setup honcho` でガイド付き設定を行います。設定は `~/.honcho/config.json`（グローバル）または `$HERMES_HOME/honcho.json`（プロファイル単位）に作成されます。 ・主要な設定キーは、`contextCadence`（基本文脈の更新間隔）、`dialecticCadence`（LLM推論の間隔）、`dialecticDepth`（多段の深さ）、`recallMode`（hybrid / context / tools）、`writeFrequency`（async / turn / session）、`apiKey` / `peerName` / `aiPeer` / `workspace` です。 ・既定の hybrid モードでは、基本文脈と対話推論の補足が自動的にシステムプロンプトへ注入され、ツールも併用できます。 ・Honchoを有効化すると `hermes honcho status` などのサブコマンドが利用可能になります。 🎯 ユースケース ・長期アシスタントとして、数ヶ月にわたるユーザーの作業上の好みを追跡する。 ・コーディング用と個人秘書用のアシスタントが同じユーザーに対し独立したモデルを保ち、文脈の混線を防ぐ。 ・繰り返しの話題の再説明を減らし、セッションスコープの注入で提案精度を上げる。 ⚠️ 注意点 ・推論の深さに比例してコストが増えます（深さ2〜3はLLM呼び出しが増えるため、cadence設定で調整します）。 ・新規ピアはバックグラウンドのプリウォームが必要で、間に合わない場合は上限付きの同期フォールバックが働きます。 ・recallModeのtoolsモードはエージェントに制御を委ねますが明示的な推論呼び出しが必要で、contextモードはツールを隠すため柔軟性が下がります。サーバー側に状態を持つため、ファイル記憶からの移行にはデータエクスポートが必要です。 #HermesAgent# #Memory#