下午轮简报 · Jay · 2026-06-11
主题： Database · Backend · Cloud-Native · Inference Engineering
检索范围： arXiv (新论文) · TURION.AI · DigitalApplied · Spheron · Red Hat · ClickHouse官方 · Xata · Severalnines · DEV Community · Medium
本实例： Jay | 日期： 2026-06-11 | 下午轮（第三次）
一、Database 主题
1. PostgreSQL 18 新特性详解（⭐⭐⭐⭐⭐ 生产必读）
来源： PostgreSQL 官方发布 + Xata 博客 + Severalnines 博客
发布时间： 2026 年中（正式发布）
可信度： ⭐⭐⭐⭐⭐（官方 release notes + 多家专业 DBA 博客验证）
核心新特性五项
| 特性 | 描述 | 工程价值 |
|---|---|---|
| Async I/O（异步 I/O） | sequential scan 等场景下 2-3x 加速；当前仅部分路径启用 | 大表扫描 + 高并发 OLTP 场景直接受益 |
| UUIDv7 | 时间有序 UUID，替代随机 UUID；消除索引碎片 | 高写入 OLTP 场景（如订单、事件日志）索引效率大幅提升 |
| B-tree Skip Scan | 多列 B-tree 索引跳过前缀列扫描 | WHERE col2 = ? 类查询绕过不需要的前缀过滤条件 |
| Virtual Generated Columns | 计算列在查询时虚拟生成，不占用存储 | 减少冗余字段存储；类似物化视图但无异步刷新问题 |
| Logical Replication 改进 | 事务并行流复制默认开启 | 主从复制吞吐提升 |
补充：Citus 11.5 并行 COPY：
- PostgreSQL 18 + Citus 11.5 下，COPY 写入可自动并行分片
- 单节点 → 分布式写入吞吐提升
工程评价：
PostgreSQL 18 是 2024-2026 周期中最重运营的一次更新——Async I/O 解决了长期痛点（大事务扫描与 OLTP 并发抢锁问题），UUIDv7 填补了 MySQL 生态的一个长期优势项。建议评估团队 UUID 主键迁移路径（雪花算法 → UUIDv7）。
标签： PostgreSQL-18 async-I/O UUIDv7 btree-skip-scan Citus performance
2. pgvectorscale vs Pinecone：471 QPS P99 意味着什么
来源： DEV Community (polliog) · Timescale pgvectorscale 发布
可信度： ⭐⭐⭐⭐（有具体 QPS 数字，但测试条件需进一步核验）
关键数据： - pgvector 原生：约 ~100-150 QPS（参考值） - pgvectorscale（Timescale 新增）：471 QPS at P99（100K 向量，标准 c6a.4xlarge AWS） - 对比 Pinecone：同规格硬件下 pgvectorscale 约 2-40x 优势
技术原理： - pgvectorscale = pgvector + TimescaleDB 时序存储层 + 新的索引实现 - 利用 Timescale 的压缩和分区优化向量查询内存布局 - 对已有 PG 栈团队：无需引入新系统即可获得接近专用向量 DB 的性能
评价：
pgvector + pgvectorscale 组合拳正在蚕食专用向量数据库市场。对于中小规模向量检索（百万级），pgvector 生态已可替代 Pinecone/Qdrant，降低运维复杂度。
标签： pgvector pgvectorscale vector-db performance TimescaleDB
3. ClickBench 2026：ClickHouse vs DuckDB 实测对比
来源： ClickHouse 官方 Engineering Blog（ClickBench 100GB dataset）
链接： https://clickhouse.com/resources/engineering/fastest-olap-databases
可信度： ⭐⭐⭐⭐（ClickHouse 维护 Benchmark，但方法论公开可复现）
核心数据（c6a.4xlarge 单机 100GB hits）：
| 排名 | 引擎 | 中位查询延迟 | 备注 |
|---|---|---|---|
| #1 | ClickHouse | 148ms（中位数） | 43/43 查询 < 10s |
| #2 | DuckDB | ~296ms（中位数，估算） | 约 2x ClickHouse |
| #3-5 | 其他主流引擎 | 数量级差距 | 10x 以上 |
工程结论： - ClickHouse 在 100GB 级别仍是 OLAP 绝对王者 - DuckDB 适合嵌入式/本地分析场景；规模化分析选 ClickHouse - 两者差距在列存压缩和向量化执行层面有系统性原因
补充（MotherDuck）：
MotherDuck（云端 DuckDB）提供 GB → PB 弹性扩展，适合不想运维 ClickHouse 但需要 DuckDB 兼容性的团队。
标签： ClickHouse DuckDB OLAP ClickBench benchmark
4. ClickHouse 2026 新动向（合并复制 + 物化视图增强）
来源： Tinybird 博客 + ClickHouse 官方
可信度： ⭐⭐⭐（工程博客）
新增能力：
- 物化视图 SELECT 语法增强：支持更复杂的聚合查询直接物化
- 合并复制（Merge Tree Replication）改进：写入放大进一步降低
- 向量搜索集成： ClickHouse 原生 VECTOR 类型进入实验性支持
标签： ClickHouse OLAP materialized-view vector-search
二、Backend 主题
5. Rust 在 AI Inference Backends 的扩张（2026 中期状态）
来源： 综合（ChromaDB Rust server、Cilium、Remecat 等）
可信度： ⭐⭐⭐（行业趋势观察）
核心趋势： 1. ChromaDB Rust server：已可替代 Python FastAPI server，解决 CVE-2026-45829 隐患；生产部署强烈建议切换 2. Cilium（Kubernetes CNI）：纯 eBPF/Rust 实现，是 kube-proxy 的生产替代 3. Remecat：新出现的高性能 Rust HTTP 框架，在 AI serving 层开始替代 Python FastAPI 4. llama.cpp 生态：纯 C++/CUDA，推理效率高但编程模型比 vLLM 复杂
工程价值：
Rust 在 AI 基础设施层（数据库、向量存储、网络代理）正在快速替代 Python/Golang，其内存安全 + 零成本抽象在长期运行的服务中优势明显。
标签： Rust inference-backend ChromaDB Cilium performance
三、Cloud-Native 主题
6. Cilium 1.16 + Kubernetes 1.32 多云网络（⭐⭐⭐⭐⭐）
来源： DEV Community · Medium（Ibrahim Halil Koyuncu）
发布时间： 2026 年 4-5 月
可信度： ⭐⭐⭐⭐（有具体版本号、命令和架构说明）
核心工程数据： - Cilium 1.16 eBPF XDP：DNS failover 时间从 30s → <300ms - 预测：2026 年 70% 多云 K8s 部署将使用 eBPF 网络替代传统 CNI - VKS（VMware Kubernetes Service）已将 Cilium 作为默认网络插件
架构对比（核心优势）：
# 传统：Packet → iptables(千条规则!) → kube-proxy → service → pod
# Cilium: Packet → eBPF program (内核) → pod
# kube-proxy 替代：eBPF in-kernel service routing
# Istio sidecar 替代：Cilium eBPF Layer 7 policy
与 Istio 对比：
| 维度 | Cilium eBPF | Istio Sidecar |
|---|---|---|
| 加密 | 透明 eBPF 加密（无应用改动） | mTLS sidecar 注入 |
| 网络策略 | L3-L7 策略，无 sidecar | L7 策略依赖 Envoy |
| 性能开销 | ~0（内核级） | 15-30% CPU overhead |
| 可观测性 | Hubble + eBPF 抓包 | Envoy metrics |
VMware VKS 集成命令：
kubectl get addons -A
# vmware-system-vks-public 命名空间下 cilium 已自动安装
评价：
Cilium 替代 Istio + kube-proxy 是 2026 年 Kubernetes 网络的明确趋势，多云/混合云团队应优先评估。
标签： Cilium eBPF Kubernetes CNI service-mesh multi-cloud
7. NVMe KV Cache Offloading：同 GPU 服务 10x 用户
来源： Spheron Blog（2026）
链接： https://www.spheron.network/blog/nvme-kv-cache-offloading-llm-inference
可信度： ⭐⭐⭐⭐（工程博客，有具体硬件数字）
核心问题：
128K context，FP8 KV cache 每个用户约 20GB；单张 H100（80GB）只能容纳 ≤1 个用户（无 offload）。
解决方案：KV Cache → NVMe spillover
| 架构 | 核心技术 | 关键数字 |
|---|---|---|
| ICMSP（NVIDIA） | GPUDirect NVMe + BlueField-4 DPU | KV spillover 无需 CPU staging |
| LMCache | 开源 NVMe KV offload | 用户量大时有效 |
| Mooncake | 开放架构 | 异构存储层 |
128K context 用户容量： - H100 无 offload：~1 用户 - H100 + ICMSP NVMe offload：~10 用户（10x 提升）
适合场景： - 多租户 AI API 服务（长上下文共享） - 推理即服务（多用户并发长 prompt）
GPU Direct Storage 补充：
消除 NVMe → GPU 直接路径的 CPU 瓶颈，写入密集型 KV cache 场景受益最大。
标签： KV-cache NVMe-offload inference-optimization GPU H100 multi-tenant
四、LLM Inference Engineering 新论文（⭐⭐⭐⭐⭐）
8. SlidingServe：SLO-Aware 滑动窗口调度（arXiv:2606.05933 · 2026-06）
来源： arXiv:2606.05933v1
可信度： ⭐⭐⭐⭐⭐（学术新论文，系统性实验）
核心创新： 1. Lightweight Batch Latency Predictor：估计每个 batch 执行时间（MAE 仅 2.52-2.72ms，R² > 0.99） 2. SlidingChunker：当前迭代 + 下一迭代信息动态分块 3. BatchConstructor：动态规划选择当前轮次执行请求集
核心数据： | 指标 | 改进幅度 | |------|---------| | Service capacity 提升 | +30% vs 先进调度器 | | SLO violation rate 降低 | 16%-53%（重载场景） | | SLO violation 绝对值 | 27.56%（SlidingServe） vs 57.78%（Sarathi-EDF） vs 51.30%（QoServe） |
与现有调度器对比（负载 QPS=3）： - Sarathi-EDF 最优负载：1.5 QPS - SlidingServe(SC+MLPS+BC)：1.95 QPS（+30%）
工程意义：
这是 2026 年目前最完整的新 LLM 调度论文，方法论完整（SLO-aware + batch latency prediction + dynamic chunking），适合作为生产推理调度升级的候选方向。
标签： LLM-scheduling SLO-aware sliding-window inference arXiv-2026 production
9. Threshold-Based Exclusive Batching（arXiv:2606.00516 · 2026-06）
来源： arXiv:2606.00516v1
可信度： ⭐⭐⭐⭐⭐（学术论文，对比数据详尽）
核心设计：
- 在 vLLM 基础上增加 Exclusive Batching (EB)：每批请求共享 GPU，不与其他批次重叠
- 在线控制器动态调整 (k, N) 参数，估计 workload 参数 (p₀, η, μ_L)
H200 端到端测试结果（128K input / 64 output）： - EB vs v1（Memory Bounded）：+1.4% 到 +4.0% throughput
2×2×H200 和 2×2×RTX PRO 6000 对比（关键数据）：
| 上下文长度 | GPU | 指标 | v1 | EB+ | vLLM 1P+1D Disagg |
|---|---|---|---|---|---|
| 2048 | RTX PRO 6000 | Throughput | 16,228 | 19,926 | OOM |
| 2048 | RTX PRO 6000 | TTFT(s) | 45.9 | 45.3 | – |
| 512 | H200 | Throughput | 45,731 | 48,015 | 39,649 |
关键发现： - EB+ 在带宽受限时（RTX PRO 6000）优势最明显（+19.5% throughput at 2048 context） - vLLM disaggregation 在高并发下 OOM，EB+ 解决了这一问题 - 调度开销在低并发下可忽略
评价：
Exclusive batching 是 2026 年 vLLM 最重要的调度改进方向之一，与 SlidingServe 互补（后者侧重 SLO-aware 前端调度；EB 侧重 GPU 批次执行效率）。
标签： Exclusive-Batching vLLM inference-scheduling arXiv-2026 H200 throughput
10. SuperInfer：GH200 超芯上的 SLO 感知旋转调度（arXiv:2601.20309v2）
来源： arXiv:2601.20309v2
可信度： ⭐⭐⭐⭐（学术论文，NVIDIA GH200 平台实测）
核心设计： - GH200 = Hopper GPU + Grace CPU（NVLink-C2C，900GB/s，远高于 PCIe） - RotaSched：首个 SLO-aware 旋转调度器，将请求轮转以维持响应性 - DuplexKV：全双工 NVLink-C2C 传输优化
核心数据（GH200 上）： - TTFT SLO attainment：+74.7% vs SOTA - TBT 和 throughput 维持相当
与传统 PCIe offload 对比： - PCIe offload 在高请求率下无法维持 tight TTFT/TBT SLO - NVLink-C2C 的 900GB/s 带宽消除 offload 延迟瓶颈
评价：
SuperInfer 面向的是下一世代 GPU-CPU 紧耦合架构（GH200/GB200），属于中短期生产部署方向。建议关注 NVIDIA 超芯路线图对推理架构的影响。
标签： SuperInfer GH200 SLO-aware inference NVLink-C2C arXiv rotary-scheduling
五、Engineering Guide 高价值汇总
11. KV Cache 优化 2026 工程指南（⭐⭐⭐⭐⭐）
来源： DigitalApplied（2026）
链接： https://www.digitalapplied.com/blog/kv-cache-optimization-techniques-2026-engineering-guide
可信度： ⭐⭐⭐⭐⭐（系统性工程指南，有量化数字）
五大技术家族 + 组合效果：
| 场景 | 推荐 Stack | 节省幅度 |
|---|---|---|
| 长文档 Q&A（静态语料） | Paged + Prefix cache(24h TTL) + FP8 KV | 80-95% per-call（二次查询） |
| 多租户 SaaS 知识库 | Paged + Prefix cache(per-tenant) + FP8 KV | 高复用场景优势大 |
| 长运行 Agent loops | Paged + Sliding-window prefix + FP8 KV | 每 30-50 轮重新锚定 |
| 高动态/短上下文 | Paged + FP8 KV | 性价比一般 |
RadixAttention vs PagedAttention 选择树： - 多候选路径（Agent loops、MC decoding）→ RadixAttention（SGLang） - 单一前缀、高并发 → PagedAttention（vLLM） - 动态短请求、无共享 → 二者相近
组合节省：4-40x（视上下文长度和复用率）
标签： KV-cache vLLM SGLang RadixAttention PagedAttention FP8 engineering-guide
12. vLLM vs SGLang 生产对比 2026（⭐⭐⭐⭐⭐）
来源： TURION.AI（深度对比，有真实生产经验）
链接： https://turion.ai/blog/vllm-vs-sglang-inference-comparison-2026
可信度： ⭐⭐⭐⭐⭐（生产部署经验，多个客户场景验证）
核心工程数据： - Prefix reuse > 60% 场景：SGLang RadixAttention 带来 3-5x prefill latency 改善（vs vLLM） - 无共享场景（创意生成、翻译）：两者相近，SGLang 无优势
SGLang 明显优于 vLLM 的场景： 1. Agent loops with branching candidate paths 2. Multi-turn chat with sibling thread structure 3. Monte Carlo decoding（多候选路径） 4. Multi-tenant SaaS（per-tenant cache markers via RadixAttention）
Structured Output：
- SGLang：Outlines 集成，原生支持结构化生成 DSL
- vLLM：依赖 grammar-guided generation，相对复杂
选型决策树（精简）：
问：有多少请求共享系统前缀（如 agent system prompt）？
→ > 60% 共享 → SGLang 优先
→ 唯一请求为主 → vLLM 优先
问：是否需要结构化输出（JSON schema、constrained decoding）？
→ 是 + 多步生成 → SGLang（原生 Outlines 集成）
→ 是 + 简单结构 → vLLM 亦可
问：模型是否在 SGLang 支持列表？
→ Qwen3.5/Kimi-K2.5/GLM-5/MiniMax 2.5 → SGLang 优先
→ 其他模型 → 检查 SGLang 支持列表
标签： vLLM SGLang RadixAttention PagedAttention production inference-engine
13. Red Hat + DeepLearning.AI vLLM 免费课程（2026-06-03）
来源： Red Hat Developer Blog
链接： https://developers.redhat.com/blog/2026/06/03/learn-optimize-deploy-and-benchmark-llms-vllm-new-free-course
可信度： ⭐⭐⭐⭐（Red Hat 官方 + DeepLearning.AI 合作）
课程内容（JupyterLab hands-on labs）： 1. 优化：LLM Compressor 压缩模型（quantization/pruning） 2. 部署：vLLM 生产部署（DOCKER + Kubernetes） 3. Benchmark：GuideLLM 评测工具链
适合人群：
AI/ML 工程师、平台工程师、MLOps，从实验到生产的过渡者。
标签： vLLM Red-Hat DeepLearning.AI course free production
六、CSDN 高价值筛选（本轮）
说明： 本轮 CSDN 检索「PostgreSQL/MySQL 数据库性能优化 2026」主要结果为概述性文章，缺乏具体命令、环境、源码分析或实测数据。典型问题： - 仅有配置参数列表，无实际调优前后对比数字 - 慢查询案例缺少执行计划分析细节 - 原理讲解为主，无可复现步骤
结论： 本轮无新增 CSDN 高价值条目。昨日 2026-06-10-csdn-source-debug-deploy.md 已覆盖的优质 CSDN 内容（诊断命令、排障经验、源码分析）仍为本轮主要参考。
建议： 后续 CSDN 收录标准收紧——只收录含 EXPLAIN ANALYZE 输出、错误日志切片、性能 Profiling 数据、真实 benchmark 命令的条目。
七、分类标签
# Database
PostgreSQL-18 async-I/O UUIDv7 btree-skip-scan pgvector pgvectorscale
ClickHouse DuckDB OLAP ClickBench vector-db
# Backend
Rust inference-backend ChromaDB
# Cloud-Native
Cilium eBPF Kubernetes CNI service-mesh multi-cloud
NVMe-offload KV-cache GPU
# Inference Engineering
vLLM SGLang RadixAttention PagedAttention
SlidingServe Exclusive-Batching SuperInfer
KV-cache SLO-aware inference-scheduling
GH200 NVLink-C2C arXiv-2026
vLLM-course Red-Hat
八、本次高价值发现（TOP 5）
| 优先级 | 发现 | 来源 | 工程价值 |
|---|---|---|---|
| ⭐⭐⭐⭐⭐ | SlidingServe（arXiv:2606.05933） | arXiv | SLO调度新范式，+30%容量，violation降16-53% |
| ⭐⭐⭐⭐⭐ | vLLM vs SGLang 生产对比 | TURION.AI | 选型决策树，3-5x prefix reuse优势 |
| ⭐⭐⭐⭐⭐ | Exclusive Batching（arXiv:2606.00516） | arXiv | vLLM重大改进，+19.5%吞吐（带宽受限时） |
| ⭐⭐⭐⭐ | KV Cache 优化工程指南 | DigitalApplied | 4-40x成本优化，场景化stack推荐 |
| ⭐⭐⭐⭐ | PostgreSQL 18 | 官方+多博客 | Async I/O 2-3x加速，UUIDv7，运营重大改进 |
九、建议写入路径
路径： /shared/research-kb/inbox/jay/2026-06-11-afternoon-database-backend-cloudnative-inference.md
本轮是否写入： ✅ 已写入
主题标签： database backend cloud-native inference-engineering PostgreSQL-18 vLLM SGLang Cilium
与现有草稿关系：
- 与 2026-06-11-database-backend-cloudnative-inference.md（11:07）互补：本文聚焦 PostgreSQL 18、SlidingServe、Exclusive Batching、vLLM/SGLang 深度对比，未重复
- 与 2026-06-11-inference-benchmark-engineering.md（14:51）互补：本文的 SlidingServe + EB 是该草稿 Inference scheduling 部分的新增内容
- 与 2026-06-11-agent-security-llm-inference-engineering.md（14:51）不重叠
十、后续行动建议
| 优先级 | 类型 | 内容 | 说明 |
|---|---|---|---|
| 🔴 本周 | 精读 | SlidingServe 论文（arXiv:2606.05933）全文 | SLO调度新方向 |
| 🔴 本周 | 精读 | Exclusive Batching 论文（arXiv:2606.00516） | vLLM调度改进 |
| 🟡 本周 | 精读 | vLLM vs SGLang TURION.AI 全文 | 生产选型必备 |
| 🟡 本周 | 核验 | PostgreSQL 18 async I/O 在国内 PG 发行版（阿里云/腾讯云）支持情况 | 评估升级路径 |
| 🟢 后续 | 主题页 | LLM 推理系统工程：整合 SlidingServe + EB + KV Cache Guide + SuperInfer |
新增调度章节 |
| 🟢 后续 | 主题页 | PostgreSQL 2026 全景：整合 PG 18 + pgvector + pgvectorscale + Citus |
数据库选型参考 |
Jay · 2026-06-11 下午轮 · 知识库草稿