五分类知识库简报 · Jay · 2026-09-28 晚间版
执行体:Jay · 每日第 3 次轮次 · 2026-09-28 21:00 CST
本次窗口:2026-09-28 19:50 ~ 2026-09-28 21:00（约 70 分钟增量窗口）
分类:database · backend · cloud-native · csdn · reproduction
底本:本轮 Tavily 多源检索 + 今日各 Agent 已产出草稿去重后综合
📌 本次核心发现
- backend：推理引擎三足鼎立格局稳定（vLLM vs SGLang vs LMDeploy）；FP8+连续批处理+投机解码组合可带来 5-8 倍成本效益；vLLM 仍是生产安全选择，SGLang 在 prefix-reuse 场景有 29% 吞吐量优势
- database：向量数据库 2026 年选型格局趋于稳定——pgvector 适合 <50M 向量 PostgreSQL 团队；Qdrant 自托管性能+过滤最优；Milvus 亿级分布式；Chroma 仅限本地原型
- cloud-native：KServe + llm-d 组合成为 Kubernetes 原生 LLM serving 标准路径；Crusoe 案例达到 6,000 tokens/s；llm-d 已升格 CNCF Sandbox
- reproduction：arXiv 新增两条高质量 KV Cache 系统论文——SSV（稀疏投机验证，arXiv:2605.19893）和 VeriCache（将 lossy KV Cache 转为无损，arXiv:2605.17613）
- Substack：Ken Huang 的"Frontier LLM Inference 2026"十章系列值得关注；Pragmatic Engineer 的 inference engineering 深度分析；SoK: Agentic RAG（arXiv:2603.07379）已发表
一、database（含 KV Cache 基础设施）
条目 D1｜向量数据库 2026 选型决策框架（综合多源）
来源:iternal.ai / aiml.qa / groovyweb.co / firecrawl.dev / encore.dev
可信度:高 · 多源横向对比，生产决策导向
发布时间:2026 年（多篇 9 月更新）
核心结论（决策矩阵）:
| 场景 | 推荐方案 | 理由 |
|---|---|---|
| PostgreSQL 已有团队，<5000 万向量 | pgvector + pgvectorscale | 无新运维，延迟 4-12ms p95 |
| 新项目 <1000 万向量 | Qdrant Cloud（最佳免费层）或 ChromaDB（原型） | Qdrant 性能最优；Chroma 零运维 |
| 新项目 1000 万~1 亿向量 | Pinecone（易用）/ Weaviate（混合搜索）/ Milvus（成本最优自托管） | 各有取舍，需按团队能力选 |
| >1 亿向量或需 GPU 加速 | Milvus/Zilliz Cloud 或 Pinecone serverless | 亿级分布式场景 |
| 边缘/本地/嵌入式 | LanceDB | 多模态友好，持久化简单 |
| 需要语义缓存 + 结构化数据 | Redis（Vector + 缓存一体化） | 唯一同时覆盖两者的方案 |
关键工程判断:
- Chroma 水平扩展和 payload index 缺失（无法做 where 过滤，需全表扫描），生产慎用
- Qdrant 1.17（2026-07 更新）在过滤和量化上有显著改进
- Redis Vector vs 专用 VecDB 的边界：若已有 Redis 用它；新起步直接用专用向量库
建议写入路径:organized/knowledge/vector-db.md 选型章节补充
行动:已有多篇，今日数据库 e1prep 已有覆盖；本次补充选型矩阵
条目 D2｜VeriCache — 将 Lossy KV Cache 转为无损推断（arXiv:2605.17613）
来源:arXiv
可信度:高 · 系统论文，技术方案完整
发布时间:2026-09
核心要点: - 问题:现有 KV Cache 压缩方法（KVzip/KVZap/ExpectedAttention/SnapKV + KIVI/KVQuant/RotateKV）均为有损压缩，在某些输入上会损害模型质量 - 方案:VeriCache 核心思路——用压缩后的 KV Cache 做 draft 解码，然后对完整 KV Cache 做 verify；在 decode 阶段将压缩 KV 解码与完整 KV swap 并行化（二者带宽特性不同：压缩 KV 解码受 HBM 带宽限制，完整 KV swap 受 PCIe/网络带宽限制，可并行） - 效果:在长 context 场景（>128K）质量损失被消除，同时保持了压缩的内存收益 - 系统挑战:将完整 KV Cache 保留在 GPU 外部（避免撑爆显存），同时最小化 swap 开销
评价:将 KV Cache 压缩和 speculative decoding 两个正交方向结合的思路新颖；属于"KV Cache 作为基础设施"大方向的最新工作；与 LMCache / llm-d 路线图直接相关
建议写入路径:organized/papers/kv-cache.md 新增条目
行动:精读原文，补充方法细节
二、backend（LLM 推理引擎与系统）
条目 B1｜vLLM vs SGLang vs LMDeploy — 2026 推理引擎Benchmark 决策框架
来源:PremAI / Spheron / JarvisLabs / AIMultiple / DeployBase
可信度:高 · 多源实测数据可交叉验证
数据新鲜度:2026 年 9 月（September 27 更新）
Benchmark 核心数据（H100 80GB，Llama 3.1 8B / Llama 3.3 70B）:
| 引擎 | 吞吐量（共享前缀） | 冷启动 | 适用场景 |
|---|---|---|---|
| vLLM | ~12,500 tok/s | ~62s | 通用首选，广谱模型，成熟生态 |
| SGLang | ~16,200 tok/s（+29%） | ~58s | Multi-turn，prefix-reuse，结构化输出 |
| LMDeploy | ~16,200 tok/s（与 SGLang 持平） | — | MoE/特殊架构，中国生态 |
| TensorRT-LLM | ~2,100 tok/s（峰值） | ~28min | 延迟敏感，已知 workload |
关键技术差异: - SGLang RadixAttention vs vLLM PagedAttention：RadixAttention 维护一棵共享 token 前缀树，在 multi-turn 对话中自动复用 KV Cache，命中率达 75-95%（SGLang 优势明显） - Prefix overlap ratio 是关键指标：>60% 共享前缀的工作负载选 SGLang；否则差异在噪声范围内 - 连续批处理（Continuous Batching）：三者均支持，是吞吐量的核心保障
生产工程建议（已由今日 engineering-filter 确认）:
先用 vLLM 快速上线
↓ 按真实流量跑 SGLang 对比
↓ 若 prefix-reuse ratio > 60% → 切换 SGLang
↓ 若有 MoE / 特殊架构 → 评估 LMDeploy
优化组合（成本效益 5-8x）:FP8 量化 + Flash Attention-3 + 连续批处理 + 投机解码 ≈ $125-200/天（替代 $1,000/天未优化版本）
建议写入路径:organized/knowledge/inference-engines.md 补充 2026 Benchmark 数据
行动:已有大量覆盖；本次补充量化数据表
条目 B2｜推理工程成为独立工程学科（Pragmatic Engineer Substack）
来源:open.substack.com / pragmaticengineer / Gergely Orosz
可信度:高 · 顶级工程 newsletter，业界认可度高
发布时间:2026 年
核心观点: - 推理工程（Inference Engineering）从 2024 年的"AI 工程师专属技能"扩展为 2026 年独立工程学科 - 核心技能栈：prefill vs decode 分离 / KV Cache / 连续批处理 / PagedAttention / 量化 / 投机解码 / 分布式推理 / TTFT/TPOT/P99 指标 - 闭环 vs 开环推理：闭环需要 agentic loop 持续调用 LLM；开环是单次请求；二者对延迟和吞吐量的取舍不同 - 平台规模化三阶段：单实例优化 → 多实例路由 → 全球多区域部署（数据主权 + 99.95% SLO） - 闭源模型（OpenAI 等）的推理工程由模型方完成；开源模型（Kimi 2.5 等）的推理工程由使用方完成——这是 AI 公司最稀缺工程岗位
评价:这篇是进入 inference engineering 的系统化指南；适合作为知识库"inference 工程入门"参考
建议写入路径:organized/knowledge/inference-engineering.md 新增入门框架
行动:引用存档
条目 B3｜SoK: Agentic RAG — 系统化知识论文（arXiv:2603.07379）
来源:arXiv（Semantic Scholar 收录）
可信度:高 · ACL 2026 体系化论文
发布时间:2026-03（持续更新）
核心要点: - Agentic RAG 将 RAG pipeline 嵌入 LLM Agent，使其决定何时检索、检索什么、是否答案足够好 - 相比经典 RAG 单次 retrieve-then-generate，Agentic RAG 可多次调用检索、在 hops 间重写查询、切换工具（向量搜索/BM25/网络搜索/SQL）、检查忠实度 - 代价：更多 Token 消耗 + 更多延迟 - 核心发现：Agentic 增强并非在所有场景都有收益；需根据查询类型和领域特点选择性应用 - 评估方法论：Output-level 指标（答案正确性、检索准确率）不足以评估 Agentic RAG；需要过程感知评估（reasoning trajectories、planning depth、adaptability、对噪声检索的鲁棒性、成本效率）
技术栈现状:LangGraph + OpenAI Agents SDK 主导有状态 Agentic RAG；LlamaIndex AgentWorkflow 强在 retrieval-first 模式；CrewAI 适合 role-based 多 Agent 检索
建议写入路径:organized/papers/agentic-rag.md 新增 SoK 条目
行动:精读，补充 taxonomy 细节
三、cloud-native（K8s + AI 基础设施）
条目 C1｜KServe + llm-d — 云原生 LLM 推理最优路径（Crusoe / KServe 官方博客）
来源:Crusoe AI 博客（2026-09-03）/ KServe 官方博客 / Red Hat Developer
可信度:高 · CNCF 项目官方 + 云厂商案例
发布时间:2026 年 9 月
KServe + llm-d 组合核心价值: - KServe = Kubernetes 模型服务控制面（生命周期 / 扩缩容 / 运营治理）；提供 LLMInferenceService CRD（v0.16+）；将多 GPU LLM 部署的复杂度压缩为单一声明式 CRD - llm-d = 推理运行时（ disaggregated prefill/decode / KV cache-aware 路由 / chunked prefill） - 实测案例（Crusoe on Managed Kubernetes）:Qwen2.5-72B 部署达到 6,000 tokens/s 吞吐量；4 种负载配置对比
LLMInferenceService 安装组合:
| 组合 | 用途 | 组件 |
|---|---|---|
| KServe Only | 预测性 AI | kserve |
| KServe + LLMInferenceService | 预测性 + 生成性 AI | kserve + llmisvc |
| Full Stack | + 模型缓存 | kserve + llmisvc + localmodel |
平台工程需求（KServe 解决的）: - 大流量 LLM 请求管理 - 推理性能优化 - 可预测延迟 - 基础设施成本控制 - GPU 利用率优化 - 智能请求路由 - 成本感知扩缩容
NVIDIA NIM + KServe:NIM 提供容器化推理runtime（支持 LLM 和 VLM）；通过 Helm 和 Kubernetes 声明式部署；支持 LoRA adapter 热加载
与 llm-d CNCF Sandbox 的关系:llm-d 于 2026 年升格 Sandbox，KServe v0.16 将 llm-d 深度集成，形成"K8s 原生生態"
建议写入路径:organized/knowledge/cloud-native-ai.md 补充 KServe + llm-d 章节
行动:已有 llm-d 覆盖；补充 KServe + llm-d 集成架构图
条目 C2｜State of Open Models: Summer 2026（Hugging Face 官方博客）
来源:Hugging Face Blog（Adina Yakefu 等）
可信度:极高 · HF 官方年度报告
发布时间:2026 年夏
核心观点（5 大洞察）: 1. 注意力 ≠ 采用率：最强模型不等于最多使用量 2. 开源权重改变价值积累位置：价值从模型本身转向数据 / 微调 / 推理基础设施 3. Qwen 成为社区 base model：2026 年最流行的微调基座 4. 小模型仍是实用层：Llama.cpp 在消费级硬件上运行万亿参数模型 5. Agent 是新用户：模型 API 消费者从人类变为 AI Agent（模型间调用）
Llama.cpp 重要更新:2026 年 2 月 ggml 团队加入 Hugging Face，项目保持开源社区治理；HF Hub 上的 llama.cpp 支持成为本地推理事实标准
建议写入路径:organized/knowledge/open-source-llm-landscape.md 补充 2026 夏 观察
行动:引用存档，补充 Qwen 社区地位数据
四、csdn（中文高价值内容）
注：CSDN 筛选严格标准：必须有版本/环境/命令/源码分析/复现过程/真实排障经验的高价值文章。本次未发现符合严格标准的新条目（今日 engineering-filter 已处理大部分 CSDN 推理框架对比内容）。本次 CSDN 条目贡献为空，详见下方说明。
条目 CSDN 本次无新增
原因:今日已有 Jay engineering-filter 和 five-category briefing 覆盖： - 2026-09-28T1950 条目 12/13/14 = CSDN SGLang vs vLLM 2026 横评（已在 engineering-filter 中评估） - 2026-09-28-ai-engineering-rag-agents.md 中"构建可靠 LLM Agent"已有中文工程实践覆盖
说明:CSDN 本次候选来源（SGLang + vLLM 生产对比、2026 年 LLM 推理框架全解析）均属框架介绍类，缺少实测数据/源码分析，不符合 CSDN 高价值文章标准（需要版本+命令+源码+复现经验）。
行动:如需追踪 CSDN 高价值内容，建议关注具备以下特征的文章：
- 含 nvidia-smi / torchrun / vllm serve 等实际命令输出
- 含 benchmark 数据表（含模型版本/GPU 型号/量化方法）
- 含源码走读（而非框架介绍）
五、reproduction（可复现的 arXiv / 论文 / 源码）
条目 R1｜SSV: Sparse Speculative Verification（arXiv:2605.19893）
来源:arXiv
可信度:高 · 系统论文
发布时间:2026-05
核心方法: - 问题:投机解码（speculative decoding）和动态稀疏注意力（dynamic sparse attention）均是加速长 context LLM 推断的正交方法，但直接组合存在结构冲突——投机验证依赖跨查询共性，而动态稀疏注意力分配查询特定稀疏布局，导致 KV block 重用受限 - 方案:SSV 在验证阶段使用稀疏注意力，只对动态选中的相关 KV blocks 做验证；减少 KV-cache 访问量同时保持投机解码的并行优势 - 相关工作:Gupta et al. 2021 / Yuan et al. 2025 / Liu et al. 2025 / Gao et al. 2026（blockwise sparsity）
评价:属于推理系统层面的工程优化论文；适合有 speculative decoding 实际部署经验的团队参考
建议写入路径:organized/papers/speculative-decoding.md 补充 SSV 条目
行动:归档，待有 speculative decoding 落地需求时精读
条目 R2｜KV Cache 优化策略系统综述（arXiv:2603.20397）
来源:arXiv
可信度:高 · 系统综述
发布时间:2026-03
五大方向分类: 1. Cache Eviction（缓存淘汰）：H2O / Scissorhands / StreamingLLM 2. Cache Compression（缓存压缩）：KVzip / KVZap / ExpectedAttention / SnapKV / KIVI / KVQuant / RotateKV 3. Hybrid Memory Solutions（混合存储）：GPU HBM + CPU DRAM + NVMe 分层 4. Novel Attention Mechanisms（新注意力机制）：FlashAttention 系列 / Linear Attention 5. Combination Strategies（组合策略）：INF2（SSD 存 KV）/ CXL-SpecKV（FPGA）/ LMCache
核心指标:内存减少 / 吞吐量 / 模型精度 三维权衡
评价:目前最完整的 KV Cache 优化技术分类综述；适合作为知识库"KV Cache 系统全景"的锚定论文
建议写入路径:organized/papers/kv-cache.md 锚定论文
行动:引用，补充五大方向分支
条目 R3｜An Internet for the KV Cache（arXiv:2608.01526）
来源:arXiv
可信度:高 · 系统架构论文
发布时间:2026-08
核心观点: - 将 KV Cache 视为可复用的分布式基础设施（类比 CDN），而非每次请求重新计算的临时状态 - KVDirect（2025）：GPU-RDMA + pull-based 传输 - LMCache（2025）：跨 GPU/CPU/存储/网络分层流水线 - TraCT（2025）：GPU-CXL DMA 直连共享内存 - CXL-SpecKV（2026）：CXL FPGA memory + 投机解码 - CacheBlend（2025）：选择性重计算缓存块而非全量重算 - Cache-Craft（2025）：修复可复用 RAG chunk 缓存 - EPIC（2025）：位置无关模块化缓存复用 - KVEraser（2026）：从 KV Cache 高效删除局部信息
范式转变:temporary state → persistent AI-native knowledge
建议写入路径:organized/papers/kv-cache.md 补充架构层条目
行动:已有 KV Cache 基础设施覆盖；本次补充系统架构视角
📋 汇总与后续行动
| 类别 | 高价值条目 | 建议行动 |
|---|---|---|
| database | D1 选型矩阵 / D2 VeriCache | D2 精读原文；选型矩阵入库 |
| backend | B1 Benchmark 框架 / B2 Inference Eng / B3 Agentic RAG SoK | B2/B3 引用存档；Benchmark 数据入库 |
| cloud-native | C1 KServe+llm-d / C2 HF State of Open Models | C1 补充集成架构；C2 引用存档 |
| csdn | 本次无新增高价值条目 | — |
| reproduction | R1 SSV / R2 KV Cache 综述 / R3 KV Cache Internet | R2 作为锚定论文；R1/R3 归档 |
本轮写入路径:
- /shared/research-kb/inbox/jay/2026-09-28T2100-jay-evening-five-category-briefing.md（本文）
待精读清单: 1. VeriCache 原文（arXiv:2605.17613） 2. SoK: Agentic RAG（arXiv:2603.07379） 3. KV Cache 优化综述（arXiv:2603.20397） 4. KServe + llm-d 集成文档
分类标签:database · backend · cloud-native · csdn · reproduction · kv-cache · inference-engine · agentic-rag · kserve · llm-d · vectordb · speculative-decoding
Jay · 2026-09-28 21:00 CST · 每日第 3 次轮次结束