资源 / 技术指南

从输入文件到可核对的报告。

这条路径复跑离线评测机制。要逐项重现公开结果,还需相同的矩阵、检查点、参数与软件版本。

运行前核对输入

以下命令从已安装 Enthalpy 的项目根目录执行,不会自动准备你的业务数据或生产凭据。

矩阵
使用记录了各任务、各候选模型奖励与成本的矩阵。先查看统计,确认任务标识、候选覆盖和成本字段;没有成本的数据不能支持美元成本结论。
检查点与模型池
检查点必须与评测矩阵和模型池对应。公开矩阵训练出的检查点不能直接作为你自己的供应商模型池的生产检查点。
环境与存档位置
准备依赖与编码器权重,记录版本、设备及运行参数,并为新的实验名称与报告路径留出空间,避免覆盖已有结果。

先检查矩阵,再启动训练

下面使用你已准备的 mine.jsonl.gz。若尚无矩阵,可用 enthalpy data list 查看公开来源,再按其说明下载。

数据获取与回放分开
公开数据下载需要网络与本地存储。data harvest 则会真实调用供应商并产生费用;它不是复跑离线评测所必需的一步。
enthalpy data matrix stats data/matrices/mine.jsonl.gz

enthalpy train sft \
  --matrix data/matrices/mine.jsonl.gz \
  --name gen1

生成基线比较与成本扫描

训练和评测回放矩阵,不调用供应商。若矩阵带有来源划分,则来源划分优先于下方哈希划分参数;保留划分日志。

不要只保留控制台结论
报告同时写入 JSON 与 Markdown;成本扫描另存为 sweep.json。将报告与检查点身份、命令和日志一起保存。
enthalpy eval \
  --matrix data/matrices/mine.jsonl.gz \
  --checkpoint gen1 \
  --test-fraction 0.3 --split-seed 0 \
  --reference best_single --sweep-cost \
  --out reports/gen1.json

输出文件各自负责什么

评测复核和对外引用应使用生成文件,而不是手工重录结果。

gen1.json / gen1.md
JSON 保存评测数据;Markdown 提供表格、比较与口径。引用时检查来源划分描述,并保留边界标记和区间。
gen1.sweep.json
保存成本权重、各策略点与前沿信息。使用仓库的 sweep_table.py 格式化,不假设评测命令会自动输出扫描表格。
检查点与日志
保存 checkpoint_id、模型池指纹、训练参数与实际划分来源。数值一致之前,先确认比较的是同一实验。
python3 scripts/sweep_table.py reports/gen1.sweep.json

结果不一致时先查什么

先排除输入与环境差异,再解释算法差异。

模型池指纹不匹配

核对模型标识、供应商、模型名称与描述。不要跳过一致性检查来加载不匹配的检查点;改用对应池或重新训练。

样本数量或结果与公开表不同

核对数据版本、官方划分、任务过滤、训练参数与检查点。重新训练一个同名实验不等于获得公开案例的同一检查点。

4ROUTER / 系统研究

跨层复现:状态传输也要可测量

复现实验不能只记录模型和 GPU;还要记录缓存层级、传输路径、命中 token 与失败回退。

NOTE / 05TIERS / TRANSFER

LMCache:把 KV 状态放进存储层级

少算一次 prefill,要先付一次状态访问的成本。

当可复用上下文超过 GPU 常驻容量,问题从“有没有缓存”变成“缓存在哪里、何时搬运、是否值得搬运”。LMCache 为推理引擎提供 KV 存储与传输连接,将复用扩展到 CPU、磁盘和远端层级。它改变的是状态的生命周期和位置。

FIG. 01TIERS / TRANSFER
TIER 00GPU · HBM
TIER 01CPU · DRAM
TIER 02NVMe / Remote
状态按层存储,按需载入示意图,未表示实测比例或具体引擎布局。

连接器与存储层分工

推理引擎负责模型执行;LMCache 的连接与存储组件负责 KV 的存取和移动。分层架构允许把较冷状态放到容量更大的层级,但从存储命中到 GPU 可使用之间仍有搬运路径。集成版本、块粒度和数据布局会影响这个边界,不能只按后端名称判断兼容。 [1]

复用是否划算取决于临界点

一次命中需要查找、读取、传输以及必要的布局转换。当这些开销小于重新 prefill 的代价时,复用才有单请求收益。异步预取可能隐藏部分开销,但会占用带宽和缓冲区。应测有效传输带宽与排队,不能把链路标称速率直接代入服务承诺。 [2]

上下文复用与 P/D 分离不是同一目标

上下文缓存跨请求保存已有状态;prefill/decode 分离则把同一请求的两个阶段放在不同执行实例,中间需要传递 KV。二者可以组合,但成功缓存历史前缀并不证明跨实例传输或故障恢复已验证。每条传输路径都应有命中、未命中、超时和回退的可观测记录。 [2]

模型与记号

T_lookup + T_read + T_transfer + T_reformat < T_prefill_saved

这是不考虑重叠时的复用判据,不是吞吐预测。并发传输会竞争带宽;采用流水线时,应测量关键路径而不是机械相加。

如何设计实验

  1. 分别测试各缓存状态

    区分 GPU 热、CPU 热、磁盘热、远端热与完全冷的请求。记录模型、序列长度、缓存层级、命中字节与重算范围。

  2. 把数据移动放进 trace

    记录查找、读入、设备搬运和等待时间,并观察 pinned memory、NUMA、PCIe 或网络竞争;同时保留 TTFT。

  3. 验证失败回退与清理

    模拟对象缺失、容量耗尽、后端不可达和版本不兼容,验证重算或明确失败;制定租户隔离、保留与删除策略。

机制图为原创示意;公式用于解释或容量建模。论文与官方文档中的结果不等同于 4Router 实测。