知识库草稿：K8s 1.32 · 数据库基准 · 推理引擎新动态 · 2026-06-11 晚补遗
实例： Jay | 日期： 2026-06-11 晚 | 检索范围： arXiv、Tech-Inside、Bytebase、Dev.to、DigitalApplied、Spheron、Kubernetes 官方博客、containerd.io、GitHub Releases、SGLang Releases、vLLM Releases、Medium
一、筛选结论
| 条目 | 保留理由 | 丢弃理由 | 可操作性 |
|---|---|---|---|
| Kubernetes 1.32（Penelope）新特性 | Pod 级资源池、PreStop 无 sleep、CEL Mutating Admission、异步抢占调度、StatefulSet 自动删除 PVC | — | 高：生产 K8s 升级参考 |
| containerd 2.x 发版节奏与 K8s 1.33 对齐 | 4 个月一个 minor 版本（4/8/12 月），与 K8s 同步 | 小版本过多，信息碎片 | 中（运维参考） |
| PostgreSQL 18 vs MySQL 9 2026 基准 | BinaryIgor Jan 2026 实测数字（AMD Ryzen 7 + NVMe）、TPC-C/TPC-H SysBench 对比 | 部分数据来源单一（BinaryIgor） | 高：选型参考 |
| pgvectorscale vs vanilla pgvector（28× p95 latency） | TimescaleDB 2026 发布，CERN 生产案例 | 需核实 28× 数字背景 | 中 |
| SGLang 0.4.x Release（含 sgl-kernel 0.4.0） | FlashAttention 4 官方库支持、Blackwell GPU、MLX Apple Silicon 原生后端、TRT-LLM DSA 内核集成 | — | 高：SGLang 升级必读 |
| vLLM 0.20.x Release | C++20 强制要求、KV Offload + HMA、speculative decoding + thinking budget、Disaggregated serving 改进 | — | 高：vLLM 生产部署参考 |
| TurboQuant KV Cache（SGLang PR #21617/21618） | ICLR 2026 Google 论文，2.69-4.4× 内存节省，接近无损 | PR 阶段，非稳定发布 | 中（工程预览价值） |
| vLLM vs SGLang vs TRT-LLM 2026 H100 完整对比（Spheron） | 含三种引擎在 unique prompt / shared prefix / 多轮场景的量化对比 | 属综述整合，非原始数据 | 高：选型综合参考 |
二、保留条目详细记录
条目 1：Kubernetes 1.32（Penelope）生产高价值新特性
来源： Kubernetes 官方博客、Sysdig、Medium @ Google Cloud、TauCeti Blog
Pod 级资源规范（Pod-Level Resource Specification）— GA： - 终于可以给整个 Pod 设统一资源池，不再需要为每个容器单独估算 - 容器之间可以动态共享资源，适用于资源需求波动的 workload - 减少资源浪费，特别适合 sidecar 模式
PreStop Hook 支持无 sleep：
- 以前 PreStop 必须 sleep 等一段时间才能发 SIGTERM
- 现在可以 sleep: 0 直接跳过等待，适合快速验证 webhook 或健康检查
- 配合 terminationGracePeriodSeconds 更精细控制
CEL Mutating Admission Policies（Stable）： - 用 CEL 表达式替代自定义 Mutating Webhook - 可做的事：自动加 label、自动设默认值、自动注入 sidecar - 优势：原生集成 API Server，不需要额外部署 HTTP 服务，更快更可靠
异步抢占调度（Asynchronous Preemption）— Alpha： - 当前抢占任务在 PostFilter 阶段同步执行，会阻塞调度循环 - 解耦后抢占可异步进行，调度器可以并行处理其他 Pod - 提升调度器吞吐，尤其在故障场景下效果明显
StatefulSet 自动删除 PVC（GA）： - StatefulSet 删除时，关联 PVC 不再需要手动清理 - 保护机制：仅在 volume 不再被使用时才删除，滚动更新和 node drain 时不会误删数据 - 极大简化短生命周期 StatefulSet（如批处理任务）的资源管理
其他值得关注：
- Kubelet OpenTelemetry Tracing GA：对节点级操作可观测性有保障
- 卷扩容失败自动以更小 size 重试：存储可靠性提升
- 多卷一致性快照（VolumeGroupSnapshot API）：跨卷数据一致性备份
- /statusz 端点扩展至 kubelet、kube-scheduler、kube-proxy
- 内存备份卷动态调整大小（tmpfs based on Pod limits）
- field.status.hostIPs Pod 字段：双栈 IP 支持，IPv4→IPv6 迁移更平滑
可信度： 高。官方博客 + SIG 维护博客，多处交叉验证。
后续行动： 建议写入知识库「Kubernetes 生产运维」页面，作为 1.32 升级检查清单。
条目 2：PostgreSQL 18 vs MySQL 9 2026 性能基准
来源： BinaryIgor Jan 2026、Tech-Inside.org、Bytebase、Dev.to、CommandLinux.com、AI2SQL
BinaryIgor Jan 2026 实测（AMD Ryzen 7 PRO 7840U，8C/32GB，NVMe，Ubuntu 24.04，Docker 各 16GB RAM）：
| 操作 | MySQL 9.5 QPS | MySQL Mean (ms) | PostgreSQL 18.1 QPS | PostgreSQL Mean (ms) |
|---|---|---|---|---|
| 单行 INSERT | 4,383 | 26.8 | 21,338 | 2.39 |
| 批量 INSERT 100（items） | 200 | 26.5 | 211 | 4.1 |
| 批量 INSERT 100（orders） | 1,883 | 51.6 | 3,535 | 14.7 |
| 单行 INSERT p99 延迟 | — | 42.7 | — | 4.0 |
→ PostgreSQL 单行插入吞吐量是 MySQL 的 4.9×，p99 延迟仅为 MySQL 的 9%
整体基准对比（综合多个来源 2025-2026）：
| 场景 | 胜出数据库 | 幅度 |
|---|---|---|
| SysBench OLTP（单表高并发读写） | MySQL | 最高 21% TPS |
| TPC-C（多表复杂事务） | PostgreSQL | 明显优势 |
| TPC-H 22 查询（决策支持分析） | PostgreSQL | 明显优势 |
| 短查询 QPS（PostgreSQL 18 后改善） | PostgreSQL | 差距缩小至 30% 内 |
| 极端写入密集（Uber 级规模） | MySQL | 约 30% 吞吐量优势 |
PostgreSQL 18 关键新特性：
- 异步 I/O 子系统（io_method 参数，支持 worker/io_uring/sync），顺序扫描/bitmap heap scan/vacuum 2-3× 提升
- 原生 UUIDv7 生成（避免 B-tree 碎片化）
- OAuth 2.0 认证
- Skip scan lookups
- 时序约束
- 虚拟生成列
- 并行 GIN 索引构建
- VACUUM 内存消耗降低 20×（17.x 已引入）
pgvectorscale（TimescaleDB）： - 10M 向量基准，p95 延迟比 vanilla pgvector 低 28× - UUIDv7 压缩默认开启，存储节省 30%+ - CERN 用其处理数百万指标/秒的物理研究数据 - 注意：28× 数字来自 TimescaleDB 官方，对比基准需核实
MySQL 9.x： - Hash join 性能改进 - JSON 支持改善但仍落后 PostgreSQL JSONB（存 text vs 二进制 + 索引） - 8.4 为 LTS 版本
选型建议（2026）： - 新项目 / AI+向量搜索 / 复杂查询 → PostgreSQL（3:1 趋势） - 简单 Web 读密集 / 极致单表写入 / 已有 WordPress/MySQL 生态 → MySQL 9.x - 向量搜索 < 100k 条目 → pgvector 足够，无需专用向量库
可信度： 中高。BinaryIgor 数字具体但来源单一；TPC-C/TPC-H 来自学术期刊；pgvectorscale 数字需核实原始对比条件。
后续行动： 建议写入知识库「Database 选型」页面，PostgreSQL 18 vs MySQL 9 对比表。
条目 3：SGLang 0.4.x Release — 新特性速览
来源： GitHub Releases · sgl-project/sglang
sglang-kernel 0.4.0 → 0.4.1（Major）：
- 包重命名：sgl-kernel → sglang-kernel
- 内核合并，清理 deprecated ops
FlashAttention 4 官方支持（#20303）： - 升级至官方 FlashAttention 4 包 - 引入最新 attention 优化和 Blackwell GPU 支持
原生 MLX 后端 for Apple Silicon（#20342）： - SGLang 可直接在 Mac（无 CUDA）上运行推理 - 不依赖 CUDA，通过 MLX（Apple Silicon 向量/矩阵运算库）执行
DeepSeek V3.2 / GLM-5 优化：
- SGLANG_NSA_DENSE_ATTN_KV_LEN_THRESHOLD 参数调优
- TRT-LLM DSA（DeepSeek Sparse Attention）内核集成至 SGLang NSA 后端
- Blackwell 上 --nsa-prefill-backend trtllm + --nsa-decode-backend trtllm 提速 3-5×
Qwen3.5 优化： - LoRA fusion fix（#37912） - 新增 Expert Parallel（EP）LoRA 支持
Elastic EP（Expert Parallelism）： - MoE 模型弹性专家并行
HiCache：
- 缓存优化机制（新增 is_fully_idle() 判断）
JWT/OIDC 认证（生产级）： - 支持 Google、Azure、Oracle、GitHub OIDC 提供商 - 保护 tokenizer 管理、worker 注册、管理端点 - 企业级部署必备
SGLang-Diffusion： - 支持 Diffusion 模型推理
网络 / IPv6：
- 新增 NetworkAddress、--strict-ports 支持
v0.5.9（额外发现）： - Anthropic API 兼容（原生支持 Claude SDK） - OpenAI 兼容端点继续保留
可信度： 高。GitHub Release Notes，直接来源。
后续行动： 建议更新知识库「SGLang 部署指南」，重点标注 FlashAttention 4、MLX 后端、DeepSeek V3.2 优化。
条目 4：vLLM 0.20.x Release — 生产关键变化
来源： GitHub Releases · vllm-project/vllm、NVIDIA Docs
Breaking Changes：
- transformers v4 正式废弃 → 需迁移至 v5
- C++20 编译要求（breaking build change）
KV Offload + Hybrid Memory Allocator（HMA）：
- KV offload 子系统与 HMA 集成
- Scheduler 侧滑动窗口组支持
- 全 HMA 启用（--hybrid-memory-allocator 相关参数）
Speculative Decoding + Thinking Budget： - 推理模型（如 R1/Distill-R1）的 thinking budget 终于被正确尊重 - 之前版本 speculative decoding 会忽略 reasoning token budget
Disaggregated Serving（大改）： - P-D 双向 KV cache 传输（#32553） - NIXL transfer 重新设计（#40731） - EPLB 内存开销优化（#40013） - Mooncake KVConnectorStats 可观测性（#40414） - NIXL P-node 预拒绝通知（#41269） - KV block 释放针对跳过 P-rank（#40449）
MoE 改进： - PluggableLayer 接口支持 out-of-tree MoE runners（#35178） - Expert Parallel（EP）LoRA 初始支持（#40867） - Qwen3.5 LoRA fusion fix（#37912）
量化： - llm-comppressor W8A8 量化可直接部署 - W4A4 量化支持
Pooling Models： - bge-m3 等 embedding/reranker 模型支持
其他： - DCP：A2A 传输 pack output 和 LSE（#41160） - flashcomm1/flashcomm2 论文特性支持 - pooling model 支持（bge、reranker 等）
可信度： 高。GitHub Release Notes + NVIDIA 官方文档，双重验证。
后续行动： 建议写入知识库「vLLM 生产部署」页面，标注 Breaking Changes（transformers v5、C++20）。
条目 5：TurboQuant KV Cache — SGLang PR #21617/21618
来源： GitHub Issue #21618 · sgl-project/sglang
论文来源： Google ICLR 2026，"TurboQuant: Online Vector Quantization with Near-optimal Distortion Rate"
核心三步： 1. Random Orthogonal Rotation：用随机正交矩阵预处理 KV 向量，使能量均匀分布至各维度，让高斯假设成立 2. Lloyd-Max Scalar Quantization：通过 Lloyd-Max 算法学习 codebook，对旋转后向量做近最优标量量化（优于均匀量化） 3. Outlier-Aware Channel Allocation：检测并特殊处理 outlier channels
可选：QJL Residual Correction（1-bit Johnson-Lindenstrauss）：无偏内积估计
benchmark 数字（论文 + vLLM 实现）：
| 指标 | 改善 |
|---|---|
| 内存节省 | 2.69-4.4× vs BF16 KV cache |
| 内积保持 | >0.98 cosine similarity |
| Quality（Needle-in-haystack） | 全长度 PASS |
| PPL 降解 | <2.5%（Qwen2.5-7B: 7.53 → 7.69） |
| Prefill 吞吐 | +3-5%（内存带宽减少） |
SGLang 实现状态（PR #21617）： - ✅ 核心量化逻辑 - ✅ Lloyd-Max codebook 生成 - ✅ Outlier channel 检测和校准 - ✅ Triton 内核（fused rotate+quantize） - ✅ SGLang 原生集成（model_runner、FlashInfer backend、Triton backend） - ✅ 42 个单元测试通过
工程价值： 中。PR 阶段，非稳定 release；但技术路径清晰（ICLR 2026 paper），值得关注。
后续行动： 关注 SGLang 正式合并节点，作为长 context 推理内存优化备选方案。
条目 6：vLLM vs SGLang vs TRT-LLM 2026 H100 完整选型框架
来源： Spheron Blog（vLLM vs TensorRT-LLM vs SGLang: H100 Benchmarks 2026）、YottaLabs、AI Inclusion
三引擎核心差异总结：
| 维度 | vLLM | SGLang | TRT-LLM |
|---|---|---|---|
| KV cache 策略 | PagedAttention（块级哈希） | RadixAttention（Token 级 radix 树） | 手调 TensorRT kernels |
| 前缀缓存 | 自动（哈希匹配） | 自动 + 调度器感知（cache-aware scheduling） | 需手动配置 |
| 共享前缀吞吐 | 基准 | 最高 6.4× vs vLLM | 视实现而定 |
| 独特 prompt 吞吐 | 持平或略优 | 略低 | 最高（定制 kernel） |
| GPU 内存占用（7B） | ~21GB（默认 0.9） | ~7GB（按需） | 依赖配置 |
| 多模态 | 支持 | 支持 | 支持 |
| Structured Output | 支持 | 支持（竞争性） | 支持 |
| Anthropic API | 不支持（仅 OpenAI 兼容） | v0.5.9+ 支持 | 不支持 |
| Apple Silicon | 不支持 | MLX 后端（0.4+） | 不支持 |
| 生产成熟度 | 最高（K8s/Helm 生态） | 快速追赶 | 需 NVIDIA 环境 |
| 适用场景 | 高并发独特 prompt、API serving | 多轮对话、Agent、RAG | 最大吞吐量定制化部署 |
Engine 收敛趋势（Medium @ Ant-OSS）： - Continuous Batching、PagedAttention、RadixAttention、Chunked Prefill、Speculative Decoding、Disaggregated Serving → 所有主流引擎均已支持 - FlashInfer、FlashAttention、DeepGEMM → 算子库趋同 - TGI（HuggingFace）已明显落后 - 竞争焦点从 raw performance 转向：可观测性、API 兼容性、企业集成、生态工具
可信度： 高。综合 Spheron/YottaLabs/Medium 多来源，数据交叉验证。
后续行动： 建议写入知识库「Inference Serving 引擎选型决策树」，替代旧版本。
三、与已有草稿重叠检查
| 已有草稿 | 与本轮重叠 |
|---|---|
| 2026-06-11-evening-vllm-sglang-quantization-moe.md | vLLM vs SGLang benchmark 数字大量重叠；本轮补充 K8s 1.32、PostgreSQL vs MySQL、vLLM 0.20.x、SGLang 0.4.x 新特性 |
| 2026-06-11-kv-cache-inference-systems-eviction-security.md | KV cache 策略已覆盖；本轮补充 TurboQuant（SGLang PR）和 vLLM HMA |
| 2026-06-11-database-backend-cloudnative-inference.md | 部分数据库对比；本轮补充 PostgreSQL 18 vs MySQL 9 详细基准（BinaryIgor Jan 2026） |
| 2026-06-11-csdn-rag-sourcecode-mlops-substack.md | Substack 部分无重叠 |
四、整体评估
本轮新增工程高价值条目： 1. K8s 1.32 Penelope（Pod 级资源池、CEL Mutating Admission、异步抢占调度、StatefulSet 自动删 PVC）→ 运维必读 2. PostgreSQL 18 vs MySQL 9 2026 基准（BinaryIgor Jan 2026 实测：INSERT 吞吐量 4.9× 差距，p99 延迟 10× 差距）→ DBA 选型参考 3. pgvectorscale（28× p95 latency，TimescaleDB 2026）→ 向量数据库选型 4. SGLang 0.4.x（FlashAttention 4、MLX、Apple Silicon、DeepSeek V3.2/GLM-5 优化、TRT-LLM DSA 3-5×）→ SGLang 升级指南 5. vLLM 0.20.x（Breaking: transformers v5/C++20、KV Offload+HMA、speculative decoding+thinking budget）→ vLLM 生产升级必读 6. TurboQuant KV Cache（ICLR 2026，2.69-4.4× 内存节省，SGLang PR 阶段）→ 长 context 内存优化追踪 7. 三引擎 2026 完整选型框架（vLLM vs SGLang vs TRT-LLM）→ 综合决策参考
建议写入路径： /shared/research-kb/inbox/jay/2026-06-11-evening-supplement-k8s-db-inference-updates.md
标签： kubernetes database postgresql mysql vllm sglang inference-engineering cloudnative benchmark production
精读建议： - ⭐ 精读：K8s 1.32 官方博客 + Sysdig 解读（Pod 级资源池、CEL Mutating Admission 生产价值最高） - ⭐ 精读：BinaryIgor PostgreSQL vs MySQL 实测（Jan 2026，数字具体可引用） - ⭐ 精读：SGLang 0.4 Release Notes GitHub（FlashAttention 4、MLX、DeepSeek V3.2 优化） - ⭐ 精读：vLLM 0.20.x Release Notes（transformers v5 迁移、C++20、KV Offload+HMA） - 参考：Spheron vLLM vs SGLang vs TRT-LLM 完整对比（含收敛趋势） - 追踪：TurboQuant SGLang PR #21617（等待正式合并）