长记忆大模型系统 2026年5月8日

第11章：性能—成本协同优化建模

单 token 边际成本的精确定义、成本模型四件套、性能-成本 Pareto 曲面、SLO 约束嵌入、预算分配、在线优化算法——把申报书的「低成本」从口号变成可计算的工程目标

token 成本成本建模 Pareto 曲面 SLO 约束预算分配 MPC 在线优化

第 1 章把”低成本”作为申报书核心卖点提了出来,Ch3-10 把”放置 / 迁移 / 一致性”的工程武器讲完——但**“低成本”如果只停留在直觉,就会被工程师反复问倒**:你怎么知道这个调整真省了钱?哪些项算成本?租户 A 抢占的资源是租户 B 的损失吗?本章给”低成本”四层精确含义的具体公式 + 在线优化框架——把 Ch9 的 placement 决策、Ch10 的 migration 协议都喂进同一个目标函数,让”为什么这么放、为什么这么搬”有一个可计算的、可证明的、可解释的答案。读完本章,申报书第一模块的”成效”指标可以从”经验值”升级到”可推导的承诺”。

1. 为什么成本建模是项目的最终归宿

1.1 三个驱动力

驱动力 1:申报书的可量化承诺

申报书写”长记忆 token 边际成本降低 ≥ 50%“——评审会立即追问:**“成本”具体指什么?怎么算?对照 baseline 是什么?**没有数学定义,这句话不可信。

驱动力 2:工程决策的”硬核仲裁者”

Ch9 / Ch10 的算法都依赖一个目标函数——“让 X 最小”。X 是什么?是 token 成本。没有公式化的目标函数,placement / migration 就是凭直觉。

驱动力 3:多模块的”共同语言”

第二模块(分离式池化)、第三模块(容错冗余)各自有自己的优化目标,只有共享的成本模型才能让三模块的优化目标可加、可比、可权衡。

1.2 现有系统的成本视角缺什么

系统	关心的成本视角	缺什么
vLLM	单实例 GPU 利用率	不算长记忆数据成本
Mooncake	KV pool 命中率	不区分类型 / 不算 SLO 罚
云厂商账单	按机时 / 流量计费	不深入 token 级别
Agent 框架	任务完成时间	完全不感知存储成本

🌟 关键事实:长记忆系统的”token 单位边际成本”目前没有任何系统精确算——这是项目第一模块的科学贡献空间。

2. 单 token 边际成本的精确定义

2.1 直觉版 vs 精确版

直觉版(模块零第 1 章里给过):

   总成本(硬件折旧 + 电费 + 运维) × 长记忆访问占比
    ────────────────────────────────────────────
                 服务的总 token 数

但这个版本太粗——把”服务一个新 token”和”维持已有用户的长记忆”混了。精确版要分清。

2.2 边际成本 vs 平摊成本

平摊成本:总成本 / 总 token 数。容易算,但不能指导决策。

边际成本:多服务一个 token 增加多少成本。指导决策的关键。

   marginal_cost(extra_token) = 增量计算 + 增量存储 + 增量迁移 + 增量 SLO 罚

2.3 形式化定义

设系统在时间窗 T 内服务的 token 总数为 N,总成本为 C,则:

\text{平摊成本} = \frac{C}{N}

\text{边际成本}(t) = \lim_{\Delta N \to 1} \frac{C(N + \Delta N) - C(N)}{\Delta N}\bigg|_{t}

🌟 关键洞察:边际成本随负载非线性变化——HBM 还有空闲时,新 token 接近”免费”;HBM 满了后再来一个 token,可能要触发 GB 级搬运,边际成本陡升 100 倍。

2.4 长记忆系统的特殊性:多对象联动

LLM 推理的边际成本主要看模型 / 量化等;长记忆系统的边际成本还要看”这个 token 的 KV 该放哪、关联的向量记忆该不该召回”——一个新 token 的成本受到周围 LMObject 的影响。

   marginal_cost(extra_token | LMObject_pool, SystemState)

📍 设计含义:成本模型必须 LMObject-aware——不是粗粒度公式,要按对象和层级展开。

3. 成本模型四件套

把成本拆成四块独立可加的部分:

3.1 容量成本(C_cap)

C_\text{cap} = \sum_{i, t} \text{size}(i) \cdot x_{i,t} \cdot \text{unit\_price}(t)

其中:

$i$ 遍历所有 LMObject
$t$ 遍历所有 tier(HBM / DRAM / RDMA pool / SSD / archive)
$x_{i,t} \in \{0, 1\}$ 表示对象 $i$ 是否在 tier $t$
$\text{unit\_price}(t)$ 是该 tier 单位字节·秒成本

📍 数量级:HBM 单位成本是 SSD 的 ~1000×(Ch3),四档之间差异巨大。

3.2 带宽成本(C_bw)

C_\text{bw} = \sum_{i} \text{access\_freq}(i) \cdot \text{size}(i) \cdot \text{bw\_price}(\text{tier}(i))

🌟 关键事实:HBM 带宽的”单位字节读取成本”远低于 SSD(因为 HBM 带宽很高,摊到每字节的折旧时间极短)——这正解释了”高频访问数据放 HBM”的经济学根据。

3.3 迁移成本(C_mig)

C_\text{mig} = \sum_{(i, A \to B)} \text{size}(i) \cdot (\text{bw\_price}(A) + \text{bw\_price}(B)) + \text{setup\_cost}(A \to B)

📍 重点:迁移占用源和目标两端的带宽,所以是 $A$ 加 $B$ 。setup_cost 是固定开销(协议握手、metadata 切换)。

3.4 SLO 罚成本(C_slo)

C_\text{slo} = \sum_{r \in \text{requests}} \text{penalty}\bigl(\text{actual\_latency}(r), \text{target\_SLO}(r)\bigr)

penalty 函数典型形态:

   penalty(actual, target):
     if actual <= target:        return 0
     if target < actual <= 2*target: return α × (actual - target)²    # 软罚
     if actual > 2*target:        return  β × actual + 退款 / 用户流失  # 硬罚

⭐ 关键设计:penalty 函数是”业务决定”的——不同租户、不同任务的 SLO 罚函数不同(免费用户罚轻,付费用户罚重)。

3.5 总成本与目标函数

\text{Total Cost} = C_\text{cap} + C_\text{bw} + C_\text{mig} + C_\text{slo}

\text{minimize} \quad \frac{\text{Total Cost}}{N}

其中 $N$ 是服务的 token 总数。这就是 Ch9 placement 决策、Ch10 migration 决策共享的目标函数。

🌟 关键准则:四项可加且独立可测——任何一项的优化都可以单独评估贡献,这给了 ablation study 的基础。

4. 性能-成本 Pareto 曲面

4.1 单 token 成本 vs P99 长记忆延迟的 trade-off

任何系统都不能同时把”P99 延迟”和”token 成本”都做到最低——它们之间存在 Pareto 前沿:

   token 成本
      ▲
      │   ●   ← 全 SSD,便宜但慢
      │     ●
      │       ●  ← 部分 DRAM
      │         ●
      │           ●  ← 大部分 DRAM + HBM 热点
      │             ● ● ●  ← Pareto 前沿
      │                   ●
      │                     ● ← 全 HBM,极快但贵
      └────────────────────────► P99 延迟

🌟 目标:把系统推到 Pareto 前沿——不是某个特定点,而是让 placement 决策能根据当前 SLO 要求自动选择前沿上的最优点。

4.2 Pareto 前沿的形状决定 ROI

不同负载形态下,前沿的”陡度”差异巨大:

负载特征	前沿陡度	ROI
长尾 + 高复用	平缓	优化收益大,几倍
均匀访问 + 低复用	陡	优化收益小,~10-20%
极度不均(单热点)	极平缓	优化收益数十倍

📍 观察:项目示范系统选 evaluation 负载时,要选”前沿平缓”的真实场景——这样优化效果显著,论文 / 申报书数字好看。

4.3 Pareto 改进的两条路径

                                优化前
                                  ●
                  优化后(同性能更便宜)─→ ●
                                ↓
                            (同成本更快)
                                  ●←─ 优化后

路径 A:成本不变,性能变好——比如把 HBM 用得更高效,SLO 满足率提升

路径 B:性能不变,成本下降——比如把冷数据更激进卸载,token 成本减半

⭐ 可以同时朝两个方向走——这正是项目的”低成本 + 高性能”承诺的数学化版本。

5. SLO 约束的三种嵌入方式

5.1 方式 1:硬约束(LP 友好)

   minimize  C_cap + C_bw + C_mig
   s.t.      latency(i) ≤ SLO(i)  for all i

📍 优势:LP / MIP 自然支持。

📍 劣势:不可行解时优化崩(没有方案能满足所有 SLO)。

5.2 方式 2:软约束(罚函数)

   minimize  C_cap + C_bw + C_mig + C_slo
            (其中 C_slo 是 SLO 违反的罚)

📍 优势:总有可行解,体现”宁愿多花钱也别破坏关键 SLO”。

📍 劣势:罚函数权重难调——太大变硬约束,太小 SLO 形同虚设。

5.3 方式 3:概率约束(Chance Constraint)

   minimize  C_cap + C_bw + C_mig
   s.t.      P(latency(i) ≤ SLO(i)) ≥ 1 - ε

📍 优势:直接对应 SLA 的 P99 / P999 表达——P99 < 500ms 就是 ε = 0.01 的概率约束。

📍 劣势:求解需要分布建模,复杂度高。

5.4 实战推荐:三段式

   关键 SLO       → 硬约束(数据持久性、可用性)
   核心 SLO(P99)→ 概率约束(转化为对应分位数硬约束)
   次要 SLO       → 软约束(罚函数,可被资源压力压过)

🌟 设计建议:项目示范系统就用这三段式——既能保证关键不崩,又给优化空间。

6. 预算分配:租户 / 类型 / 时间

6.1 多租户预算

每个 namespace 有”长记忆预算”——可以是金额、是资源配额,或两者结合:

   namespace_alice:
     budget = 100 USD / month
     hard_cap = {HBM: 5 GB, DRAM: 100 GB, SSD: 1 TB}
     soft_cap_with_overage_billing = {……}

📍 设计建议:LMObject 的 namespace 字段是预算的承载点——所有成本汇总到 namespace 后做账。

6.2 类型间预算

集群级别给每类数据预设”基础配额”,防止某一类抢占其它:

   KV cache:    HBM 总量的 60%
   向量索引:    DRAM 总量的 30%(导航结构)
   多模态 blob: SSD 总量的 50%
   推理 trace:  SSD 总量的 20%
   缓冲 / 杂项: 余下

⭐ 关键准则:配额是软上限——使用率低时可以让出,但流量飙升时优先重新拿回。

6.3 时间维度的预算

电费 / 资源单价随时间变化(白天 vs 夜间、绿电高峰 vs 低谷),调度可以利用这一点:

时间窗	策略
白天高峰	严格执行 SLO,牺牲非紧急后台任务
夜间低谷	大批量 rebalance / 索引重建 / 归档
绿电高峰	优先跑高功耗后台任务

🌟 设计含义:时间维度的成本变化也要进 cost model——而不是把 unit_price 当常数。

7. 在线优化:MPC / 拉格朗日 / RL

7.1 模型预测控制(MPC)

   每隔 ΔT:
     1. 用历史数据预测未来 H 个时间步的负载
     2. 求解 H 步内的 cost-minimizing 放置 + 迁移决策
     3. 执行第 1 步决策,丢弃后面 H-1 步
     4. ΔT 后重复

📍 优势:显式预测 + 滚动重规划,处理动态负载比纯 LP 强。

📍 劣势:H 越大求解越慢,通常 H = 5-10 时间步实用。

7.2 拉格朗日松弛

把硬约束加到目标函数(乘以拉格朗日乘子),用对偶上升法迭代:

L(x, \lambda) = \text{Cost}(x) + \sum_k \lambda_k \cdot (g_k(x) - b_k)

用历史数据更新 $\lambda$ ,效果接近全局最优。

📍 优势:分布式友好(每节点局部决策, $\lambda$ 全局同步)。

📍 劣势:收敛速度有时慢,对约束矩阵质量敏感。

7.3 强化学习(RL)

   State:  系统当前状态 + 历史窗口的成本 / SLO 表现
   Action: 选定一组对象迁移到目标 tier
   Reward: -ΔCost - SLO 罚

如 Ch9 所述,RL 是终极方案但工程量大。

7.4 实战组合

时间尺度	算法
毫秒级(每次访问)	启发式(Ch9 档 1)
秒级	拉格朗日松弛 / 在线启发式(Ch9 档 3)
分钟级	LP / MPC(Ch9 档 2)
长期(天 / 周)	RL 训练 + 上线(Ch9 档 4)

🌟 关键设计:多时间尺度叠加——快慢决策各司其职,互相校准。

8. 成本可观测性:Token Cost Dashboard

8.1 必备指标(MVP 版)

   全局视图:
     [按 tier 占用]    HBM 95%  DRAM 70%  SSD 40%
     [按类型成本]      KV: 40%  向量: 30%  blob: 20%  trace: 10%
     [token 边际成本]  当前: $0.0012/1k tok  最近 24h: 0.0010-0.0015
     [SLO 达成率]      P99 长记忆延迟: 98%  目标 99%

   按 namespace 视图:
     [namespace_alice]  本月已用: $34 / $100  
                        热门数据: …… 冷归档: ……

8.2 二级诊断指标

指标	揭示什么
各 tier 命中率随时间	工作负载漂移
迁移成本占总成本比	迁移过度还是不足
SLO 罚成本归因	哪一类 / 哪一租户拖了后腿
不同放置算法的 cost 对比	A/B 实验结果

8.3 数据源

源	内容
LMObject metadata service	各对象当前位置 + 历史访问
各 tier 的硬件 telemetry	DCGM / iostat / NIC counters
placement 决策日志	每次决策的输入特征和输出
migration engine 日志	每次搬运的 size / time / 是否成功
应用层 trace	每个请求的 SLO 达成情况

📍 关键准则:所有数据进同一个时序数据库(Prometheus / VictoriaMetrics / TimescaleDB),才能做联合分析。

8.4 给 SRE 的告警

告警	触发条件
token 边际成本飙升	比 baseline 高 2×
HBM 容量告急	> 90%
迁移失败率上升	> 1%
SLO 罚成本占比上升	> 10% 总成本
某 namespace 超预算	软 cap 超 50% / 硬 cap 触发

⭐ 设计含义:Token Cost Dashboard 是项目示范系统不可或缺的可视化产出——它让”低成本”承诺可被持续验证,也是申报书”实施成效”的最佳呈现。

9. 「低成本」四层精确化(申报书呼应)

回到 Ch1 提到的”低成本”四层,现在可以给精确公式:

9.1 第一层:单 token 边际成本

\text{Goal: } \frac{\partial C_\text{total}}{\partial N}\bigg|_\text{long-memory part} \leq 50\% \text{ baseline}

baseline 用现有”四子系统各自调优”的方案。

9.2 第二层:统计意义的资源利用率

\text{Utility}(t) = \frac{\text{useful work on tier } t}{\text{capacity}(t)}

目标:四档介质的 Utility 分布拉平——不再某档拥挤某档闲置。

9.3 第三层:副本开销可控

\text{Replication overhead} = \frac{\sum_i \text{replicas}(i) \cdot \text{size}(i)}{\sum_i \text{size}(i)}

目标 ≤ 1.5×(对比传统 3 副本的 3×,即压缩 50%)。详细见第三模块。

9.4 第四层:总持有成本(TCO)可解释

\text{TCO} = C_\text{capex}(N) + C_\text{opex}(N, T) + C_\text{loss}(\text{SLO violations})

每一项可独立度量、可归因到具体决策——让”为什么花了这么多钱”有完整解释链。

🌟 申报书直接可用的承诺表:

维度	量化目标	公式
边际成本	$\leq 50\%$ baseline	$\partial C / \partial N$
Utility 拉平	各档之间方差 $\leq 0.2$	资源利用率分布
副本开销	$\leq 1.5\times$	replication overhead 公式
TCO 可解释	100% 可归因	每项有 cost monitor

优先级	内容	难度
⭐⭐⭐	成本模型四件套实装 + Token Cost Dashboard	中(2-3 月)
⭐⭐⭐	边际成本作为 placement 目标函数	中
⭐⭐	SLO 三段式嵌入	中-高
⭐⭐	多租户 namespace 预算	中
⭐	MPC 上线	高
⭐	RL 探索(论文方向)	高

Cost-aware Caching: Near-Optimal Online Algorithm(算法理论文献)
Borg / Kubernetes Resource Quotas —— 多租户预算的工业实践
AWS Cost Explorer / GCP Billing Reports —— 工业 Token Cost Dashboard 的镜像

在线优化方法

Model Predictive Control: Theory and Design(Rawlings 教科书)
Lagrangian Relaxation for Integer Programming(综述)
Online Convex Optimization(Hazan 教材)

多目标 / Pareto

Multi-Objective Optimization(Miettinen 经典)
Lexicographic Optimization 在系统调度的应用

强化学习用于成本优化

Decima(SIGCOMM’19) —— RL 调度
Park(NeurIPS’19) —— RL 系统平台
Online RL for Resource Management(综述)

工业经验

Google Borg paper(EuroSys’15) —— 大规模资源配额
Meta TPP / Pond / FlexBSP —— 多层级实战
Mooncake KVCache-centric scheduling 报告 —— LLM 服务成本视角

调研笔记

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

本系列其它模块

本模块第 1 章长记忆为什么是关键基础 —— “低成本”四层提出
本模块第 8 章统一表示与跨层资源映射 —— 成本作为目标函数
本模块第 9 章分层放置策略 —— placement 调用本章成本模型
本模块第 10 章自适应迁移 —— migration 调用本章成本模型
模块零第 1 章 Goodput —— Goodput 与 token 边际成本的关系

搜索