精读与批判：LLM 推理在线调度（KV 约束）+ Elastic 可观测性新品速览

作者：flyP ｜ 时间：2026-10-26 15:50 (Asia/Shanghai) ｜ 批次：3d8f503a-7aeb-4a17-9550-c2514939fbfa

一、Online Scheduling for LLM Inference with KV Cache Constraints

• 标识：arXiv:2502.07115（v5，2026-01-15 提交；作者 Zijie Zhou 等）
• 来源 URL：https://arxiv.org/abs/2502.07115
• 卡片：organized/paper_cards/058-2502-07115.md
• 证据边界：paper_card_abstract + 一次 arXiv 摘要页核查（已取到官方完整 abstract 与版本历史）。未读正文 PDF，未读方法证明与实验章节，因此下述"方法拆解"来自摘要自述的贡献结构推导，非全文精读；论文卡中"延迟降低 76%、吞吐提升 2x、跨层流量减少 5.94x"等数字为卡片转述，未在本次核查中核实，不作为结论引用。

方法拆解（基于摘要自述的四段式结构）

1. 理论建模：把 LLM 在线推理抽象为带 KV cache 内存约束的调度问题——每个请求有输入长度与输出长度，KV 占用随解码步线性增长，内存上限直接决定可并发批大小。这是把 vLLM 类 continuous batching 从工程直觉转成优化问题的标准动作。
2. hindsight optimal benchmark：构造一个整数规划（IP），在"知晓全部未来到达与长度信息"的理想下求最小总推理时延。这是一个下界参照物，不是可部署算法。
3. 不可逼近性证明：证明当到达过程任意时，任何确定性在线算法都不可能达到常数竞争比。这句是论文最有价值的部分：它把"完美调度"的期望封死在理论天花板内。
4. 多项式时间在线算法 + 条件性常数竞争比：由于 IP 不可扩展求解，作者提一个在线算法，并只在"某些条件下"才能给出常数竞争比保证。

核心贡献

• 把 KV cache 约束显式纳入在线推理调度的理论框架，给出可与最优解比较的量化基准（hindsight optimal）。
• 负结果（no constant competitive ratio for arbitrary arrivals）本身就是贡献——它解释了为什么生产系统必须用启发式（FCFS、SJF、continuous batching 变体）而非指望最优。
• 实证线有两条：合成数据集对比 hindsight optimal；以及用真实公开推理数据集模拟 Llama2-70B 在 A100 上的表现。

主要问题

• "在某些条件下"的常数竞争比是核心弱点：条件是什么、覆盖多宽的到达/长度分布，摘要未交代。若条件过于贴近真实负载，理论意义会大幅缩水。
• hindsight optimal 的构造依赖未来信息：它以"知道全部未来"为前提构造下界，因此它离任何在线现实都很远；用它衡量"算法强劲"容易被误读为可达性能。
• Llama2-70B 是"模拟"而非实机：摘要明确写 "simulating the Llama2-70B model on A100 GPUs"。这意味着 GPU 实际执行、显存碎片、NVLink 拓扑、prefill/decode 抢占开销大概率被建模简化，与真实 vLLM/SGLang 服务的偏差未量化。
• 与现有工作差异点未核实：论文卡的"待补齐"项列出"与现有工作的差异点""方法与实验设置细节""是否有代码和数据集"，本次未解决。
• 论文卡的"可复用信息"段落（HBM/DRAM 分层、block-wise streaming attention）与摘要描述的调度主题并不完全对应，可能是卡片聚合时混入的相邻工作内容；本篇摘要本身讲的是调度与 KV 约束，不是存储分层。这是卡片层面的信息污染风险，需后续单独核。

实验风险

• 合成数据集与"真实公开数据集"两条线的结论强度不同，但摘要未区分哪条支撑哪条结论。
• 模拟环境中，硬件争抢（SM 占用、显存拷贝）被抽象掉，算法可能因过于依赖理想化代价模型而失真。
• 基准算法的选择范围未知；若仅与简单策略对比，"显著优于"的说服力有限。
• v3 版本曾被 withdrawn（摘要页提交历史可见），v5 为当前版本，修订动因未查。

复现难度

中高。理论上 IP 与竞争比证明需要读全文才能实现；实证侧需要自行实现调度器、KV 显存模型、A100 上的 Llama2-70B 模拟管线，并复现被抽象的成本模型。摘要未提供代码链接（论文卡"代码："为空）。

可信度

中高（作为理论论文）／中等（作为工程性能证据）。作者为已在 LLM serving 一线的研究者（摘要页提交信息），多版本迭代、v5 修订，负结果表述克制，无夸大形容词；且被引 23（S2）/ OpenAlex 1（卡片面数据）。但性能类结论依赖模拟环境，工程可信度打折。

后续验证

1. 读 https://arxiv.org/html/2502-07115v5 的方法与实验节，确认常数竞争比的条件假设与到达分布假设。
2. 核实具体收益数字是否与卡片转述一致（延迟/吞吐/流量倍数），以及这些数字来自合成线还是真实数据线。
3. 查 v3 withdrawn 与 v4/v5 修订原因。
4. 确认是否有开源代码/数据集；若无可复现路径，需在知识库标注"不可复现"。
5. 单独核对卡片中 HBM/DRAM 分层内容归属，避免串篇。

二、What's new in Elastic Observability（Elastic Observability Labs 栏目页）

• 标识 / 来源 URL：https://www.elastic.co/observability-labs/blog/category/whats-new
• 卡片：organized/indexes/article-evidence/d5816113889ccd64826426b5f7d54eb8dcfcc54019e77eab446720501fc749a6.json
• 证据边界：原为 search_snippet_only。本次一次页面核查返回 HTTP 200，但正文抽取只拿到站点 CSS 样板，未取得任何正文段落；随后做了一次限定主题的轻量补充搜索，取得该栏目条目与其中单篇的标题、作者与描述性片段。未读单篇文章全文，未核实任何性能数字。

观察到的主题线索（据标题与片段）

• Telemetry Policy（作者 Jack Shirazi）：把"想要什么"与"怎么实现"解耦——平台团队声明一次策略，各 SDK/agent/collector 自行落地；片段称可将运行中 Java 应用的 trace 采样率从 5% 调到 1%（另一片段提及 0.1）而不重启 JVM，JVM 持续服务。
• EDOT Android：一个 Gradle 依赖即接入移动 APM，提供 crash reporting、session tracking 与端到端分布式追踪（从点击到后端），在 Kibana 可见（作者 Cesar Munoz）。
• Elastic Agent 9.3：日志、指标、追踪统一走一条 OTel Collector 管线，Beats 集成与原生 OTel 数据源共存于单个 Fleet 管理的 agent（Nima Rezainia）。
• Elastic Agent 9.5：小日志文件的身份由其已有字节构建，随文件增长越过 1024 字节阈值后重链接，避免重复摄取（Orestis Floros）——实质是摄取侧的幂等/去重设计。
• 另见同栏目条目：ES|QL 单查询关联日志/指标/追踪；连续 profiling 对未修改 Java 应用采样；365 天审计日志在热数据与 searchable snapshot 上同一查询。

核心贡献（就栏目定位而言）

这一页本质是厂商发布节奏索引，其价值在于把"可观测性标准的运行时可配置化"（Telemetry Policy）这条主线显式摆出来：过去遥测配置多数在组件启动时固化，Telemetry Policy 试图把它变成运行期可改的策略面。

主要问题

• 厂商自述，非独立评测："without restart""JVM keeps serving traffic"均为 Elastic 自己的产品叙事，无第三方基准、无延迟代价测量。
• 标准成熟度不明：Telemetry Policy 被描述为"新兴标准"，但标准草案版本、SDK 支持矩阵、与其他 OTel 提案的关系均未核实，落地门槛未知。
• 栏目页不等于文章：条目标题与作者可确认，具体机制、实现限制（片段自称"the rest of this post covers what a policy is and where the limits are"）需读单篇正文。
• 快照时间跨度覆盖多个版本（9.3/9.5），条目新旧混杂，无法判断当前可用状态。

实验风险

• 无实验数据可核。所有性能与"不重启"结论目前只是厂商陈述。
• 采样率下调示例（5%→1%、0.1%）在真实生产中对账单、可观测性覆盖率的影响未讨论。

复现难度

低到中（相对第一篇完全不同性质：这不是论文）。多数条目是可直接试用/开源的版本功能；Telemetry Policy 的复现门槛取决于标准支持度与各 agent 实现完整度，需读单篇正文确认。

可信度

中低（作为技术结论）／中（作为版本情报索引）。来源可靠、URL 权威，但属产品方自述，且本次核查未取得正文，全部结论停留在标题与片段层面。

后续验证

1. 读单篇 Telemetry Policy 文章：https://www.elastic.co/observability-labs/blog/opentelemetry-java-agent-telemetry-policy（作者 Jack Shirazi），确认标准草案版本、支持矩阵与"limits"章节。
2. 核实 EDOT Android 的 GA 状态与最低 Android/Gradle 版本要求。
3. 确认 Elastic Agent 9.3 / 9.5 的实际发布说明与 changelog 细节。
4. 若需要性能结论，须另找第三方 OTel 运行时配置方案的横向对比。

证据边界总声明

• 本次精读对象严格限于清单 2 项，未新增第三个对象，未回退扫描全库。
• 网页核查共 2 次（arXiv 摘要页、Elastic 栏目页）+ 1 次限定主题的轻量补充搜索；未抓取长 PDF，未多轮扩展。
• arXiv 一项为摘要级证据，方法证明与实验章节未读；Elastic 一项为标题/片段级证据，正文未取得。
• 论文卡中未核实的数字（76%、2x、5.94x）已标注为待查，不作为本文结论。
• 两条目在各自证据边界内给出方法、贡献、问题、风险、复现与可信度判断；所有待补查项已列明。

清单条目与来源对照