知识库简报 · Jay · 2026-09-16 第3次（15:05 SGT）
基本信息
- 实例： Jay
- 执行时间： 2026-09-16 15:05 SGT（07:05 UTC）
- 本轮主题： Database · Backend · Cloud-Native · CSDN · Reproduction 工程笔记
- 检索来源： Tavily（向量数据库基准 / Mooncake 生态 / Kubernetes GPU 调度 / KTransformers / Substack）
- 去重依据： 今日 08:00、09:37、11:05、12:20、13:35、14:50 草稿
📦 Database
⭐ 高价值：2026 向量数据库基准数据（1M向量 / 1536维 / Q1 2026）
来源：Salt Technologies AI | VectorDBBench 开源项目 数据背景：标准化测试条件——1M向量×1536维（OpenAI ada-002），AWS r6g.xlarge 自托管，P50/p99 查询延迟，QPS 吞吐量，2026年2月更新
核心性能数据：
| 数据库 | P50 延迟 | P99 延迟 | QPS（1M向量） | 开源协议 | 备注 |
|---|---|---|---|---|---|
| Qdrant | 4ms | ~6ms | ~1200+ | Apache 2.0 | Rust+SIMD，延迟最低 |
| Milvus（GPU） | 6ms | 12-18ms | ~550 | Apache 2.0 | 8种索引算法含GPU加速 |
| Pinecone Serverless | 8ms（热）/ 20-30ms（冷） | 10-15ms（热）/ 40-80ms（冷） | — | 商业 | 零运维，冷查询有毛刺 |
| Weaviate Cloud | 50-70ms | 100-150ms | — | BSL | 自托管显著更快 |
| pgvector | 基准较差 | 基准较差 | 规模 >10M 时垫底 | PostgreSQL | 生态集成好，非专用向量场景首选 |
Qdrant vs Milvus 详细对比（F22 Labs 实测）： - 插入时间：Qdrant 41.27s vs Milvus（GPU）~0.6s（索引分离设计） - 查询延迟：Qdrant 94.52ms vs Milvus 250.01ms（2.6x差距） - QPS：Qdrant 4.70 vs Milvus 未给出 - Qdrant 优势：Rust 资源占用稳定，无内存峰值；支持 JSON 嵌套过滤、地理位置过滤 - Qdrant 弱点：>10M向量规模后性能下降明显；50M向量@90%召回率仅 41.47 QPS vs pgvectorscale 471 QPS
Qdrant 混合搜索代码示例：
from qdrant_client import QdrantClient, models
results = client.query_points(
collection_name="documents",
prefetch=[
models.Prefetch(query=dense_vector, using="dense", limit=20),
models.Prefetch(
query=SparseVector(indices=sparse_indices, values=sparse_values),
using="sparse", limit=20,
),
],
query=models.FusionQuery(fusion=models.Fusion.RRF),
limit=10,
)
评价：向量数据库选型在 2026 年已基本收敛——Qdrant 在延迟敏感的自托管场景领先，Milvus 在 billion-scale 企业场景领先，Pinecone 在零运维需求场景首选。50M向量规模是 Qdrant 的软肋，需提前评估规模路径。
标签：database vector-db benchmark Qdrant Milvus performance
链接：
- https://www.salttechno.ai/datasets/vector-database-performance-benchmark-2026（CSV 可下载，CC BY 4.0）
- https://www.f22labs.com/blogs/qdrant-vs-milvus-which-vector-database-should-you-choose
- https://github.com/zilliz/VectorDBBench（开源基准工具，MIT）
建议行动：更新「向量数据库选型」知识库页；补充 Qdrant 50M规模性能边界说明
数据库架构趋势：Hybrid DB + 向量一体化
来源：综合（Milvus 2.6 内置 BM25 / SingleStore / Weaviate）
重要趋势：2026 年纯向量数据库正在被混合型数据库侵蚀： - Milvus 2.6：内置 BM25 全文搜索，实测比 Elasticsearch 同等硬件吞吐量高 400%，可将 Elasticsearch + 向量库双系统栈合并为单次部署 - SingleStore：向量 HNSW/IVF + JSON + 时序 + 全文 + 空间 + KV，SQL 统一查询，Apache Iceberg 集成（2025年） - Weaviate：multi-tenancy 原生 + 合规隔离，Claude Code / VOYAGER 等生产验证
评价：混合搜索（dense+sparse+关系过滤）已从加分项变成 RAG 生产的必要条件。选型时应优先评估 metadata 过滤复杂度，而非单纯比较向量召回率。
标签：database hybrid-search Milvus SingleStore Weaviate
建议行动：RAG 系统评估应将"metadata 过滤能力"纳入一等评估标准
⚙️ Backend
⭐ 高价值：Mooncake × vLLM 深度集成（2026年里程碑汇总）
来源：Mooncake 官方 Changelog | vLLM Blog（2026-05-06）| llm-d Blog 核心定位：Mooncake 是 KVCache 分发引擎，解决 PD（Prefill-Decode）分离架构中跨节点 KVCache 传输的瓶颈
2026年集成里程碑时间线：
| 日期 | 事件 | 工程意义 |
|---|---|---|
| 2026-08-20 | Miles 集成 Mooncake 作为 rollout 数据传输后端 | RL 训练与推理解耦 |
| 2026-08-17 | Speculators 集成，支持多节点在线训练，RDMA 传输 hidden-state | vLLM worker ↔ trainer 直接 RDMA，零巨大存储 |
| 2026-07-28 | NVIDIA Dynamo 1.0 GA，支持 Mooncake Transfer Engine | PD 分离进入 NVIDIA 官方参考架构 |
| 2026-05-07 | vLLM 正式集成 Mooncake Store | 核心里程碑——生产级 PD 分离落地 |
| 2026-02-25 | SGLang 合并 Encoder Global Cache Manager，支持 Mooncake 全局多模态 embedding 缓存 | ViT embedding 跨实例共享，避免 GPU 重复计算 |
| 2026-02-24 | vLLM-Omni 支持 disaggregated inference 连接器（MooncakeStoreConnector + MooncakeTransferEngineConnector） | 多节点 omni-modality pipeline |
| 2026-02-12 | Mooncake 正式加入 PyTorch 生态 | 主流框架互操作保障 |
| 2026-01-28 | FlexKV（Tencent × NVIDIA）支持 Mooncake Transfer Engine | 分布式 KVCache reuse |
vLLM × Mooncake 集成架构要点（vLLM Blog 2026-05-06）：
- Mooncake clients 运行在 GPU 节点，管理本地 CPU/DRAM/SSD 资源
- 节点间通过 RDMA 直连形成分布式 KVCache 池
- 连接器角色：
- Scheduler 侧：新请求到达时，vLLM 对 prompt token blocks 做 hash，查 Mooncake master 获取匹配的 KVCache blocks，指导调度
- RDMA I/O：所有 RDMA 操作在独立后台 I/O 线程执行，不阻塞主 CPU 路径（避免延迟 GPU kernel 启动）
- MultiConnector：支持 MultiConnector 接口链式组合多个子连接器，天然支持 PD 分离
NIXL × PD Connector（llm-d）：
- NixlConnector 是 vLLM disaggregated serving 架构中的 KVCache 传输连接器
- Pull-based 模型：decode worker（D）通过 one-sided RDMA p2p READ 直接从 prefill worker（P）的 GPU 内存拉取 KVCache blocks
- 支持 UCCL / UCX / Mooncake 三个 NIXL transport 后端
- 在 100G RoCE / 400G InfiniBand / 100G TCP 上评测，结果显示 Mooncake 在 RDMA 环境下延迟最优
跨数据中心 KVCache 展望（arXiv 2604.15039v1）： - 当前 PD 分离局限于单数据中心 + RDMA 级别网络 - 未来方向：异构加速器（compute-dense 用于 prefill，bandwidth-optimized 用于 decode） - 硬件路线图已在往这个方向演进
评价：Mooncake 在 2026 年已成为 PD 分离的事实标准，从 DeepSeek（Kimi）内部系统演化为横跨 vLLM / SGLang / NVIDIA Dynamo / PyTorch 的开放生态。关键工程贡献是将 KVCache 从"推理的副产物"提升为"一等系统资源"。
标签：backend LLM-inference Mooncake PD-disaggregation RDMA vLLM SGLang
链接：
- https://vllm.ai/blog/2026-05-06-mooncake-store
- https://kvcache-ai.github.io/Mooncake
- https://llm-d.ai/blog/networking-for-distributed-inference-llm-d
- https://arxiv.org/html/2604.15039v1
建议行动：精读 vLLM Mooncake Store 博客；将 PD 分离架构纳入推理引擎选型 SOP
⭐ 高价值：KTransformers v0.7 更新（2026-08，异构推理 + LoRA SFT）
来源：GitHub kvcache-ai/ktransformers | CSDN 报道 核心定位：CPU-GPU 异构推理框架，专注超大 MoE 模型低成本部署
v0.7 关键更新（2026-08）： 1. AVX512 x86 CPU 支持：LoRA SFT 不再依赖 AMX，可在兼容 AVX512 的 AMD 服务器上运行（不再强制要求 Intel AMX） 2. 原生 Block-FP8 LoRA 微调：可直接加载 checkpoint 中的 FP8 Routed Expert 权重，无需生成完整 BF16 权重副本（节省显存） 3. MoE 端到端 BF16 全量微调：支持保存完整 checkpoint（PR #2094，2026-07-23） 4. MoE 微调 Cookbook 发布（2026-08-25）：覆盖硬件检查、环境安装、BF16/FP8/INT8 配置、LoRA/全量微调、资源规划、故障排查
性能数据：
| 模型 | 硬件 | 总吞吐量 | 输出吞吐量（8路并发） |
|---|---|---|---|
| DeepSeek-R1-0528（FP8） | 8×L20 + Xeon Gold 6454S | 227.85 tokens/s | 87.58 tokens/s |
| Kimi-K2-1TB（单卡消费级 GPU+CPU） | RTX 4090 + CPU | — | 仅需单卡 |
与 SGLang 集成（2025-10-10）： - 架构合入 SGLang 同一分支 - 用户安装 SGLang + KTransformers CPU 内核后，一条命令启动服务 - 适合资源受限环境：消费级 GPU+CPU 即可跑万亿参数 MoE
评价：KTransformers 解决了 MoE 模型在有限 GPU 显存下的部署难题。v0.7 的 AVX512 松绑了 Intel 硬件绑定，AMD 服务器也能跑 LoRA SFT，对国内算力环境（大量 AMD EPYC）有直接价值。FP8 LoRA 微调省显存的工程意义重大——千亿 MoE 全量微调从"需要 H100×8"降到"消费级 GPU 起"。
标签：backend inference-engineering KTransformers MoE heterogeneous fine-tuning
链接：
- https://github.com/kvcache-ai/ktransformers/blob/main/README_ZH.md
- https://blog.csdn.net/2600_95884800/article/details/164117098
建议行动：评估 KTransformers + SGLang 集成在国产 GPU 硬件（昇腾、壁仞）上的可行性
☁️ Cloud-Native
⭐ 高价值：Kubernetes GPU 编排 2026——DRA / KAI Scheduler / Grove / HAMi 全景
来源：Spheron Blog | CloudOptimo | Premai | HAMi Docs | MLflow | CAST AI 核心判断：2026 年 Kubernetes GPU 调度已进入"DRA + 拓扑感知 + Gang 调度"三合一时代
1. NVIDIA DRA → CNCF（KubeCon EU 2026）
关键事件：NVIDIA 在 KubeCon EU 2026 将 Dynamic Resource Allocation（DRA）驱动捐赠给 CNCF - 这替代了接近 10 年历史的旧 NVIDIA Device Plugin 体系 - DRA 的核心优势：将 GPU 拓扑信息通过 NVML 库直接从硬件读取，MIG partition 作为 first-class 资源声明
DRA + MIG 配置示例：
# 通过 ResourceClaimTemplate 请求特定 MIG profile
resources:
limits:
nvidia.com/mig-1g.10gb: 1 # A100/H100 MIG 分区
2. KAI Scheduler（Kubernetes AI Scheduler）
定位：专门为 AI 训练/推理 workload 设计的调度器，增强 Kubernetes 默认调度器 - Gang scheduling：保证分布式训练 job 所有 worker 同时启动（避免死锁） - 拓扑感知调度：考虑 NVLink / PCIe / NUMA 拓扑，将 pod 放在最优节点 - 与 Volcano / YuniKorn 互补，后者更多用于批处理队列管理
3. Grove（NVIDIA 官方 K8s 推理声明式 API）
定位：NVIDIA 捐赠的声明式 K8s API，管理推理 workload
- 引入 CRD：PodCliqueSet、PodClique、PodCliqueScalingGroup、ClusterTopology、PodGang
- 处理：gang scheduling、startup ordering、拓扑感知 placement、自动扩缩容
- 与 DRA 深度集成
KubeCon NA 2026 预告：11月9-12日，Salt Lake City，预期有 DRA/Grove 生产案例大规模披露
4. HAMi（CNCF Incubating）——多厂商 GPU 调度
更新：HAMi v2.9.0 支持 Kunlunxin（昆仑芯）P800 拓扑感知调度 - Kunlunxin P800 支持 1/2/4/8 卡分配，不跨 NUMA - 已在 KubeCon China 2026（9月7-9日，上海）亮相
HAMi vs Device Plugin 对比： | 特性 | NVIDIA Device Plugin | HAMi | |------|-------------------|------| | 多厂商 GPU | 仅 NVIDIA | NVIDIA / AMD / 华为昇腾 / 昆仑芯 / 寒武纪 | | GPU 共享 | MIG / time-slicing | 原生 vGPU 份额切分 | | 拓扑感知 | 基础 | 多厂商支持 | | CNCF 状态 | 独立项目 | Incubating |
5. 生产 Kubernetes LLM 推理关键配置
拓扑感知调度（NUMA + GPU 共置）：
# kubelet 配置
topologyManagerPolicy: single-numa-node
topologyManagerScope: pod
GPU Operator（v25.10.1）：一键式 GPU 发现、MIG 分区、time-slicing；GPU Feature Discovery 自动打标签（GPU型号/显存/CUDA版本）
HPA 基于自定义指标（2026年 GA）：
# Gateway API Inference Extension（v1.3.1，2026-02 GA）
# 支持按 model name 路由 + KV-cache 感知调度 + 按模型名 A/B 流量分发
Autoscaling 指标演进： - 旧：CPU / 内存 - 2024：队列深度（queue depth） - 2026：KV cache 利用率（直接反映 GPU 显存压力）
GPU 利用率真相（CAST AI 2026 报告）： - 生产 K8s 集群平均 GPU 利用率：5% - 最好集群（136节点 H200）：49% - 大部分团队在为空闲容量付费，而非有用工作
NVLink 拓扑带宽层级（H200 NVL 8卡节点）： | 层级 | 互联方式 | 带宽 | |------|---------|------| | Tier 1 | NVLink | ~337 GB/s | | Tier 2 | PCIe + UPI | ~50 GB/s | | Tier 3 | RoCE | ~35 GB/s |
配置 topologySpreadConstraints 将 pod 放在同一 NVLink 域，可降低 3-5x GPU 通信延迟。
评价：Kubernetes 在 2026 年已从"容器编排工具"演化为"AI 基础设施控制平面"。DRA 捐赠 CNCF 是一个分水岭事件，意味着 GPU 调度 API 标准化正式启动。平台团队应关注 DRA + KAI Scheduler + Grove 的组合如何影响现有 GPU 调度脚本和 operator 设计。
标签：cloud-native kubernetes GPU-scheduling DRA HAMi Grove KAI-Scheduler topology-aware
链接：
- https://www.spheron.network/blog/kubernetes-gpu-orchestration-2026
- https://www.cloudoptimo.com/blog/kubernetes-ai-infrastructure-in-2026-gpu-scheduling-and-production-realities
- https://www.premai.io/blog/deploying-llms-on-kubernetes-vllm-ray-serve-gpu-scheduling-guide-2026
- https://project-hami.io/docs/next/userguide/kunlunxin-device/enable-kunlunxin-schedule
- https://cast.ai/blog/llm-inference-cost-optimization
建议行动：
1. 评估 DRA 替代 Device Plugin 的迁移路径（KubeCon EU 2026 后应有关方指南）
2. 对照 CAST AI 报告估算团队 GPU 实际利用率
3. 关注 Kunlunxin / 昇腾等国产 GPU 与 HAMi 的集成成熟度
📄 CSDN
本轮无新增主动 CSDN 检索
说明：本轮检索重点在数据库架构、推理后端和 Kubernetes 编排。CSDN 高价值内容已在上轮（2026-09-16T0820、T1220）完整覆盖，包括： - Qwen3.6-35B-A3B 三框架部署对比 - Kimi K2.6 / K2.7-Code 部署指南 - MCP × A2A × AG-UI 协议栈现状 - KTransformers 异构推理深度解析
本轮补充一条 CSDN 来源（来自 KTransformers GitHub 页面中文翻译项目）： - KTransformers v0.7 Cookbook：BF16/FP8/INT8 配置对比、LoRA/全量微调资源规划、AVX512 兼容性检查步骤——中文高价值内容
标签：csdn KTransformers fine-tuning
链接：https://blog.csdn.net/2600_95884800/article/details/164117098
🔬 Reproduction / Engineering Notes
⭐ 高价值：向量数据库完整基准规格（可直接复现）
来源：Salt Technologies AI VectorDBBench | F22 Labs 复现规格：
硬件环境：
CPU: AMD EPYC 或等效 x86_64
实例: AWS r6g.xlarge (4 vCPU, 32 GB RAM)
存储: SSD（数据库标准测试用）
测试参数：
向量规模: 1,000,000 条
维度: 1536 维（OpenAI text-embedding-ada-002）
批量插入: batch size = 100
延迟测量: p50 / p99，单次查询
过滤基准: metadata filter，10 个不同过滤值
工具：VectorDBBench（GitHub 开源，MIT License，Python） - 支持 Milvus / Zilliz Cloud / Qdrant / Weaviate / Pinecone 等 - 可用自定义数据集测试 - 下载：https://github.com/zilliz/VectorDBBench
可信度：高——标准化方法论，CSV 数据可下载，有 2026 Q1 版本追踪
标签：reproduction vector-db benchmark benchmark-spec
建议行动：建议将 VectorDBBench 作为团队向量数据库选型标准化工具；建立测试 SOP
⭐ 高价值：Kubernetes LLM 推理完整部署命令集
来源：Premai Blog（2026）| 验证版本：vLLM v0.17.0 / Ray 2.54.0
部署栈： - vLLM + Ray Serve - Kubernetes + NVIDIA GPU Operator v25.10.1 - Autoscaling：KEDA + 自定义指标（queue depth / KV cache 利用率） - 监控：Prometheus + Grafana - 模型版本管理：KServe InferenceService
关键命令片段：
# MIG 生产多租户配置
resources:
limits:
nvidia.com/mig-1g.10gb: 1
# Time-slicing 开发测试配置
apiVersion: v1
kind: ConfigMap
metadata:
name: time-slicing-config
data:
any: |-
version: 1
sharing:
timeSlicing:
resources:
- name: nvidia.com/gpu
replicas: 4
# 拓扑感知调度
topologyManagerPolicy: single-numa-node
topologyManagerScope: pod
# KServe InferenceService 示例
apiVersion: serving.kserve.io/v1beta1
kind: InferenceService
metadata:
name: vllm-llama-serve
spec:
predictor:
model:
modelFormat:
name: vLLM
runtime: vllm
Gateway API Inference Extension（GA 2026-02，v1.3.1）： - 支持按 model name 路由（A/B 测试） - KV-cache 感知调度 - 流量按模型名自动分发
可信度：高——具体版本号、Helm 命令、YAML 示例，可直接参考
标签：reproduction kubernetes vLLM GPU-scheduling deployment
链接：https://www.premai.io/blog/deploying-llms-on-kubernetes-vllm-ray-serve-gpu-scheduling-guide-2026
GitHub Trending 关注
来源：GitHub Topics - gpu-scheduling（2026-09 排序）
| 项目 | Stars | 类型 | 备注 |
|---|---|---|---|
| HAMi | 高 | CNCF Sandbox | 多厂商 GPU 共享 |
| Volcano | 高 | 批调度 | 拓扑感知 / gang scheduling |
| KubeRay | 高 | 分布式训练 | Ray + Kubernetes |
| SoftMig | 56 | SLURM GPU 切片 | NVIDIA MIG memory limit + time-slicing |
| PipelineScheduler | 12 | 批推理 | 时空调度减少共置干扰 |
| ld-singh/ai-factory-ops-lab | 16 | 工程实践 | K8s GPU 调度 / HAMi / Slurm / vLLm 观测 |
标签：reproduction github gpu-scheduling kubernetes
🏷️ 本轮分类标签总览
#database #vector-db #Qdrant #Milvus
#benchmark #hybrid-search #SingleStore #Weaviate
#backend #Mooncake #PD-disaggregation
#RDMA #vLLM #SGLang #KTransformers
#MoE #heterogeneous #fine-tuning
#cloud-native #kubernetes #DRA #HAMi
#Grove #KAI-Scheduler #GPU-scheduling
#topology-aware #autoscaling #KubeRay
#reproduction #benchmark-spec #deployment
#csdn #KTransformers
📋 建议后续行动
| 优先级 | 行动 | 关联主题 |
|---|---|---|
| P0 | 更新「向量数据库选型 2026」主题页，纳入 Qdrant/Milvus 规模边界数据 | #database #vector-db |
| P0 | 将 VectorDBBench 建立为团队标准选型工具 | #reproduction #benchmark-spec |
| P1 | 精读 vLLM Mooncake Store 博客（2026-05-06） | #backend #Mooncake #vLLM |
| P1 | 评估 DRA 替代 Device Plugin 迁移路径（KubeCon EU 2026 后） | #cloud-native #kubernetes #DRA |
| P1 | KTransformers v0.7 AVX512 + FP8 LoRA 国产算力验证 | #backend #KTransformers #MoE |
| P2 | 整理 PD 分离架构知识库专题（Mooncake + llm-d NIXL） | #backend #PD-disaggregation |
| P2 | 对照 CAST AI 报告估算团队 GPU 实际利用率基线 | #cloud-native #kubernetes |
📝 本轮写入文件
主草稿：/shared/research-kb/inbox/jay/2026-09-16T1505-jay-five-category-briefing.md
本轮新增独立草稿路径建议：
- /shared/research-kb/inbox/jay/2026-09-16-mooncake-pd-disaggregation-2026.md（P1，Mooncake 生态全景）
- /shared/research-kb/inbox/jay/2026-09-16-k8s-gpu-orchestration-2026.md（P1，DRA/HAMi/Grove 全景）
Jay · 第3次（15:05 SGT）· 2026-09-16 | 累计今日已产出 18 份草稿 | 实例：Jay