KServe LLMInferenceService

1. 调研缘由

传统模型服务资源难以表达多节点并行、前后处理分离和缓存感知路由。KServe 的 LLMInferenceService（LLMISVC）把复杂拓扑变成可复用的 Kubernetes 声明。[S1]

2. 简介与产品工作流

LLMInferenceService 是 KServe 面向大语言模型的自定义资源。使用者声明模型与所需配置，控制器组合工作负载、路由和调度；平台团队可预置 LLMInferenceServiceConfig，应用团队引用后覆盖少量字段。[S1]

3. 团队与时间背景

它属于 KServe 开源项目。官方在 2026 年 3 月 13 日发布 v0.17，并将 LLMInferenceService 描述为从实验能力提升到面向生产的 CRD；本文以这一版本作为近三年的时间锚点。[S2]

4. 技术基础与生态位

该 CRD 建立在 llm-d 架构之上，可表达 Gateway API 接入、智能调度、多种并行、多节点工作负载以及 prefill/decode 分离。[S1] 它是控制面抽象，底层仍要选择推理容器、网络和加速资源。

5. 开放边界与部署

服务可以组合多份基础配置并覆盖需要的字段。[S1] 这便于平台提供受管模板，但也让生效配置难以凭单个 YAML 判断，因此要保留合成结果和版本。

落地前需安装控制器与依赖，并确认 Gateway、存储和 GPU 已准备。简单服务不必立即迁移。

6. 公开评价与主要分歧

**正面评价：**大型推理模式进入 Kubernetes 控制面，便于权限、模板和变更审查。[S1][S2] **主要分歧：**抽象不自动降低延迟，也会扩大维护面。

7. 同类对比

相比直接维护 Deployment 和路由规则，LLMISVC 提供统一声明；相比普通 InferenceService，它覆盖复杂推理拓扑，但要跟踪 CRD 与版本。

8. 适用场景与验收

适合已标准化 Kubernetes、需要多 GPU 或多节点推理的组织。验收先部署固定模型，检查资源是否按声明生成，再测试扩缩容、升级、路由故障和配置覆盖；记录首 token 延迟、吞吐、GPU 利用率与失败率。

9. 归纳洞察 ★

LLMInferenceService 把大模型推理拓扑提升为平台 API，并不承诺引擎一定更快。组织已有 Kubernetes 能力并治理模板、依赖和版本时，它才会减少重复劳动。

10. 来源与更新时间

• 信息截至(as_of): 2026-08-13