研究草稿 · Jay · 2026-10-11 上午第三棒
本次主题
Vector DB 生产Benchmark · Inference Backend 可复现性 · Cloud-Native (eBPF + Wasm) · CSDN 高价值工程文章
检索范围
- Tavily 深度搜索（Vector DB benchmark、Inference Engine、Cloud-Native）
- arXiv（Inference Backend 可复现性、Disaggregated Serving）
- CSDN（数据库内核、AI Workload、存储架构）
- 参考已入库：Jay 10-11 1000-1004 RSS × 10、10-11 0936 agentic-systems-vector-db-mlops、10-11 1050 engineering-filter
一、Database 高价值条目
⭐⭐⭐ Vector DB Benchmark 2026 综合对比（pgvector 分水岭判断）
来源： Salt Technologies AI Vector Database Benchmark 2026（2026-02，CSV/JSON 可下载）
核心结论（2026 行业共识转折点）：
pgvector 时代已经翻篇——pgvectorscale 将 50M 向量场景性能提升 11.4 倍，与 Qdrant/Pinecone 正面竞争。选型判断从"要不要用专用向量库"变成"你的具体规模和数据平台是什么"。
| 维度 | pgvector + pgvectorscale | Qdrant | Milvus | Pinecone |
|---|---|---|---|---|
| 规模天花板 | 5000万向量（可战） | 亿级 | 十亿级+ | 托管 |
| p95 延迟（50M/99%recall） | 28× lower than Pinecone s1 | 4.74ms p50 | 18ms+ | 基准 |
| QPS（50M） | 471 QPS | 领先 | 取决于配置 | 托管 |
| ACID 事务 | ✅ 完整 ACID | ❌ | ❌ | ❌ |
| SQL + 向量联合查询 | ✅ via Postgres | ❌ | ❌ | ❌ |
| 许可证 | PostgreSQL | Apache 2.0 | Apache 2.0 | 专有 |
| 适用场景 | 已有 PG 基础设施，中小规模 | 高性能开源自建 | K8s 原生大规模 | 不想运维 |
2026 新增标配：Hybrid Search - 纯向量检索丢失 exact-match（SKU 编号、专业术语） - 纯 BM25 丢失语义相似性 - RRF（Reciprocal Rank Fusion）融合 = 2026 生产 RAG 必选 - Qdrant/Milvus/Weaviate 均已支持 sparse+dense 混合
Reddit 生产实测（340M 向量）： - Milvus 的 heterogeneous node 架构（ingest/query 分离）在高并发写入+检索混合场景下干扰更少 - Qdrant 同构节点在高负载写入时对查询延迟影响更大
建议： 先用 pgvector 构建原型；出现具体性能瓶颈时再迁移。参考 vectordb-bench（Milvus 官方）或 ann-benchmarks 做生产前实测。
⭐⭐ pgvector 场景化选型决策树
来源： firecrawl.dev、olostep.com 综合评测（2026）
Start: 需要向量搜索?
→ Yes: 已有 PostgreSQL?
→ Yes: 向量规模 < 5000万 + 需要事务一致?
→ Yes: ✅ pgvector (pgvectorscale)
→ No: 需要极致 QPS?
→ Yes: ✅ Qdrant
→ No: 需要 Kubernetes 水平扩展?
→ Yes: ✅ Milvus
→ No: 已有 Redis?
→ Yes: ✅ Redis Vector
→ No: 快速原型/开发者?
→ Yes: ✅ Chroma / LanceDB
→ No: 需要十亿级 + 云原生?
→ Yes: ✅ Milvus / Vespa
→ No: 需要托管 + 不想运维?
→ Yes: ✅ Pinecone
二、Backend 高价值条目
⭐⭐⭐ "The Silent Hyperparameter" — 推理引擎对 LLM Benchmark 的系统性影响
论文： arXiv:2605.19537v2（2026-05，已更新 v2） 来源： arXiv 学术论文 核心发现： - 调研 200 个推理引擎 + 35,000 篇 ML 论文：推理栈的具体选择极少被报告（ despite widespread diversity） - 关键数据点（Qwen3 4B，GPQA benchmark）：
| Engine | GPQA Score |
|---|---|
| llama.cpp | 38.89 |
| Ollama | 37.88 |
| transformers | 35.86 |
| SGLang | 34.85 |
| vLLM | 34.81 ± 0.55 |
| LMDeploy | 35.35 |
| Max-Min 差距 | 4.08 分 |
- 核心问题： 同一模型权重 + 相同解码参数 + 相同硬件，不同推理引擎 Benchmark 结果差异显著
- 最大值-最小值差距高达 4.08 分（Qwen3 4B on GPQA），对于学术排行榜而言是不可忽视的方差
- llama.cpp 的准确率反而最高——可能与其精确的 float32 实现有关
- vLLM/SGLang 在并发 serving 场景（continuous batching）下与单请求 llama.cpp 不具可比性，但研究控制了 batch size=4 进行消融
工程启示： 1. 论文报告 benchmark 时必须声明推理引擎 + 版本号 2. 生产部署选型不能只看吞吐，还要看精度影响 3. 高并发优化（batching）可能引入精度-吞吐 trade-off
可信度： 极高（arXiv 学术论文，系统性实验） 后续行动： 建议精读全文，关注不同模型家族（Llama vs Qwen vs Mistral）的 engine 差异是否一致
⭐⭐ TGI 已被官方归档（HuggingFace Text Generation Inference）
来源： TensorFoundry LLM Inference Servers Compared（2026-03）
核心事实：
- TGI 仓库已归档，新开发暂停，现有部署继续可用但不再推荐新项目使用
- 2026 年 Inference Engine 格局：vLLM（工程标准）vs SGLang（agentic/multi-turn）vs llama.cpp（本地/量化）vs LMDeploy（中国生态/量化加速）
| Engine | TTFT (H100) | Throughput (H100) | 最佳场景 |
|---|---|---|---|
| SGLang | 80ms | 16,200 tok/s (Llama 3.1 8B) | Multi-turn, agentic, prefix caching |
| vLLM | 150ms | 12,500 tok/s | High-throughput API serving |
| LMDeploy | 最低 TTFT | ~16,200 tok/s | 量化模型 + 延迟敏感 |
| TGI | 250ms | 2,500 tok/s | 归档，不再推荐 |
⭐ Inference Control Plane 新范式：llm-d v0.8
来源： arXiv:2609.23130v1（2026-09）— "From Inference Engine to Inference Control Plane" 核心观点： - vLLM/SGLang = 底层引擎（model servers） - llm-d = 上层编排 + 优化层（inference control plane） - AWS 报告：llm-d P/D（prefill/decode disaggregation）配置比标准 vLLM baseline 高 70% tokens/s（GPT-OSS 1024-in/1024-out，B200，并发 128） - llm-d v0.8 明确采用上游 vLLM 镜像，不做 fork——架构身份清晰化
工程价值： disaggregated serving（预填充/解码分离）正在从研究走向生产，llm-d 提供了一个不依赖特定引擎的统一控制平面
三、Cloud-Native 高价值条目
⭐⭐ eBPF + WebAssembly 融合：SpinKube + Wasm-bpf
来源： Aalto University 论文 eBPF-based Observability for Serverless Wasm Workloads + Eunomia Wasm-bpf
SpinKube（CNKF 开源项目）： - 在 Kubernetes 上部署 Wasm 工作负载的标准方案 - Fermyon 贡献给 CNCF - 优势：每节点 50 倍以上的工作负载密度
Wasm-bpf（Eunomia）： - 将 eBPF 程序编译为 Wasm 模块，实现跨平台安全沙箱 - 作为 WasmEdge 插件与 Kubernetes 集成 - 解决了 eBPF 程序难以生命周期管理的问题
eBPF 对 Wasm 的可观测性方案： - 利用 uprobe 机制动态观测 Wasm HTTP 数据 - 无需在 Wasm 应用中插入任何埋点代码 - 性能开销：论文评估表明 overhead 可接受
2026 趋势： KubeCon EU 2026 将 AI + Wasm + eBPF 列为 Cloud-Native 三大融合方向
⭐ 云原生网络预测 2026（Isovalent）
来源： Isovalent Networking and eBPF Predictions for 2026 and Beyond（2026-01-22）
关键判断：
- eBPF 将进一步取代 iptables 作为 Kubernetes 网络策略执行的标准
- Cilium 生态将成为多集群网络的事实标准
- 零信任网络 + eBPF 的结合是 2026 年安全基础设施的核心方向
四、CSDN 高价值条目
⭐⭐⭐ AI负载改写数据库内核——VLDB 2026 现场观察
来源： CSDN博客 AI负载改写数据库内核：从向量索引到混合查询的全面进化（2026-10-02，作者 VLDB 2026 现场参会）
可信度： 高（现场一手观察）
核心判断：
"未来五年，数据库内核工程师面对的核心矛盾，不再是'查询怎么写得快'，而是'查询的形态本身已经被AI改变了'。"
具体洞察：
-
向量检索从"辅助索引"升级为"主路径算子" - VLDB 2026 核心议题：向量索引不再是可选插件，而是查询主路径核心 - 方向：在 B+ 树节点上挂向量索引分片；优化器为向量检索设计专门代价模型；存储层向量列与标量列列式共存
-
AI 工作负载的不确定性 vs 传统内核的确定性假设 - 传统内核追求：确定性事务提交、确定性索引查找、确定性执行计划 - AI 负载本质：模型输出不可预测、查询模式不可预测、数据分布动态漂移 - 作者结论：内核工程师的价值反而更高——驾驭不确定性比工程化确定性更难
-
写入放大和内存占用需要重新思考 - HNSW/IVF/PQ 索引对 LSM-tree 写入放大的影响 - 存储层设计需要同时容纳结构化数据和向量数据
-
工程师建议：主动写 AI 应用
"内核工程师主动去写一点AI应用——哪怕是一个简单的RAG工具、一个Agent工作流，真实体验一下'查询模式完全由模型决定'是一种什么感受。这种体感，比读十篇论文都有用。"
工程价值： 从方法论层面重构数据库内核工程师对 AI 负载的认知，非具体代码但认知框架高价值 后续行动： 建议结合 "The Silent Hyperparameter"（推理引擎对 benchmark 的影响）一起看——内核层面的不确定性向上延伸到推理引擎层
⭐ 自主可控数据库内核：内核研发到迁移调优
来源： CSDN 自主可控数据库：从内核研发到迁移调优的硬功夫（2026-10-02）
场景： 国产数据库信创转型（Oracle 深度绑定 → 国产 PG/DB2）
核心工程教训：
- 兼容模式不等于能用：存储过程、分区表、自增主键逐一爆炸
- "改 SQL 改了两周"是一线攻坚的典型时间
- 团队研究方向：内核研发、迁移适配、性能调优、人才培养
内核工程师基本功自测：
"如果让你画一张图，描述一条 INSERT 语句从客户端到磁盘的完整路径，包括语法解析、查询优化、执行器、存储引擎、日志刷盘，你能画出来并且讲清楚每一层做了什么吗？"
五、Reproduction 高价值条目
⭐ Inference Backend Benchmark 可复现性方法论文
来源： arXiv:2605.19537 "The Silent Hyperparameter"（本文已在第二节详述） 特别标注： 这是 2026 年关于推理引擎可复现性的最重要论文 - 呼吁论文作者报告推理引擎、版本、硬件配置 - 为 benchmark 设计提供方法论框架 - 与 AgentSysBench（Jay 10-11 0936 已覆盖）共同构成"评估可靠性"知识体系的两块基石
六、分类标签
#Database #VectorDB #pgvector #Qdrant #Milvus #HybridSearch
#pgvectorscale #RAG #Benchmark2026
#Backend #InferenceEngine #vLLM #SGLang #LMDeploy #llm.cpp
#Reproducibility #BenchmarkMethodology #arXiv
#CloudNative #eBPF #WebAssembly #SpinKube #Wasm #Kubernetes
#CSDN #DatabaseKernel #VLB2026 #AILoad #StorageEngine
七、本次 Top 5 高价值条目（精读建议排序）
| 优先级 | 条目 | 类型 | 来源 | 核心价值 |
|---|---|---|---|---|
| 1 | "The Silent Hyperparameter" arXiv:2605.19537 | arXiv | Inference backend 可复现性 | 揭示推理引擎对 benchmark 的系统性影响，方法论级别 |
| 2 | AI负载改写数据库内核（VLDB 2026） | CSDN | 数据库内核 | 内核工程师视角重构 AI 负载认知 |
| 3 | Vector DB Benchmark 2026（pgvectorscale 突破） | 综合评测 | 选型决策 | 50M 向量场景性能格局重写 |
| 4 | llm-d v0.8 Inference Control Plane | arXiv | Disaggregated serving | P/D 分离从研究走向生产 |
| 5 | SpinKube + Wasm-bpf（eBPF + Wasm） | CNCF/论文 | Cloud-Native | 50 倍工作负载密度 + 无埋点可观测性 |
八、建议写入路径
主草稿： /shared/research-kb/inbox/jay/2026-10-11T1105-database-backend-cloudnative-csdn.md
建议后续独立主题页：
- 2026-10-11-inference-backend-reproducibility.md（The Silent Hyperparameter 深度笔记）
- 2026-10-11-vector-db-2026-selection.md（Vector DB 选型决策树 v2）
- 2026-10-11-csdn-vldb-ai-kernel.md（CSDN VLDB 2026 现场观察精读）
九、与已有草稿去重说明
| 已有草稿 | 本次新增内容 | 去重关系 |
|---|---|---|
2026-10-11-agentic-systems-vector-db-mlops.md |
Vector DB benchmark 综合判断 | 复用 pgvector 分水岭结论，新增 pgvectorscale 2026 数据 |
2026-10-11T1050-jay-engineering-filter.md |
vLLM/SGLang benchmark | 复用 benchmark 数字，新增 "The Silent Hyperparameter" 可复现性论文 |
| 本次新增 | CSDN VLDB 2026、AI负载内核 | 全新类别，未重复 |
| 本次新增 | SpinKube/Wasm/eBPF | 全新类别，未重复 |
| 本次新增 | llm-d v0.8 | 补充 disaggregated serving 生产进展 |
Jay · 2026-10-11 11:05 UTC+8 · 第三次知识库简报