Jay · 晚间知识简报 · 2026-06-29 21:30
本次主题
晚间简报：推理引擎深度对比 · VectorDB 大规模评测 · KubeCon India 2026 AI 采纳率
🔬 Inference Engine · 推理引擎
▶ SGLang vs vLLM · 2026 H100 实测（Spheron, 2026-06-24）
来源: https://www.spheron.network/blog/vllm-vs-sglang-2026
可信度: 高（实测平台 RunPod，H100 SXM5 / H200 SXM5，环境公开）
核心数据：
| GPU | 引擎 | 有效 tok/s | 每 1M token 成本 |
|---|---|---|---|
| H100 SXM5 | vLLM (APC off) | 1,850 | $0.61 |
| H100 SXM5 | vLLM (APC on) | 2,100 | $0.54 |
| H100 SXM5 | SGLang | 2,550 | $0.44 |
| H200 SXM5 | SGLang | 3,200 | $0.51 |
关键结论： - 共享前缀（system prompt / RAG doc / tool definition）超过 60% 请求时，SGLang 的 RadixAttention 有显著优势 - 前缀重叠低于 60% 时，两者差距在 5% 以内，选择取决于模型支持广度 - 独立 prompt 吞吐量：SGLang 620 tok/s vs vLLM 580 tok/s（差距不大） - TTFT p50（80% 共享前缀）：SGLang 520ms vs vLLM 730ms（差距明显）
决策门槛：前缀重叠率 > 60% → SGLang；否则两者差异有限。
评价：数据质量高，GPU 型号、spot 定价（2026-06-24）均标注。推荐用于向团队解释引擎选型逻辑。
▶ SGLang vs LMDeploy vs vLLM · H100 全面对比（AI Multiple, 2026-06）
来源: https://aimultiple.com/inference-engines
可信度: 中（第三方分析平台，部分数据引用自 Fish Audio benchmark）
核心发现：
SGLang（16,215 tok/s）和 LMDeploy（16,132 tok/s）在 H100 上几乎持平（差 < 0.6%，在误差范围内）；而配备 FlashInfer 的 vLLM 为 12,553 tok/s，落后约 29%。
作者判断：差距来源不是数学 kernel（均用 FlashInfer），而是引擎内部调度开销（orchestration overhead）。这意味着即使 kernel 相同，vLLM 的调度架构劣势依然存在。
重要限定：测试配置 tp=1, context=8192, batch=128，具体场景未必泛化到 tp=8 生产环境。
建议：关注 29% 差距是"架构问题还是测试配置问题"，建议在其他并发量级复测后再作为选型依据。
▶ 推理引擎 2026 全面对比（Deploybase, 2026）
来源: https://deploybase.ai/articles/best-llm-inference-engine
可信度: 中（集合多个来源的对比文章，含 TensorRT-LLM 对比）
要点：
- TensorRT-LLM：NVIDIA 原生优化（kernel fusion、tensor 优化），在 H100/H200 上峰值吞吐最高，但编译开销大、不支持动态前缀共享、冷启动慢
- SGLang：RadixAttention + 结构化输出（xgrammar）优势明显，适合 agentic 工作流、多轮对话
- vLLM：连续 batching 成熟，内存效率高，适合高并发、batch 推理
- TGI：生态集成好，bfloat16 开启有 10-15% 提升，适合 Hugging Face 模型为主的开箱即用场景
- llama.cpp：CPU/GPU 混合推理最优解，GPU offload 80 层时 -ngl 80 可用
Structured Output 维度： - SGLang xgrammar 与 GPU 推理步骤重叠，overhead 低 - vLLM guided decoding 在 batch size ≥ 8 时显著降速（SqueezeBits 实测）
🗄️ Database · VectorDB
▶ Qdrant vs pgvectorscale · 5000万向量评测（AlphaCorp AI, 2026-06）
来源: https://alphacorp.ai/blog/best-vector-databases-rag-2026-top-7-picks
可信度: 高（引用 Tiger Data 基准测试，数据可溯源）
核心数据（50M 向量，768 dim，99% recall）： - pgvectorscale: 471 QPS，p95 latency 显著低于 Pinecone s1（28 倍差距） - Qdrant: 41.47 QPS（同条件） - 差距：pgvectorscale 吞吐量是 Qdrant 的 11.4 倍
技术原因：pgvectorscale 使用 DiskANN + Statistical Binary Quantization，向量存磁盘，高效且 recall 不降。
评价：这一结果颠覆了"专用向量数据库一定比 pgvector 快"的常识。自托管 PostgreSQL 团队注意：pgvectorscale 是值得认真评估的生产选项。
使用建议： - 已有 PostgreSQL 基础设施 → 优先评估 pgvectorscale（运维成本最低） - 需要毫秒级 p99 + 复杂 metadata 过滤 → Qdrant 仍然是 OSS 首选 - 10M 以下向量，Qdrant p99 ~12ms，仍然是延迟最优解
▶ VectorDB 2026 Benchmark 全景（Salt Technologies, Q1 2026）
来源: https://www.salttechno.ai/datasets/vector-database-performance-benchmark-2026
可信度: 高（标准化测试，CSV/JSON 公开，1M vectors，1536 dim，19 个字段）
延迟排名（p50 / p99）：
| DB | p50 ms | p99 ms |
|---|---|---|
| Qdrant OSS | 4 | 25 |
| Redis OSS | 5 | 20 |
| Milvus OSS | 6 | 35 |
| Pinecone | 8 | 45 |
| ChromaDB | 12 | 70 |
| pgvector | 18 | 90 |
注意：pgvector p99 90ms 在 1M 向量下已接近可用上限，高召回率场景建议加 pgvectorscale。
☁️ Cloud Native · K8s
▶ KubeCon India 2026 · AI on Kubernetes 采纳数据（2026-06-18/19, Mumbai）
来源: https://www.cncf.io/announcements/2026/03/10/cncf-unveils-kubecon-cloudnativecon-india-2026-schedule
可信度: 高（CNCF 官方）
关键数据：
82% 的组织已在 AI 工作负载中采用 Kubernetes，但只有 7% 每天在生产中部署 AI。
CNCF 评价：这一差距说明"Kubernetes 用于 AI"和"Kubernetes 融入 AI 开发流程"是两件事。印度贡献者在 CNCF committer 排名第三，正在推动缩小这一差距。
CNCF 重点关注方向： - GPU 管理与编排 - AI Agent 和模型路由 - 可观测性 - 平台工程
评价：7% vs 82% 的差距是 2026 年 AI + Cloud Native 领域的核心张力——基础设施就绪，流程未就绪。这对平台工程师和 AI infra 团队是明确的机遇信号。
▶ Microsoft AI Runway · K8s 推理工作负载通用 API（KubeCon EU 2026）
来源: https://opensource.microsoft.com/blog/2026/03/24/whats-new-with-microsoft-in-open-source-and-kubernetes-at-kubecon-cloudnativecon-europe-2026
可信度: 高（Microsoft 官方开源博客）
核心发布：AI Runway 开源项目，定位是为推理工作负载建立通用 Kubernetes API，解决各推理引擎（vLLM / SGLang / TensorRT-LLM / NVIDIA Dynamo / llm-d / KAITO）各自有独立部署方式的碎片化问题。
功能： - HuggingFace 模型发现（内置） - GPU memory fit 指示器 - 实时成本估算 - Web UI（面向非 K8s 用户） - 支持多运行时
评价：AI Runway 值得关注——如果它能成为推理工作负载的"Kubernetes 通用界面"，多引擎并存的企业环境将显著受益。
▶ Istio Ambient + Gateway API Inference Extension（KubeCon EU 2026, Solo.io）
来源: https://www.solo.io/blog/highlights-from-kubecon-cloudnativecon-europe-2026
可信度: 中（厂商博客，引用自 KubeCon EU 2026 现场）
亮点： - Istio Ambient 模式（sidecar-less）新增多集群支持 - Gateway API Inference Extension：用于 AI 流量的智能路由（GPU / CPU 分流） - 演示架构：Istio + agentgateway → LLM-D（CPU 推理） + SLM（≤8B，CPU）→ GPU 推理
与 AI Runway 的关系：两者从不同方向解决同一问题（AI 工作负载标准化），可能走向竞争或融合。
📡 Substack · Newsletter 高价值条目
▶ "The AI Agents Stack: LLM to Production (2026 Edition)" · theaiengineer (Paolo Perrone)
来源: https://theaiengineer.substack.com/p/the-ai-agents-stack-2026-edition
可信度: 高（技术 newsletter，作者从事 AI 工程，有真实部署经验）
核心洞察： 1. Memory 是第一等公民：2024 年 memory = vector DB；2026 年 memory = 三层架构（context window / session state / long-term） 2. MCP 标准化了工具连接：整个 tools 层是 2024-2026 新增的，MCP 是关键推动力 3. "Context Engineering" 替代 "Prompt Engineering"：架构师信息源，不是写更好的 prompt 4. Memory Blocks：命名结构化字段，agent 可在每轮对话中读写、覆盖，不再是全量塞入 system prompt
评价：对理解 2024 → 2026 的 AI Agent 架构演进非常有价值。Memory 作为"第一等公民"的判断值得记入知识库。
📋 分类标签
inference-engine vllm sglang kv-cache vector-db qdrant pgvectorscale kubernetes kubecon ai-runway istio agentic memory 2026-jun
💡 是否需要精读/审稿
| 条目 | 行动 |
|---|---|
| Spheron vLLM vs SGLang 2026 benchmark | 建议精读：选型决策直接可用 |
| AI Multiple SGLang vs LMDeploy vs vLLM | 建议审稿：29% 差距需在其他并发量级复验 |
| pgvectorscale vs Qdrant 50M 向量 | 建议精读：颠覆常识的生产评估数据 |
| AI Runway K8s 推理 API | 建议跟踪：开源社区发展，关注成熟度 |
| Paolo Perrone - AI Agents Stack 2026 | 建议审稿：架构层判断（Memory as first-class）值得核验 |
📁 建议写入路径
/shared/research-kb/inbox/jay/2026-06-29-2130-evening-briefing-inference-engine-vecdb-kubecon-2026.md（本文）- 如后续有精读产出，可拆出独立条目：
2026-06-30-inference-engine-vllm-vs-sglang-selection-guide.md2026-06-30-pgvectorscale-production-evaluation.md
本简报由 Jay（Jay · 研究知识库实例）整理于 2026-06-29 21:30 UTC+8 不包含 Substack 原文复制内容，仅做中文摘要、引用与建议