Memory 技术日报 2026-08-12:五条提交把状态交接变成可验证测试

Memory 技术日报 2026-08-12:五条提交把状态交接变成可验证测试

SGLang、vLLM、OpenViking 与 TensorRT-LLM 的五条窗口内提交,把 HiCache 恢复、长上下文 gather、量化 KV、tool output 和零拷贝 token 输入分别接上独立对照物;本期能确认的是正确性边界,不是共同 workload 下的性能收益。

今天的五个新增都来自工程提交,主题集中在同一个问题:memory 状态交给另一个执行路径后,什么证据能证明它仍然是同一个状态。SGLang 把 HiCache 的 host round-trip 放进多轮 bit-exact 测试;vLLM 为长上下文 MLA gather 和 4-bit TurboQuant decode 补上不规则序列与参考实现;OpenViking 把 tool output 的截断责任移到服务端;TensorRT-LLM 则让零拷贝 token 输入与普通 list 输入走同一套 cache-key 语义。它们提供的是可复现的正确性边界,不是共同 workload 下的吞吐或显存结论。

SGLang:HiCache 的恢复状态开始接受逐位检查

SGLang 于 2026 年 8 月 12 日 01:54(北京时间)提交 f9153df6,为 Inkling-Small-NVFP4 增加多轮 HiCache decode-cache-hit 测试。测试在 4 张 B200 上运行,启用 CUDA graph、write_through、host HiCache、页大小 128 和 Mamba track interval 128;它构造 3 组、每组 3 个分支、共 3 轮的交错请求,让多个分支共享前缀后再分叉。1
这组参数不是普通的单轮 cache-hit smoke test。提交说明明确要求请求跨过 track boundary,并在显存池收紧时触发 eviction;后续 cache hit 会把状态从 host tier 恢复回来。测试同时比较 decode logprob,并用 make_mamba_decode_assert(track_interval=128) 检查 decode-side track 保存结果。提交没有给出一次运行的误差数字或 host 传输延迟,所以它能证明的是「恢复后的值不能改变」,不能证明 HiCache 带来多少吞吐。
先跑 test_multiturn_decode_cache_hit_over_hicache,再分别关闭 write_through、缩短或拉长 track interval、放宽内存池,观察哪一个条件让路径不再真正经过 host tier。这样才能区分「测试覆盖了状态搬运」和「测试只命中了本地 cache」。SGLang 仓库当前 API 返回 Apache-2.0 许可证、31,691 stars;stars 只是仓库定位线索,不是本次提交的性能指标。2

vLLM MLA gather:长上下文测试把错位和不均匀长度摆到台面上

vLLM 于 2026 年 8 月 11 日 13:23(北京时间)提交 c76a4252,标题是「Optimize long-context MLA cache gathers」。补丁新增 benchmark_cp_gather.py,把单序列 60k、300k,以及 60k 到 300k 的 skew batch 写成固定场景;它还新增了 cp_gather_cache、FP8→BF16 upconvert 和可能解量化路径的带宽计算入口。脚本打印 latency 和按搬运字节计算的 GB/s,但提交本身没有附带运行结果,不能把这些场景写成已经获得的加速数字。3
正确性覆盖比 benchmark 场景更有信息量。新增测试使用 [17, 32_768, 71] 这样的不均匀序列长度,分别测试有无 seq_starts;另一个测试覆盖 [0, 1, 63, 4],并故意让源和目标 tensor 处在非对齐 view。FP8 路径先用固定 scale 得到 BF16 期望值,再比较 gather 结果。这样检查的是 page table、非零起始位置、空请求和不同 stride 是否仍然对应同一批 token,而不是只看一个整齐的 batch。
适合的最小复现是先跑 tests/kernels/attention/test_cache.py 中的 *_with_seq_starts*_large_uneven_sequences,再用 benchmarks/kernels/benchmark_cp_gather.py --scenario skew-8 做自己的硬件测量。读者需要保留 GPU 型号、dtype、block size、序列长度和是否 upconvert;没有这些字段,脚本输出的 GB/s 不足以和别人的结果比较。vLLM 当前 API 返回 Apache-2.0 许可证、88,803 stars。4

vLLM TurboQuant:4-bit KV decode 先和 FP32 oracle 对齐

同一时间窗内,vLLM 还于 2026 年 8 月 11 日 23:45(北京时间)提交 5426311d,为 ROCm gfx950 接入 FlyDSL 的 4-bit TurboQuant KV decode attention kernel。测试模块只在 ROCm、gfx950、FlyDSL 可用时运行;它用 16 个 centroid 构造压缩 key/value,保存 K norm、V scale 和 V zero,再把这些量精确解码,交给纯 PyTorch 的 FP32 softmax attention 作为 oracle。实现输出使用 BF16,测试设置的绝对误差阈值为 5e-35
这里的证据等级要说清楚:提交新增了 kernel、后端选择和 correctness test,证明「有一条在特定硬件与运行时上的对照路径」;它没有报告端到端 decode latency、显存节省或与 FP16 KV 的吞吐比。源码还按 max_seq_len 把 decode 分成短序列 2D 路径和长序列 3D 路径,调用方需要把实际 block table 的长度提示传进来,避免为了省一次 .item() 而改变路径判断。这个约束是 kernel 复现条件,不是性能收益。
如果要复现,先确认 gfx950、FlyDSL 版本和 4-bit cache layout,再检查 FP32 oracle 的 K/V 是否来自同一份 centroid、scale、zero;只比较最终输出而不核对量化数据,会把 cache 编码错误和 kernel 累加误差混在一起。5

OpenViking:tool output 不再在客户端提前丢掉

OpenViking 于 2026 年 8 月 11 日 19:17(北京时间)提交 7e26fab6,修正多个 coding-agent memory plugin 的 tool-result 捕获。此前客户端把一个 tool part 的 tool_output 截到 2,000 个字符;服务端默认在 20,000 个字符后才把结果写入 ToolResultStore。因此 2k 到 20k 的内容会在客户端先消失,更大的内容也到不了 tool_output_ref 回读路径。6
修复把 captureToolMaxChars 的默认值提高到 1,000,000,但这个值只是防止病态 payload 的 guard cap,不是要求服务端把一百万字符都塞进活动上下文。超过服务端 tool_output_externalization.threshold_chars(默认 20,000)的结果仍由服务端外置,part 中保留 synopsis 和 tool_output_ref,原文再通过 /tool-results 读回。提交还修掉了 pi 插件在 tool-only payload 中把同一结果同时写入 tool part 和普通 text part 的重复问题。6
测试用 50,000 个字符检查原样上报,再把操作员配置降到 1,000 个字符,确认显式低 cap 仍然生效。对 agent memory 来说,最有价值的复现不是只看 session 是否返回 200,而是分别检查:客户端是否保留原文、服务端是否产生外置引用、回读是否拿到同一结果、tool-only 消息是否只有一份。这个提交没有提供 recall precision、检索延迟或长期保留率。OpenViking 当前 API 返回 AGPL-3.0 许可证、28,228 stars。7

TensorRT-LLM:零拷贝先证明 hash 语义没有分叉

TensorRT-LLM 于 2026 年 8 月 11 日 12:41(北京时间)提交 0c98e929,在 KVCacheManagerV2 的 C++/nanobind 路径中启用连续 int32 ndarray 的 token ingest。对不含 multimodal digest 的普通 token,绑定层可以把连续的 4-byte token buffer 解释为 TokenIdExt*,避免先复制成逐元素 list。8
提交新增的单测没有把 zero-copy 直接包装成吞吐结论。它先用 3 个 block、每 block 8 个 token 的纯整数 prompt,通过 ndarray 完成 create_kv_cachecommit,再分别用 list 与 ndarray 调 probe_reuse;随后清空可复用树,反过来用 list 提交、ndarray 探测。两种方向都要求完整命中。测试同时把 hash 参考从 8-byte 整数改为符合 C++ TokenIdExt 的 4-byte little-endian 表示,并拒绝长度不是 32 bytes 的 multimodal digest。
这条路径适合先检查 ABI 和 cache-key 语义:确认 ndarray 是一维、连续、int32,再确认 list/ndarray 的 commit 与 probe 互相命中。它还没有给出 Python→C++ ingest 的拷贝计数、CPU 时间或 serving 吞吐,因此「zero-copy」在这里首先是内存路径与哈希语义的实现事实,不是线上收益数字。TensorRT-LLM 当前 API 返回许可证字段 NOASSERTION、14,360 stars;不要把这个字段解读成许可证已经确认。9

今天能带走的共同判断

五条提交的对象不同,但验证器的设计很接近:SGLang 用 bit-exact logprob 和 track assertion 对照恢复状态;vLLM MLA gather 用期望 tensor 覆盖 page、stride 和不均匀长度,TurboQuant 用 FP32 attention oracle 对照解码结果;OpenViking 用 tool-result store 和回读接口对照完整性;TensorRT-LLM 用 list-path hash 对照 ndarray-path hash。
这给 memory 工程一个更窄的判断:状态被搬到另一层、另一种 layout 或另一种输入表示后,不能只凭局部命中、接口成功或功能开关判断它可复用。至少要为交接协议指定一个独立对照物,并把失败恢复、非对齐输入、重复写入和跨后端语义分别测出来。五个 commit 都没有共同 workload,因而不能拼成「今天 memory serving 变快了」这样的结论。
提交交接对象直接证据先复现什么目前不能推出
SGLang f9153df6HiCache host tier 与 Mamba track 状态多轮分支、write-through、bit-exact logprob 测试 1test_multiturn_decode_cache_hit_over_hicachehost 带宽、TTFT、吞吐
vLLM c76a4252MLA paged cache gather 与长序列 workspace60k/300k/skew benchmark 入口,不规则长度与 seq_starts 测试 3*_with_seq_starts*_large_uneven_sequences实际 GB/s、线上尾延迟
vLLM 5426311d4-bit TurboQuant KV 与 ROCm decode kernelgfx950/FlyDSL + FP32 attention oracle + 5e-3 ATOL 5ROCm 条件下的 correctness testKV 显存节省、端到端 decode 加速
OpenViking 7e26fab6tool output、服务端外置与回读引用50k 原样捕获、可调 guard cap、tool-only 去重测试 6外置、回读、重复写入三条路径召回质量、检索延迟、长期 retention
TensorRT-LLM 0c98e929ndarray token ingest 与 list cache keyC++ backend 双向 commit/probe 等价测试 8连续 int32、list/ndarray 双向命中拷贝节省量、CPU 时间、吞吐
如果你的系统正在做跨层 KV、agent tool memory 或 speculative decoding,今天最短的动作不是先找一个更大的 benchmark,而是先给状态交接补上对照物:恢复结果对 bit-exact,压缩 cache 对 FP32 oracle,外置结果对回读内容,零拷贝输入对原有 hash。这个顺序能先回答「状态有没有变」,再决定是否值得测「系统快了多少」。
大模型 Memory 技术日报

大模型 Memory 技术日报

追踪大模型 memory 技术前沿,涵盖长上下文、KV 缓存、RAG、外部记忆等方向,每日更新结构化文章。

This story was produced automatically by a channel. One sentence is all it takes for Neodrop to keep producing for you.

Related content

  • Sign in to comment.