第8章：统一表示与跨层资源映射机理

前 7 章把”问题域”和”现有方案”讲透了——KV Cache、向量索引、多模态、中间推理状态四类数据各有各的最佳实践,但它们各自为政、互不通气。本章是项目第一模块最核心的科学问题腹地:这四类数据能不能在同一个抽象下被统一管理?如果能,这个抽象长什么样,跨层级映射的机理如何形式化? 我先论证”为什么必须统一”,然后给出 LMObject 数据模型、跨层映射函数、三层 API(metadata / placement / migration)、基于 LMCache 改造的实现路径,最后把这一章浓缩成可以直接搬进申报书的科学问题表述。读完本章你应该能回答:项目第一模块的”基础研究属性”具体落在哪里?为什么必须通过基础研究予以突破?

📑 目录

• 1. 为什么必须统一:前七章的归一
• 2. 现有抽象为什么不够
• 3. LMObject:四类数据的统一模型
• 4. 跨层资源映射机理:形式化
• 5. 三层 API:metadata / placement / migration
• 6. 实现路径:基于 LMCache 改造
• 7. 与现有系统的对接清单
• 8. 设计准则
• 9. 给申报书的科学问题表述
• 自我检验清单
• 参考资料

---

1. 为什么必须统一:前七章的归一

1.1 把前面四章汇成一个表

章	数据类型	现有最强方案	已有抽象	缺什么
4	KV Cache	LMCache / Mooncake	”KV 块 + key + 多后端”	与其它三类数据不互通
5	向量索引	DiskANN / AlayaDB	”图节点 / 簇 + ANN 引擎”	不能与 KV 共享 metadata
6	多模态	LanceDB	”embedding + blob 双流”	不能与 KV 互引用
7	推理状态	LangGraph checkpoint	各家自定义	几乎没有跨层级抽象

🌟 关键观察:每个领域内部都有局部抽象,但没有任何一个能跨四类。这就是问题。

1.2 业务场景里”四类数据其实是一回事”

考虑一个真实的 Agent 任务:

   用户问:"帮我找上次会议里讨论过的那张架构图,补一段说明"

   Agent 内部:
   1. 召回:向量索引找相似 query → 命中 3 个历史片段
                                      │
                                      ├─ 片段 A: 文字说明(对应一段 KV 历史)
                                      ├─ 片段 B: 图片(对应一个 blob)
                                      └─ 片段 C: 当时的 tool call trace
   2. 把召回内容作为上下文 → 进入新的 prefill (新建 KV)
   3. 生成思考 → scratchpad
   4. 调用图像理解工具 → tool call trace
   5. 输出答案

⭐ 核心观察:这一次任务里四类数据交织出现、相互引用、生命周期相互锁定——它们物理上必须可以互相定位、共享 metadata、协同迁移。统一抽象不是工程偏好,是业务客观要求。

1.3 不统一的直接代价

   片段 A 的 KV 在 vLLM 里
   片段 B 的 blob 在 LanceDB 里
   片段 C 的 trace 在 LangGraph SQLite 里
   ↓
   召回时三套系统各自查
   迁移时三套系统不协同
   失效时三套系统各报各错
   成本时三套账单加不起来

🌟 结论:不统一抽象 = 工程混乱 + 资源浪费 + 不可优化。

---

2. 现有抽象为什么不够

2.1 LMCache 的”块抽象”:只解了 KV 一半

LMCache 抽象:    block_key (token hash) → block_data (KV tensor)
                                          + backend (HBM/DRAM/...)

优点	局限
跨实例 / 跨层级	仅 KV
多后端	key 是 token-hash,不能给向量 / blob 用
工程成熟	没有 metadata 层概念

2.2 向量库的”对象抽象”:只解了向量一半

Milvus / Qdrant:  obj_id → vector + scalar payload

优点	局限
多 payload	不能与 KV 互通
索引内置	不感知跨层级
多租户	不感知 LLM 推理

2.3 LanceDB 列式抽象:对多模态最友好,仍不通用

Lance:  table schema with vector / blob columns + metadata

优点	局限
列式 + 多模态原生	KV / 推理状态进不了
版本化	不感知三级存储

2.4 Agent 框架的应用层抽象:在错的层

LangGraph / Letta:  应用层 state + checkpoint

🌟 关键洞察:应用层抽象 ≠ 系统层抽象。LangGraph 的 state 是 Python 对象,工程上方便,但底层存储无法据此优化。

2.5 总结:现有抽象都”只切一面”

                   LMCache: 抽 KV 一面
                              ╲
                               ╲
                               
   现实需要:                   ▼
                ┌──────────────────────────┐
                │ 长记忆数据统一抽象       │
                │ 跨四类 + 跨三级 + 应用感知│
                └──────────────────────────┘
                ▲
               ╱
              ╱
   LanceDB: 抽多模态一面
   Milvus: 抽向量一面
   LangGraph: 抽推理状态应用层一面

⭐ 观察:真正缺的是底下那条”系统级 + 跨四类”的抽象层——这正是项目第一模块要建的”基础设施”。

---

3. LMObject:四类数据的统一模型

3.1 核心数据结构

提出一个统一对象模型,简称 LMObject(Long-Memory Object):

# 概念伪代码,不是某个具体框架 API
@dataclass
class LMObject:
    # ─── 统一标识 ───────────────────────
    obj_id: ObjectID                # 全局唯一 ID
    obj_type: ObjectType            # KV | VECTOR | BLOB | TRACE
    namespace: str                  # 用户/租户/任务隔离

    # ─── 内容寻址 ────────────────────
    payload_locations: list[Location]   # 当前存在的层级 + 物理地址
    content_hash: bytes             # 用于跨实例去重 / 一致性

    # ─── 关联与依赖 ──────────────────
    parents: list[ObjectID]         # 这个对象由谁产生 / 引用
    siblings: list[ObjectID]        # 同源的"重影"(如 KV 与 trace)

    # ─── 访问与生命周期 ──────────────
    access_profile: AccessProfile   # 第 2 章的六维指纹
    lifecycle: Lifecycle            # 创建 / 最后访问 / 预期死亡时间

    # ─── 编码与压缩 ──────────────────
    encodings: list[Encoding]       # 各层级各自用什么编码 / 量化档

    # ─── 重要性 / 持久化 ─────────────
    importance: ImportanceLevel     # 应用层显式标(见 Ch7 准则 2)
    durability: DurabilityLevel     # 几副本 / 是否 EC

    # ─── 类型特定字段(union)──────
    type_specific: KVMeta | VectorMeta | BlobMeta | TraceMeta

3.2 四类数据如何映射到 LMObject

数据类型	obj_type	type_specific	例子
KV Cache 段	KV	layer_idx, token_range, model_id	一个会话的 layer-12 KV 块
向量	VECTOR	embedding_dim, index_handle, modality	一条用户记忆的 embedding
多模态 blob	BLOB	mime_type, byte_size, codec	一张用户上传的图片
推理 trace 事件	TRACE	event_type, ts, idempotency_key	一次 tool call 记录

🍎 直觉比喻:LMObject 像云存储里的 “Object”——所有不同类型的资源统一用一个”对象”概念,各自有各自的 metadata,但寻址、生命周期、权限、跨层级搬运用同一套机制。

3.3 关键设计取舍

取舍 1:粗粒度 vs 细粒度

选择	后果
粒度太细(每 KV token 一个 LMObject)	metadata 爆炸,管理开销超过收益
粒度太粗(整段对话一个 LMObject)	不能精细放置

📍 建议:类型自适应粒度——KV 取 layer×block 粒度、向量取单条、blob 取整对象、trace 取事件。

取舍 2:metadata 集中 vs 分布

选择	后果
集中(单点 metadata service)	强一致 + 简单,但成单点瓶颈
分布(每节点缓存,周期同步)	高吞吐,但可能出现短暂不一致

📍 建议:两层 metadata —— 全局轻量索引(集中,只存 obj_id → 节点)+ 节点级详细 metadata(分布)。

取舍 3:语义嵌入与否

应该把 embedding 嵌入 LMObject 自己,还是只存”指向 embedding 的引用”?

📍 建议:引用式——embedding 自己是一个 LMObject(VECTOR 类型),其它对象通过 siblings 字段引用它。这样 embedding 可以独立量化、独立放置、独立淘汰。

3.4 sibling 关系:消除”重影”

第 7 章提到的 KV 与 scratchpad 重影,在 LMObject 模型里这样处理:

LMObject A: type=KV, content="思考:需要先查项目编号"
              │ siblings ──┐
              ▼            │
LMObject B: type=TRACE     │
            content_hash 同 A
            (指向同一份字节)
              ▲
              │ siblings 反向
              └────────────┘

存储层看到 sibling 时只存一份字节,通过 metadata 让两个 LMObject 都能定位到——消除冗余,但保留语义独立性。

---

4. 跨层资源映射机理:形式化

4.1 映射函数的核心命题

把”放置决策”形式化:给定一个 LMObject,决定它当前应该在哪一级存储,以及在该级的具体位置。

   placement: LMObject × SystemState → (Tier, Address)

其中:

• Tier ∈ {HBM, DRAM, RDMA_pool, SSD, archive}
• Address = 该 tier 内的具体物理位置
• SystemState = 当前各 tier 的容量占用、IO 负载、网络状态

4.2 决策的四个输入维度

   ┌───────────────────────────────────────┐
   │       placement decision              │
   └───────────────────────────────────────┘
              ▲     ▲     ▲     ▲
              │     │     │     │
   ┌──────────┘     │     │     └──────────┐
   │                │     │                │
   D1: AccessProfile│     │ D3: SystemState
   (Ch2 六维指纹)    │     │ (各级 当前可用)
                    │     │
       D2: Importance & Durability
       (应用层语义,Ch7 引入)
                    │
                    │
              D4: Cost Model
              (Ch11 token 边际成本)

4.3 形式化 placement 函数

把 placement 写成约束优化问题:

                               总收益(对所有 LMObject 求和)
   placement* = argmax  ─────────────────────────────────────
                placement                总成本

   subject to:
     C1: ∀tier, 该 tier 上 LMObject 总占用 ≤ tier 容量
     C2: ∀critical LMObject, durability ≥ 应用要求
     C3: ∀hot LMObject, 所在 tier 延迟 ≤ SLO
     C4: 物理硬约束(C1-C5,见 Ch3)

   收益(LMObject o) = 期望访问次数 × (高一级延迟 - 当前级延迟)
   成本(LMObject o) = 占用容量 × 该 tier 单位 GB 成本
                      + 历史搬运次数 × 搬运成本

🌟 关键事实:这是一个混合整数规划问题(每个 LMObject 选一个 tier,枚举型变量)。FlexGen(模块零第 10 章)证明了这类问题在静态场景下可解,但长记忆系统是在线 + 多类型 + 多约束的——没有现成解法。

📍 科学问题候选:如何在多类型、动态、多 SLO 约束下高效求解 placement 优化?这是基础研究问题,不是工程优化问题。

4.4 在线决策的三种实用近似

完整 MIP 在线求解不现实,实际用三种近似:

方法	思路	适用
启发式规则(LRU/类型偏置)	简单规则按类型挑层	baseline,容易实现
小规模 LP 周期重解	每隔 N 秒把当前 LMObject 集合喂给 LP,采纳输出	中规模,需要 SystemState 慢变
强化学习 / 模仿学习	训练一个策略模型,实时输出放置决策	大规模,需要历史数据训练

⭐ 设计建议:三层 fallback —— 默认用启发式,周期性做 LP 校准,长期收集数据训练 RL 模型。这正是项目第一模块”分层放置策略”(Ch9)的具体内容。

4.5 migration 函数:何时把 LMObject 从 A 移到 B

placement 决定”应该在哪”,migration 决定”什么时候搬”:

   migrate(o, from_tier, to_tier) iff
     placement_optimal(o) ≠ current_tier(o)
     AND migrate_benefit(o) > migrate_cost(o)
     AND not blocking_critical_path(o)

🌟 关键约束:搬运不能阻塞主路径(Ch3 阈值 T3)——这把所有 GB 级搬运强制后台化。

---

5. 三层 API:metadata / placement / migration

把上面形式化落到具体接口,设计三层 API:

5.1 Metadata API:统一标识与查询

# 概念签名
def put(obj: LMObject) -> ObjectID: ...
def get_metadata(obj_id: ObjectID) -> LMObject: ...
def update_metadata(obj_id, **fields): ...
def delete(obj_id, mode='soft'|'hard'): ...

# 关联查询
def find_siblings(obj_id) -> list[LMObject]: ...
def find_by_namespace(ns, filter) -> Iterator[LMObject]: ...
def find_by_content_hash(h) -> list[LMObject]: ...

5.2 Placement API:决定数据物理位置

def place(obj_id) -> (Tier, Address): ...           # 查询当前位置
def request_placement(obj_id, target_tier): ...      # 提请放置到某级
def get_placement_decision(obj_id) -> Decision: ...  # 调度器的最优决策
def report_access(obj_id, access_event): ...         # 反馈给放置算法

5.3 Migration API:数据搬运的执行层

def migrate(obj_id, target_tier) -> MigrateHandle: ...  # 异步搬运
def cancel_migration(handle): ...
def list_pending_migrations(filter) -> ...

# 协议层
def lock(obj_id, mode='read'|'write'): ...           # 防止搬运中被改
def commit_migration(handle): ...                     # metadata 切换到新位置

5.4 数据访问的统一入口

具体上层(vLLM / 向量库 / Agent 框架)如何用?

# 上层只需用 obj_id 拿数据,不关心物理位置
data = lm_runtime.read(obj_id, mode='kv'|'vector'|'blob'|'trace_event')

# 写入时只需指定 type 和 type_specific
obj_id = lm_runtime.write(
    obj_type=OBJ_TYPE_KV,
    type_specific=KVMeta(layer=12, token_range=(0, 1024), model_id="…"),
    payload=...,
    importance=ImportanceLevel.HIGH,
)

🌟 关键设计目标:上层”无感知”——vLLM 调用 read(obj_id, mode='kv') 拿到 KV,不需要关心它当前在 HBM、DRAM 还是 SSD。

---

6. 实现路径:基于 LMCache 改造

6.1 为什么从 LMCache 出发

LMCache 已经把 KV 一类做了”块 + key + 多后端”——抽象方向对了,只是范围窄。改造 LMCache 加上多类型 + 多层级 + metadata 层 = LMObject 运行时。

6.2 改造路线图

Step 1: 把"block_key"泛化成"obj_id",支持多 obj_type
        ──> 仍然只有 KV,但接口可扩

Step 2: 接入向量索引
        ──> 把 LanceDB / FAISS 包装成 backend
        ──> 实现 OBJ_TYPE_VECTOR 的 read/write

Step 3: 接入 blob 后端
        ──> 接 S3 / 本地 NVMe + GDS
        ──> 实现 OBJ_TYPE_BLOB 的 read/write

Step 4: 接入推理 trace
        ──> WAL + 列式存储后端
        ──> 实现 OBJ_TYPE_TRACE 的 append/replay

Step 5: 加全局 metadata service
        ──> 跨节点 obj_id → 位置查询
        ──> sibling 关系维护

Step 6: 加 placement 决策引擎
        ──> 启发式 → LP → RL 三层 fallback

Step 7: 加 migration 执行引擎
        ──> 后台异步搬运 + 锁协议

Step 8: 加 cost monitor + access profiler
        ──> Ch2 六维指纹的运行时采集
        ──> 喂给 placement 决策引擎

📍 节奏建议:Step 1-4 是工程,半年内可成型;Step 5-8 是科学问题集中区,可能需要 1-2 年迭代。

6.3 与 vLLM / Mooncake 的关系

                ┌─────────────────────────┐
                │  应用层(vLLM / Agent)  │
                └──────────┬──────────────┘
                           │ 通过统一接口
                           ▼
                ┌─────────────────────────┐
                │   LMObject Runtime       │
                │   (改造自 LMCache)        │
                └──────────┬──────────────┘
                           │
       ┌───────────────────┼────────────────────┐
       ▼                   ▼                    ▼
  KV backend          Vector backend       Blob backend
  (vLLM PagedAttn /   (LanceDB / DiskANN)  (S3 / NVMe + GDS)
   Mooncake KV pool)

🌟 关键观察:Mooncake 的 KV pool 在新架构里降级为”backend 之一”——它仍然存在,但不再是顶层抽象。这正是把 Mooncake 当作”工业级基线”而非竞争方案的合理整合方式。

---

7. 与现有系统的对接清单

现有系统	在新架构中的角色	对接难度
vLLM	KV backend(其中一个),通过 LMObject 访问 KV	中
Mooncake	KV pool backend(分布式 KV 选项)	中-高
LMCache	改造对象本身	高
DiskANN / FAISS	Vector backend	低-中
LanceDB	Vector + Blob backend(列式)	低
S3 / OSS	冷归档 backend	低
本地 NVMe + GDS	热 blob backend	中
LangGraph / Letta	Trace backend(应用层适配器)	中
Redis Streams	多 Agent 协作日志 backend	中
NIXL / RDMA	跨节点搬运通道	中(模块零第 4 章已就绪)

⭐ 观察:统一抽象的实现 = 改造 LMCache + 适配多个 backend + 加 metadata 层——架构图清晰,关键科学问题集中在 placement / migration / cost-model 三个引擎里。

---

8. 设计准则

8.1 准则 1:obj_id 跨类型唯一,namespace 隔离租户

ID 全局唯一,跨类型可互引用;namespace 提供权限和资源隔离边界。

8.2 准则 2:metadata 与 payload 物理分离

metadata 集中查询 + payload 分布存储,各自最优。

8.3 准则 3:sibling 关系一等公民,消除重影

KV 与 scratchpad、embedding 与 blob 等”同源数据”显式标 sibling,存储层只存一份字节。

8.4 准则 4:placement 决策可降级

启发式 → LP → RL 三层,任何一层失效都能回退到下一级,生产可用。

8.5 准则 5:migration 永远后台,不阻塞主路径

GB 级搬运强制异步 + 双缓冲 + 锁协议保证一致性。

8.6 准则 6:应用层提供 importance / durability,系统层据此分级

不要让系统层猜应用语义——应用显式标,系统忠实执行。

8.7 准则 7:six-dim AccessProfile 是调度的统一输入

Ch2 的六维指纹是 placement 决策唯一输入接口——任何新数据类型都要先建 profile。

8.8 准则 8:cost monitor 长期采集,数据反哺 RL

每个访问都打 trace,长期数据训练 RL 模型,模型反过来优化 placement——形成闭环。

---

9. 给申报书的科学问题表述

把这一章浓缩成可以直接搬进申报书的一段(< 150 字)版本:

9.1 科学问题(150 字版本)

多类型长记忆数据的统一表示与跨层资源映射机理:研究 KV Cache、向量索引、多模态对象、中间推理状态四类异构长记忆数据在显存-内存-SSD 多层级体系中的统一抽象与映射函数,建立访问规律驱动的分层放置和自适应迁移决策模型,形成性能与成本协同的形式化优化框架。

9.2 为什么必须基础研究

维度	理由
理论维度	多类型 + 多层级 + 多 SLO 约束下的 placement / migration 是一个新的混合整数优化形态,没有现成最优解法
抽象维度	跨四类数据的统一对象模型(LMObject)在文献中尚无系统化提出
机理维度	”访问规律 → 物理放置”的形式化映射函数(包括有损语义压缩、sibling 关系、importance 分级)是新的研究对象
跨学科	涉及 LLM 推理、向量检索、多模态、分布式系统、调度理论的交叉,工程经验单一领域不足以解决

⭐ 可量化预期成效(直接搬进申报书):

维度	量化目标
容量	单服务实例支持 ≥ 10× HBM 容量的长记忆
成本	长记忆 token 边际成本降低 ≥ 50%
延迟	长记忆访问 P99 ≤ 直接 HBM 访问的 2×
通用	同一抽象同时承载 KV / 向量 / 多模态 / 推理状态 四类工作负载
开放	1 套基准 + 1 套开源参考实现 + 至少 X 篇 SOSP/OSDI 级别论文

---

✅ 自我检验清单

• 统一动机:能用一段话讲清”为什么单一领域局部抽象不够”
• 现有抽象的局限:能对 LMCache / 向量库 / LanceDB / LangGraph 各举一个”切的不全”的例子
• LMObject 数据结构:能默写 obj_id / obj_type / siblings / access_profile / importance 等核心字段
• 粒度取舍:能说出”每 token 一对象”和”整段一对象”两种极端的代价
• sibling 消重:能用 KV 和 scratchpad 的例子讲清重影怎么消
• placement 形式化:能写出”argmax 收益/成本 + C1-C4 约束”的优化形态
• 三层 fallback:能讲清启发式 / LP / RL 各自适用场景
• 三层 API:能区分 metadata / placement / migration API 的职责边界
• 改造路线:能复述 8 个 step 的实现节奏
• 科学问题表述:能默写 150 字版本和”为什么必须基础研究”四个理由

---

📚 参考资料

系统抽象先行者

• vLLM PagedAttention(SOSP’23):arXiv 2309.06180 —— 单一类型块抽象先驱
• LMCache:github.com/LMCache/LMCache —— KV 跨实例 + 跨层级
• LanceDB / Lance:lancedb.com —— 多模态列式
• LangGraph Checkpointer —— 推理状态应用层抽象

形式化 placement 相关

• FlexGen(ICML’23):arXiv 2303.06865 —— LP 求最优单卡放置
• HeMem(ASPLOS’21) —— DRAM-PMEM 自动 tiering
• TPP(Meta ASPLOS’23) —— DRAM-CXL 透明放置
• Pond(Microsoft ASPLOS’23) —— Azure CXL pool

系统级抽象的经典论文

• LegoOS: A Disseminated, Distributed OS for Hardware Resource Disaggregation(OSDI’18) —— 资源分离式抽象奠基
• InfiniSwap(NSDI’17) —— 远端内存 swap 的统一抽象
• CoALA: Cognitive Architectures for Language Agents(Sumers et al., 2023):arXiv 2309.02427 —— Agent 内存分类法

优化方法论

• Mixed Integer Programming for Resource Allocation —— 系统调度领域大量综述
• 强化学习用于资源调度:Decima(SIGCOMM’19)、AlphaSched 等

调研笔记

• 项目调研 - 长记忆分离式存储 —— 8 篇核心论文 + 三模块清单

本系列其它模块

• 本模块第 2 章 多类型数据访问规律 —— AccessProfile 的来源
• [本模块第 3 章 三级存储 cheat sheet](./第3章-三级存储基础与延迟带宽cheat sheet.md) —— SystemState 的物理底座
• [本模块第 4-7 章] —— 四类数据现有方案
• 模块零第 1 章 Goodput —— “useful work” 的方法论根基