知识库草稿 · Jay · 2026-07-09 18:00

本次主题

CNCF llm-d Sandbox 入场 · K8s v1.36 AI-native 新特性 · Trendshift.io 新兴 GitHub AI 项目

一、llm-d：CNCF Sandbox 新成员（2026-03-24 正式入场）

背景： 2026年3月24日 KubeCon EU（阿姆斯特丹），IBM Research、Red Hat、Google Cloud 联合将 llm-d 捐赠给 CNCF 并进入 Sandbox 阶段。创始合作方包括 NVIDIA、CoreWeave、AMD、Cisco、Hugging Face、Intel、Lambda、Mistral AI。

核心价值定位： 解决 Kubernetes 原生环境中分布式 LLM 推理的标准化问题——填补 KServe（高层控制面）与 vLLM/SGLang（底层推理引擎）之间的中间层空白。

四大核心组件（截至 2026-06）： 1. Endpoint Picker（EPP）：基于 prompt prefix hash 的缓存感知路由，最大化 KV Cache 命中率，多租户 SaaS 场景下系统提示共享时效果显著 2. Disaggregated Serving（预解码分离）：将 prefill 和 decode 阶段部署到独立 GPU 池，解决单块 vLLM 在高并发 decode 时 prefill GPU 饱和问题 3. Tiered KV Cache：分级缓存策略，分离热/冷数据 4. Accelerator Topology Awareness：感知 GPU peer-to-peer 链路和 NIXL fabric 网络拓扑，将请求路由到满足延迟目标且成本最低的硬件组合

InferencePool CRD 示例（缓存感知路由）：

apiVersion: inference.networking.x-k8s.io/v1alpha2
kind: InferencePool
metadata:
  name: llm-pool
  namespace: llm-serving
spec:
  targetPortNumber: 8000
  selector:
    app: vllm-llm-d
  endpointPickerConfig:
    extensionRef:
      name: llm-d-epp
      group: ""
      kind: Service

llm-d vs 其他方案的对比： - vs NVIDIA Dynamo：Dynamo 是独立编排层（运行在 vLLM 上方，不依赖 K8s）；llm-d 是 K8s 原生公民，使用标准 CRD 和 Gateway API Inference Extension - vs 传统 K8s Service 路由：默认 round-robin 无法感知推理状态（prompt 长度、缓存局部性、模型阶段），导致放置低效、缓存碎片化、高负载下延迟不可预测

"Well-Lit Paths"哲学： 提供经过真实负载验证的生产级部署配方（benchmarked recipes），而非让平台团队自行拼装黑箱。

可信度： 高 — CNCF 官方公告，Linux Foundation 中立治理，多厂商背书 建议分类： kubernetes / inference-engineering / cncf / distributed-serving 后续行动： 建议纳入 AI 原生基础设施主题页；与 disaggregated inference 论文对比（如有）

二、Kubernetes v1.36 AI 原生特性（2026-05）

来源： openEuler 社区 · CSDN · 2026-05-29

三大 GA（正式可用）特性：

2.1 动态资源分配（DRA）正式 GA

• AI 算力调度新标准：GPU 资源不再是静态分配，可动态调整
• 与 vLLM/SGLang 等推理引擎的资源弹性需求直接对应
• 解决多租户 GPU 集群中碎片化问题

2.2 用户命名空间（User Namespaces）正式 GA

• 容器安全的终极防线：user namespace 将容器内 UID/GID 映射到主机，隔离更强
• 对 AI 安全推理场景（如多租户 LLM 服务）有直接价值

2.3 PodGroup API 解耦（调度状态与工作负载定义分离）

• 支持分布式训练 gang scheduling（minMember 字段保证所有 Pod 同时调度）
• 支持 AI 训练优先级抢占（preemptible: true）
• 配合 PriorityClass 实现生产级训练 PodGroup 配置：

apiVersion: scheduling.k8s.io/v1alpha1
kind: PodGroup
metadata:
  name: pytorch-training-job
spec:
  minMember: 8
  scheduleTimeoutSeconds: 300
  priorityClassName: high-priority-ai

• 推理侧价值：冷启动优化（Pod 预热、PodGroup 优先级调度）

KCD Beijing + vLLM 2026（2026-03-21，北京）： 云原生社区 × 大模型推理社区联合共建，K8s 作为 AI 基础设施事实标准的进一步确认。

可信度： 高 — K8s v1.36 官方特性，CSDN openEuler 社区翻译验证 建议分类： kubernetes / ai-native / inference-engineering 后续行动： 建议纳入 K8s AI 基础设施主题页，与 llm-d 条目联动

三、Trendshift.io 新兴 GitHub AI 项目速览（2026-07）

来源： trendshift.io/rss/feed

3.1 OfficeCLI（addyosmani/agent-skills 相关生态）

• 首个专为 AI Agent 构建的 Office 套件：读取、编辑、自动化 Word/Excel/PowerPoint 文件
• 标签：AI agent / MCP / document-processing
• 工程价值： AI Agent 办公自动化落地路径具体

3.2 TencentDB-Agent-Memory

• Agent 持久记忆层，标签：AI agent / AI memory
• 工程价值： 多会话 Agent 记忆管理，与 AutoMem（今日下午 arXiv 条目）可互为参考

3.3 Agentic RAG 相关 GitHub 项目（2026 新兴）

• 关键词覆盖：agentic-rag / multi-agentic / MCP
• 趋势：MCP（Model Context Protocol）作为 Agent 工具调用标准件持续火热

四、2026 推理引擎格局快拍（今日综合）

关键更新（TGI 已进入维护模式）： - HuggingFace TGI 于 2025 年 12 月进入维护模式，新部署建议用 vLLM 或 SGLang - HuggingFace Inference Endpoints 现在默认 vLLM，SGLang 为替代选项

vLLM vs SGLang 选型参考（2026-07）： | 维度 | vLLM | SGLang | |------|------|--------| | 核心创新 | PagedAttention（KV Cache 分块管理）| RadixAttention（前缀复用优化）| | 优势场景 | 通用高吞吐、多 GPU 扩展 | 前缀密集型（RAG、多轮对话、结构化输出）| | 生态 | 更大（2000+ 贡献者、每日 10+ 新 issue）| 更小但聚焦 | | 生产就绪度 | ✅ 极高 | ✅ 成熟 |

新进入者： - Modular MAX（Mojo 内核，图编译）：在密集模型高并发场景下超越 vLLM - llama.cpp：CPU/边缘推理事实标准

可信度： 高 — 多方 benchmark 文章（TechSy、Spheron、Deploybase）交叉验证 建议分类： inference-engineering / vllm / sglang / benchmark

本次输出摘要

建议写入路径： /shared/research-kb/inbox/jay/2026-07-09-cncf-llm-d-k8s-inference-roundup.md 是否需要精读： llm-d 架构文档值得精读；K8s v1.36 DRA GA 细节可查阅官方 CHANGELOG 主题页更新建议： AI 原生基础设施（K8s + LLM 推理）、分布式推理架构（llm-d）