模型推理服务云原生后端微服务MLOps人工智能【免费下载链接】kserveStandardized Distributed Generative and Predictive AI Inference Platform for Scalable, Multi-Framework Deployment on Kubernetes项目地址https://gitcode.com/gh_mirrors/ks/kserve点击查看免费下载本文以仓库根目录下的 ROADMAP.md 为骨架结合 pkg/apis、config/runtimes、cmd/llmisvc 等源码与配置逐条解读 KServe 面向 2024-2025 年的技术路线如何围绕 Support GenAI inference 补齐 LLM 推理运行时、自动扩缩容、RAG/Agent 编排、LLM Gateway以及如何将核心推理能力、Python SDK、InferenceGraph 逐一推向 1.0 稳定版并同步推进安全加固与文档体系。读完本文你将能够对照路线图在仓库中找到每一项规划的落地载体与实现证据为选型、二次开发和贡献代码提供地图。一、路线图定位KServe 走向 GenAI 推理平台的关键一跃KServe 是一个运行在 Kubernetes 之上、面向分布式生成式Generative与预测式Predictive推理的标准化平台支持多框架、可扩展的模型部署。仓库根目录的 README.md 将其定位为 Standardized Distributed Generative and Predictive AI Inference Platform。ROADMAP.md 将 2024-2025 年的工作组织为6 个 Objective目标Support GenAI inference支持生成式 AI 推理——路线图的主线目标Graduate core inference capability to stable/GA核心推理能力走向稳定版Graduate KServe Python SDK to 1.0Python SDK 走向 1.0Graduate InferenceGraph推理图走向成熟Secure InferenceService加固推理服务安全KServe 1.0 documentation完善 1.0 文档体系。其中前 5 项都是工程能力建设最后一项则是为整个平台发布 1.0 版本所做的文档配套。下文逐条展开并在每个目标下给出当前仓库中已有的实现载体CRD、运行时、控制器、配置与测试作为路线图已开工/已落地的印证。二、Objective 1Support GenAI inference——让 KServe 全面拥抱 LLM这是整个路线图的核心目标细分为五个子方向LLM Serving Runtimes、LLM Autoscaling、LLM RAG/Agent Pipeline Orchestration、Open Inference Protocol 向 GenAI Task API 的扩展、以及 LLM Gateway。2.1 LLM Serving RuntimesvLLM、LoRA 与多主机多 GPU路线图对 LLM 推理运行时提出了四项具体工作支持基于 vLLM 运行时的投机解码Speculative Decoding支持 LoRA 适配器支持 TensorRT-LLM、TGI 等更多 LLM 运行时并提供基准对比支持多主机multi-host、多 GPU 推理运行时。从当前仓库看vLLM 运行时已经作为一等公民落地配置文件 config/runtimes/kserve-vllmserver.yaml 定义了名为kserve-vllmserver的 ServingRuntime通过标签serving.kserve.io/server-type: vllmserver标识镜像默认值占位为vllmserver:replace由isvcutils.UpdateImageTag在部署时替换启动入口指向vllm.entrypoints.openai.api_server并暴露VLLM_CONFIG_ROOT、VLLM_WORKER_MULTIPROC_METHOD等环境变量。仓库还提供了 config/runtimes/kserve-llm-sglang.yaml说明 LLM 运行时家族正在持续扩充。多主机、多 GPU的能力已经体现在 API 设计中pkg/apis/serving/v1beta1/predictor.go 中的WorkerSpec提供PipelineParallelSize流水线并行 worker 数同时决定 worker 集合的副本规模与TensorParallelSize每节点使用的 GPU 数表示跨 GPU 的张量并行度。配套的运行时示例见 config/runtimes/kserve-huggingfaceserver-multinode.yaml。LoRA 适配器方向仓库在v1alpha1的 LLM InferenceService 类型LLMInferenceService中提供了LoRA字段并在 pkg/apis/serving/v1alpha1/llm_inference_service_conversion.go 中通过注解internal.serving.kserve.io/lora-criticalities保存 LoRA 适配器的关键性criticality信息以在版本转换间无损传递对应的测试 llm_inference_service_conversion_test.go 验证了该注解的保留逻辑。可以推断后续 LoRA 的正式化方向是让适配器声明能力从 alpha API 进入稳定 API。2.2 LLM Autoscaling模型缓存与自定义指标扩缩容路线图在自动扩缩容方向的规划支持带自动 PV/PVC 供给的模型缓存Model Caching支持 ServingRuntime 的扩缩容设置支持基于自定义指标的扩缩容。模型缓存在仓库中已经形成了独立 CRD——LocalModelCachelocal model cache即本地模型缓存定义位于 pkg/apis/serving/v1alpha1/local_model_cache_types.go生命周期与状态条件LocalModelCacheReady实现在 pkg/apis/serving/v1alpha1/local_model_cache_lifecycle.go控制器位于 pkg/localmodelcache其中包含 pkg/localmodelcache 目录下的两个 Go 文件。缓存场景的使用文档与示例见 docs/samples/localmodelcache。可以推断该方向后续的演进重点是自动 PV/PVC 供给即由控制器依据缓存声明自动创建与回收存储卷而不是依赖管理员预先准备 PVC。基于自定义指标的扩缩容依赖外部指标源如 KEDA、HPA custom metrics。仓库在安装目录中提供了 KEDA 与 HPA 两种依赖安装脚本例如 install/v0.18.0/llmisvc-autoscaling-hpa-dependency-install.sh 与 install/v0.18.0/llmisvc-autoscaling-keda-dependency-install.sh说明 KServe 官方在发布物层面同时维护 HPA 与 KEDA 两条扩缩容链路通用扩缩容场景的用法可参考 docs/samples/autoscaling。2.3 LLM RAG/Agent Pipeline Orchestration用 InferenceGraph 编排声明式工作流路线图要求使用 KServe InferenceGraph 支持声明式 RAG/Agent 工作流。也就是说RAG 的检索—增强—生成流水线与 Agent 的多步调用将被建模为一张由路由节点router和步骤step组成的推理图而不是靠外部编排框架硬编码。仓库中的InferenceGraphCRD 定义于 pkg/apis/serving/v1alpha1/inference_graph.go其InferenceGraphSpec包含路由配置路由节点通过Steps []InferenceStepinference_graph.go声明下一跳目的地支持按流量权重分流等语义。Graph 的使用示例集中在 docs/samples/graph。结合 ROADMAP.md 中Graduate InferenceGraph目标可以推断InferenceGraph 在 2024-2025 年的定位已从简单流量图升级为RAG/Agent 工作流编排的底座。2.4 Open Inference Protocol 扩展到 GenAI Task API路线图在此方向提出两项工作将 Open Inference Protocol 扩展为面向 OpenAI schema 的社区维护协议仓库支持垂直化的 GenAI 任务 API如 embedding向量嵌入、Text-to-Image文生图、Text-To-Code文生码、Doc-To-Text文档转文本。这意味着 KServe 的数据面协议data plane不再只服务于传统预测式推理的v1/v2接口而是要向生成式任务的专用接口演进。仓库侧可以对照的现状是v2 预测协议KServe Predict Protocol v2的规范、protobuf 与配置文档位于 docs/predict-api/v2包含.md、.proto与.yaml文件是当前数据面协议的事实标准而 GenAI 任务 API 属于路线图中的增量规划仓库内尚处于规划阶段。2.5 LLM Gateway多提供商、限流、路由与可观测路线图对 LLM Gateway 提出四点规划支持多个 LLM 提供商providers支持基于 token 的限流rate limiting支持带流量整形traffic shaping、fallback、负载均衡的 LLM 路由器提供面向指标与成本报告的 Gateway 可观测性。仓库中已有专门的LLM 服务治理llmisvc组件承载这一方向控制器入口位于 cmd/llmisvc含 main.go 与迁移逻辑 migration.go运行时配置集中在 config/llmisvcconfig其中可以看到与 Gateway 能力一一对应的配置模板config-llm-router-route.yaml——路由规则config-llm-scheduler.yaml 与 config-llm-scheduler-eppconfig-default.yaml——调度与端点配置config-llm-tokenizer.yaml——token 相关配置config-llm-tracing.yaml——链路追踪可观测性config-llm-worker-data-parallel.yaml、config-llm-prefill-worker-data-parallel.yaml 与 config-llm-decode-worker-data-parallel.yaml——预填充/解码阶段的数据并行 worker 配置。从源码结构看llmisvc 同时包含 webhook 配置config/webhook/llmisvc、RBACconfig/rbac/llmisvc与完整的 CRDcharts/kserve-llmisvc-crd、config/crd/full其部署示例见 docs/samples/llmisvc。可以认为路线图中的多提供商支持、token 限流、LLM 路由器、成本指标是对现有 llmisvc 能力的深化与产品化。三、Objective 2把核心推理能力推向 stable/GA3.1 InferenceService 与 ServingRuntime CRD 升级到 v1路线图提出将InferenceService与ClusterServingRuntime/ServingRuntimeCRD 提升到v1版本。具体工作包括改进InferenceServiceCRD 的 REST/gRPC 协议接口改进模型存储接口弃用TrainedModelCRD并将多模型 co-hosting、draft model草稿模型、LoRA 适配器等能力并入InferenceService改进 predictor 与 transformer 容器共置collocation的 YAML 体验缩小RawDeployment与Serverless模式之间的功能差距。当前仓库中InferenceService的稳定 API 是v1beta1其核心类型定义在 pkg/apis/serving/v1beta1/inference_service.goInferenceServiceSpec与 pkg/apis/serving/v1beta1 目录下的组件类型predictor/transformer/explainer中而 LLM 相关的LLMInferenceService位于v1alpha1两者之间的双向转换逻辑正是 llm_inference_service_conversion.go 所承担的。CRD 的完整清单见 config/crd/full24 个 YAML与 minimal 版本 config/crd/minimal。多模型能力已经部分体现在 API 上predictor.go 中的PredictorSpec同时提供Model任意框架的模型 spec与StorageUris []StorageUri多存储地址列表每个StorageUri可指定uri与容器内挂载路径mountPath默认/mnt/models——这正是 co-hosting 多模型与 LoRA 适配器挂载所需的字段基础。多模型服务ModelMesh 风格的使用手册见 docs/MULTIMODELSERVING_GUIDE.md。RawDeployment 与 Serverless 模式KServe 支持两种部署形态Route 层分别对接 Knative Serverless 与原生 Kubernetes 资源仓库在 docs/samples 下提供 rollout-strategydocs/samples/rollout-strategy等示例。路线图要求缩小两种模式的功能差距例如让RawDeployment也能获得流量切分、金丝雀发布等 Serverless 特性。3.2 Open Inference Protocolv2的深化为 v2 推理协议支持 batching批处理Transformer 与 Explainer 的 v2 协议互操作改进 v2 协议的 codec编解码器。仓库中 v2 协议栈已包含独立的批处理模块 pkg/batcher2 个 Go 文件实现了请求聚合/拆分的逻辑示例见 docs/samples/batcherv2 协议规范与 protobuf 定义在 docs/predict-api/v2。protocolVersion字段v1/v2/grpc-v1/grpc-v2定义于 predictor.go是各框架运行时统一遵循的协议开关。路线图此节的目标是让 v2 协议在批处理、组件互操作与编解码三个维度达到生产级成熟度。四、Objective 3Graduate KServe Python SDK to 1.0路线图对 Python SDK 提出三项工作创建标准化的模型打包 APImodel packaging API改进 KServe model server 的可观测性metrics 与分布式追踪支持批量推理batch inference。Python SDK 的主体位于 python/kserve约 428 个.py文件除核心推理与客户端库外还包含存储处理python/storage、各框架 server如 python/huggingfaceserver、python/autogluonserver 等与通用服务端实现。SDK 的安装与用法通过根目录的 python/pyproject.toml 管理。可观测性方面仓库在 Go 侧已有 pkg/metrics指标注册与 pkg/tracing分布式追踪注入Python server 侧则通过 pkg/oteljson 与 docs/otel-json-stdout.md 所描述的 OTel JSON 输出协议向标准输出暴露追踪数据。可以推断模型打包 API将把训练产物 → KServe 可部署模型的转换过程标准化而批量推理能力会与 v2 协议的 batching 形成呼应。五、Objective 4Graduate InferenceGraph路线图对InferenceGraph的成熟化提出六项工作改进InferenceGraphspec 的副本replica与并发concurrency控制支持分布式追踪为InferenceGraph支持 gRPC为InferenceGraph提供独立的Transformer支持支持流量镜像traffic mirroring节点改进InferenceGraph的RawDeployment模式。InferenceGraphCRD 的结构pkg/apis/serving/v1alpha1/inference_graph.go目前已支持多步骤、按权重分流的声明式图追踪能力可以复用 pkg/tracing 的 OpenTelemetry 注入机制。这些规划表明InferenceGraph 的目标是成为生产可用的编排原语——支持并发控制、gRPC 入口、可插入 transformer 预处理以及灰度级的流量镜像从而承担上一节提到的 RAG/Agent 工作流编排职责。六、Objective 5Secure InferenceService文档化 KServe ServiceMesh 的 mTLS 配置支持程序化认证令牌programmatic authentication token实现服务级per service认证支持 SPIFFE/SPIRE 身份与InferenceService的集成。仓库当前的 webhook 与认证基础设施包括webhook 配置目录 config/webhookmanifests、service 与 CA 注入补丁如 config/default/isvc_mutatingwebhook_cainjection_patch.yaml、RBAC 目录 config/rbac以及 TLS 相关工具包 pkg/tls。OpenShift 环境下的 ServiceMesh / cert-manager / serverless 配置示例见 docs/openshift含 networkpolicies.yaml 与 service-mesh 子目录。可以推断mTLS 文档化与 SPIFFE/SPIRE 集成将复用并扩展 pkg/tls 与 webhook 注入链路而服务级认证则需要在InferenceService上暴露独立的认证配置字段。七、Objective 6KServe 1.0 documentation补充 ModelMesh 文档并说明经典 KServe 与 ModelMesh 各自的使用场景统一数据面 v1 与 v2 页面的格式改进 v2 数据面文档讲清楚为什么变、变了什么清理仓库中的示例与官网建立单一事实来源single source of truth更新过时文档保持全站一致性与连贯性。这一目标对应仓库文档基础设施的现状根目录有 docs 目录含 v1beta1 API 文档 docs/apis/v1beta1、开发者指南 docs/DEVELOPER_GUIDE.md、清单指南 docs/MANIFESTS_GUIDE.md、多模型服务指南 docs/MULTIMODELSERVING_GUIDE.md 与 OpenShift 指南 docs/OPENSHIFT_GUIDE.md示例集中存放在 docs/samplesv1beta1 示例约 219 个文件另外仓库同时维护 Helm Chartscharts与 Kustomize 清单config两者的一致性通过 hack/validate-manifests.sh 等脚本校验。可以推断单一事实来源的落地方式是让 docs 下的示例与官网、Chart 模板如 charts/kserve-resources、charts/kserve-crd指向同一份内容并借助 verify-doc-links.py 之类的工具持续校验链接有效性。八、小结如何把路线图当作仓库的阅读地图ROADMAP.md 的六个目标大致对应了仓库中的六块核心资产可按下表速查路线图目标仓库中的主要落地载体Support GenAI inferenceconfig/runtimes/kserve-vllmserver.yaml、pkg/apis/serving/v1beta1/predictor.goWorkerSpec、pkg/apis/serving/v1alpha1/local_model_cache_types.go、cmd/llmisvc config/llmisvcconfigLLM Gateway核心推理能力 stable/GApkg/apis/serving/v1beta1InferenceService、config/crd/full、docs/predict-api/v2、pkg/batcherPython SDK 1.0python/kserve、python/pyproject.toml、pkg/tracingGraduate InferenceGraphpkg/apis/serving/v1alpha1/inference_graph.go、docs/samples/graphSecure InferenceServiceconfig/webhook、pkg/tls、docs/openshift1.0 文档docs、docs/samples、charts、hack/validate-manifests.sh对于想要参与 KServe 贡献或做二次开发的读者建议从与路线图强相关的目录入手先读 ROADMAP.md 确定方向再到对应 CRDpkg/apis/serving与控制器pkg/controller约 265 个 Go 文件中定位实现最后用各目录下的*_test.go如 pkg/apis/serving/v1alpha1/llm_inference_service_conversion_test.go验证行为契约。需要注意的是路线图中的部分条目如 GenAI Task API、SPIFFE/SPIRE 集成在仓库中仍处于规划或早期阶段本文对这类条目仅作方向性解读并以可以推断标注避免将规划当作已实现能力。总的来说这份路线图描绘了 KServe 从多框架预测推理平台向同时覆盖生成式与预测式推理的标准化 AI 推理平台演进的完整路径LLM 运行时与 Gateway 补齐生成式推理的能力面InferenceService/ServingRuntime/InferenceGraph/SDK 的 1.0 化夯实稳定性安全与文档则确保平台可以放心地部署到生产环境。赞分享模型推理服务云原生后端微服务MLOps人工智能【免费下载链接】kserveStandardized Distributed Generative and Predictive AI Inference Platform for Scalable, Multi-Framework Deployment on Kubernetes项目地址https://gitcode.com/gh_mirrors/ks/kserve点击查看免费下载相关推荐Longhorn v1.11.3 补丁版本深度解读稳定性修复、升级约束与源码印证Longhorn v1.11.3 补丁版本深度解读稳定性修复、升级约束与源码印证 Longhorn 1.11.3 是面向 v1.11 系列的一个补丁发布pa云原生存储高可用容器编排如何轻松备份微信聊天记录WeChatMsg完整指南与数据自主管理如何轻松备份微信聊天记录WeChatMsg完整指南与数据自主管理 你是否曾因手机丢失或更换而担心珍贵的微信对话永久消失那些与亲友的温馨对话、工作的重要讨论、物联网消息队列后端Eww 版本演进深度解读从 0.3.0 到 0.6.0 的完整变更历史与源码印证Eww 版本演进深度解读从 0.3.0 到 0.6.0 的完整变更历史与源码印证 本篇技术指南以仓库根目录下的 CHANGELOG.md https://li桌面应用上一篇PhotoMaker无障碍设计为视障用户优化的人像生成工具下一篇Skia图形库静态分析工具代码质量与安全检查创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 
长河君 · 2026/10/10 5:29:01 · 阅读 1.2k KServe 2024-2025 Roadmap 深度解读：从 GenAI 推理到 v1 稳定版的六大目标与源码印证
模型推理服务云原生后端微服务MLOps人工智能【免费下载链接】kserveStandardized Distributed Generative and Predictive AI Inference Platform for Scalable, Multi-Framework Deployment on Kubernetes项目地址https://gitcode.com/gh_mirrors/ks/kserve点击查看免费下载本文以仓库根目录下的 ROADMAP.md 为骨架结合 pkg/apis、config/runtimes、cmd/llmisvc 等源码与配置逐条解读 KServe 面向 2024-2025 年的技术路线如何围绕 Support GenAI inference 补齐 LLM 推理运行时、自动扩缩容、RAG/Agent 编排、LLM Gateway以及如何将核心推理能力、Python SDK、InferenceGraph 逐一推向 1.0 稳定版并同步推进安全加固与文档体系。读完本文你将能够对照路线图在仓库中找到每一项规划的落地载体与实现证据为选型、二次开发和贡献代码提供地图。一、路线图定位KServe 走向 GenAI 推理平台的关键一跃KServe 是一个运行在 Kubernetes 之上、面向分布式生成式Generative与预测式Predictive推理的标准化平台支持多框架、可扩展的模型部署。仓库根目录的 README.md 将其定位为 Standardized Distributed Generative and Predictive AI Inference Platform。ROADMAP.md 将 2024-2025 年的工作组织为6 个 Objective目标Support GenAI inference支持生成式 AI 推理——路线图的主线目标Graduate core inference capability to stable/GA核心推理能力走向稳定版Graduate KServe Python SDK to 1.0Python SDK 走向 1.0Graduate InferenceGraph推理图走向成熟Secure InferenceService加固推理服务安全KServe 1.0 documentation完善 1.0 文档体系。其中前 5 项都是工程能力建设最后一项则是为整个平台发布 1.0 版本所做的文档配套。下文逐条展开并在每个目标下给出当前仓库中已有的实现载体CRD、运行时、控制器、配置与测试作为路线图已开工/已落地的印证。二、Objective 1Support GenAI inference——让 KServe 全面拥抱 LLM这是整个路线图的核心目标细分为五个子方向LLM Serving Runtimes、LLM Autoscaling、LLM RAG/Agent Pipeline Orchestration、Open Inference Protocol 向 GenAI Task API 的扩展、以及 LLM Gateway。2.1 LLM Serving RuntimesvLLM、LoRA 与多主机多 GPU路线图对 LLM 推理运行时提出了四项具体工作支持基于 vLLM 运行时的投机解码Speculative Decoding支持 LoRA 适配器支持 TensorRT-LLM、TGI 等更多 LLM 运行时并提供基准对比支持多主机multi-host、多 GPU 推理运行时。从当前仓库看vLLM 运行时已经作为一等公民落地配置文件 config/runtimes/kserve-vllmserver.yaml 定义了名为kserve-vllmserver的 ServingRuntime通过标签serving.kserve.io/server-type: vllmserver标识镜像默认值占位为vllmserver:replace由isvcutils.UpdateImageTag在部署时替换启动入口指向vllm.entrypoints.openai.api_server并暴露VLLM_CONFIG_ROOT、VLLM_WORKER_MULTIPROC_METHOD等环境变量。仓库还提供了 config/runtimes/kserve-llm-sglang.yaml说明 LLM 运行时家族正在持续扩充。多主机、多 GPU的能力已经体现在 API 设计中pkg/apis/serving/v1beta1/predictor.go 中的WorkerSpec提供PipelineParallelSize流水线并行 worker 数同时决定 worker 集合的副本规模与TensorParallelSize每节点使用的 GPU 数表示跨 GPU 的张量并行度。配套的运行时示例见 config/runtimes/kserve-huggingfaceserver-multinode.yaml。LoRA 适配器方向仓库在v1alpha1的 LLM InferenceService 类型LLMInferenceService中提供了LoRA字段并在 pkg/apis/serving/v1alpha1/llm_inference_service_conversion.go 中通过注解internal.serving.kserve.io/lora-criticalities保存 LoRA 适配器的关键性criticality信息以在版本转换间无损传递对应的测试 llm_inference_service_conversion_test.go 验证了该注解的保留逻辑。可以推断后续 LoRA 的正式化方向是让适配器声明能力从 alpha API 进入稳定 API。2.2 LLM Autoscaling模型缓存与自定义指标扩缩容路线图在自动扩缩容方向的规划支持带自动 PV/PVC 供给的模型缓存Model Caching支持 ServingRuntime 的扩缩容设置支持基于自定义指标的扩缩容。模型缓存在仓库中已经形成了独立 CRD——LocalModelCachelocal model cache即本地模型缓存定义位于 pkg/apis/serving/v1alpha1/local_model_cache_types.go生命周期与状态条件LocalModelCacheReady实现在 pkg/apis/serving/v1alpha1/local_model_cache_lifecycle.go控制器位于 pkg/localmodelcache其中包含 pkg/localmodelcache 目录下的两个 Go 文件。缓存场景的使用文档与示例见 docs/samples/localmodelcache。可以推断该方向后续的演进重点是自动 PV/PVC 供给即由控制器依据缓存声明自动创建与回收存储卷而不是依赖管理员预先准备 PVC。基于自定义指标的扩缩容依赖外部指标源如 KEDA、HPA custom metrics。仓库在安装目录中提供了 KEDA 与 HPA 两种依赖安装脚本例如 install/v0.18.0/llmisvc-autoscaling-hpa-dependency-install.sh 与 install/v0.18.0/llmisvc-autoscaling-keda-dependency-install.sh说明 KServe 官方在发布物层面同时维护 HPA 与 KEDA 两条扩缩容链路通用扩缩容场景的用法可参考 docs/samples/autoscaling。2.3 LLM RAG/Agent Pipeline Orchestration用 InferenceGraph 编排声明式工作流路线图要求使用 KServe InferenceGraph 支持声明式 RAG/Agent 工作流。也就是说RAG 的检索—增强—生成流水线与 Agent 的多步调用将被建模为一张由路由节点router和步骤step组成的推理图而不是靠外部编排框架硬编码。仓库中的InferenceGraphCRD 定义于 pkg/apis/serving/v1alpha1/inference_graph.go其InferenceGraphSpec包含路由配置路由节点通过Steps []InferenceStepinference_graph.go声明下一跳目的地支持按流量权重分流等语义。Graph 的使用示例集中在 docs/samples/graph。结合 ROADMAP.md 中Graduate InferenceGraph目标可以推断InferenceGraph 在 2024-2025 年的定位已从简单流量图升级为RAG/Agent 工作流编排的底座。2.4 Open Inference Protocol 扩展到 GenAI Task API路线图在此方向提出两项工作将 Open Inference Protocol 扩展为面向 OpenAI schema 的社区维护协议仓库支持垂直化的 GenAI 任务 API如 embedding向量嵌入、Text-to-Image文生图、Text-To-Code文生码、Doc-To-Text文档转文本。这意味着 KServe 的数据面协议data plane不再只服务于传统预测式推理的v1/v2接口而是要向生成式任务的专用接口演进。仓库侧可以对照的现状是v2 预测协议KServe Predict Protocol v2的规范、protobuf 与配置文档位于 docs/predict-api/v2包含.md、.proto与.yaml文件是当前数据面协议的事实标准而 GenAI 任务 API 属于路线图中的增量规划仓库内尚处于规划阶段。2.5 LLM Gateway多提供商、限流、路由与可观测路线图对 LLM Gateway 提出四点规划支持多个 LLM 提供商providers支持基于 token 的限流rate limiting支持带流量整形traffic shaping、fallback、负载均衡的 LLM 路由器提供面向指标与成本报告的 Gateway 可观测性。仓库中已有专门的LLM 服务治理llmisvc组件承载这一方向控制器入口位于 cmd/llmisvc含 main.go 与迁移逻辑 migration.go运行时配置集中在 config/llmisvcconfig其中可以看到与 Gateway 能力一一对应的配置模板config-llm-router-route.yaml——路由规则config-llm-scheduler.yaml 与 config-llm-scheduler-eppconfig-default.yaml——调度与端点配置config-llm-tokenizer.yaml——token 相关配置config-llm-tracing.yaml——链路追踪可观测性config-llm-worker-data-parallel.yaml、config-llm-prefill-worker-data-parallel.yaml 与 config-llm-decode-worker-data-parallel.yaml——预填充/解码阶段的数据并行 worker 配置。从源码结构看llmisvc 同时包含 webhook 配置config/webhook/llmisvc、RBACconfig/rbac/llmisvc与完整的 CRDcharts/kserve-llmisvc-crd、config/crd/full其部署示例见 docs/samples/llmisvc。可以认为路线图中的多提供商支持、token 限流、LLM 路由器、成本指标是对现有 llmisvc 能力的深化与产品化。三、Objective 2把核心推理能力推向 stable/GA3.1 InferenceService 与 ServingRuntime CRD 升级到 v1路线图提出将InferenceService与ClusterServingRuntime/ServingRuntimeCRD 提升到v1版本。具体工作包括改进InferenceServiceCRD 的 REST/gRPC 协议接口改进模型存储接口弃用TrainedModelCRD并将多模型 co-hosting、draft model草稿模型、LoRA 适配器等能力并入InferenceService改进 predictor 与 transformer 容器共置collocation的 YAML 体验缩小RawDeployment与Serverless模式之间的功能差距。当前仓库中InferenceService的稳定 API 是v1beta1其核心类型定义在 pkg/apis/serving/v1beta1/inference_service.goInferenceServiceSpec与 pkg/apis/serving/v1beta1 目录下的组件类型predictor/transformer/explainer中而 LLM 相关的LLMInferenceService位于v1alpha1两者之间的双向转换逻辑正是 llm_inference_service_conversion.go 所承担的。CRD 的完整清单见 config/crd/full24 个 YAML与 minimal 版本 config/crd/minimal。多模型能力已经部分体现在 API 上predictor.go 中的PredictorSpec同时提供Model任意框架的模型 spec与StorageUris []StorageUri多存储地址列表每个StorageUri可指定uri与容器内挂载路径mountPath默认/mnt/models——这正是 co-hosting 多模型与 LoRA 适配器挂载所需的字段基础。多模型服务ModelMesh 风格的使用手册见 docs/MULTIMODELSERVING_GUIDE.md。RawDeployment 与 Serverless 模式KServe 支持两种部署形态Route 层分别对接 Knative Serverless 与原生 Kubernetes 资源仓库在 docs/samples 下提供 rollout-strategydocs/samples/rollout-strategy等示例。路线图要求缩小两种模式的功能差距例如让RawDeployment也能获得流量切分、金丝雀发布等 Serverless 特性。3.2 Open Inference Protocolv2的深化为 v2 推理协议支持 batching批处理Transformer 与 Explainer 的 v2 协议互操作改进 v2 协议的 codec编解码器。仓库中 v2 协议栈已包含独立的批处理模块 pkg/batcher2 个 Go 文件实现了请求聚合/拆分的逻辑示例见 docs/samples/batcherv2 协议规范与 protobuf 定义在 docs/predict-api/v2。protocolVersion字段v1/v2/grpc-v1/grpc-v2定义于 predictor.go是各框架运行时统一遵循的协议开关。路线图此节的目标是让 v2 协议在批处理、组件互操作与编解码三个维度达到生产级成熟度。四、Objective 3Graduate KServe Python SDK to 1.0路线图对 Python SDK 提出三项工作创建标准化的模型打包 APImodel packaging API改进 KServe model server 的可观测性metrics 与分布式追踪支持批量推理batch inference。Python SDK 的主体位于 python/kserve约 428 个.py文件除核心推理与客户端库外还包含存储处理python/storage、各框架 server如 python/huggingfaceserver、python/autogluonserver 等与通用服务端实现。SDK 的安装与用法通过根目录的 python/pyproject.toml 管理。可观测性方面仓库在 Go 侧已有 pkg/metrics指标注册与 pkg/tracing分布式追踪注入Python server 侧则通过 pkg/oteljson 与 docs/otel-json-stdout.md 所描述的 OTel JSON 输出协议向标准输出暴露追踪数据。可以推断模型打包 API将把训练产物 → KServe 可部署模型的转换过程标准化而批量推理能力会与 v2 协议的 batching 形成呼应。五、Objective 4Graduate InferenceGraph路线图对InferenceGraph的成熟化提出六项工作改进InferenceGraphspec 的副本replica与并发concurrency控制支持分布式追踪为InferenceGraph支持 gRPC为InferenceGraph提供独立的Transformer支持支持流量镜像traffic mirroring节点改进InferenceGraph的RawDeployment模式。InferenceGraphCRD 的结构pkg/apis/serving/v1alpha1/inference_graph.go目前已支持多步骤、按权重分流的声明式图追踪能力可以复用 pkg/tracing 的 OpenTelemetry 注入机制。这些规划表明InferenceGraph 的目标是成为生产可用的编排原语——支持并发控制、gRPC 入口、可插入 transformer 预处理以及灰度级的流量镜像从而承担上一节提到的 RAG/Agent 工作流编排职责。六、Objective 5Secure InferenceService文档化 KServe ServiceMesh 的 mTLS 配置支持程序化认证令牌programmatic authentication token实现服务级per service认证支持 SPIFFE/SPIRE 身份与InferenceService的集成。仓库当前的 webhook 与认证基础设施包括webhook 配置目录 config/webhookmanifests、service 与 CA 注入补丁如 config/default/isvc_mutatingwebhook_cainjection_patch.yaml、RBAC 目录 config/rbac以及 TLS 相关工具包 pkg/tls。OpenShift 环境下的 ServiceMesh / cert-manager / serverless 配置示例见 docs/openshift含 networkpolicies.yaml 与 service-mesh 子目录。可以推断mTLS 文档化与 SPIFFE/SPIRE 集成将复用并扩展 pkg/tls 与 webhook 注入链路而服务级认证则需要在InferenceService上暴露独立的认证配置字段。七、Objective 6KServe 1.0 documentation补充 ModelMesh 文档并说明经典 KServe 与 ModelMesh 各自的使用场景统一数据面 v1 与 v2 页面的格式改进 v2 数据面文档讲清楚为什么变、变了什么清理仓库中的示例与官网建立单一事实来源single source of truth更新过时文档保持全站一致性与连贯性。这一目标对应仓库文档基础设施的现状根目录有 docs 目录含 v1beta1 API 文档 docs/apis/v1beta1、开发者指南 docs/DEVELOPER_GUIDE.md、清单指南 docs/MANIFESTS_GUIDE.md、多模型服务指南 docs/MULTIMODELSERVING_GUIDE.md 与 OpenShift 指南 docs/OPENSHIFT_GUIDE.md示例集中存放在 docs/samplesv1beta1 示例约 219 个文件另外仓库同时维护 Helm Chartscharts与 Kustomize 清单config两者的一致性通过 hack/validate-manifests.sh 等脚本校验。可以推断单一事实来源的落地方式是让 docs 下的示例与官网、Chart 模板如 charts/kserve-resources、charts/kserve-crd指向同一份内容并借助 verify-doc-links.py 之类的工具持续校验链接有效性。八、小结如何把路线图当作仓库的阅读地图ROADMAP.md 的六个目标大致对应了仓库中的六块核心资产可按下表速查路线图目标仓库中的主要落地载体Support GenAI inferenceconfig/runtimes/kserve-vllmserver.yaml、pkg/apis/serving/v1beta1/predictor.goWorkerSpec、pkg/apis/serving/v1alpha1/local_model_cache_types.go、cmd/llmisvc config/llmisvcconfigLLM Gateway核心推理能力 stable/GApkg/apis/serving/v1beta1InferenceService、config/crd/full、docs/predict-api/v2、pkg/batcherPython SDK 1.0python/kserve、python/pyproject.toml、pkg/tracingGraduate InferenceGraphpkg/apis/serving/v1alpha1/inference_graph.go、docs/samples/graphSecure InferenceServiceconfig/webhook、pkg/tls、docs/openshift1.0 文档docs、docs/samples、charts、hack/validate-manifests.sh对于想要参与 KServe 贡献或做二次开发的读者建议从与路线图强相关的目录入手先读 ROADMAP.md 确定方向再到对应 CRDpkg/apis/serving与控制器pkg/controller约 265 个 Go 文件中定位实现最后用各目录下的*_test.go如 pkg/apis/serving/v1alpha1/llm_inference_service_conversion_test.go验证行为契约。需要注意的是路线图中的部分条目如 GenAI Task API、SPIFFE/SPIRE 集成在仓库中仍处于规划或早期阶段本文对这类条目仅作方向性解读并以可以推断标注避免将规划当作已实现能力。总的来说这份路线图描绘了 KServe 从多框架预测推理平台向同时覆盖生成式与预测式推理的标准化 AI 推理平台演进的完整路径LLM 运行时与 Gateway 补齐生成式推理的能力面InferenceService/ServingRuntime/InferenceGraph/SDK 的 1.0 化夯实稳定性安全与文档则确保平台可以放心地部署到生产环境。赞分享模型推理服务云原生后端微服务MLOps人工智能【免费下载链接】kserveStandardized Distributed Generative and Predictive AI Inference Platform for Scalable, Multi-Framework Deployment on Kubernetes项目地址https://gitcode.com/gh_mirrors/ks/kserve点击查看免费下载相关推荐Longhorn v1.11.3 补丁版本深度解读稳定性修复、升级约束与源码印证Longhorn v1.11.3 补丁版本深度解读稳定性修复、升级约束与源码印证 Longhorn 1.11.3 是面向 v1.11 系列的一个补丁发布pa云原生存储高可用容器编排如何轻松备份微信聊天记录WeChatMsg完整指南与数据自主管理如何轻松备份微信聊天记录WeChatMsg完整指南与数据自主管理 你是否曾因手机丢失或更换而担心珍贵的微信对话永久消失那些与亲友的温馨对话、工作的重要讨论、物联网消息队列后端Eww 版本演进深度解读从 0.3.0 到 0.6.0 的完整变更历史与源码印证Eww 版本演进深度解读从 0.3.0 到 0.6.0 的完整变更历史与源码印证 本篇技术指南以仓库根目录下的 CHANGELOG.md https://li桌面应用上一篇PhotoMaker无障碍设计为视障用户优化的人像生成工具下一篇Skia图形库静态分析工具代码质量与安全检查创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考