📚 学术研究知识库草稿 · Jay · 2026-06-22 傍晚 18:30
主题： 向量数据库 2026 基准全览 · KVCache 工程前沿（PrefixWall / DroidSpeak / SAGA / BatchLLM）· Substack 高价值工程洞察 · Cloud-Native GPU 调度 检索范围： arXiv、Substack、Vecstore / Salt 基准、Modular Blog、Red Hat Developer、Spheron、GitHub NSDI 2026 去重说明： 今日已有 0935/1050/1105/1220/1335/1450 共 6 篇；本篇聚焦：①向量数据库 2026 横向基准（未单独成篇）②KVCache 安全/跨变体共享/调度新研究 ③Substack 新工程洞察 ④Cloud-Native GPU 编排，均未与上述重叠 Substack 来源： Substack 搜索规则（2026-06-10 启用）：必须记录作者、链接、发布时间、核心观点、可信度判断及后续行动；不复制原文长段内容
🏆 高价值条目（优先精读）
🔴 数据库 / 向量数据库（⭐⭐⭐⭐⭐）
1. 向量数据库 2026 基准全览（综合多家来源）
来源： Salt Technologies AI（Salt 基准 2026 Q1）、Vecstore.app、Digital Applied、Firecrawl
核心数据（1M 向量 / 1536 维，p50/p99 延迟）：
| 数据库 | p50 | p99 | 开源 | 托管起步 | 核心场景 |
|---|---|---|---|---|---|
| Qdrant | 4ms | 25ms | Apache 2.0 | $9/mo | 过滤搜索最快，OSS 首选 |
| Redis | 5ms | 20ms | RSAL/SSPL | $7/mo | 语义缓存 + 向量，70% LLM 成本节省 |
| Milvus | 6ms | 35ms | Apache 2.0 | $65/mo | 十亿级 + GPU 加速 |
| Pinecone | 8ms | 45ms | ❌ | $70/mo | 零运维 serverless |
| Weaviate | 12ms | 65ms | BSD-3 | $25/mo | 内置向量化 + hybrid search |
| pgvector | 18ms | 90ms | PostgreSQL 扩展 | 免费 | Postgres 团队 <10M 向量 |
| ChromaDB | 12ms | 70ms | Apache 2.0 | — | 原型 / 本地开发 |
| MongoDB Atlas | 22ms | 110ms | ❌ | $57/mo | 已有 MongoDB 团队 |
关键结论（2026-06 更新）： - pgvector + HNSW（0.5.0+）已不再是慢速方案：在 1M 规模匹配甚至超越专用向量库；pgvectorscale（Timescale）用 DiskANN + Statistical Binary Quantization 在 5000 万向量规模达到 471 QPS / 99% recall，是 Qdrant 的 11.4 倍 - hybrid search 是 2026 标配：BM25 + 向量 + RRF 融合；Qdrant 过滤性能最强，Weaviate 原生支持最好 - 选型决策树：先看数据平台承诺（Postgres → pgvector / GCP → Vertex / 已有 Mongo → MongoDB Atlas），再看规模（<10M → pgvector / 10-100M → Qdrant / >1B → Milvus 或 Vespa） - 数字引用来源： Salt Technologies AI benchmark（CC BY 4.0 开放），Vecstore 独立评测
工程价值： 高——生产选型决策依据，具体数字可引用 可信度： 高（多来源交叉验证，含 CSV/JSON 下载链接） 后续行动： 建议纳入向量数据库主题页「2026 选型决策树」
2. Redis 8 向量搜索 vs Pinecone（⭐⭐⭐⭐）
来源： Redis Blog — "Best Open Source Vector Databases 2026" 链接： https://redis.io/blog/top-pinecone-alternatives-for-vector-search 核心观点： - Redis 8 命令延迟降低 87%，启用量化后 QPS 提升 144% - Redis vs 纯向量库：3.4×更高吞吐；vs pgvector 类扩展：9.5×更高 QPS - 语义缓存（Semantic Caching）：LangCache 方案通过 Redis 缓存 LLM 响应，测试显示 LLM 成本降低 70%——这是 Pinecone 等纯向量库无法提供的差异化能力 - 统一平台优势：向量搜索与缓存/会话/消息共用同一平台，无网络开销
可信度： 中高（Redis 官方博客，但含具体基准数据） 工程价值： 高——语义缓存是 2026 新兴方向，70% LLM 成本节省数据值得关注 后续行动： 纳入 RAG 工程最佳实践，关注 LangCache 开源进展
🟠 后端 / 推理系统工程（⭐⭐⭐⭐⭐）
3. DroidSpeak：跨微调变体 KV Cache 共享（NSDI 2026）⭐⭐⭐⭐⭐
来源： USENIX NSDI 2026 — "DroidSpeak: KV Cache Sharing Across Fine-tuned Model Variants" 链接： https://www.aussieai.com/research/prefix-caching （引用来源：Yuhan Liu, Yihua Cheng, Shan Lu, Madan Musuvathi, Esha Choukse，May 2026）
核心观点： - 问题： 企业通常同时部署同一基模型的多个 LoRA/Adapter 微调变体（如代码助手 v1 / v2 / v3），各自独立维护 KV cache，无法跨变体共享 - 方案： DroidSpeak 在不同微调变体之间共享 prefix KV cache，辅以部分层级重计算（partial layerwise recomputation） - 意义： 允许多个 LoRA 变体复用同一 KV cache，前向传播只需为特定层重新计算，大幅减少多变体部署的显存占用 - 发布： USENIX NSDI 2026（5 月 4-6 日，Rent on, WA）
工程价值： 高——对多 LoRA 变体生产部署（企业级 Agent 平台）有直接收益 可信度： 极高（NSDI 2026 正式论文，有源码） 后续行动： 精读论文；追踪 GitHub 开源进展
4. BatchLLM：大批量任务全局前缀共享优化（arXiv:2412.03594v3）⭐⭐⭐⭐
来源： arXiv（原始提交 2024-12，持续更新至 2026-01-16 v3） 链接： https://arxiv.org/html/2412.03594v3 核心观点： - 问题： vLLM 默认 prefix caching 只在单实例内隐式工作；大批量任务（批量 RAG / 批量分类 / 多文档摘要）跨请求共享前缀效率低，vLLM 隐式 prefix caching 仅达到 35.8% 节约率 - 方案： BatchLLM 三层优化： 1. 全局前缀提取：跨批次识别所有请求的公共前缀，避免前缀被过早 evict 2. DP 前缀树算法：将第一层前缀节点合并，简化调度和注意力计算开销 3. 前缀组粒度调度：按前缀共享组调度请求，最大化前缀复用 + 缩短前缀 KV 内存生命周期 - 具体数据： 在 A100 上，vLLM 最新 prefix caching 优化后吞吐 6.57；BatchLLM 达到 8.67（同旧版 vLLM 基线）；批量 prefill token 节约率远超 vLLM 隐式方案 - 对比 vLLM APC： vLLM APC 节约率 35.8%，BatchLLM 在大数据量任务上显著更高
工程价值： 高——对批量 API 场景（RAG 管道批量查询 / 多租户 Agent 服务）直接可用 可信度： 高（arXiv 持续更新 v3，2026-01 对比了当时最新 vLLM） 后续行动： 建议加入「批量 LLM 推理优化」主题页；与上午工程过滤中 PASTE 对比
5. PrefixWall：自动前缀缓存的安全边界（arXiv:2603.10726v2）⭐⭐⭐⭐
来源： arXiv:2603.10726v2 链接： https://arxiv.org/html/2603.10726v2 核心观点： - 问题： Automatic Prefix Caching（APC）在多租户 LLM 服务系统中引入时序侧信道攻击：攻击者可通过测量 cache hit/miss 延迟差异（缓存命中 vs 未命中），推断其他用户敏感提示词前缀 - 长前缀 + 更大模型 + 低负载条件下，攻击更容易成功 - 现有防御缺陷： - 隔离方案（完全禁用跨用户缓存）：牺牲性能 - 混淆方案（注入随机延迟）：不解决根本问题，统一延迟并不能区分前缀内容 - 方案： PrefixWall——轻量级实用系统，在保留 prefix reuse 性能优势的同时选择性隔离可疑前缀，而非隔离整个用户 - 关键设计：基于前缀级别的隔离，而非用户级别
工程价值： 高——生产多租户 LLM 部署（API 服务 / Agent 平台）的安全必读 可信度： 高（arXiv 安全方向，有完整安全分析和实证验证） 后续行动： 建议加入 Agent 安全主题页；作为 OWASP MCP Top 10 补充
6. SAGA：AI Agent 推理的工作流原子调度（arXiv:2605.00528）⭐⭐⭐⭐
来源： arXiv:2605.00528 链接： https://arxiv.org/html/2605.00528 核心观点： - 问题： Agent 工作流产生高相关性的 burst 请求（共享系统提示词 / 工具定义 / 多轮对话历史），100:1 输入/输出 token 比，高前缀重叠；现有 LRU eviction 在对抗设置下退化到 O(n) 竞争比 - 方案： WA-LRU（Workflow-Aware LRU）——利用工作流结构信息指导 eviction 决策 - 理论保证：WA-LRU 达到 O(log n) 竞争比（LRU 为 O(n)） - 调度与 eviction 联合优化 - 配套发现： 生产 traces 揭示 100:1 输入/输出 token 比和 session 内高前缀重叠，是 Agent 工作负载与普通 LLM 请求的本质差异
工程价值： 高——生产 Agent 系统（尤其是高并发多工具 Agent）的 KV cache 管理 可信度： 高（arXiv，含理论分析 + 实证验证） 后续行动： 建议与上午过滤中的 PASTE 和 Continuum 一起纳入 Agent 推理优化主题页
7. Continuum v6：多轮 Agent KV Cache TTL 调度（arXiv:2511.02230v6）⭐⭐⭐⭐
来源： arXiv:2511.02230v6（2026-06 最新版本） 链接： https://arxiv.org/html/2511.02230v6 更新要点（相比早前版本）： - Turn-based Eviction 问题形式化：vLLM/SGLang 在工具调用结束后隐式 evict KV cache，导致 Agent 返回时需要完整 prefill 或从 DRAM 重载 - TTL 机制增强：Request Unpinning 策略优化，防止多轮场景下 follow-up 请求已到达但 scheduler 尚未调度时的 premature eviction - 与 PrefixWall 关系： Continuum 优化 KV cache 保留策略，PrefixWall 解决安全隔离；两者可互补
工程价值： 高——多轮 Agent 生产部署的核心挑战 可信度： 高（持续更新 v6，实验充分） 后续行动： 与 PrefixWall 对比研究，两者结合是 Agent 生产部署安全+效率完整方案
8. Fluid-Guided Online Scheduling（arXiv:2504.11320v3）⭐⭐⭐⭐
来源： arXiv:2504.11320v3 链接： https://arxiv.org/html/2504.11320v3 核心观点（与上午下午已覆盖内容关系说明）： - 本论文在上午/下午简报中均被引用为背景材料，但本次深度解析其核心机制： - 关键洞察：Eviction 形成恶性循环——被 evict 的请求重新进入 prefill，再次消耗显存，再次触发 eviction，导致级联失败（failed/aborted generations） - 数学框架：提出 α-protection / β-clearing 算法类，在 KV cache 内存约束下最小化 eviction cascades - 流体近似视角：将 LLM 推理调度问题建模为排队论中的流体控制问题，求解稳定运行点
工程价值： 中高——理论框架，但对理解生产级 eviction cascades 根本原因有价值 可信度： 高（arXiv，与 MSRA 合作） 后续行动： 建议加入 LLM 推理理论主题页，作为调度算法参考
9. Modular · The Five Eras of KVCache（⭐⭐⭐⭐⭐）
来源： Modular Blog，2026-06-22（今日最新！） 链接： https://www.modular.com/blog/the-five-eras-of-kvcache 核心观点（Five Eras 框架）： 1. Era 1 — 经典 LLM 推理：Prefill + Decode 两阶段，KVCache 作为存储过去注意力状态的内存优化 2. Era 2 — PagedAttention / vLLM：将 KVCache 分页管理，解决显存碎片化，vLLM 崛起 3. Era 3 — Prefix Caching / RadixAttention：跨请求共享公共前缀 KV cache（SGLang / vLLM APC） 4. Era 4 — Disaggregated Prefill/Decode：将 prefill 和 decode 分布到不同 GPU 集群，解决互相阻塞问题 5. Era 5 — 上下文压缩 / 选择性缓存：H200/Mixtale 等新硬件推动，KVCache 与压缩技术结合
工程价值： 高——以时间轴视角梳理 KVCache 演进，帮助理解当前技术栈的定位和历史脉络 可信度： 高（Modular 工程师博客，MAX 团队） 后续行动： 建议加入 KVCache 主题页作为概览图；与 TreeAI-Lab/Awesome-KV-Cache-Management 结合
🟡 Cloud-Native / Kubernetes GPU 编排（⭐⭐⭐⭐）
10. KubeCon EU 2026：NVIDIA DRA 捐赠 CNCF + KAI Scheduler（⭐⭐⭐⭐）
来源： Spheron Blog — "Kubernetes GPU Orchestration in 2026: DRA, KAI Scheduler, and More" 链接： https://www.spheron.network/blog/kubernetes-gpu-orchestration-2026 核心事件： KubeCon Europe 2026 上，NVIDIA 将其 Dynamic Resource Allocation（DRA）驱动捐赠给 CNCF——这是 Kubernetes GPU 调度领域的重大里程碑
关键内容： - DRA（Dynamic Resource Allocation）：取代 decade-old NVIDIA device plugin，成为 Kubernetes GPU 调度的新标准 API - KAI Scheduler（Kubernetes AI Scheduler）：拓扑感知 GPU 调度，配合 DRA 实现精细化资源分配 - Grove：DRA 的配套项目，提供生产级 GPU 资源视图 - Spot H100 定价（2026-04-15）：$1.03/hr vs on-demand $2.50/hr，节省约 59%；Spot B200 $2.12/hr - DRA+Grove 适用场景：裸金属 GPU 节点（无虚拟化层），可看到完整硬件拓扑
可信度： 高（KubeCon 官方事件 + 具体定价数据） 工程价值： 高——Kubernetes AI 基础设施选型的关键信号 后续行动： 建议加入云原生 AI 主题页，作为 2026 中期 Kubernetes GPU 调度事实标准
11. Kubernetes AI 基础设施 2026 生产指南（⭐⭐⭐⭐）
来源： CloudOptimo Blog — "Kubernetes AI Infrastructure in 2026: GPU Scheduling & Production Realities" 链接： https://www.cloudoptimo.com/blog/kubernetes-ai-infrastructure-in-2026-gpu-scheduling-and-production-realities 核心观点： - Kubernetes 已成 AI 基础设施事实标准：2026 年已不再讨论"要不要用 K8s"，而是"如何优化" - 多租户隔离基线配置： - Namespace 级别 ResourceQuota + 每团队 GPU 限制 - 两层 PriorityClass（生产推理 vs 研发） - GPU 节点 taints 阻止纯 CPU 工作负载占用加速器 - Kueue borrowing policies：未使用配额可临时借给其他团队，不永久移除原分配 - Karmada / Liqo：多集群工作负载联合（适合地理分布式 GPU 容量），但生产训练采用仍有限 - HPC 与 K8s 融合趋势：拓扑感知放置、gang scheduling、紧网络fabric集成正在进入生产 K8s
可信度： 高（工程博客，具体配置示例） 工程价值： 高——多租户 GPU 集群设计指南 后续行动： 纳入 Kubernetes AI 主题页多租户设计部分
🟢 Substack 高价值工程洞察（⭐⭐⭐⭐）
12. FUNDA AI · Deep LLM 2026（⭐⭐⭐⭐）
来源： Substack — FUNDA AI 链接： https://fundaai.substack.com/p/deepllm-2026-from-the-illusion-of 发布时间： 2026（具体日期见原文） 核心洞察（不复制原文，仅摘要）： - 第三个拐点不是模型能力突破，而是系统经济学转变：从「can think」到「can do」，从模型能力到规模化生产力 - 约束从 per-inference FLOPS 转向系统级能力：并发会话管理、长生命周期 KV cache、多轮推理上下文积累、工具调用外部状态管理 - AWS GPU 定价信号：2026-01 AWS 将 p5e.48xlarge（8×H200）从 $34.61/hr 涨至 $39.80/hr（+15%），挑战「云定价长期下行」共识 - 2026 真实趋势：不是泡沫破裂，而是从模型投机阶段转向 Agent 驱动的真实系统级需求；推理时间轴更长、使用强度更高、基础设施需求更结构化 - FUNDA 结论：2025 不是停滞，而是范式转换；2026 是 AI 从「能思考」到「能执行」的关键年份
可信度： 中高（研究型 Substack，有具体定价数据支持论点） 工程意义： 高——帮助理解 2026 AI 基础设施成本趋势和投资逻辑 后续行动： 建议加入 AI 行业趋势主题页
13. Pragmatic Engineer · 什么是推理工程（⭐⭐⭐⭐）
来源： Substack — The Pragmatic Engineer（Gergely Orosz） 链接： https://open.substack.com/pub/pragmaticengineer/p/what-is-inference-engineering 核心洞察： - 推理工程定义：将 LLM 部署到生产环境所需的系统工程技能总和（区别于模型训练/研究） - 闭源 vs 开源模型对推理工程的影响： - 闭源模型：推理工程由模型构建方（AI 工程师）完成，全球可能仅数千人 - 开源模型：更多团队需要自己推理工程（性能调优、部署、监控）——这推动了 2026 年推理工程职位需求的增长 - Cursor 案例：Cursor 在 Kimi 2.5 基础上构建 Composer 2.0，通过推理工程优化使其超越原版 - 核心挑战：延迟、吞吐量、成本、可观测性、eval、guardrails——这些是推理工程师日常面对的真实问题
可信度： 高（Pragmatic Engineer 是知名工程垂直媒体，内容严谨） 工程意义： 高——推理工程师角色定位清晰，适合作为知识库「AI 工程角色图谱」参考 后续行动： 纳入 AI 工程职业/技能主题页
14. The Neural Maze · AI Systems Engineer Journey（⭐⭐⭐⭐）
来源： Substack — The Neural Maze 链接： https://theneuralmaze.substack.com/p/welcome-to-the-ai-systems-engineer 核心洞察（工程框架视角）： - 所有 AI 系统都可以映射到同一个 chassis： - Feature Pipeline（数据/文档摄入 → Parser → Chunker → Embed → 写入向量 DB + 关键词索引） - Training Pipeline（Prompt 工程 + 微调 + Prompt registry 版本管理） - Inference Pipeline（Query → 重写 → Hybrid retrieve → Re-rank → Prompt build → Generate → Guardrails → Citation validation） - RAG 的真实挑战：Demo 容易，生产难——分块策略、检索质量、混合搜索、查询重写、重排序、幻觉检测、引用强制、eval 体系、延迟、成本、知识库新鲜度 - Naive RAG 是"hello world"，真正的 RAG 系统需要 survives contact with users
可信度： 中高（工程教程型内容，IEEE-CAI 2026 tutorial 背景） 工程意义： 高——RAG 工程化全景图，适合作为学习路径参考 后续行动： 纳入 RAG 主题页「工程化全景」部分
15. llm-d · KV-Cache 精确调度（Red Hat AI Blog，2026-06-11）⭐⭐⭐⭐
来源： Red Hat Developer — "Intelligent inference scheduling with llm-d on Red Hat AI" 链接： https://developers.redhat.com/articles/2026/06/11/intelligent-inference-scheduling-llm-d-red-hat-ai 核心观点： - 问题：传统 round-robin 负载均衡将 LLM 推理视为无状态流量，忽略 KV cache 亲和性，导致 prefix caching 在多副本部署中失效 - llm-d EPP（Exact Prefix Placement）：精确前缀放置路由，将每个请求路由到已缓存相关前缀的 pod，使 vLLM prefix caching 真正生效 - Filter → Score → Pick 三阶段： - Filter：剔除无法服务的 pod（不健康/OOM/模型不符） - Score：根据各 pod 的请求前缀缓存命中量评分 - Pick：选最高分 pod；平分时随机打破 - Red Hat 测试结果（8 pods / 16 H100，prefix-cache-aware vs round-robin）：TTFT 提升 57×，吞吐量提升 2×
可信度： 高（Red Hat 官方开发者博客，含具体基准数据） 工程意义： 高——分布式 LLM 推理的 prefix cache 路由问题完整方案；适合与上午 SGLang/vLLM 对比一起纳入推理系统工程主题页 后续行动： 建议加入「llm-d vs SGLang RadixAttention vs vLLM APC」对比表
🔵 Benchmark 精选（⭐⭐⭐⭐）
16. vLLM vs TensorRT-LLM vs SGLang H100 基准（2026）⭐⭐⭐⭐
来源： Spheron Blog — "vLLM vs TensorRT-LLM vs SGLang: H100 Benchmarks (2026)" 链接： https://www.spheron.network/blog/vllm-vs-tensorrt-llm-vs-sglang-benchmarks 测试环境： H100 80GB / Llama 3.3 70B / FP8
| 引擎 | 最佳场景 | 吞吐（50 req） | TTFT p50（10 req） | 冷启动 |
|---|---|---|---|---|
| vLLM | 通用 / 宽模型支持 | 1,850 tok/s | 120ms | ~62s |
| TensorRT-LLM | 最大吞吐 / 固定模型 | 2,100 tok/s | 105ms | ~28min |
| SGLang | 共享前缀 / 低延迟 | 1,920 tok/s | 112ms | ~58s |
选型建议： - 从 vLLM 开始：覆盖最广、文档最完善、无需编译 - 换 TensorRT-LLM：模型固定不变 + 需要压榨每 token/秒 - 换 SGLang：共享前缀工作负载（聊天机器人 / RAG / 多轮对话），测 TTFT 发现有实质改善
可信度： 中高（Spheron 独立基准，具体硬件配置） 后续行动： 纳入 SGLang vs vLLM 选型主题页
📂 分类标签
#VectorDB #Qdrant #pgvector #Pinecone #Milvus #Redis #HybridSearch
#KVCache #PrefixCaching #PrefixWall #DroidSpeak #BatchLLM #SAGA
#Continuum #FluidScheduling #DRA #KubeCon2026 #KAI #Kubernetes
#LLMInference #vLLM #SGLang #TensorRT-LLM #llm-d #NSDI2026
#Substack #FUNDA-AI #PragmaticEngineer #InferenceEngineering
#AgentSecurity #SideChannel #MultiAgent #NeurIPS2025 #MLSys2026
📋 建议写入路径
| 条目 | 路径 | 操作 |
|---|---|---|
| 向量数据库 2026 基准全览 | /shared/research-kb/inbox/jay/2026-06-22-vecdb-benchmark-2026.md |
新建，精读 |
| DroidSpeak NSDI 2026 | /shared/research-kb/inbox/jay/2026-06-22-droidspeak-nsdi2026.md |
新建，审稿 |
| BatchLLM 全局前缀共享 | /shared/research-kb/inbox/jay/2026-06-22-batchllm-prefix-sharing.md |
新建，精读 |
| PrefixWall 安全分析 | /shared/research-kb/inbox/jay/2026-06-22-prefixwall-security.md |
新建，审稿 |
| SAGA workflow-atomic scheduling | /shared/research-kb/inbox/jay/2026-06-22-saga-workflow-scheduling.md |
新建 |
| Modular Five Eras of KVCache | /shared/research-kb/inbox/jay/2026-06-22-five-eras-kvcache.md |
新建，加入 KVCache 主题页 |
| KubeCon EU 2026 DRA + KAI | /shared/research-kb/inbox/jay/2026-06-22-kubecon-eu-dra-kai.md |
新建，加入 Kubernetes AI 主题页 |
| llm-d Red Hat prefix scheduling | /shared/research-kb/inbox/jay/2026-06-22-llm-d-prefix-scheduling.md |
新建，加入推理系统工程 |
| FUNDA AI Deep LLM 2026 | /shared/research-kb/inbox/jay/2026-06-22-funda-llm-2026-substack.md |
新建，加入行业趋势 |
| Pragmatic Engineer Inference Engineering | /shared/research-kb/inbox/jay/2026-06-22-pragmatic-inference-engineering.md |
新建，加入角色图谱 |
| vLLM/TensorRT/SGLang H100 基准 | /shared/research-kb/inbox/jay/2026-06-22-h100-benchmark-2026.md |
新建，加入选型参考 |
🔍 本次 Substack 来源记录
| 作者/机构 | 专栏 | 可信度 | 主题 |
|---|---|---|---|
| FUNDA AI | fundaai.substack.com | ⭐⭐⭐⭐ 中高 | Deep LLM 2026 系统经济学 |
| Gergely Orosz | pragmaticengineer.substack.com | ⭐⭐⭐⭐⭐ 高 | 推理工程定义与职位需求 |
| The Neural Maze | theneuralmaze.substack.com | ⭐⭐⭐⭐ 中高 | AI Systems Engineer 全景图 |
| Philip Kiely | inference engineering blog (substack) | ⭐⭐⭐⭐ 中 | 推理工程实战书籍 |
| Shirin Khosravi Jam | jamwithai.substack.com | ⭐⭐⭐ 中 | LLM 推理延迟 10 大技巧 |
✅ 后续行动
- 精读优先级：DroidSpeak（NSDI 2026）> PrefixWall > BatchLLM > SAGA
- 审稿优先级：Modular Five Eras of KVCache（今日最新）> llm-d Red Hat blog
- 主题页更新建议：
-
topic-kv-cache-management.md— 新增 Five Eras 概览图 + PrefixWall 安全边界 -topic-vecdb-2026.md— 新建向量数据库选型决策树（含 2026 基准数据） -topic-cloudnative-ai.md— 新增 KubeCon EU 2026 DRA/KAI 最新动态 -topic-agent-security.md— 新增 PrefixWall 作为 APC 侧信道防御方案 -topic-agent-production-engineering.md— 新增 SAGA/Continuum 多轮 Agent 调度
草稿整理：Jay · 2026-06-22 傍晚 · 共收录 16 个条目 · arXiv 占 7 个 · Substack 占 4 个 · 博客/基准占 5 个 · 新增向量数据库 2026 基准专题 · DroidSpeak NSDI 2026 首发 · PrefixWall 安全必读 · llm-d Red Hat 生产数据