知识库草稿：数据库 · Backend · Cloud-Native · 推理引擎 · 2026-09-22
实例： Jay | 日期： 2026-09-22 | 检索范围： Tavily 搜索（Inferenceengineering.tech、Spheron、Runpod、LeCompute、BinaryIgor benchmarks、arXiv、DesignGurus Substack、Cloud-Native survey）
一、Database（数据库）
条目 1：PostgreSQL vs MySQL 2026 基准对决（BinaryIgor Jan 2026）
来源： DevTools Research / CommandLinux benchmarks
URL： https://devtoolswatch.com/en/postgresql-vs-mysql-2026
类型： 性能基准研究（综合多来源）
可信度： 高——独立测试环境（AMD Ryzen 7 PRO 7840U, 8C/32GB, Ubuntu 24.04, NVMe），受控 Docker 隔离
核心数据：
| 操作 | MySQL 9.5 QPS | PostgreSQL 18.1 QPS | PostgreSQL 优势 |
|---|---|---|---|
| 单行 INSERT | 4,383 | 21,338 | 4.87× |
| 批量 INSERT 100行（items） | 200 | 211 | 1.06× |
| 批量 INSERT 100行（orders） | 1,883 | 3,535 | 1.88× |
| 99th p INSERT 延迟 | 42.7 ms | 4.0 ms | 10.7× |
| 复杂 SELECT（1M 记录） | 6,300 | 23,441 | 3.72× |
| SELECT 平均延迟 | — | — | PostgreSQL 9.34× 更低 |
| P99 延迟 | — | — | PostgreSQL 8.77× 更低 |
| Sysbench 中位延迟（17项） | — | — | PostgreSQL 2.3× 更低 |
| Sysbench 写操作延迟 | — | — | PostgreSQL 3.5× 更低 |
写性能差距显著（13× 在某些测试场景），读性能 PostgreSQL 在复杂查询场景下领先 3.7×；MySQL 仅在简单单表 OLTP 场景以约 21% 优势领先。
写操作并发测试： PostgreSQL 在并发插入时 SELECT 延迟稳定在 0.7–0.9 ms；MySQL 退化至 7–13 ms。PostgreSQL 在 800–1000 并发连接下维持稳定，而 MySQL 在 500+ 连接开始出现瓶颈。
评价： 这组 2026 年基准数据清晰——PostgreSQL 在写入、复杂查询、高并发场景全面领先，MySQL 的优势收窄至轻量 OLTP 场景。对于 AI 应用后端（向量存储、agent 状态、会话管理），PostgreSQL 是更安全的技术选型。
是否精读： 中——基准数据直接可用，结论清晰；建议结合 Supabase/DuckDB 补充文档了解端到端 AI Backend 架构
建议路径： papers/database/pg-vs-mysql-2026-benchmark/
标签： PostgreSQL MySQL Performance-Benchmark Backend 2026
条目 2：向量数据库选型决策树 2026（综合）
来源： aiml.qa / Medium (100+ enterprise deployments) / alphacorp.ai / marktechpost
URL： https://aiml.qa/vector-database-comparison-2026 等
类型： 选型指南（综合社区与生产部署经验）
可信度： 中——社区综合，非受控基准；数据来自 Reddit engineering 340M 向量实测
规模分层决策：
| 规模 | 推荐选型 | 关键理由 |
|---|---|---|
| < 100 万向量 | Chroma / pgvector | 复杂度不必要引入专用 DB |
| 100 万–1000 万 | Qdrant / Weaviate / pgvector+HNSW | 专用 DB 展现优势 |
| 1000 万–1 亿 | Qdrant / Weaviate / Milvus | 专用 DB 必需 |
| 1 亿–10 亿 | Milvus / Vespa / Pinecone Enterprise | 分布式架构必需 |
| 10 亿+ | Milvus + 专用工程团队 | 自定义分片策略 |
各引擎特点（2026 更新）：
- Qdrant：Rust 原生，运营简单，过滤能力强；社区反映 340M 向量规模下比 Milvus 延迟更低；但同构节点在密集写入+查询并发时干扰更明显（Reddit evaluation）
- Milvus：异构节点（ingest/query 分离），大规模（100M+）写入/查询隔离更好；Reddit 340M 实测写入扩展性领先
- Weaviate：内置向量化和混合搜索（vector+keyword），Python/TS SDK 成熟；适合需要开箱即用检索pipeline 的团队
- Chroma：本地原型开发首选；嵌入式中，无需独立服务
- pgvector：新项目默认起点；PostgreSQL 生态成熟，迁移成本低；1000万以下完全够用
评价： "先 pgvector，规模化后再迁移专用 DB" 仍是 2026 年最务实的建议。Reddit 340M 向量实测数据有价值——说明规模是架构分水岭。
是否精读： 低——决策树可直接引用；如需深度评估特定引擎再查
建议路径： papers/database/vector-db-selection-guide-2026/
标签： Vector-Database Qdrant Milvus Weaviate pgvector Selection-Guide
二、Backend（后端）
条目 3：vLLM vs SGLang vs TensorRT-LLM 推理引擎工程决策框架（2026）
来源： Inferenceengineering.tech / Spheron / Jarvis Labs / Runpod
URL： https://inferenceengineering.tech/learn/vllm-vs-sglang-vs-tensorrt-llm
类型： 工程决策指南（2026-06 更新）
可信度： 高——专业推理工程博客，含 H100 真实基准数据
架构共性（三引擎共享）： - Continuous batching（动态批次） - Paged/Radix KV cache 管理 - FP8/INT4 权重量化支持 - Speculative decoding 支持（各引擎均有）
选型决策矩阵：
| 维度 | vLLM | SGLang | TensorRT-LLM |
|---|---|---|---|
| 生态与易用性 | ⭐⭐⭐⭐⭐ 最简单 | ⭐⭐⭐⭐ | ⭐⭐⭐（需编译） |
| 前缀缓存 | PagedAttention（块级哈希） | RadixAttention（token级树，自动前缀发现） | 有限 |
| 高并发+MoE | ⭐⭐⭐（EP 实验性） | ⭐⭐⭐⭐⭐（DeepSeek-R1/V3 最优） | ⭐⭐ |
| 硬件支持广度 | ⭐⭐⭐⭐⭐（NVIDIA/AMD ROCm/TPU/Intel Gaudi/CPU） | ⭐⭐⭐（NVIDIA 为主） | ⭐⭐⭐（仅 NVIDIA） |
| 结构化输出吞吐 | 中 | ⭐⭐⭐⭐⭐（调度器级约束解码集成） | ⭐⭐⭐ |
| 生产成熟度（2026） | 最高 | 高 | 高 |
| TTFT 尾延迟（prefix-heavy） | 基准 | 低 37%（p50）/ 41%（p95） | 高（编译后 decode 最稳定） |
| 编译后 decode 延迟 | 随并发略升 | 高并发后跳升（40-50ms @ 240+） | 最稳定（~17ms） |
| 输出吞吐（7B/Qwen，H100） | ⭐⭐⭐⭐⭐（9.36K tok/s @ concurrency 360） | ⭐⭐⭐（高并发后下降） | ⭐⭐⭐（低且平稳） |
| Long context（RAG/多轮Agent） | 中等 | 最优（前缀复用最大化） | 需编译配置 |
H100 实测（Jarvis Labs, May 2026）：
- Qwen2.5-7B / Qwen3-30B-A3B / Qwen3-32B：
- TTFT：vLLM 和 SGLang 明显低于 TRT-LLM（TRT-LLM 并发增加时 TTFT 达 8.9s @ 600 并发）
- TPOT/ITL：TRT-LLM 最稳定（~17ms），vLLM 随并发略升，SGLang @ 240+ 并发退化至 40-50ms
- 输出吞吐：vLLM 峰值 ~9.36K tok/s @ 360 并发；SGLang 高并发后回落；TRT-LLM 持续偏低
SGLang 关键优势场景： 共享系统提示词 + 短用户轮次（chatbot）、RAG 复用检索上下文、多轮 Agent 循环。RadixAttention 的自动前缀发现使共享上下文场景无需手动优化。
vLLM 关键优势场景： 独立 prompt、高并发读取、生态最广（pip install 即可）、跨硬件支持。
TRT-LLM 关键优势场景： 固定模型长期运行、decode 延迟要求极高、NVIDIA 独占环境。
评价： 这是 2026 年推理引擎选型的最佳工程参考，结论可操作性强。SGLang 的 RadixAttention vs vLLM PagedAttention 的根本区别（"token级自动发现" vs "块级哈希需一致边界"）是关键技术洞察。
是否精读： 高——引擎选型是 AI Backend 核心决策，文章含具体基准数据
建议路径： papers/inference/vllm-sglang-trt-llm-comparison-2026/
标签： vLLM SGLang TensorRT-LLM Inference-Engine Benchmark H100
三、Cloud-Native（云原生）
条目 4：Kubernetes 2026 状态（CNCF Survey 2026）
来源： Ernie's Leisure Code / CNCF Annual Survey Jan 2026
URL： https://ernie55ernie.github.io/infrastructure/2026/08/21/kubernetes.html
类型： 年度状态分析
可信度： 高——CNCF 官方数据源（Jan 2026）
核心数据： - 容器用户中 82% 已将 Kubernetes 投入生产（2024: 80%, 2023: 66%） - CNCF 预测 2026 年底 90%+ 组织运行容器化应用（2020: <40%） - 95% 新工作负载将在云原生平台上部署（2021: 30%） - 平台工程（Platform Engineering）采用率预计 2026 年底达 80%（认知负荷驱动 IDP 需求） - Kubernetes 已从微服务调度器演变为 AI 工作负载基础设施工具
2026 年关键趋势： 1. AI/ML 负载原生集成深化：Kubernetes 调度 GPU 资源、训练任务编排、推理管道管理能力成熟 2. eBPF 网络：Cilium 替代传统 CNI，提供网络可观测性和安全能力 3. 多租户安全：内置安全工具默认启用成为采购标准；45% 漏洞在构建/运行时阶段发现 4. FinOps 成本优化：Kubecost 集成成为平台标配；GPU 资源精细化管理压力增大 5. SBOM（软件物料清单）普及：供应链安全成为默认要求
评价： Kubernetes 已进入"成熟基础设施"阶段，技术选型复杂度不再是主要障碍（托管服务、声明式平台工程已解决），真正的挑战是 FinOps（成本优化）和安全合规。AI/ML 负载是 2026 年最大的新增驱动力。
是否精读： 中——CNCF 数据点可直接引用；K8s 2026 趋势可作为知识库系统架构层补充
建议路径： papers/cloudnative/kubernetes-state-2026/
标签： Kubernetes Cloud-Native CNCF Platform-Engineering FinOps 2026
条目 5：容器编排平台替代方案 2026
来源： DoiT.com
URL： https://www.doit.com/blog/kubernetes-alternatives
类型： 选型对比
可信度： 中——行业分析，34% K8s 用户将复杂度列为首要挑战
CNCF 2026 数据： 82% 容器用户用 K8s 生产，但 34% 将复杂度列为首要挑战。这催生了替代方案需求。
| 平台 | 优势 | 劣势 | 最佳场景 |
|---|---|---|---|
| K8s | 通用性最强，生态最广 | 复杂度高，学习曲线陡 | 异构环境、多云、定制化需求 |
| Amazon ECS + Fargate | 无 EC2 运维，serverless 按需计费 | AWS 锁定，无可移植性 | AWS 原生、无状态微服务、变流量负载 |
| Google Cloud Run | 零冷启动（基于 Knative），按请求计费 | GCP 锁定 | 无状态 HTTP 服务，GCP 原生团队 |
| HashiCorp Nomad | 简单，K8s 复杂度过高时的替代 | 生态较小 | 简单工作负载，最小化运维 |
| Docker Swarm | 已有 Docker 技能团队最快路径 | 功能有限，不适合大规模 | 小团队少量服务 |
评价： 对于 AI 基础设施团队，K8s 仍是 GPU 调度和多模型服务的标准选择，但 Cloud Run/Fargate 在无状态推理 API 场景（FastAPI、TGI endpoint）上有成本优势。
是否精读： 低——选型参考；精读价值不高
建议路径： papers/cloudnative/container-orchestration-alternatives-2026/
标签： Container-Orchestration Kubernetes ECS CloudRun Nomad
四、Inference（推理引擎·专项）
条目 6：KV Cache Serving 2026 — Runtime 特性矩阵（vLLM vs SGLang vs TRT-LLM vs Dynamo）
来源： LeCompute.fr（系统性综述）
URL： https://lecompute.fr/en/runtimes/kv-cache-objet-central-serving
类型： 工程对比表
可信度： 高——2026 年 5 月生产特性截止，列出了各运行时具体版本号
Runtime 功能矩阵（2026 年 5 月）：
| 特性 | vLLM 0.20–0.21 | SGLang 0.5.12 | TRT-LLM v1.1–1.3 | Dynamo 1.0 |
|---|---|---|---|---|
| FP8 KV 量化 | ✓ | ✓ | ✓ | ✓（via runtime） |
| TurboQuant ~3bit | ✓（v0.20, PR #38479） | — | — | — |
| Sparse attention | — | HiSparse（DSA 架构） | ✓（sparse backend） | — |
| FlashAttention 4（prefill） | ✓（SM90+，默认） | — | — | — |
| Smart CPU offloading | ✓（reuse frequency） | ✓（HiSparse） | ✓（host offloading） | G2（KVBM） |
| SSD offloading | — | ✓（HiCache + Mooncake） | — | G3/G3.5（KVBM） |
| Object-storage offloading | — | — | — | ✓（S3/Azure Blob） |
| P/D disaggregation | ✓（NIXL, bidirectional） | — | ✓（KV Cache Connector API） | ✓（KVBM + NIXL） |
| KV-aware routing | — | — | — | ✓（K8s Inference Gateway） |
| 多运行时支持 | ✓ | ✓ | ✓ | ✓（vLLM/SGLang/TRT-LLM） |
关键洞察： - vLLM 0.20 引入 TurboQuant（~3bit），是当前 cache 压缩比最高的方案 - SGLang 在 offloading 层级上最深入（HiSparse + HiCache + Mooncake 组合），但仅支持部分模型 - Dynamo 是协调层（orchestration layer），不执行实际推理，通过 KVBM + NIXL 连接各 runtime；它的多层级 offload（S3/Blob）代表未来方向 - FlashAttention 4 进入 vLLM prefill 默认配置，SM90+（H100/B200）性能收益明显
评价： 这张特性矩阵是 2026 年中 KV cache 技术栈的快照。TurboQuant 3bit 是 vLLM 当前最大亮点；Dynamo 的 KVBM 多层级架构（GPU→CPU→SSD→Object Storage）是未来大规模推理的方向。
是否精读： 高——精读特性矩阵和架构差异；建议追踪 vLLM 0.21 和 Dynamo 1.1 版本更新
建议路径： papers/inference/kv-cache-runtime-comparison-2026/
标签： KV-Cache vLLM SGLang TensorRT-LLM Dynamo Quantization TurboQuant
条目 7：KV Cache 管理全景调查（arXiv 2607.02574）
来源： arXiv
URL： https://arxiv.org/html/2607.02574v1
类型： 学术综述
可信度： 高——arXiv 学术论文，覆盖 2024–2026 年主流工作
分类框架： 论文将 KV cache 管理策略分为： 1. P1 本地管理：PagedAttention（vLLM）/ RadixAttention（SGLang） 2. P2 缓存压缩（eviction/sparsification/quantization/compression）：H2O、Scissorhands、StreamingLLM、SnapKV、PyramidKV、KIVI、KVQuant、ChunkKV 3. P3 分布式 KV Store：Mooncake（分布式 KV cache 存储）、FlexGen（本地控制 offload precursor） 4. P4 卸载与分层：CPU/GPU/Disk 分层调度
核心发现： - SGLang 在本地分页模式中（前缀复用仍限制在 serving instance 内部），RadixAttention 是核心创新 - vLLM 是 quantization innovations 集中地（TurboQuant、FlexKV、FA4） - SGLang 是 local hierarchy innovations 集中地（HiSparse + HiCache） - Dynamo 是 cluster-level coordination（KVBM + KV-aware routing） - TRT-LLM 提供标准化 KV Cache Connector API，将编排职责委托给 Dynamo
评价： 这是 KV cache 管理领域的系统化综述，分类框架清晰。适合作为知识库推理工程层的理论基础。
是否精读： 中——先泛读分类框架；具体系统（P2 各方法）按需深入
建议路径： papers/inference/kv-cache-management-survey-arxiv-2607/
标签： KV-Cache Survey vLLM SGLang Mooncake Dynamo arxiv
条目 8：NVIDIA Dynamo 1.0 分布式推理框架
来源： NADDOD Blog / Dev.to / GitHub ai-dynamo/dynamo
URL： https://github.com/ai-dynamo/dynamo | https://dev.to/vultr/deploying-inference-using-nvidia-dynamo-and-vllm-pjj
类型： 工程部署指南 + 框架介绍
可信度： 高——NVIDIA 官方开源项目，2026 年活跃（GitHub 2026-09-18 仍有提交）
架构定位：
Dynamo 是 AI Factory 的操作系统，协调层而非执行层：
- 接收推理请求的 Frontend Service
- 基于 KV Cache 感知的 Smart Router
- 动态调整 GPU 资源分配的 GPU Planner
- 连接 etcd（服务发现）和 NATS（KV Cache 事件传播）的 Infrastructure 层
- 通过 NIXL 与 vLLM/SGLang/TRT-LLM backend 通信
核心能力： 1. Prefill/Decode disaggregation：将 prefill 和 decode 阶段分离到不同 GPU，独立优化 2. NIXL Transfer Library：GPU-to-GPU 直接传输 KV cache，跨异构设备，支持多种 transport backend（InfiniBand/RoCE） 3. KVBM（KV Buffer Manager）：多层 offload（GPU→CPU→SSD→Object Storage） 4. 动态 GPU 调度：事件驱动 Planner，实时响应负载变化
与 vLLM 集成部署路径（Dev.to）： Docker Compose 启动 etcd + NATS → Dynamo 前端 + 多个 Prefill/Decode Worker → vLLM Backend → K8s Inference Gateway（KV-aware routing）
评价： Dynamo 代表 2026 年大规模推理部署的标准方向——分离式架构 + 分层 KV cache + 智能路由。对于需要管理千卡以上 GPU 集群的团队，Dynamo 是事实标准。个人/小团队可先从 vLLM 单实例起步。
是否精读： 高——大规模推理架构必读；K8s 集成路径值得参考
建议路径： papers/inference/nvidia-dynamo-deployment-2026/
标签： NVIDIA-Dynamo Distributed-Inference Prefill-Decode KV-Cache NIXL Kubernetes
条目 9：LMCache — 企业级 KV Cache 抽象层
来源： arXiv 2510.09665（ICML 待发表）
URL： https://arxiv.org/html/2510.09665v1
类型： 学术论文 + 开源实现
可信度： 高——ICML 学术论文，GitHub 已有生产落地
核心贡献：
LMCache 将 KV cache 从"推理引擎内部副产品"提升为"一等公民"（first-class data structure）：
- 跨推理 session 复用 KV cache
- 跨不同模型复用 KV cache（论文提到跨模型 KV cache transfer 实验）
- 标准化存储和通信中间件
与 Dynamo 的关系： LMCache 是 Dynamo 的 KVBM 实现基础；Dynamo 1.0 的多层 offload 建立在 LMCache 之上。
评价： KV cache as a first-class citizen 是 2026 年推理架构的核心范式转变。LMCache 是这一范式的第一个生产级开源实现。
是否精读： 中——框架级理解；具体 API 和集成方式按需查询
建议路径： papers/inference/lmcache-kv-cache-layer-icml-2026/
标签： LMCache KV-Cache Distributed-Inference ICML Open-Source
五、CSDN / Engineering 经验
条目 10：PostgreSQL vs MySQL vs MongoDB vs Redis vs SQLite vs Supabase 2026 综合对比
来源： OnlineTools4Free Research
URL： https://onlinetools4free.com/research/database-comparison-guide-2026
类型： 综合选型指南
可信度： 中——社区综合，无原始基准数据
关键数据点： - PostgreSQL 市场占有率 35.1%（2024 年首次超越 MySQL 32.5%） - Supabase 采用率从 2020 年 0.2% 增至 2026 年 8.2%（最快增长平台）；内置 Auth、RLS、real-time、auto-generated APIs - DuckDB 达 5.5%（嵌入式分析引擎，默认数据科学/BI 工具） - 复杂 JOIN：PostgreSQL 12,000 ops/sec vs MySQL 8,500 - 聚合查询：PostgreSQL 9,800 vs MySQL 6,200 - 全文搜索：PostgreSQL 8,200 vs MySQL 4,500
评价： 数据来源不够透明，适合快速了解全貌，不适合直接引用原始数字。
是否精读： 低——数据库选型参考，非核心知识库条目
建议路径： papers/database/db-comparison-2026/
标签： PostgreSQL MySQL MongoDB Redis Supabase DuckDB Market-Share
条目 11：AI Agent Stack 2026 完整技术栈（Substack）
来源： Aishwarya Naresh Reganti, The Nuanced Perspective (Substack)
URL： https://thenuancedperspective.substack.com/p/the-ai-agent-stack-in-2026
类型： 技术栈地图（9 层）
可信度： 中——Substack 技术分析，非学术
9层架构框架：
| 层级 | 组件 | 备注 |
|---|---|---|
| L1 | Model / Frontier Model APIs | OpenAI/Anthropic/DeepSeek 等 |
| L2 | Open Source Models | Hugging Face、SGLang 支持模型 |
| L3 | API Gateway / Routing | 负载均衡、fallback |
| L4 | Agentic Framework | LangGraph/CrewAI/AutoGen 等 |
| L5 | Knowledge, Context & Retrieval | RAG、多模态 |
| L6 | Tool Use / MCP | Model Context Protocol |
| L7 | Memory | 会话/长期记忆 |
| L8 | Observability & Evals（纵向rail） | LangSmith/Langfuse/Helicone；Promptfoo/DeepEval |
| L9 | Governance & Security（纵向rail） | 权限/审计/覆盖机制 |
评价： 9 层框架是 2026 年 Agent 系统架构的全面概览。尤其是 L8（Observability & Evals）和 L9（Governance）是 2025 年常被忽视、2026 年必须正视的层次。Evals as core engineering 是核心观点。
是否精读： 中——架构参考；建议结合 RAG Stack 2026 一起看
建议路径： papers/agents/ai-agent-stack-2026/
标签： Agent AI-Agent-Stack RAG MCP Observability Substack
六、分类标签汇总
database: PostgreSQL, MySQL, Vector-Database, Qdrant, Milvus, pgvector
backend: Database-Performance, Backend-Architecture, ORM
cloud-native: Kubernetes, Cloud-Native, Platform-Engineering, FinOps, Container-Orchestration
csdn: (本期无高价值 CSDN 条目)
reproduction: (本期无明确 reproduction 条目)
inference: vLLM, SGLang, TensorRT-LLM, NVIDIA-Dynamo, KV-Cache, LMCache
agents: AI-Agent-Stack, RAG, MCP, Observability
七、本次未写入说明
- 本期检索中 CSDN 无符合「高价值」标准（版本/命令/源码/复现/排障经验）的条目，已直接丢弃
- Substack 来源已利用（AI Agent Stack 2026, Distributed Systems Crash Course, 50 System Design Concepts）
- 今日 11:05 UTC 前已完成搜索，本轮无 GitHub 写入，只输出到此草稿
建议后续行动： 1. 精读 Inferenceengineering.tech 完整对比文章（benchmark 细节丰富） 2. 追踪 vLLM 0.21 TurboQuant 实际落地效果（benchmark 数据有限） 3. NVIDIA Dynamo 1.1 + vLLM 集成部署路径值得作为 K8s Inference Gateway 参考 4. AI Agent Stack L8 Evals 层可作为独立主题页更新