engineering · E1 预消化简报(2026-07-22)
执行时间： 2026-07-22 11:20 (Asia/Shanghai) 检查范围： inbox jay/tom/flyp/spark/stephen 近 2 天（2026-07-20~22）+ paper_cards 近 3 天新卡（卡号 481~515）+ 跨日间已有工程简报 知识库现状： knowledge/engineering.md v32（2026-07-20 09:43，599 行，88 主线）；昨日 E1（2026-07-21）已收录 8 条增量 状态： 中高增量（12 条新信号，含 1 项今日重磅发布）
📦 本次增量工程信号（12 条）
条目 1：PyTorch 2.13 正式发布——CuTe DSL、FlexAttention Apple Silicon 12×、LinearCrossEntropyLoss ⭐⭐⭐⭐⭐
来源： PyTorch 官方博客，https://pytorch.org/blog/pytorch-2-13-release-blog/，2026-07-22 今日发布 可信度： ⭐⭐⭐⭐⭐（PyTorch Foundation 官方，3328 commits / 526 贡献者）
要点（按工程价值排序）： 1. CuTe DSL Native Backend：Inductor 的第二高性能代码路径（与 Triton 并行），GPU 核心操作编译速度更快——这是 2.x 系列首个非 Triton 的 GPU 代码生成后端 2. FlexAttention Apple Silicon：MPS 后端稀疏模式比 SDPA 快约 12×；CUDA 后端新增 deterministic backward path（可复现梯度计算） 3. nn.LinearCrossEntropyLoss：合并最终预测与损失计算，大词表语言模型训练峰值 GPU 内存降低最高 4×（对 MoE、大词表 embedding 模型意义重大） 4. torchcomms：PyTorch Distributed 新型通信后端，提升大规模集群训练的容错性、可扩展性 5. FSDP2 重叠优化：reduce-scatter 与 all-gather 通信通过专用 process group 重叠（opt-in） 6. Python 3.15 free-threaded 兼容构建
与 knowledge/engineering.md 现有脉络的关系： v32 未收录 PyTorch 2.13（v32 截止于 7-20）；PyTorch 2.13 是 2.x 系列走向"统一硬件无关平台"的关键版本，CuTe DSL 给推理编译生态带来直接影响——与 §2.29（推理引擎选型）直接关联；LinearCrossEntropyLoss 4× 内存降低是 MoE 训练的新里程碑。
建议归入： §2.29（推理引擎基础设施更新）+ 新增 PyTorch 2.13 条目作为框架层重要里程碑
条目 2：Netflix 自建 LLM Serving——vLLM 生产选型 + 静默参数丢弃 Bug + 版本对齐教训 ⭐⭐⭐⭐⭐
来源： Netflix Technology Blog，"In-house LLM Serving at Netflix"，2026-07-18 可信度： ⭐⭐⭐⭐⭐（一线工程团队亲述，含具体版本号/Bug/故障树）
要点： Netflix 选择 vLLM 而非 TRT-LLM 作为内部推理引擎，核心原因：ML 工程师已在研究阶段熟悉 vLLM、支持自定义模型架构、支持自定义解码逻辑扩展（约束解码必需）。
关键生产教训（全新细节，与 v32 §2.13 静默失败论点高度吻合）：
1. response_format 静默丢弃 Bug：Triton 兼容前端转发时，response_format 参数被静默丢弃，guided decoding 约束未生效，但平台无任何错误上报——这是经典的"错误信号从未以可操作形式触达人类"案例
2. 版本对齐陷阱：Triton 25.09 引入 vllm.engine.metrics 时，该模块已在 vLLM 0.11.2 中移除，导致 backend 加载失败——平台需统一 pinned 版本，禁止 model author 自行 override
3. OpenAI 兼容 API 作为生态桥接：存量 gRPC 路径服务旧应用，OpenAI 兼容 HTTP 路径服务新 LLM 应用，迁移成本极低
与 knowledge/engineering.md 现有脉络的关系： v32 §2.13（推理工程可复现性危机）+ §2.27（静默失败分类学）→ Netflix 案例是大厂自建推理平台的最完整实战案例，提供了 vLLM vs TRT-LLM 选型第一性工程理由，response_format 静默丢弃是 §2.13/v32 主张的直接印证。
建议归入： §2.13 可复现性危机 + §2.29 推理引擎 2026-07 选型；可新建 §2.88 大厂自建 LLM Serving 案例
条目 3：Albireo——超越 Amdahl 扩展极限的并行推理系统（arXiv:2606.01927） ⭐⭐⭐⭐⭐
来源： arXiv:2606.01927 | Tsinghua / scitix 可信度： ⭐⭐⭐⭐⭐（清华 + 已有 vLLM 对比基准）
核心洞察： - 问题：Tensor Parallelism 扩展受 Amdahl's Law 限制，TP degree ↑ 时 cross-GPU 通信和 non-scalable runtime work 成为瓶颈 - 方案：Albireo 通过 overlap 调度 + I/O + compute + sequence-parallel sampling 压缩 non-scalable portion - 效果：Llama-2-13B: 4× throughput（t=1→t=4）；Qwen-2.5-32B: 2× throughput（vLLM vs Albireo @ H100N）
与 knowledge/engineering.md 现有脉络的关系： v32 §2.3（调度理论七层支柱）仅含 STAR MAE / Floor-First Triage 等调度相关工作，未收录 Albireo；Albireo 与 vLLM TP 扩展形成互补——后者帮助选择配置，Albireo 帮助榨取配置性能。
建议归入： §2.3 调度理论 + 新增 Albireo 条目作为 TP 扩展 alternative 路径
条目 4：Floor-First Triage for LLM Serving——H20 GPU 系统性 Profiling 方法论（arXiv:2607.05876） ⭐⭐⭐⭐⭐
来源： arXiv:2607.05876 | 2026-07 新发表 可信度： ⭐⭐⭐⭐⭐（工程分析 + 真实硬件数据）
核心洞察： - 问题：GPU 异构集群中，用户在选择 GPU 类型 / TP degree / 精度前无法预估实际成本 - 方案：Floor-First Triage——先建立理论性能下界（analytical floor），再用 benchmark 验证，profiling 仅在 residual 不符时触发 - 案例：DeepSeek-V3.2-style 671B MoE/MLA 模型在 16 × NVIDIA H20（TP16, batch=64, 8K context）→ KV-capacity-limited 至约 70 并发请求 - 关键数据：DSA-style sparse attention 移除 KV-bandwidth 项但不消除 capacity wall；EP16+DP-attention 布局将 capacity wall 从 ~70 提升至 ~644 请求
与 knowledge/engineering.md 现有脉络的关系： v32 §2.3 收录 Floor-First Triage（arXiv:2607.05876）在 v32 发布时尚未被收录——本次正式纳入；H20 因 FLOP/byte 比 H100 低得多（~74 vs ~590），decode-oriented 场景下需要专门优化；这是目前唯一对 H20 上 671B MoE 模型进行系统性 profiling 的公开分析。
建议归入： §2.3 调度理论 + §2.29（新增 H20 生产选型数据）
条目 5：Jailbreak——LLM 直接读数据库存储文件绕过引擎，27× 分析加速（arXiv:2607.07696） ⚠️安全边界 ⭐⭐⭐⭐⭐
来源： arXiv:2607.07696 | 提交：2026-07-08 | 会议：AIDB 2026（VLDB 联会） 可信度： ⭐⭐⭐⭐⭐（AIDB 2026 同行评审，MIT/Vrije University）
核心洞察： - 分析型负载通过 JDBC/ODBC 访问数据库存在根本瓶颈——驱动层不适合批量列式分析 - Jailbreak 通过 LLM 直接从数据库存储文件（PostgreSQL/MySQL）读取，绕过数据库引擎，生成内存列式缓冲区（Apache Arrow），可直接被 DuckDB/Spark/RAPIDS/cuDF 消费 - 端到端分析吞吐量提升最高 27 倍 - LLM 读取数据库文件格式规范（源码 + 文档），生成专用 table reader，无需手工解析逻辑
⚠️ 安全边界警示： LLM 直接读原始存储文件绕过访问控制——这是数据库安全模型的重大挑战，需纳入 v32 §2.14（AI Security）讨论。
与 knowledge/engineering.md 现有脉络的关系： v32 未收录该论文；这是 LLM + 数据库存储格式的交叉点创新，与 §2.29（推理引擎选型）属不同方向，建议归入数据库 + 安全交叉地带。
建议归入： §2.14（AI Security 边界问题）+ 数据库 Engineering 主题页；27× 数字需在 AIDB 同行评审后确认置信度
条目 6：Hugging Face 安全事件披露——July 2026（2026-07-16） ⭐⭐⭐⭐⭐
来源： Hugging Face 官方 Blog，https://huggingface.co/blog/security-incident-july-2026 可信度： ⭐⭐⭐⭐⭐（HF 官方安全公告）
工程行动建议（待官方完整报告确认前执行预防措施）： - 确认生产环境 HF Token / Model Hub 访问鉴权机制 - 核查 model weights 下载来源完整性校验（hash/checksum） - 评估是否需要内部 model cache 隔离方案
与 knowledge/engineering.md 现有脉络的关系： v32 §2.14（AI Security）未收录 HF 7 月安全事件——这是 HF 自身的安全事件披露，与 v32 §2.14 的 GRIEF 漏洞/CVE 话题属于同一条安全线索，需纳入追踪。
建议归入： §2.14（AI Security 新增 HF 安全事件追踪）
条目 7：vLLM vs SGLang 融合加速——共享 FlashInfer 内核 + API 统一 ⭐⭐⭐⭐⭐
来源： Turion.ai 工程博客，https://turion.ai/blog/vllm-sglang-convergence-inference-ecosystem-2026，2026-07 可信度： ⭐⭐⭐⭐（工程垂直博客，具体技术数据）
要点： 1. 内核层融合：两者现在共享 NVIDIA FlashInfer kernels，底层优化路径收敛 2. API 层统一：均暴露 OpenAI 兼容 API，部署差异变为配置 flag 而非架构决策 3. 生态里程碑：RadixArk（SGLang 分叉）获 $100M 种子轮；vLLM 周安装量突破 2M 4. SGLang vs vLLM 性能场景表：
| 场景 | 推荐 |
|---|---|
| H100 标准吞吐 | SGLang +29%（16,200 vs 12,500 tok/s） |
| DeepSeek V3 | SGLang 3.1× 更快 |
| Prefix-heavy RAG/多轮对话 | SGLang 最高 6.4× |
| 唯一 prompt 批处理 | 两者性能趋近 |
与 knowledge/engineering.md 现有脉络的关系： v32 §2.29（推理引擎选型 v3 收敛）已收录相关趋势；本次补充：vLLM 2M 周安装量（v32 中未出现该数字）确认生态规模霸主地位；API 统一后"同时运维两种引擎"的成本从架构决策降级为部署参数。
建议归入： §2.29（vLLM vs SGLang 融合趋势更新 + 选型决策表）
条目 8：IBM Research 模型路由三大工程陷阱——成本 ≠ 定价 / 复杂度 ≠ 难度 / 延迟 ≠ 速度 ⭐⭐⭐⭐⭐
来源： IBM Research via Hugging Face Blog，https://huggingface.co/blog/ibm-research/model-routing-is-simple-until-it-isnt，2026-07-15 可信度： ⭐⭐⭐⭐⭐（IBM Research 工程论文支撑）
要点（实测数据）： - 陷阱 1（成本 ≠ 定价）：Claude Sonnet $0.19/任务 vs GPT-4.1 $0.37/任务——Sonnet 因 cache-read 定价优势抵消 base 价格差，实际成本低 2 倍 - 陷阱 2（复杂度 ≠ 难度）："总结这份合同"可能触发 retrieval + 合规检查 + 工具调用 + 多轮精化；技术性 prompt 可能被小模型高效处理 - 陷阱 3（延迟 ≠ 速度）：路由本身有 overhead；基础设施因素（硬件、缓存预热状态、endpoint 繁忙度）往往主导端到端延迟 - IBM 解法：从分类问题转向 cost + quality + latency + compliance + reliability 五维优化问题
与 knowledge/engineering.md 现有脉络的关系： v32 §2.5（推理工程学科化）+ LangChain Fleet Agents 路由（Sonnet→GLM→Kimi 降本 3×）已收录路由降本趋势；IBM 三大陷阱是对 v32 路由话题的深度工程化补充，提供了可操作的生产失败模式和五维优化框架。
建议归入： §2.5（Inference Engineering 六层框架 Gergely Orosz 已收录；本次补充 IBM 路由三陷阱作为生产路由决策checklist）
条目 9：Pawan K Jha 27 实验并行性研究——完整可复现 vLLM Benchmark 体系 ⭐⭐⭐⭐⭐
来源： Pawan K Jha Substack，https://pawankjha.substack.com/p/architecting-llm-inference-part-6，2026-06-15 可信度： ⭐⭐⭐⭐⭐（实验驱动，含完整代码/vLLM 命令/benchmark 脚本 GitHub 仓库）
要点（27 个实验分 5 阶段）： - E01–E04（单 GPU 基准）：TTFT/TPOT/p95 latency/GPU memory/max useful concurrency 指标矩阵 - E05–E10（batching 优化）：continuous batching 对吞吐和尾延迟的影响 - E11–E13（vLLM serving 优化）：prefix caching / chunked prefill 实测数据 - E21–E23（replicas）：请求级并行如何扩展流量 - E31–E33（tensor parallelism）：模型分片对内存和通信开销的影响 - E41–E43（pipeline parallelism）：分层划分引入的 pipeline bubble - E51–E53（MoE）：expert 路由对 GPU 利用率和负载均衡的影响 - E61–E63（disaggregation）：prefill/decode 分离如何改变瓶颈
与 knowledge/engineering.md 现有脉络的关系： v32 未收录该实验体系；每个实验目的不是声称绝对 benchmark 数字，而是使某一种 scaling 行为可观测——与 §2.3（调度理论七层支柱）的方法论目标高度一致；建议 E11–E13（prefix caching / chunked prefill 实测数据）作为生产优化参考优先提取。
建议归入： §2.3（benchmark 方法论补充）+ §2.29（vLLM serving 优化数据）
条目 10：OmniPilot——GPU 集群 LLM Serving 成本预测 Advisor（arXiv:2607.01579） ⭐⭐⭐⭐
来源： arXiv:2607.01579 | Harvard Kempner Institute + 工程验证，2026-07-03 可信度： ⭐⭐⭐⭐（工程验证，conformal calibration 方法论）
核心洞察： - 问题：共享异构 GPU 集群上，用户难以选择 GPU 类型 / TP degree / 精度，预估实际 Serving 成本 - 方案：OmniPilot = conformally calibrated quantile cost model + OOD abstention layer - 覆盖范围：A100 / H100 / H200 × 4 种精度 × 8 种 serving targets - 精度：MAPE 6.2%，log-space R²=0.92 - Abstention：当请求超出 support envelope 时主动拒绝预测（coverage gap 0）
与 knowledge/engineering.md 现有脉络的关系： v32 §2.3（Floor-First Triage）已收录 H20 profiling；OmniPilot 与 Floor-First Triage 形成互补——前者建立理论下界，后者建立跨硬件成本预测模型，共同构成 2026 年 GPU 集群调度的完整工具链。
建议归入： §2.3（与 Floor-First Triage 并列作为调度工具链新增）
条目 11：xHC: Expanded Hyper-Connections——N>4 扩展 + xHC-Flash 40C（arXiv:2607.14530） ⭐⭐⭐⭐
来源： arXiv:2607.14530 | paper_cards/461，2026-07-15 可信度： ⭐⭐⭐⭐（paper_cards 已建卡，engineering 主分类）
核心洞察： - 首个在 N=4 之外实现有意义扩展的 HC 系列方法 - xHC-Flash 将 per-sublayer 内存访问从 73.5C 降至 40C（与 mHC N=4 的 34C 相当），同时保留完整 xHC 性能增益 - 与 mHC N=4 的 34C 相当，同时保留完整 xHC 性能增益
与 knowledge/engineering.md 现有脉络的关系： v32 §2.4（KV Sharing / mHC / Compressed Attention 架构演进）+ §2.56（Linear Attention 5 路线 arXiv:2607.07953）已收录 mHC；xHC 是 KV sharing 系列的最新进展，与 v32 §2.4 同脉络。
建议归入： §2.4（KV Sharing / mHC / Compressed Attention 架构演进更新）
条目 12：PyTorch Newsletter 7月——SGLang + DeepSeek-V4 on GB300 确认 5× throughput ⭐⭐⭐⭐
来源： PyTorch Foundation Newsletter，https://pytorch.org/newsletter/july-2026，2026-07-21 可信度： ⭐⭐⭐⭐⭐（PyTorch Foundation 官方）
要点（三项工程更新）：
1. PyTorch 2.13（526 贡献者，3328 commits）：Apple Silicon FlexAttention 稀疏模式加速最高 12×；CuTeDSL Native DSL backend；nn.LinearCrossEntropyLoss 使大词表语言模型训练峰值 GPU 内存降低最高 4×
2. SGLang + DeepSeek-V4 on GB300：Day-0 支持，持续改进包括 MHC fusion、token-bucket prewarm、KV Compression V2、W4A4 MegaMoE、SWB budgeting；PyTorch 原文确认：5× throughput 提升（同交互延迟下）
3. LMCache + Helion + vLLM 协同：Helion 内核的 LLM-Guided Autotuning（从分钟级压缩到秒级）
⚠️ 需核实说法： 5× throughput 具体对比基线（vLLM？SGLang 上一版本？TRT-LLM？）——避免在 knowledge/engineering.md 中直接引用该数字作为跨引擎对比数据
与 knowledge/engineering.md 现有脉络的关系： v32 §2.29（SGLang 16,215 vs vLLM 12,553 tok/s）+ §2.17（vLLM × Mooncake + SGLang RDMA）已收录 SGLang + GB300 趋势；PyTorch 官方确认 5× 提升是v32 已收录趋势的权威背书；LMCache 生态加速是新的工程信号。
建议归入： §2.29（SGLang + GB300 性能数据更新确认）+ §2.17（新增 MoE Serving 生态：LMCache + Helion）
⚠️ 值得警惕的矛盾或待核实说法
-
PyTorch Newsletter 中"SGLang + DeepSeek-V4 5× throughput"基线不明：5× 是对比基线不明（vLLM？SGLang 上一版本？TRT-LLM？）；建议对照 SGLang GitHub release notes 或官方 blog 确认。
-
Jailbreak arXiv:2607.07696 的 27× 数字：AIDB 2026 同行评审正在进行中，27× 加速数字需在正式发表后确认置信度；该论文的安全隐患（LLM 直接读存储文件绕过访问控制）需优先审稿。
-
Netflix 静默 Bug 的适用范围：
response_format静默丢弃是 Triton 前端问题还是 OpenAI 兼容 API 普遍现象？若是普遍现象，则所有通过代理层转发 OpenAI 请求的生产系统都可能受影响。建议核验 vLLM 官方文档中 guided decoding 参数的完整列表。 -
vLLM 2M 周安装量的时间节点：需核实该数字是 2026-07 某周的峰值还是历史累计，以判断是否值得作为 vLLM 生态规模的里程碑数据纳入。
📚 涉及 arXiv 号列表（本次新增/确认）
| arXiv | 来源 | 主题 | 建议归入节段 |
|---|---|---|---|
| 2606.01927 | 晨间简报 2026-07-22 | Albireo：超越 Amdahl 扩展极限（Llama-2-13B 4× / Qwen-2.5-32B 2×） | §2.3 调度理论 |
| 2607.05876 | 晨间简报 2026-07-22 | Floor-First Triage：H20 GPU 系统性 profiling（671B MoE / H20 TP16 capacity wall ~70→644） | §2.3 调度理论 |
| 2607.07696 | 跨域简报 2026-07-22 | Jailbreak：LLM 直接读数据库存储文件（27× 加速，⚠️安全边界） | §2.14 AI Security + 数据库 Engineering |
| 2607.01579 | 晨间简报 2026-07-22 | OmniPilot：GPU 成本预测 Advisor（MAPE 6.2%，A100/H100/H200 × 4 精度） | §2.3 调度理论 |
| 2607.14530 | paper_cards/461 | xHC: Expanded Hyper-Connections（N>4，xHC-Flash 40C） | §2.4 KV Sharing / mHC |
| 2607.13276 | 跨域简报 2026-07-22 | Aurora DSQL：多区域 active-active OLTP（Journal replication，AWS Marc Brooker） | 数据库 Engineering（非 LLM 主线，供参考） |
v32 §2.86 已收录的全部 15 个 arXiv 号本次无新增变更：
arXiv:2605.01280 / 2605.03275 / 2605.11202 / 2605.19537 / 2606.04594 / 2602.03786 / 2602.20478 / 2603.09619 / 2603.21354 / 2607.11149 / 2607.13705 / 2607.14541 / 2607.14777 / 2607.14952 / 2607.15257
✅ 本次简报增量评估
状态： 中高增量（12 条新信号）
| 类别 | 条目 | 评估 |
|---|---|---|
| 框架/里程碑 | 1 | PyTorch 2.13 今日发布（CuTe DSL + FlexAttention 12× + LinearCrossEntropyLoss 4×） |
| 大厂实战案例 | 2 | Netflix vLLM 选型逻辑 + response_format 静默丢弃 Bug + 版本对齐教训 |
| 性能边界突破 | 2 | Albireo（超越 Amdahl 4×）+ Floor-First Triage（H20 profiling） |
| 安全边界 | 2 | Jailbreak 27× 数据库 bypass + HF July 2026 安全事件披露 |
| 引擎融合 | 1 | vLLM/SGLang 共享 FlashInfer + API 统一 + vLLM 2M 周安装量 |
| 路由/调度 | 2 | IBM 模型路由三大陷阱 + OmniPilot GPU 成本预测 |
| Benchmark 方法论 | 1 | Pawan K Jha 27 实验并行性（完整可复现 vLLM benchmark 体系） |
| 架构演进 | 1 | xHC N>4 扩展（xHC-Flash 40C） |
与 v32 的 gap： v32 于 2026-07-20 09:43 发布，距今约 26 小时；本轮 inbox 增量主要来自今日 PyTorch 2.13 发布（重磅）、Netflix 案例（大厂完整实战）、Albireo/Floor-First Triage（性能边界）、Jailbreak（安全边界）、vLLM/SGLang 融合加速。本简报不重复 v32 已覆盖内容，聚焦 7-20 上午之后的新信号。
📂 检查过的来源（全部）
jay inbox 今日（2026-07-22，共 16 个文件）：
0820-morning-briefing-rag-optimization-agentic-ai-arxiv-csdn · 1000-rss-bytebytego · 1000-rss-raschka · 1001-rss-cool-papers · 1001-rss-nathan-benaich · 1001-rss-simon-willison · 1002-rss-cool-papers-ir · 1002-rss-lilian-weng · 1003-rss-import-ai · 1003-rss-msr-blog · 1004-rss-yt-karpathy · 1005-rss-yt-fireship · 1100-morning-inference-engineering-vllm-sglang-hf-blog-arxiv · 1105-cross-domains-db-backend-cloudnative-csdn-repro · llm-systems-inference-engineering（共 16 个）
jay inbox 昨日至晚间（2026-07-21，共 ~35 个）：
1000-inference-stack-netflix-pytorch-dbaas · csdn-inference-stack-vllm-sglang-substack · engineering-e1prep · hf-blog-model-routing-engineering-pitfalls · hf-blog-pytorch-attention-profiling · hf-blog-vllm-transformers-backend · jay-engineering-filter × 3 · 1105-afternoon-briefing · 1335-afternoon-briefing-hf-blog-github-trending-jul2026 · 1450-jay-engineering-filter · 1500-evening-briefing-cidr-dbhammer-raschka-agentic-rag-hf-ecosystem · 1735-evening-briefing-github-trending-substack-agent-stack-hf-blog-w11-papers · 1950-jay-engineering-filter · 2105-evening-briefing-hf-security-kimi-k3-vector-db-inference-stack · 2340-news-x-tech-radar · llm-rag-agent-weekly
tom inbox（2026-07-20~22，共 ~14 个）：
agent-rag-longcontext-radar（4 个版本） · hf-daily-2026-07-20 · 2× yt RSS · rag-e1prep · hf-daily-2026-07-21 · 2× yt RSS · rag-lite · hf-daily-2026-07-22 · 2× yt RSS
flyp inbox（2026-07-20~22，共 ~24 个）：
LoCoBench-Agent-longcontext-coding-agent-critical-read · SpecBench-Reward-Hacking-LongHorizon · xHC-Hyper-Connections-critical-read · Substack-Interconnects-6months-open-models · agent-evaluation-surveys · CVG-compositional-video-inference-time-guidance-critical-read · coding-agents-e1prep（7-20 + 7-21） · multimodal-e1prep × 2 · risk-e1prep × 2 · rss-cameron-wolfe × 3 · rss-interconnects × 3 · rss-yt-ai-explained × 3 · rss-yt-two-minute-papers × 3 · TimeLens2-ShotPlan-critical-read（7-22）
spark inbox（2026-07-20~22，共 ~7 个）：
rss-gradient-flow × 3 · rss-chip-huyen × 2 · rss-yt-3blue1brown × 3
stephen inbox（2026-07-20~22，共 ~23 个）：
news-x-vip-radar × 3 · news-anthropic-news × 3 · news-deepmind-news × 3 · news-google-ai × 3 · news-openai-news × 3 · news-hf-blog × 3 · news-tldr-ai × 3 · news-bens-bites × 3 · coordination-check × 2 · ai-industry-e1prep × 2 · llm-application-e1prep × 2
paper_cards（近 3 天新卡，卡号 481~515，全部检查）：
481（COLD EE 2026，法律检索） · 482（Cost-Aware Security Agents） · 483（Robot-Centric Pointmaps，VLA） · 484（SVR-R1，多模态推理） · 485（RAG Reranking Cross-Encoder） · 486（REBASE，In-Context Segmentation） · 487（Behavioral Privacy Leakage，Agentic Negotiation） · 488（HOMIE，视频多模态个性化，arXiv:2607.18217） · 489（SWE-Pruner Pro，代码 LLM 上下文剪枝，arXiv:2607.18213） · 490（Token-Level Off-Policy Learning） · 491（FlashRT，Agent Harness，arXiv:2607.18171） · 492（TimeLens2，视频时序定位） · 493（EvolvingWorld，Agent Role-Play） · 494（Distilled RL for LLM Post-training） · 495（ReflectWorld-MM，多模态记忆） · 496（Self-State Attacks on Self-Hosted AI Agents，arXiv:2607.17986，OS 安全） · 497（Vector Search as NN Matching，RAG） · 498（ShotPlan，视频生成规划） · 499（MLLM Understands OCT） · 500（Tool-Call Boundary Drift，arXiv:2607.07050） · 501（GigaChat Audio） · 502（GigaAM Multilingual） · 503（DeepSearch-World，arXiv:2607.07820） 工程主分类新增（2 条）： 489（SWE-Pruner Pro，agent/coding，engineering 副分类）+ 496（Self-State Attacks on Self-Hosted AI Agents，agent 主分类，engineering 副分类——已在条目 12 提及）
Jay · 2026-07-22 11:20 (Asia/Shanghai) · E1 engineering 预消化 · 增量 12 条 · arXiv 6 个（2606.01927 / 2607.05876 / 2607.07696 / 2607.01579 / 2607.14530 / 2607.13276）