# Wiki Overview Navigation: [[index]] | [[hot]] | [[log]] --- ## 目的 この `wiki/` は、既存の研究 vault に Karpathy の [LLM Wiki パターン](https://gist.github.com/karpathy/442a6bf555914893e9891c11519de94f) を導入した**横断知識レイヤー**である。RAG のように質問のたびにゼロから検索するのでなく、新規ソースを取り込む(ingest)時点で LLM が要約・概念集約・相互参照を行い、知識を複利的に蓄積する。 claude-obsidian (v1.9.2) の skill 群 — `wiki-ingest` / `wiki-query` / `wiki-lint` — がこのレイヤーを駆動する。 ## 既存 vault との関係(共存設計) | レイヤー | パス | 責務 | |---|---|---| | 既存一次ノート | `papers/`, `research/conferences/`, `notes/` | 個別論文/トーク/技術の詳細メモ。`create-*-note` skill が作成 | | 既存 MOC | `structures/*.MOC.md` | 人間がキュレートするトピック索引(読み筋) | | 原本 | `.raw/` | 新規ソースの不変原本。ingest は read-only で読む | | **この wiki** | `wiki/` | LLM 生成の横断知識(sources / entities / concepts) | **スコープ = 新規ソースのみ**。既存の `papers/`・`research/` は ingest しない。今後 `.raw/` に投入する新規ソースだけを wiki 化する。 **差別化**: `structures/` の MOC は人間がキュレートする「読み筋」、`wiki/concepts/` は LLM が新規ソースから機械的に積み上げる「定義・関係の集約」。concept は関連 MOC を `[[...]]` で一方向参照するが、MOC 側への逆リンク追記は人間が承認したときのみ。 ## 運用ルール wiki を操作する前に必ず [[conventions]](`wiki/meta/conventions.md`)と [[token-discipline]](`wiki/meta/token-discipline.md`)を読むこと。frontmatter・命名・言語(日本語常体)・出典規約は既存 vault に合わせる。エージェントは `index.md` / `_index.md` / `log.md` / `hot.md` の全文を読まず、`wiki-resolve.py` / `wiki-excerpt.py` / `retrieve.py` で発見する。 ## 構成 - [[index]] — 人間向けカタログ(エージェントは読まない) - [[hot]] — 直近コンテキスト(約 2000 トークン / 最大 5 件の窓) - [[log]] — 操作履歴(追記式、新規は先頭。エージェントは読まない) - `concepts/` — 概念ページ([[concepts/_index]])。一望は [[concepts.base]] - `entities/` — 実体ページ(人物・組織・システム)([[entities/_index]])。一望は [[entities.base]] - `sources/` — ソース要約([[sources/_index]])。一望は [[sources.base]] - `questions/` — query 回答のファイリング - `meta/` — 規約・lint レポート・[[token-discipline]] ## AI インフラ観測性の最近の接続 Meta 関連ソースの蓄積により、AI インフラ観測性は複数の相補レイヤーとして整理できるようになった。[[@2023__SystemAtScale__AI Observability|AI Observability]] の GPU／ハードウェアメトリクス、[[Logarithm]] の訓練ログ・モデルテレメトリ、[[Zoomer]] の訓練・推論性能プロファイリングが、資源状態・モデル状態・実行性能という異なる問いを分担する。[[GPU観測性]]、[[LLM学習モニタリング]]、[[LLM推論]]、[[パフォーマンスエンジニアリング]]は、この三層を横断する概念集約として機能する。 ## AIインフラの物理基盤とプラットフォーム [[AIインフラ]]の整理により、wikiのAI基盤知識へ、GPUやネットワークの性能だけでなく、電力・冷却、ラック搬入、物理配線、騒音、相互運用性、Kubernetesプラットフォームを含む運用境界が加わった。[[Actapio]]の米国データセンター事例は、PUE 1.2以下のDEC、100Gbpsサービス網と400Gbps閉域RoCEv2網の分離、ラック納品、[[AI Cloud Platform (ACP)]]を一つの設計対象として示す。既存の[[GPUクラスタ運用]]、[[データセンターネットワークトポロジ]]、[[データセンター内光配線設計]]、[[PUE]]と接続することで、AIインフラを施設から利用者向けプラットフォームまでの積層として扱える。 ## LLM ネイティブソフトウェアと安全な拡張 [[ウェブ拡張型ソフトウェア]]の導入により、wiki の LLM 関連知識はモデル・エージェントの性能や運用だけでなく、ユーザーが生成するコードを製品へ組み込む責任境界まで扱うようになった。[[LLMネイティブソフトウェア]]は需要曲線の長い尾を自然言語から生成する一方、[[Extension Interface Model]]と[[Capability-based Security]]は、ホスト関数・データ・資源へのアクセスを最小権限で制限する既存の設計語彙を与える。[[サーバーレスアーキテクチャ]]、[[WebAssembly]]、[[Dynamic Workers]]は、この拡張を低コスト・短い起動時間・分離境界で実行する候補として接続される。 ## OS の特殊化と横断的性能設計 [[ソフトウェア特殊化]]と[[ユニカーネル]]の追加により、wiki はコンテナ・ハイパーバイザー比較だけでなく、アプリケーションごとに OS プリミティブ、メモリアロケータ、ネットワーク経路、ファイルシステムを選択する設計空間を扱うようになった。[[Unikraft]] は POSIX 互換性を保った自動移植と、uknetdev・専用ファイルシステムへ接続する手動特殊化を同じマイクロライブラリ基盤に載せ、性能と移植量の交換関係を定量化している。 [[DPDK性能分析]] の追加により、ユーザー空間ネットワーキングでは高速なパケット処理経路だけでなく、その内部状態を説明可能にする観測経路も設計対象として整理された。DPDK native tracer の CTF、[[Trace Compass]] の State History Tree、DPDK 固有メトリクスを組み合わせることで、RX throughput の低下から poll 分布、worker、mempool 枯渇までを同一時間軸で診断できる。 ## XDP・Wasm によるトラフィック生成 [[XDPerf]] の追加により、ネットワーク性能の設計空間へ、DPDK の NIC 占有を避ける XDP/eBPF データプレーンと、Wasm によるユーザー定義パケット生成の組み合わせが加わった。 XDPerf は Wasm を起動時の柔軟性境界、Go + [[wazero]] をテンプレート展開、eBPF/XDP live frames を per-packet hot path として分離し、未変更の upstream ドライバで 64B 116.5 Mpps を提示する。 この事例は、[[カーネルバイパスネットワーキング]]を単純な「カーネルを通るかどうか」の二択ではなく、NIC 占有、ドライバ再利用性、フロー多様性、IOMMU・キュー構成、CI 互換性を含む複数の責任境界として評価する必要を示す。 ## ストレージネットワークとユーザーレベルTCP [[@2023__USENIX ATC__Deploying User-space TCP at Cloud Scale with LUNA]] の追加により、OS特殊化とネットワーク性能の接続が本番ストレージの事例まで広がった。[[LUNA]]はrun-to-completion、[[Zbuf]]による全経路ゼロコピー、Flow BifurcationとSR-IOVによるカーネルTCP共存を組み合わせる。[[ユーザーレベルTCPスタック]]、[[ゼロコピーネットワーキング]]、[[カーネルバイパスネットワーキング]]、[[TCP IPスタック統合|TCP/IPスタック統合]]は、TCP処理、アプリケーション実行、バッファ所有権、NIC分岐、ストレージ計算分離を横断する設計軸として接続される。 ## サービス中心型ネットワーキングと移動性 [[@2012__NSDI__Serval An End-Host Stack for Service-Centric Networking]] の追加により、ネットワーク性能の整理へ、固定ホスト中心の TCP/IP 抽象をサービス中心型へ分解する古典的な設計軸が加わった。Serval は `ServiceID`・`FlowID`・IP アドレスを分離し、SAL で初回接続のサービス解決、サービス登録、フロー移行を扱う。[[サービスメッシュ]] と [[スクリプタブルロードバランサー]] が既存のホストネットワーク上でサービス間の運用責務をプロキシへ分離するのに対し、Serval はネットワークスタック内の識別子と移動性を再設計する。 ## AI ソフトウェアファクトリーの経済性 [[@2026__Uber__Running a Software Factory Efficiently at Uber Scale]] の追加により、AI エージェントの知識をモデル性能や本番運用だけでなく、ソフトウェア開発ライフサイクル全体の成果・コスト・品質の管理へ広げた。[[ソフトウェアファクトリー]] は、専門管理エージェント、実作業ベンチマーク、パレート最適なモデル選択を組み合わせる枠組みである。[[コンテキストエンジニアリング]] は、AI Context Graph、ツール検索、CLI解決、コードモード、プロンプトキャッシュによって、不要なコンテキストとモデルターンを削減する設計軸を担う。