llm-infra · E1 预消化简报(2026-08-20)
E1 日间预消化轮 · 2026-08-20 18:40 CST · spark · 窗口:8-19 18:44 → 8-20 18:40 基线:knowledge/llm-infra.md §IX 52nd(2026-08-20 05:13 落定)≡ 5 件 arXiv 主轴 + 13 件立基础延展 + 推理工程学第 9 维 47 → 54 件套扩面 任务:为今晚 §IX 53 棒 v53 接力 / v54 主题活文档预习备料
一、增量摘要
本轮增量条数:7 条(4 条主轴 net-new 增量 + 1 条生产实践补丁 + 2 条邻接级交叉)
涉及 arXiv 号:2608.14376 2608.14333 2608.11668 2608.17050 2608.17512 2608.18063 2608.17950 2606.06090 2606.00237(其中 2608.17512 / 2608.18063 / 2608.17950 已在 8-19 spark agent-e1prep 中沿用,275 以下全部为本次主轴 net-new)
窗口特征:llm-infra.md 自 8-20 05:13 落定以来,本棒是真空期首棒——engineering.md 仍处 v56/v57(2026-08-19 09:15 落定),agent.md 仍 v53(2026-08-20 10:30)。今天 8-20 期间所有公开材料(arXiv / LMSYS Blog / CSDN / Substack / GitHub)中的 llm-infra 净增量,主要通过 jay 8-20 11:22 engineering-e1prep、jay 8-20 13:35 inference-vecdb-harness-substack、jay 8-20 14:25 csdn-inference-oom-benchmark-commands、jay 8-20 11:07 sglang-h20-commands 带出,但其中 4 条直接属于 llm-infra 主轴,达到 §IX 53 棒"主轴 net-new 4 件"门槛(§IX 52 仅 5 件 arXiv 主轴 + 1 件旧卡复活;§IX 53 net-new 4 件与 5+1 持平)。
二、核心增量条目
增量 1:SGLang Advanced CUDA Graph 官方生产调优指南(LMSYS Blog, 2026-08-17)
来源:
- inbox/jay/2026-08-20T1055-jay-engineering-filter.md §条目 1
- inbox/jay/2026-08-20-engineering-e1prep.md(11:22 落定)
- LMSYS Blog 原文:https://www.lmsys.org/blog/2026-08-17-advanced-cuda-graph
arXiv:无(LMSYS/SGLang 官方工程博客)
TLDR:LMSYS 官方博客详解 SGLang 的 Breakable CUDA Graph vs Full CUDA Graph vs torch.compile piecewise 后端。生产建议明确:breakable 或 tc_piecewise 用于生产,full 仅实验性使用。prefill graph 构建速度提升 3.8–5.2×,代码量减少 75%(521 → 177 行)。
要点:
- 三种 CUDA Graph 后端对比:
- full:捕获整个 prefill 为单个 CUDA Graph,实验性,仅 FA4 / FlashInfer 后端支持
- breakable:分段捕获,可动态处理变长序列,生产推荐
- tc_piecewise(torch.compile):最小代码量(177 行 vs 521 行),生产推荐
- 关键性能数据:
- prefill graph 构建速度:breakable / tc_piecewise 比 full 快 3.8–5.2×
- 代码量减少 75%:full 521 行 → breakable/tc_piecewise 177 行
- CUDA Graph 静态 buffer 机制与 GPU 内存复用的关系
- 生产建议:breakable 或 tc_piecewise 用于生产,full 仅实验
- 关键引述:"Full prefill capture is still an experimental feature. The engine warns that full is experimental and points to breakable or tc_piecewise for production workloads"
与 knowledge/llm-infra.md §IX 52 现有脉络的关系:
- 锚入 §1.(1) 推理引擎 6 寡头 + 4+3+1+1+3+8 邻接 的 SGLang 分支(SGLang 是当前 6 寡头之一)
- 与 §IX 52 立基础延展的 vLLM vs SGLang 生产决策树 v2 形成生产实践补丁:决策树 v2 解决了"选哪个",CUDA Graph 调优解决了"选完后怎么调到极致"
- 与 §IX 51 CSDN inference 量化 5+7 件形成 SGLang 侧工程深补:§IX 51 仅有 vLLM 排障命令,本棒新增 SGLang breakable vs tc_piecewise vs full 官方生产建议
- 与 §IX 52 的 The Silent Hyperparameter arXiv:2605.19537 engine-level 可复现性危机量化 形成纵向深化:CUDA Graph 静态 buffer 机制是该轴的工程核心
建议归入节:§1.(1) 推理引擎 6 寡头 + 4+3+1+1+3+8 邻接立基础延展(新增 SGLang CUDA Graph 生产调优子节,标注 breakable/tc_piecewise 生产推荐 vs full 实验性,prefill graph 构建 3.8–5.2× 加速 + 代码量 -75%)
增量 2:CoRun 确定性 LLM 推理调度(arXiv:2608.14376,2026-08)
来源:
- inbox/jay/2026-08-20T1055-jay-engineering-filter.md §条目 3
- inbox/jay/2026-08-20-engineering-e1prep.md 增量 2
arXiv:2608.14376
TLDR:Continuous batching 中不同长度请求混合导致 CUDA Graph 形状不固定(vLLM 和 SGLang 共同的技术债务)。CoRun 解法:prefill 隔离每个请求自然形状,decode pad 到最大并发重放固定 CUDA Graph。关键数据:吞吐量提升 15–324%(所有模型均超过 2×),且输出 bit-identical(确定性)。
要点: - 核心问题:continuous batching → 不同长度请求混合 → CUDA Graph 形状不固定 → 无法有效利用 graph replay 加速 - CoRun 解法: 1. Prefill 隔离每个请求自然形状 2. Decode pad 到最大并发,生成固定形状的 CUDA Graph 3. 固定形状 graph 可重放(replay),保持高吞吐 - 关键数据:吞吐量提升 15–324%(所有模型均超 2×),输出 bit-identical - 评测模型:Qwen3-235B-A22B、DeepSeek-V3、Hy3 - 涉及:Split-KV decode 禁用、deterministic collectives 实现 - 工程意义:对 vLLM 和 SGLang 共同技术债的学术解法,若被 vLLM/SGLang 采纳整合,生产级 continuous batching 效率可进一步提升
与 knowledge/llm-infra.md §IX 52 现有脉络的关系:
- 锚入 §1.(2) 推理调度 9+1+1+2+1+1+2 学派 的"continuous batching 确定性调度"新学派候选
- 与 §IX 52 立基础延展的 Albireo arXiv:2606.01927 vLLM 插件 1.7× 加速 形成横向互补:Albireo 是"调度 + 采样侧 CPU 开销消除",CoRun 是"batching 形状固定 + 确定性"——两者层次不同目标互补
- 与 §IX 52 的 The Silent Hyperparameter arXiv:2605.19537 形成纵向深化:bit-identical 输出是 engine-level 可复现性危机的终极目标,CoRun 在 batching 层面实现了这一点
- 与 §IX 50 沿用 OpScale arXiv:2608.13499 MSR 算子级弹性扩缩容 形成对比:OpScale 是 GPU 算子级,CoRun 是 batching 调度级
- 与 §IX 52 的 EuroSys 2026 FlexPipe(无服务器 GPU 集群 LLM 推理管道重构)形成学派级新增候选——CoRun = +1 推理调度学派(连续 batching 确定性)
建议归入节:§1.(2) 推理调度 9+1+1+2+1+1+2 学派 → 第 16 候选学派(continuous batching 确定性调度,CoRun 15–324% 吞吐 + bit-identical)+ §1.(1) 立基础延展候选级补强 + §1.(1) 第 9 维推理工程学 54 → 55 件套扩面
增量 3:DASH HBM+Flash KV Cache 两级管理(arXiv:2608.14333,2026-08)
来源:
- inbox/jay/2026-08-20T1055-jay-engineering-filter.md §条目 4
- inbox/jay/2026-08-20-engineering-e1prep.md 增量 3
arXiv:2608.14333
TLDR:KV cache 容量是 MoE LLM 部署的核心瓶颈(Llama 4 Maverick KV cache 197.41 GB,超过单卡 HBM)。DASH 提出 HBM+Flash 两级 KV cache 管理:HBM 吸收细粒度写入 + 批量写回 Flash。关键数据:Llama 4 Maverick 上比 RelayOnly 提升 1.92× 吞吐量,降低 E2E 延迟 48%。
要点: - 核心问题:MoE LLM KV cache 容量超 HBM(Llama 4 Maverick 197.41 GB)→ 部署瓶颈 - DASH 解法:HBM+Flash 两级管理 - HBM:吸收细粒度写入(production 时序排序) - Flash:批量写回(HBF writeback 策略,page-padding factor = 1.0 for prefill writes) - KV write scheduling:按 production 和 reuse 时序排序 - HBF endurance 建模:0.645 年连续活动投影,page-padding factor = 1.0 - 关键数据:Llama 4 Maverick(KV cache 197.41 GB)上,DASH 比 RelayOnly 提升 1.92× 吞吐量,降低 E2E 延迟 48% - 工程意义:HBF 作为 KV-cache 主存层的设计值得追踪;与 v56 已有的 GPU 侧 KV Cache 优化(vToken/Maglev/FreeToken)形成互补(它们优化 GPU 侧,DASH 扩展到 Flash 侧)
与 knowledge/llm-infra.md §IX 52 现有脉络的关系:
- 锚入 §1.(3) KV Cache 17 路线 的第 18 路线候选(HBF 高带宽闪存 KV 主存层)
- 与 §IX 52 立基础延展的 vToken arXiv:2608.13263 GPU 内存 token 级 KV 虚拟化(已沿用 §IX 50)+ Maglev arXiv:2608.02870 + FreeToken arXiv:2608.16157(§IX 51 沿用)形成 GPU 侧 → GPU+HBM+Flash 三级扩展
- 与 §IX 52 的 ICMSP/NIXL CES 2026 NVIDIA BlueField-4 DPU + NIXL 4 介质 KV 传输协议(已沿用 §IX 50)在硬件层互补:ICMSP/NIXL 解决 GPU↔GPU 跨节点 KV 传输,DASH 解决 GPU↔Flash 单节点 KV 溢出
- 与 §IX 44 沿用的 OasisKV arXiv:2608.08097 形成路线级同步:OasisKV 关注 SSD KV 持久化,DASH 关注 HBF 写入调度
建议归入节:§1.(3) KV Cache 17 路线 → 第 18 路线候选(HBF + HBM 两级 KV Cache,DASH MoE LLM 1.92× 吞吐 + 48% 延迟降低,LLM 4 Maverick KV 197.41GB 适用)+ §1.(1) Engineer Inference 第 9 维 55 → 56 件套扩面
增量 4:HBF Sucks 全栈表征(arXiv:2608.11668v2,2026-08-13)
来源:
- inbox/jay/2026-08-20T1055-jay-engineering-filter.md §条目 5
arXiv:2608.11668v2
TLDR:系统性分析 HBF(High-Bandwidth Flash)用于 KV cache 的全栈特性,对比 GPU HBM / HBF 带宽差异对 decode vs prefill 延迟的影响,引用 LMCache、Tutti(HBF-backed KV cache)等相关工作,涵盖 KV cache 容量限制的历史(SOTA paged allocation、quantization 等均无法突破容量上限)。
要点: - 核心问题:HBF 作为 KV cache 全栈特性研究,定量分析 GPU HBM / HBF 带宽差异 - 覆盖内容:decode vs prefill 延迟分离建模、KV cache 容量限制历史综述 - 相关工作:LMCache、Tutti(HBF-backed KV cache) - 工程意义:与 DASH(增量 3)互补——DASH 是 HBF writeback 策略,HBF Sucks 是 HBF 通用特性研究。二者形成"HBF KV cache 路线"的两个互补锚点
与 knowledge/llm-infra.md §IX 52 现有脉络的关系:
- 与增量 3 DASH 互为表里:DASH = HBF 写入侧,HBF Sucks = HBF 读取/全栈侧
- 锚入 §1.(3) KV Cache 17 路线 的 HBF 路线补强(第 18 路线候选,与 DASH 并列)
- 与 §IX 47 沿用的 Memory-Centric CXL+PIM 形成路线级同步:两者都关注"GPU 内存之外"的存储介质,但介质不同(Flash vs CXL/PIM)
建议归入节:§1.(3) KV Cache 17 路线 → 第 18 路线候选补强 2(HBF 全栈表征,HBF Sucks arXiv:2608.11668v2 / DASH arXiv:2608.14333 互补)+ §6.13 沿用引用补遗
增量 5:CSDN inference 工程实战 8 件 vLLM/SGLang 实战补丁(jay 8-20 14:25)
来源:
- inbox/jay/2026-08-20T1425-jay-csdn-inference-oom-benchmark-commands-highvalue.md
arXiv:无(CSDN 实战文章)
TLDR:jay 8-20 14:25 给出的 8 件 CSDN inference 实战高价值条目,补强 vLLM / SGLang 部署排障、benchmark 命令库、KV Cache 数值计算、gpu_memory_utilization 软限制、多卡部署 + OOM 真实命令、K8s + vLLM 全链路排查、源码调试路径、Jig Harness 安全对比 2026 横评。核心增量是 OOM 实战 + benchmark 命令库 + GPU 内存计算 + SGLang vs vLLM A10 实测。
要点:
- vLLM OOM 排查实战(blog.csdn.net/weixin_36303807/article/details/155249188):
- LLaMA-7B FP16 每 token 约 1.5MB KV(4096 长度需 6GB)
- PagedAttention 每 page = 8 tokens KV,非连续分配、页表映射
- gpu_memory_utilization 0.7→0.8 反而 OOM(软限制非硬限制,warmup dummy requests 阶段已分配)
- 连续批处理:吞吐量提升 5–10×,并发请求数提升 3×
- bench_serving 完整命令库(blog.csdn.net/u013701860/article/details/148295809):
- SGLang 后端 + vLLM 后端(含 pd-separated)+ SGLang HuggingFace OAI 兼容 + bench_one_batch_server + guidellm + ModelScope 源
- gpu_memory_utilization 源码级分析(blog.csdn.net/taoqick/article/details/151715145):
- 软限制/目标预算,CUDA graphs 额外 1–3 GiB per GPU
- warmup 阶段 OOM:RuntimeError: CUDA out of memory occurred when warming up sampler with 256 dummy requests
- SGLang vs vLLM A10 + Qwen2.5-7B AWQ / Qwen3-4B AWQ 实测(blog.csdn.net/no2454410/article/details/156947444):
- 单轮短文本:vLLM 280 tok/s 85ms vs SGLang 265 tok/s 92ms(vLLM 略优)
- 复杂多步骤共享前缀:vLLM 120 tok/s 350ms vs SGLang 310 tok/s 180ms(SGLang 优势显著)
- 结构化输出 JSON:vLLM 180 tok/s(含后处理)vs SGLang 270 tok/s(原生约束)SGLang 明显优势
- K8s + vLLM 全链路 OOM 排查:kubectl describe + journalctl -k + Prometheus 报警规则 + VLLM_MAX_NUM_SEQS=150 + VLLM_GPU_MEM_UTILIZATION=0.85
- Cursor/VSCode 单步调试 vLLM/SGLang 源码:Scheduler.py / Worker.py + SGLang TpModelWorker + 推荐学习路径(PyTorch → CUDA → RoPE/ALiBi/FlashAttention → 源码)
与 knowledge/llm-infra.md §IX 52 现有脉络的关系:
- 产品级量化:A10 + Qwen2.5-7B AWQ + Qwen3-4B AWQ 实测是对 §IX 52 立基础延展的 Particula +29% 总吞吐 + SGLang 894 vs vLLM 413 +117% 输出吞吐 + JSON 合规率 SGLang 96-98.2% vs vLLM 90-94% 的第二来源独立交叉验证——CSDN 数据来自 A10 量化模型,Particula 来自 H100/H200,两套数据均指向 SGLang 在"结构化输出 + 共享前缀"场景显著优于 vLLM
- 生产命令库补强:§IX 52 已有的 vLLM/SGLang 决策树 v2 + Particula + Spheron 是"选哪个 + 价格",本棒新增 CSDN 8 件是"选完后怎么调 + 怎么排错"
- OOM 实战补强:§IX 49 沿用的 Jarvis Labs CPU Offloading + GPUYard KV 公式 + DeployBase A100 5 引擎 是"内存规划原则",本棒 CSDN 实战是"具体场景下的 OOM 数值计算 + 命令"
- 量化经济学锚入:gpu_memory_utilization 软限制 + CUDA graphs 1-3 GiB per GPU + 连续批处理 5-10× 吞吐 量化经济学具体数字,与 §IX 52 立基础延展的 Spheron H100/H200 价格 + F22labs TRT-LLM 量化精度 + Zylos 优化层级形成"价格 × 内存 × 量化"三维实证
建议归入节:§1.(1) 推理引擎 6 寡头 + 4+3+1+1+3+8 邻接立基础延展 → 第 9-12 件 / §1.(9) 量化经济学立基础延展 → 第 6-7 件(CSDN OOM 实战 + bench_serving 命令库 + A10 量化实测交叉验证)
增量 6:Cross-Model Memory Transfer Engram(arXiv:2608.17050,2026-08,邻接级)
来源:
- inbox/jay/2026-08-20-engineering-e1prep.md 增量 6
- paper_cards/1017-2608-17050.md(tom 8-19 radar 候选归档)
arXiv:2608.17050
TLDR:Engram 是可复用的外部知识工件,跨模型迁移时只需目标侧有兼容的 Reader 接口;当直接复用 Reader 效果不足时,目标侧适配可进一步改善对齐效果。核心贡献是跨模型记忆迁移的工程可行性论证。
要点:
- 核心机制:Engram 作为外部知识工件,可跨模型复用
- 前提条件:目标侧需要兼容的 Reader 接口
- 补充手段:目标侧适配可进一步改善对齐(当直接复用 Reader 效果不足时)
- 工程意义:与 §IX 52 的 Memory as first-class citizen 路线形成纵向深化:Engram 将 memory 从"单模型内部状态"扩展到"跨模型可迁移的知识资产"
与 knowledge/llm-infra.md §IX 52 现有脉络的关系:
- 与 §IX 52 立基础延展的 Context Engineering 4 层累积成熟度金字塔(arXiv:2603.09619)形成 Agent Memory 邻接级补强:Context Engineering 是"上下文管理",Engram 是"跨模型知识迁移"
- 与 §IX 52 的 Harness Engineering arXiv:2607.08028 形成 Agent 邻接级:同属 §1.(11) Kernel/AI 自动化/Harness 立基础延展候选
- 主轴归属:严格说是 agent 主轴,llm-infra 邻接级——§IX 52 §1.(11) 立基础延展候选
建议归入节:§1.(13) 边界扩展(agent 主轴 邻接级)+ §1.(11) Kernel/AI 自动化/Harness 立基础延展候选补强
增量 7:Miles v0.1 SGLang 生产级 RL Post-training(LMSYS Blog, 2026-08-18,邻接级)
来源:
- inbox/jay/2026-08-20T1055-jay-engineering-filter.md §条目 8
arXiv:无(LMSYS 官方博客)
TLDR:Miles v0.1 是 SGLang 生态的生产级 RL Post-training 框架,与 SGLang 共享 rollout integration(同一套推理基础设施),支持 NVIDIA A100–GB300 和 AMD ROCm(MI300X–MI355X)双平台。Day-0 支持 DeepSeek-V4、Nemotron 3 Ultra、Inkling、Kimi K3、Qwen3.8。
要点: - 与 SGLang 共享 rollout integration → 推理和训练共用同一套基础设施 - 双平台支持:NVIDIA A100–GB300 + AMD ROCm(MI300X–MI355X) - 低 KL divergence 验证(SGLang 和 Megatron-LM 对齐) - Day-0 支持:DeepSeek-V4、Nemotron 3 Ultra、Inkling、Kimi K3、Qwen3.8 - 工程意义:SGLang 生态从推理扩展到训练(推理 + RL post-training 一体化);AMD ROCm 支持意味着非 NVIDIA 硬件的可行生产路径
与 knowledge/llm-infra.md §IX 52 现有脉络的关系:
- 与 §IX 52 立基础延展的 SGLang RadixArk TPU 完整支持(2026-07) 形成 SGLang 生态扩展双轨:推理引擎扩展到 TPU + RL 训练框架扩展到 AMD ROCm
- 与 §IX 52 的 Mojo🔥 开源(2026-08-17 Apache 2.0) 形成"AI 工程语言基础设施 + SGLang RL 训练框架"两个并行的基础设施扩展
- 主轴归属:LLM 训练框架邻接级(llm-infra 关注推理,Miles 是 RL post-training),但因 SGLang 共享 rollout,可作为 llm-infra §1.(1) 推理引擎邻接级补强
建议归入节:§1.(1) 推理引擎 6 寡头 + 4+3+1+1+3+8 邻接立基础延展(SGLang 生态扩展)+ §1.(11) 训练-推理一体化邻接级 + §1.(13) 边界扩展
三、值得警惕的矛盾或待核实说法
-
CoRun 15–324% 吞吐量提升的可复现性:该数字来自论文 arXiv:2608.14376 自身评测,评测环境(硬件/模型/batch size)细节需 PDF 核验;GitHub 是否已开源(截至 2026-08-20 状态)需确认;若不开源,则工程价值大打折扣(参照 §IX 52 同类警示)。
-
SGLang Advanced CUDA Graph 官方建议的覆盖性:LMSYS 官方建议
breakable/tc_piecewise用于生产 +full仅实验性,但官方未给出在哪些具体 workload 下full仍优于 breakable / tc_piecewise 的边界条件——需结合vLLM V1 引擎架构 + DSpark 推测解码(H20 DSPARK block size = 7)综合判定。 -
DASH HBF endurance 0.645 年连续活动投影:0.645 年是连续满载写入的极端情况;实际生产中的典型工作负载(混合 prefill + decode)的 endurance 需结合具体使用模式估算——HBF 与 HBM 的介质寿命差异显著,需 PDF 核验 endurance 建模假设。
-
Miles v0.1 AMD ROCm 支持的生产成熟度:AMD MI300X 在大模型训练的生产部署案例相对 NVIDIA 较少;Miles 的 AMD ROCm 支持需要真实生产环境验证,不宜视为 production-ready 默认选项——与 §IX 52 沿用 NVIDIA Dynamo 1.0 的 NVIDIA 主导路线形成对比。
-
CSDN SGLang vs vLLM A10 量化实测与 Particula H100/H200 实测的数值一致性:CSDN 数据来自 A10 + Qwen2.5-7B AWQ,Particula 来自 H100/H200 + Llama-3.1 70B FP8——两套数据均指向 SGLang 在"结构化输出 + 共享前缀"场景显著优于 vLLM,但硬件代差 + 模型代差同时存在,数值直接对比需谨慎。建议补充 vLLM V1 在 A10 + 量化模型上的对位实测。
-
HBF Sucks arXiv:2608.11668v2 与 DASH arXiv:2608.14333 的关系:两者均关注 HBF + KV Cache,但 HBF Sucks 是全栈表征(读侧 + 写侧),DASH 是 HBF writeback 策略(写侧)——两者是否同一作者团队 / 是否互为引文 需 PDF 核验,避免重复归入。
-
Cross-Model Memory Transfer Engram 的"工程可行性"水位:论文论证了跨模型记忆迁移的可行性,但未量化在多大模型代差 / 架构差异(如 dense → MoE)下 Engram 仍有效——这是影响落地的关键参数。
四、可引用的 arXiv 号列表
| arXiv 号 | 论文 / 方法 | llm-infra 归属 | 状态 |
|---|---|---|---|
2608.14376 |
CoRun: Deterministic LLM Inference Scheduling(continuous batching 形状固定,15–324% 吞吐量,bit-identical) | §1.(1) 推理引擎 + §1.(2) 推理调度学派第 16 候选 | net-new(论文待建 paper_card) |
2608.14333 |
DASH: HBM+Flash KV Cache Management for MoE LLM(Llama 4 Maverick 1.92× 吞吐量,48% 延迟降低) | §1.(3) KV Cache 第 18 路线候选 | net-new(论文待建 paper_card) |
2608.11668v2 |
HBF Sucks: KV-Centric LLM Serving 全栈表征(GPU HBM/HBF 带宽差异对 decode vs prefill 延迟) | §1.(3) KV Cache 第 18 路线候选补强 | net-new(论文待建 paper_card) |
2608.17050 |
Cross-Model Memory Transfer via Target-Side Reader Adaptation(Engram 跨模型记忆迁移) | §1.(11) / §1.(13) 邻接级 | 已建 paper_card 1017 |
2608.17512 |
Embodied-Navigator | multimodal 邻接级 | 已在 8-19 spark agent-e1prep 沿用 |
2608.18063 |
EDITBRIDGE | multimodal 邻接级 | 已在 8-19 spark agent-e1prep 沿用 |
2608.17950 |
Six Degrees of Separation | evaluation 邻接级 | 已在 8-19 spark agent-e1prep 沿用 |
前轮已入账的 arXiv 号(延续引用,不重复计入本轮):
- §IX 52 主轴 5 件:2601.06288 2605.19537 2607.08028 2603.09619 2606.01927
- §IX 52 立基础延展候选 13 件:EuroSys 2026 6 件 + HPDC 2026 ATLAS + IEEE DCOSS-IoT 2026 Collaborative Edge TPU + Spheron H100/H200 + F22labs TRT-LLM + Lyceum 多模型路由 + Zylos 优化层级 + Mojo🔥 开源 + State of Open Models Summer 2026 + The AI Agents Stack 2026 Edition + MCP 工程实践三件套 + A2A 协议一周年
- §IX 51 沿用 7 件(paper_card 958 2608.08020 + paper_card 956 2608.11660 + paper_card 986 2608.13567 + paper_card 987 2608.16157 + arXiv:2608.14465 YOPO + arXiv:2608.13499 OpScale + arXiv:2608.13263 vToken paper_card 988)
- §IX 50 沿用 3 件(OpScale + vToken + DeltaKV 2602.08005)
- §IX 49 沿用 1 件(Maglev 2608.02870)
- §IX 48 沿用 9 件
五、检查过的来源
| 来源 | 文件 | llm-infra 相关性 |
|---|---|---|
inbox/jay/2026-08-20-engineering-e1prep.md |
8-20 jay 11:22 工程 E1 | 核心来源:CoRun + DASH + HBF Sucks + Cross-Model Memory Transfer + MCP 安全审计 + SWE-bench Pro + Miles v0.1 共 7 件 |
inbox/jay/2026-08-20T1055-jay-engineering-filter.md |
8-20 jay 10:53 工程筛选 | 核心来源:SGLang CUDA Graph + DeepSeek-V4-Pro H20 + CoRun + DASH + HBF Sucks + MCP Auth + A2A vs MCP + Miles v0.1 + SWE-bench Pro + Link 10 件 |
inbox/jay/2026-08-20T1130-jay-sglang-h20-commands.md |
8-20 jay 11:07 SGLang H20 命令 | 核心来源:DeepSeek-V4-Pro H20 完整 SGLang 命令 + mem-fraction-static 0.91 + DSPARK 推测解码 |
inbox/jay/2026-08-20T1335-jay-inference-vecdb-harness-substack-aug20.md |
8-20 jay 13:35 推理/向量数据库/Agent Harness | 核心来源:vLLM V1 / SGLang RadixAttention / NVIDIA Dynamo / PremAI H100 横评 / LMDeploy TTFT / 向量数据库 2026 选型决策树 |
inbox/jay/2026-08-20T1425-jay-csdn-inference-oom-benchmark-commands-highvalue.md |
8-20 jay 14:25 CSDN inference 实战 | 核心来源:vLLM OOM 排查 + bench_serving 完整命令库 + gpu_memory_utilization 软限制 + 多卡部署 + K8s + vLLM 全链路 + A10 + SGLang vs vLLM 实测 8 件 |
inbox/jay/2026-08-20T1510-jay-five-category-briefing.md |
8-20 jay 15:10 五分类简报 | 数据库 / backend / agent memory / RAG / 向量数据库 / reproduction —— llm-infra 主轴 0 件净增(辅助级) |
inbox/jay/2026-08-20T1620-jay-csdn-context-engineering-loop-agent-memory-highvalue.md |
8-20 jay 16:20 CSDN 上下文工程/Loop/Agent Memory | Context Engineering / Loop Engineering / Agent Memory——llm-infra 主轴 0 件净增,邻接级 |
inbox/jay/2026-08-20-engineering-roundup.md |
8-20 jay 工程 roundup | Substack GPU 成本量化 + 推理引擎实测 + Ollama vs vLLM 并发 + SWE-bench Pro —— 部分 llm-infra 邻接 |
inbox/jay/2026-08-20-ai-engineering.md |
8-20 jay 17:35 AI 工程 | vLLM V1 / TensorRT-LLM / SGLang RadixAttention / NVIDIA Dynamo ——已在 §IX 52 沿用,本棒无 net-new |
inbox/jay/2026-08-20T1335-jay-inference-vecdb-harness-substack-aug20.md § Substack The AI Agent Stack in 2026 |
8-20 jay 13:35 | Six 层架构图 + guardrails before action + Memory 第一公民原语——已在 §IX 52 立基础延展立基础延展 沿用 |
inbox/spark/2026-08-20-agent-e1prep.md |
8-20 spark 13:35 agent E1 | Meta-Harness / Microsoft Agent Lightning / OpenAI Black Hat / SWE-bench Pro / Cross-Model Memory Transfer / MCP 安全 / Hugo / 200B Token —— llm-infra 主轴 0 件净增,邻接级 |
paper_cards/1017-2608-17050.md |
8-19 tom radar 候选归档 | Cross-Model Memory Transfer arXiv:2608.17050 邻接级 |
未发现显著 net-new 增量的来源:
- inbox/tom/2026-08-20-rag-e1prep.md / 2026-08-20-evaluation-e1prep.md / 2026-08-20-agent-rag-longcontext-radar.md —— RAG / eval / agent-rag 主轴,llm-infra 沿用
- inbox/flyp/2026-08-20-risk-e1prep.md / 2026-08-20-multimodal-e1prep.md —— risk / multimodal 主轴,llm-infra 沿用
- inbox/stephen/2026-08-20-ai-industry-e1prep.md / 2026-08-20-1245-stephen-coordination-check-noon.md —— ai-industry / 协调棒,llm-infra 沿用
- inbox/jay/2026-08-20-ai-engineering-trending.md —— HF Trending / GitHub Top Projects / OWASP,llm-infra 邻接级沿用
- paper_cards/ 8-19 12:30 批次 5 张 net-new(987 FreeToken 已沿用 §IX 51 + 988 GRIP / 989 Hypergraph M-RAG / 990 DSPrompt / 991 IGD)均为 RAG / agent 邻接,llm-infra 主轴 0 件
六、§IX 53 棒 v53 接力棒建议
立基础延展候选(本棒新增 7 条,等于 §IX 52 立基础延展候选 13 件的 53%): 1. §1.(1) 推理引擎 6 寡头 + 4+3+1+1+3+8 邻接:SGLang Advanced CUDA Graph(增量 1)+ CSDN 推理实战 8 件(增量 5)+ Miles v0.1 邻接级(增量 7) 2. §1.(2) 推理调度 9+1+1+2+1+1+2 学派:CoRun 候选学派第 16 件(增量 2) 3. §1.(3) KV Cache 17 路线:DASH HBF + HBM 两级 / HBF Sucks 全栈表征(增量 3+4)→ 第 18 路线候选 4. §1.(11) Kernel/AI 自动化/Harness:Cross-Model Memory Transfer 邻接级(增量 6) 5. §1.(13) 边界扩展:Miles v0.1 + Cross-Model Memory Transfer 邻接级(增量 6+7)
§IX 53 棒立基础延展候选合计 ≥ 4 主轴 + 2 邻接 = 6 件——与 §IX 52 的 18 件 = 5 件 arXiv + 13 件立基础延展持平/略少。立标池饱和度供给侧 v44-v52 八日连续枯竭 → v53 班次首日仍处枯竭末段,但主轴 net-new 4 件已能满足"立基础延展第 1-4 件"水位。
待核警示(立基础延展 P0 待核): - CoRun 15-324% 提升的可复现性 + GitHub 开源状态 - DASH HBF endurance 0.645 年建模假设 - HBF Sucks 与 DASH 是否互为引文(避免重复归入) - Miles v0.1 AMD ROCm 生产成熟度 - CSDN SGLang vs vLLM A10 实测与 Particula H100/H200 实测的硬件代差 + 模型代差一致性
待建 paper_card: - CoRun arXiv:2608.14376 - DASH arXiv:2608.14333 - HBF Sucks arXiv:2608.11668v2
七、备注
- 本次窗口(8-19 18:44 → 8-20 18:40 CST)是 llm-infra.md 自 8-20 05:13 §IX 52 落定以来的真空期首棒——所有净增量均通过 jay 8-20 11:22 / 13:35 / 14:25 / 11:07 棒带出,spark 本棒本身无独立增量(本棒仅做预消化整合)。
- 与 engineering.md v56/v57 基线对照:上述 7 件增量与 engineering.md v56 §2.109 主线 7 子件 + 旁注 3 件部分重叠但主轴归属不同——CoRun / DASH / HBF Sucks / Cross-Model Memory Transfer 在 llm-infra 主轴属 §1.(1)/(2)/(3)/(11),在 engineering 主轴属 §2.1 / §2.3 / §2.24,今晚 §IX 53 棒 v53 接力时需确认归属(双轴 vs 选择其一)。
- 与 agent.md v53 基线对照:Cross-Model Memory Transfer Engram + Miles v0.1 同时属 llm-infra 邻接级 + agent 主轴邻接级,今晚 §IX 53 棒 v53 接力时需确认是双轴锚入还是按主轴优先级锚入。
本简报由 spark E1 预消化轮生成 · 2026-08-20 18:40 CST · 为今晚 §IX 53 棒 v53 接力 / v54 主题活文档预习备料 · 仅作为研究线索,不输出密钥、不修改他人目录、不 git 操作