Memory 技术日报 2026-07-13：SGLang Omni、Triton Kernel Lab 与 RISWIS

过去 24 小时的 memory/context 信号更偏工程侧：一个 serving 文档把「同一张 GPU 上跑多个副本」的 KV pool 问题讲透，一个 Triton 教学仓库把 KV-cache movement 纳入可跑 benchmark，一个 RAGFlow 集成则把检索到生成之间的治理链路补成可审计状态。今天这期收缩为三条，重点看 memory 不在模型里时，系统该把容量、移动和证据放在哪一层。

SGLang Omni 这次新增的不是一个抽象性能口号，而是一份 same-GPU DP with CUDA MPS 操作指南。它的目标场景是：单个 serving replica 已经调到吞吐平台期，但 GPU 仍有明显空闲；这时把多个完整副本放在同一张 GPU 上，让 CUDA MPS 共享 GPU，可能回收空闲算力。文档给出的 H100 80GB + Higgs TTS pinned case study 中，单副本约 21.7-22.1 qps，DP2+MPS 到 31.5-37.7 qps，DP3+MPS 到 39.9-46.9 qps。1

这条和 memory/channel 的关系在 KV pool。文档明确提醒，多个副本即使使用相同 --mem-fraction-static，也不等于拿到相同 KV 容量；该参数按每个副本启动时剩余 GPU 内存计算，顺序启动会让后启动的副本看到更小的 free memory。文档给过一个例子：三个顺序启动的 mf=0.27 副本，实际得到的 KV tokens 是 97,503 / 53,149 / 20,961。1

所以这里的工程动作不是「把副本数加到 2 或 3」这么简单，而是先读每个 replica 日志里的 KV Cache is allocated. #tokens: ...，必要时用 --max-total-tokens 给所有副本设置共同 token cap。否则同卡多副本可能只是把单副本的容量问题切成几个不等大的池子，后续路由、排队和尾延迟都会变得更难解释。1

边界也要写清楚。文档披露了失败和降级运行：DP2 曾遇到 cudaErrorMpsRpcFailure，也有副本启动失败；作者还说 generality 没有完全验证，H200 和 Qwen3-4B 相关实验尚未完整展开。今天应把它当作可复现实验指南和 sizing checklist，而不是通用加速定律。1

Triton Kernel Lab for LLM Inference 是一个偏教学和 benchmark 的仓库，作者在窗口内发帖称已发布。它覆盖 attention、RMSNorm、RoPE、SwiGLU、INT8 matmul、fusion 和 KV-cache movement，目标是让 LLM serving 背后的 GPU kernel 有可读实现、PyTorch baseline、correctness tests 和 roofline benchmark。43

仓库 README 把定位说得比较克制：它不是 FlashAttention、TensorRT-LLM、cuBLAS 或厂商 tuned library 的替代品，而是一个 interview-defensible kernel lab。这个说法反而有价值，因为 memory/context 方向经常把 KV cache 当成抽象「显存占用」，但线上延迟很多时候卡在 memory movement、layout、copy bandwidth 和 cache behavior。把 KV cache write/read/copy bandwidth 单独列成 kernel 项，比只看 attention TFLOP/s 更接近 serving 现场。3

它的最新提交也有生产味：7 月 12 日白天的 commit 补了 T4 FlashAttention correctness 与负结果，说明 pre-Ampere 机器可以通过 correctness，但性能远低于 A10G 口径；这比只展示最亮眼硬件数字更有参考价值。5

工程判断：如果团队要做 KV movement、paged KV layout 或 RoPE/RMSNorm 这类 kernel 训练，这个 repo 值得作为学习材料；如果要上生产，则仍应回到 vLLM、SGLang、TensorRT-LLM 或厂商库的成熟路径。它更像「把 memory movement 讲清楚的实验台」，不是一键替换生产推理栈。3

RISWIS 这条更新的重点是 RAGFlow pipeline 里的治理位置。作者称 RISWIS 现在捕获完整 retrieval → generation pipeline，包括检索文档、每个 chunk 的治理决策、prompt enforcement 和最终回答；目标是让每次 response 都能从 retrieval 审计到 generation。6

这和传统 RAG debug 的差别在于，审计对象不是「最后答案有没有引用」而是「哪些 chunk 为什么能进 prompt」。如果治理层只在答案生成后检查，模型已经看过可能不该看的上下文；如果每个 chunk 在进入 prompt 前都留下 allow、review 或 block 的原因，RAG memory 才能把语义相关性和策略约束分开。作者那句「Semantic winner ≠ Policy winner」说的正是这点。6

这条目前只能保守写。我们没有读到独立 release、代码 diff、demo 或可复现实验，所以它不是一个已验证的 RAGFlow 功能结论；它更像一个窗口内项目更新，提示 RAG 工程正在把 memory governance 从检索器外部的日志，前移到 chunk 级决策链。6

工程判断：如果你在做企业 RAG 或 agent memory，先别只盯召回率。下一步要问的是：每条被召回的上下文有没有策略判断、有没有进入 prompt 的证据、有没有最终答案和 chunk 决策之间的可追踪关系。没有这些记录，事故复盘时只能看到模型说了什么，看不到它为什么看见了这些材料。

今天三条线索都把 memory 问题从「存什么」推进到「谁拥有、谁移动、谁放行」。SGLang Omni 讨论的是一张 GPU 上多个 replica 如何切 KV pool；Triton Kernel Lab 把 KV-cache movement 放进可测 kernel；RISWIS 则把 RAG chunk 的治理决策放到生成前。

如果只选一条继续跟，serving 团队先看 SGLang Omni 的 same-GPU DP 文档，因为它直接关系到高显存 GPU 上的副本 sizing、MPS 验证和 KV token cap；做 kernel 或推理系统学习的读者看 Triton Kernel Lab，重点不是复刻 README 数字，而是理解 memory movement 的测量方式；做企业 RAG 的团队看 RISWIS，把「最相关」和「可进入 prompt」拆成两条独立链路。