"Memory"
- Agent Memory
Agent 在 context window 之外管理長期狀態的設計、五個層次：working / short-term / long-term episodic / semantic / procedural
- MoE CPU 卸載
把 Mixture-of-Experts 模型不活躍的專家層權重放在系統 RAM、用到再走 PCIe 拉回 GPU、讓有限 VRAM 跑得了更大模型
- VRAM
顯卡上的記憶體、跟系統 RAM 是兩塊獨立預算、決定能載入多大模型權重跟 KV cache
- 3.1 GC 與 memory limit
理解 debug.SetMemoryLimit 在長時間服務中的用途
- 3.1 PyObject 與物件模型
深入理解 Python 的物件模型
- 案例：記憶體優化
用 __slots__ 和 weakref 優化快取系統的記憶體使用
- 3.2 記憶體管理與垃圾回收
理解 Python 的記憶體管理機制
- 1.4 共享狀態與複製邊界
用 lock 與 copy 保護長期服務的狀態資料
- 2.4 慢客戶端與 send buffer 管理
控制推送佇列與記憶體風險
- 3.4 資料結構與 allocation 壓力
分析列表、歷史資料與 WebSocket payload 的配置成本
- 2.5 指標與資料複製邊界
理解指標、slice 與共享狀態的防護策略
- Memcached slab allocator 與記憶體經濟學：明明有記憶體卻在 evict
Memcached 用 slab allocator 預切記憶體成固定大小的 chunk，這讓它永不碎片化、卻會在還有大量空閒記憶體時就開始淘汰——slab calcification。本文展開 slab class、growth_factor、page 分配的會計模型、5 個把 slab 機制寫成記憶體浪費與淘汰事故的 production 踩坑，以及純 KV 邊界與多執行緒擴展的判讀
- Redis 記憶體與淘汰調校：maxmemory-policy、LFU 與碎片化的實戰判讀
Redis 的記憶體是一條會在半夜爆掉的曲線：maxmemory 設多少、policy 選 LRU 還 LFU、碎片化什麼時候開始吃掉 30% RAM、OOM 時 noeviction 怎麼讓寫入全部失敗。本文展開 Redis 記憶體會計模型、eviction policy 的選型判讀、5 個把記憶體配置寫成 production 事故的踩坑，以及單機記憶體撞牆後該往 cluster 還是 DragonflyDB 走的邊界
- 4.19 Agent memory 分層架構
Agent 在 context window 之外管理長期狀態的設計：working / short-term / long-term episodic / semantic / procedural 五個層次、寫入時機、retrieval 設計、失敗模式
- MySQL Cross-buffer Memory Contention
MySQL InnoDB buffer pool、sort / join buffer、tmp table、thread memory、OS page cache 與 memory pressure 判讀