AI推理InferNex Bridge ​

特性介绍 ​

InferNex Bridge是InferNex与KServe之间的核心枢纽，以Validating/Mutating Webhook与InferNexService CRD衔接两套部署入口，支持双模式部署策略：既可无缝融入现有KServe生态，也可在无KServe环境下独立运行。

• 模式一（LLMInferenceService部署入口）：在LLMInferenceService上设置infernex.io/runtime: "true"接入InferNex链路；推理引擎与Hermes Router由KServe编排，Bridge负责Mooncake KVCache、cache-indexer、PD-Orchestrator、Eagle-Eye等增强组件及LLMInferenceServiceConfig运行时兼容。

• 模式二（InferNexService部署入口）：不经KServe，通过InferNexService/InferNexServiceConfig由Bridge统一部署推理引擎、Hermes Router与增强组件。

已有KServe环境的团队可沿用LLMInferenceService工作流获得完整InferNex加速能力；无KServe或需独立控制面的场景亦可获得与AI推理集成部署一致的全栈推理加速能力（智能路由、Mooncake KVCache、弹性扩缩、硬件可观测等）。

说明：
与AI推理集成部署InferNex主Chart一键全栈安装入口不同，本文介绍InferNex Bridge独立安装方式，其中以配合KServe经LLMInferenceService部署为主线。架构与责任边界见OFEP-0040及InferNex-Bridge技术规格。

应用场景 ​

• 集群已安装KServe，支持的版本号为v0.17.0到v0.19.0，希望通过LLMInferenceService + infernex.io/runtime: "true"部署完整InferNex能力。
• 需要InferNex Bridge自动处理KServe内置Config与InferNex运行时的兼容问题。
• 希望通过InferNex Bridge部署InferNex推理能力，而不使用InferNex主Chart一键全栈安装（KServe + LLMInferenceService部署入口或InferNexService部署入口均可）。

能力范围 ​

• InferNex Bridge自身提供控制面：独立Helm Chart安装；下发CRD、RBAC、Webhook及默认InferNexServiceConfig模板。

• 双部署入口：支持KServe + LLMInferenceService与InferNexService两种路径。

• 通过InferNex Bridge部署的实例，其推理加速能力（智能路由、Mooncake KVCache、扩缩容决策、硬件可观测等）与AI推理集成部署 — 能力范围完全一致。其差异仅在于部署入口和编排逻辑，而非能力集合的增减。

亮点特征 ​

• KServe兼容：沿用LLMInferenceService工作流，通过标签进入InferNex链路。
• 双部署入口：KServe + LLMInferenceService部署入口与InferNexService部署入口并存。

实现原理 ​

InferNex Bridge以Mutating/Validating Webhook与InferNexService CRD构成KServe适配层：用户仍以LLMInferenceService为入口，在不改动KServe CRD的前提下补齐InferNex增强组件；亦支持不经KServe、直接提交InferNexService由Bridge统一部署。Mutating Webhook对带infernex.io/runtime: "true"的LLMInferenceService做准入改写（兼容补丁LLMInferenceServiceConfig）；Validating Webhook对直连提交的InferNexService做准入校验（KServe链路下带sourceRef的InferNexService跳过校验）。InferNexService通过sourceRef与LLMInferenceService关联并做只读观测，不会把llmisvc.spec合并进来重复拉起推理引擎或Router。

逻辑视图 ​

KServe LLMInferenceService控制器负责推理引擎、Hermes Router与Gateway/HTTPRoute/InferencePool。InferNex Bridge负责proxy-server（P/D模式）、Mooncake KVCache、Cache-Indexer、PD-Orchestrator、Eagle-Eye等补充组件。P/D模式下流量经proxy-server分流至prefill/decode。

图1 InferNex Bridge逻辑视图

部署视图 ​

KServe与InferNex Bridge分别以独立Helm Chart部署；InferNex Bridge Pod内集成Mutating/Validating Webhook与InferNexService控制器：MutatingWebhookConfiguration对KServe默认的LLMInferenceServiceConfig进行兼容补丁；ValidatingWebhookConfiguration对提交的InferNexService做准入校验（KServe链路下自动创建的带sourceRef的InferNexService跳过校验）。

图2 InferNex Bridge部署视图

运行视图 ​

KServe + LLMInferenceService部署入口：用户提交带infernex.io/runtime: "true"的LLMInferenceService后，先经Mutating Webhook准入改写KServe默认安装的LLMInferenceServiceConfig，再由KServe与InferNex Bridge并行部署各自负责的工作负载。InferNexService部署入口：用户直连提交InferNexService时，先经Validating Webhook准入校验。

图3 InferNex Bridge运行视图

与相关特性的关系 ​

AI推理集成部署通过InferNex主Chart一键安装InferNex全栈（控制面与推理实例）；本文介绍InferNex Bridge独立安装方式，部署入口为InferNex Bridge Chart，覆盖KServe + LLMInferenceService部署入口与InferNexService部署入口，与主Chart全栈入口不同。

安装 ​

前提条件 ​

InferNex Bridge控制面 ​

• 已有可用的Kubernetes集群，并安装kubectl、Helm（v3以上版本）。
• KServe：KServe安装版本为v0.17.0到v0.19.0，安装前提请参见KServe LLMISVC Prerequisites。
• API版本：LLMInferenceService/LLMInferenceServiceConfig同时支持serving.kserve.io/v1alpha1和serving.kserve.io/v1alpha2，推荐使用serving.kserve.io/v1alpha2。InferNexService/InferNexServiceConfig为infernex.infernex.io/v1alpha1。
• 已安装Envoy Gateway及Gateway API、Gateway API Inference Extension等相关CRD；采用KServe + LLMInferenceService部署方式时，Hermes Router路由与HTTPRoute对外暴露推理服务须依赖上述组件。
• 集群可访问cr.openfuyao.cn、hub.oepkgs.net（或已配置等价镜像）。
• 建议命名空间infernex-bridge-system处于Active状态；避免重复安装多套InferNex Bridge Webhook。

说明：
镜像清单、版本兼容、部署场景及Webhook对LLMInferenceServiceConfig的补丁行为请参见部署规格、部署场景、Webhook补丁说明与附录 A 默认镜像。Hermes Router容器命名要求见本文附录 — Hermes Router容器命名约定。

推理集群环境（通用） ​

部署推理实例（vLLM-Ascend、Mooncake KVCache、PD分离等）前，硬件、软件与网络前提请参见AI推理集成部署。

• 安装InferNex的前提条件请参见前提条件（包含集群版本、NPU Operator、LWS等）。
• 使用AI推理的前提条件请参见使用AI推理（包含推理节点资源、metrics-server、PD + Mooncake KVCache网络等）。
• PD分离且Mooncake KVCache经HCCS传输时的网络配置请参见昇腾HCCS设备IP地址配置示例。
• 自定义模型权重宿主机挂载路径与缓存目录结构请参见自定义模型目录配置。

说明：

• 按InferNex Bridge独立安装方式部署时，不要求预先安装主Chart的inference-backend；Mooncake KVCache、cache-indexer、PD-Orchestrator等增强组件由InferNex Bridge按实例拉起。
• 启用Eagle-Eye时须预先安装NATS、kube-prometheus-stack；配置与使用见AI推理鹰眼。

开始安装 ​

方式一：从InferNex源码仓库安装Chart ​

git clone -b release-26.6.0 https://gitcode.com/openFuyao/InferNex.git
cd InferNex/component/InferNex-Bridge

helm upgrade --install infernex-bridge ./chart/infernex-bridge \
  -n infernex-bridge-system \
  --create-namespace \
  --wait \
  --timeout 10m

Chart的version与InferNex发布版本一一对应；本release对应版本为26.6.0。安装前执行如下命令可查看Chart元数据。

helm show chart ./chart/infernex-bridge

方式二：从OCI仓库安装（推荐） ​

helm upgrade --install infernex-bridge oci://cr.openfuyao.cn/charts/infernex-bridge \
  --version 26.6.0 \
  -n infernex-bridge-system \
  --create-namespace \
  --wait \
  --timeout 10m

--version用于指定Chart的version，本release使用26.6.0。安装前执行如下命令可查看Chart元数据。

helm show chart oci://cr.openfuyao.cn/charts/infernex-bridge --version 26.6.0

Webhook TLS证书（可选） ​

InferNex Bridge Webhook需要TLS证书。Chart支持两种方式，通过webhooks.certGenerator.enabled（默认true）与certManager.enabled（默认false）切换。

表1 Webhook TLS证书配置方式

集群已部署cert-manager时，执行如下命令，设置certManager.enabled=true。

helm upgrade --install infernex-bridge oci://cr.openfuyao.cn/charts/infernex-bridge \
  --version 26.6.0 \
  -n infernex-bridge-system \
  --create-namespace \
  --set certManager.enabled=true \
  --wait \
  --timeout 10m

验证部署 ​

helm list -n infernex-bridge-system
kubectl get pods,svc -n infernex-bridge-system
kubectl get secret webhook-server-cert -n infernex-bridge-system
kubectl get mutatingwebhookconfiguration,validatingwebhookconfiguration | grep infernex-bridge
kubectl get endpoints webhook-service -n infernex-bridge-system

预期返回。

• InferNex Bridge控制器Pod为Running且READY为1/1。
• Webhook证书、配置与Service端点均已就绪，可正常接收Admission请求。

卸载 ​

卸载InferNex Bridge控制面（控制器、Webhook及相关Release资源）。

helm uninstall infernex-bridge -n infernex-bridge-system

说明：
默认webhooks.certGenerator.enabled=true且certManager.enabled=false时，pre-delete Hook Job cleanup-webhook-cert会额外清理Mutating/ValidatingWebhookConfiguration与webhook-server-cert Secret；certManager.enabled=true时不创建该Job，Webhook配置随Release删除，证书Secret由cert-manager管理。Chart下发的CRD默认不随Release删除，需自行处理。若infernex-bridge-system命名空间内已无其他需保留的资源，可执行kubectl delete namespace infernex-bridge-system删除该命名空间及其中的残留资源。

使用InferNex Bridge ​

同一推理实例不宜经两种部署入口重复安装两套同类增强组件；请为每个实例选定KServe + LLMInferenceService或InferNexService其中一种入口，勿混用。

使用LLMInferenceService ​

适用于已安装KServe的场景：推理引擎、Hermes Router由KServe reconcile；增强组件由InferNex Bridge reconcile。

前提条件 ​

• 已完成本文前提条件中的InferNex Bridge控制面与推理集群环境检查。
• InferNex Bridge与Webhook运行正常。
• 具备创建LLMInferenceService、LLMInferenceServiceConfig的权限。
• Envoy网关及GIE相关CRD已就绪（若需经网关访问）。

背景信息 ​

表2 Config与LLMISVC职责

仅在Config上设置infernex.io/runtime标签无效。推荐先创建Config，再创建带标签的LLMISVC并通过spec.baseRefs引用Config。Hermes Router路由策略、插件与网关侧配置见AI推理赫尔墨斯路由。

使用限制 ​

• infernex.io/runtime标签仅打在LLMInferenceService上，打在LLMInferenceServiceConfig上无效。
• 须使用KServe的LLMInferenceServiceConfig体系，与InferNexServiceConfig不可混用。
• 示例中replicas: 1为推理引擎默认固定副本；启用PD-Orchestrator扩缩须省略LLMISVC Config中spec.template/spec.prefill上的replicas及LLMISVC spec.replicas、spec.prefill.replicas，详见附录 — 推理引擎的副本与扩缩容。

操作步骤 ​

1. 准备入口Gateway（按需）。

   示例LLMISVC中spec.router.gateway: {}、route: {}表示由KServe创建HTTPRoute并挂到默认入口Gateway（常为kserve命名空间下的kserve-ingress-gateway）。若集群中不存在，须先创建。

   yaml

   apiVersion: gateway.networking.k8s.io/v1
   kind: Gateway
   metadata:
     name: kserve-ingress-gateway
     namespace: kserve
   spec:
     gatewayClassName: envoy
     infrastructure:
       labels:
         serving.kserve.io/gateway: kserve-ingress-gateway
     listeners:
       - name: http
         protocol: HTTP
         port: 80
         allowedRoutes:
           namespaces:
             from: All

   将上文YAML保存为kserve-ingress-gateway.yaml后，执行如下命令创建入口Gateway并确认就绪。

   bash

   kubectl apply -f kserve-ingress-gateway.yaml
   kubectl get gateway -n kserve kserve-ingress-gateway

2. 创建LLMInferenceServiceConfig并配置引擎模板。

   storageInitializer（示例默认关闭，可按需开启）。

   yaml

     storageInitializer:
       enabled: false

   表3 storageInitializer.enabled行为说明

   enabled	行为
   false（推荐）	不注入KServe storage-initializer init；冷启动更快。模型由节点hostPath缓存或推理引擎initContainers（如huggingface-download）准备。
   true	KServe按spec.model.uri内置拉模型；首启通常更慢，与KServe原生hf://流程一致。

   Hermes Router EPP容器须固定容器名main、命名端口grpc（详见附录 — Hermes Router 容器命名约定）。

   yaml

     router:
       scheduler:
         pool:
           spec:
             selector:
               matchLabels:
                 app.kubernetes.io/name: ex-ag-01-sn-sc
             endpointPickerRef:
               kind: Service
               name: ex-ag-01-sn-sc-epp-service
         template:
           spec:
             containers:
               - name: tokenizer
                 image: cr.openfuyao.cn/openfuyao/hermes-tokenizer:latest
               - name: main
                 image: cr.openfuyao.cn/openfuyao/hermes-router:latest
                 ports:
                   - name: grpc
                     containerPort: 9002

   固定main是为在存在tokenizer等sidecar时，让EndpointPickerRef经Service targetPort唯一定位EPP；否则可能连到tokenizer的8000端口，对外常表现为HTTP 500。

3. 创建带标签的LLMInferenceService。

   进入InferNex链路时，仅在LLMInferenceService上打标签。

   yaml

   metadata:
     labels:
       infernex.io/runtime: "true"

   标签与baseRefs（聚合入门示例实例名ex-ag-01-sn-sc）。

   yaml

   apiVersion: serving.kserve.io/v1alpha2
   kind: LLMInferenceService
   metadata:
     name: ex-ag-01-sn-sc
     namespace: kserve
     labels:
       infernex.io/runtime: "true"
   spec:
     baseRefs:
       - name: ex-ag-01-sn-sc-config
     model:
       uri: hf://Qwen/Qwen2.5-0.5B
       name: Qwen/Qwen2.5-0.5B

4. 部署完整示例。

   部署前请按环境修改命名空间、节点、nodeName、hostPath、模型URI、镜像tag等。示例按场景分目录维护（单机单卡/单机多卡/跨机MoE + LWS等），完整清单见InferNex仓库component/InferNex-Bridge/config/examples/llmisvc/。

   • 聚合入门：ag-01-single-node-single-card.yaml（聚合模式样例目录）
   • P/D入门：pd-01-single-node-single-card.yaml（PD分离模式样例目录）
   bash

   git clone -b release-26.6.0 https://gitcode.com/openFuyao/InferNex.git
   cd InferNex/component/InferNex-Bridge/config/examples/llmisvc
   kubectl apply -f aggregate/ag-01-single-node-single-card.yaml
   # 或
   kubectl apply -f disaggregated/pd-01-single-node-single-card.yaml

   bash

   kubectl get llminferenceservice,llminferenceserviceconfig -n kserve
   kubectl get pods -n kserve

5. 经网关验证推理服务。

   实例Ready后，经Envoy访问，URL形如：http://<网关IP地址>:<端口>/<路径前缀>/v1/chat/completions。

   5.1 查网关IP地址与端口。

   bash

   kubectl get svc -A | grep -i envoy
   kubectl get nodes -o wide

   5.2 确认路径前缀并发送请求。

   KServe默认路由的路径前缀为/<metadata.namespace>/<metadata.name>，其中第一段是LLMInferenceService所在命名空间，第二段是实例名；并非固定kserve。按入门示例YAML未改命名空间与实例名时，聚合参考路径为/kserve/ex-ag-01-sn-sc，P/D为/kserve/ex-pd-01-sn-sc。请求体中的model须与所部署YAML的spec.model.name一致。

   bash

   curl -X POST "http://<网关IP>:<端口>/kserve/ex-ag-01-sn-sc/v1/chat/completions" \
     -H "Content-Type: application/json" \
     -d '{"model":"<spec.model.name>","messages":[{"role":"user","content":"你好"}]}'

后续操作 ​

删除LLMISVC实例。删除带infernex.io/runtime: "true"的LLMInferenceService（聚合入门示例，命名空间kserve；P/D将实例名换为ex-pd-01-sn-sc）。

kubectl delete llminferenceservice ex-ag-01-sn-sc -n kserve

kubectl get llminferenceservice,insvc -n kserve
kubectl get pods -n kserve | grep ex-ag-01-sn-sc

删除后，KServe回收推理引擎、Hermes Router与HTTPRoute等；InferNex Bridge删除自动创建的同名InferNexService及Mooncake KVCache、cache-indexer、PD-Orchestrator、Eagle-Eye等增强组件。

删除LLMISVCConfig（可选）。LLMInferenceServiceConfig为可复用模板，不随LLMISVC自动删除；确需移除自定义Config时执行。

kubectl delete llminferenceserviceconfig ex-ag-01-sn-sc-config -n kserve

注意：

• 若曾通过PD-Orchestrator（Elastic-Scaler/ResourceScalingGroup）扩缩出额外推理引擎副本，删除LLMISVC后请检查是否仍有残留Deployment、ElasticScaler、ResourceScalingGroup等CR，必要时手动清理。
• 命名空间长时间处于Terminating时，检查InferNexService是否受阻在finalizer阶段，确认无残留Pod后再处理finalizer。

使用InferNexService ​

适用于不依赖KServe、由InferNex Bridge通过InferNexService/InferNexServiceConfig原生CRD部署：推理引擎、Hermes Router及增强组件均由InferNex Bridge reconcile。InferNexService资源简称为insvc，InferNexServiceConfig简称为insvccfg（CRD shortNames）；下文kubectl示例使用缩写。

前提条件 ​

• 已完成本文前提条件中的InferNex Bridge控制面与推理集群环境检查。
• 默认模板（infernex-default-aggregate-template/infernex-default-pd-template）已安装在模板命名空间（默认infernex-bridge-system）；二者仅含增强组件与IGR缺省值，不含推理引擎Pod模板，部署实例须引用示例Config或自建spec.engine。
• 若需对外入口：Envoy Gateway、GatewayClass可用；spec.intelligentGatewayRouting.router.enabled: true并配置Gateway/HTTPRoute/InferencePool。

背景信息 ​

• InferNexService经spec.baseRefs引用InferNexServiceConfig合并配置；spec.engine可写在InferNexService或InferNexServiceConfig中（示例经baseRefs引用Config；扁平结构：根字段为aggregate/decode工作负载，P/D时另设prefill子块），InferNexService另写model、IGR、组件开关等。Chart默认模板（infernex-default-aggregate-template/infernex-default-pd-template）仅含增强组件与IGR缺省值，不含引擎Pod模板；部署推理实例须引用示例Config或自建引擎模板。
• Mooncake KVCache、cache-indexer、proxy-server（PD）、PD-Orchestrator、Eagle-Eye等由控制器从内置assets或与平台默认Config合并后拉起，无需在用户YAML中展开全部PodTemplate。
• Hermes Router路由策略、插件与网关侧配置见AI推理赫尔墨斯路由。

spec字段说明 ​

InferNexService与InferNexServiceConfig分工：baseRefs按顺序merge，后者覆盖前者；spec.engine可写在InferNexService或InferNexServiceConfig中（示例通常放在Config），InferNexService另写model、IGR、组件开关等。两套Config与LLMInferenceServiceConfig不可混用。

表4 InferNexService字段说明

spec.engine字段说明 ​

spec.engine为扁平结构（不再使用engine.aggregate/engine.pd嵌套块）。每个工作负载段（根字段或prefill）共用同一组字段。

表5 spec.engine工作负载字段（根字段与prefill均适用）

模式判定：merge完成后，若prefill.template含有效containers，则为P/D（根字段为decode，须同时配置prefill）；否则为aggregate（仅根字段template）。Chart默认模板名仍区分aggregate/pd，用于组件缺省值回退，与spec.engineYAML形状无关。

聚合与P/D的YAML骨架如下（完整Pod模板见示例Config）：

# aggregate
spec:
  engine:
    template:
      spec:
        containers: [...]
    # 可选：replicas、dataParallelSize、dataParallelSizeLocal、worker

# P/D（根template=decode，prefill=prefill）
spec:
  engine:
    template:
      spec:
        containers: [...]   # decode
    prefill:
      template:
        spec:
          containers: [...]

更多LWS/Admission约束及扩缩前提见本文附录 — 推理引擎的副本与扩缩容。

IGR与网关对象 ​

• router.enabled：对外入口总开关。false时仅部署集群内推理引擎与增强组件，InferNex Bridge不调和Gateway/HTTPRoute/InferencePool。
• router.enabled: true时须配置Hermes Router EPP模板（容器名main、端口名grpc，见附录 — Hermes Router 容器命名约定）；gateway、httpRoute、inferencePool各支持两种写法。
  • ref：引用集群中已有资源名（Bring Your Own）。
  • spec：由InferNex Bridge按字段创建或更新托管对象。
  • 同一对象上ref与spec互斥，不可同时填写。
• 启用router且未为gateway/httpRoute/inferencePool指定ref时，InferNex Bridge按默认规则托管对应Gateway API对象（示例通常只写router段）。

组件开关（spec.components） ​

InferNexService部署入口下创建的InferNexService（无spec.sourceRef）若在YAML中声明某组件块，须显式写enabled: true或false，不可省略。常见字段。

• mooncake.enabled、cacheIndexer.enabled
• pdOrchestrator.elasticScaler/tidal/resourceScalingGroup
• eagleEye.hardwareMonitor/hardwareDiagnosis（启用前须安装NATS、kube-prometheus-stack）

spec.sourceRef ​

KServe链路下InferNex Bridge会自动创建带sourceRef的同名InferNexService。此类对象由InferNex Bridge仅调和增强组件，勿手改engine/router；IGR由KServe管理，InferNex Bridge不触碰Gateway API对象。

使用限制 ​

• InferNexService部署入口不需要打infernex.io/runtime标签；该标签仅用于KServe + LLMInferenceService部署入口。
• InferNexService部署入口下，Hermes Router使用openfuyao.com/pdRole、openfuyao.com/pdGroupID等标签；与KServe + LLMInferenceService部署入口的app.kubernetes.io/*标签体系不同，勿混用。
• InferNexService部署入口下、无spec.sourceRef的InferNexService，若在YAML中声明spec.components某组件块，须显式写enabled: true或false。
• KServe链路下自动创建的带spec.sourceRef的InferNexService，勿手改engine/router字段。
• 示例中replicas: 1为推理引擎默认固定副本；启用PD-Orchestrator扩缩须省略engine根字段及engine.prefill上的replicas，详见附录 — 推理引擎的副本与扩缩容。

操作步骤 ​

1. 确认默认模板与命名空间。

   bash

   kubectl get insvc,insvccfg -n infernex-bridge-system
   kubectl get pods -n infernex-bridge-system
   kubectl get gateway,httproute,inferencepool -n infernex-bridge-system

2. 准备InferNexServiceConfig（按需自定义引擎模板）。

   自定义引擎模板写在InferNexServiceConfig中，由InferNexService通过spec.baseRefs引用；亦可使用Chart安装的默认模板。

3. 创建InferNexService实例。

   yaml

   apiVersion: infernex.infernex.io/v1alpha1
   kind: InferNexService
   metadata:
     name: ex-ag-01-sn-sc
     namespace: infernex-bridge-system
   spec:
     baseRefs:
       - name: ex-ag-01-sn-sc-engine
     model:
       uri: hf://Qwen/Qwen2.5-0.5B
       name: Qwen/Qwen2.5-0.5B
     intelligentGatewayRouting:
       router:
         enabled: true

   Hermes Router模板须固定EPP容器名为main、端口名为grpc（见附录 — Hermes Router 容器命名约定）。

4. 部署完整示例。

   示例按场景分目录维护（单机单卡/单机多卡/跨机MoE + LWS等），每个YAML内含同Spec ID的InferNexServiceConfig（spec.engine）与InferNexService（model + IGR）。完整清单见InferNex仓库component/InferNex-Bridge/config/examples/insvc/。

   • 聚合入门：ag-01-single-node-single-card.yaml（聚合模式样例目录）
   • P/D入门：pd-01-single-node-single-card.yaml（PD分离模式样例目录）
   bash

   cd InferNex/component/InferNex-Bridge/config/examples/insvc
   kubectl apply -f aggregate/ag-01-single-node-single-card.yaml
   # 或
   kubectl apply -f disaggregated/pd-01-single-node-single-card.yaml

5. 经网关验证推理服务。

   与LLMISVC类似，查Gateway/HTTPRoute后curl；路径前缀同为/<命名空间>/<实例名>（InferNex Bridge托管路由亦按此规则生成）。model须与spec.model.name一致。聚合入门实例名ex-ag-01-sn-sc，P/D为ex-pd-01-sn-sc（以示例YAML为准）。

后续操作 ​

删除InferNexService实例。删除InferNexService后，InferNex Bridge会回收该实例调和的推理引擎、Hermes Router、增强组件，以及启用IGR时创建的Gateway/HTTPRoute/InferencePool等（以控制器ownership为准）。聚合入门示例（命名空间infernex-bridge-system）。

kubectl delete insvc ex-ag-01-sn-sc -n infernex-bridge-system

kubectl get insvc,pods -n infernex-bridge-system | grep ex-ag-01-sn-sc
kubectl get gateway,httproute,inferencepool -n infernex-bridge-system

删除InferNexServiceConfig（可选）。InferNexServiceConfig为可复用引擎模板，不随InferNexService实例自动删除。删除实例时通常只需删insvc，不必删Config。

• 用户自定义模板（如示例ex-ag-01-sn-sc-engine）。确认无其他InferNexService通过spec.baseRefs引用后，可按需删除。

kubectl delete insvccfg ex-ag-01-sn-sc-engine -n infernex-bridge-system

• Chart默认模板（infernex-default-aggregate-template、infernex-default-pd-template）：由InferNex Bridge Chart安装在模板命名空间，供新建实例通过baseRefs引用或作为控制器默认回退，与单个推理实例无绑定关系。删除某个InferNexService时无需也不要删除它们；仅在卸载InferNex Bridge控制面、确认集群不再使用该Bridge时再一并清理。

注意：
若PD-Orchestrator扩缩产生额外workload，删除实例后请同样检查Deployment、ElasticScaler、ResourceScalingGroup等相关资源是否残留，必要时手动清理。

相关操作 ​

除删除实例外，常见运维命令如下。

查看InferNex Bridge控制面。

helm status infernex-bridge -n infernex-bridge-system
kubectl get pods -n infernex-bridge-system

查看推理实例（KServe + LLMInferenceService部署入口）。

kubectl get llminferenceservice,insvc -n kserve
kubectl get pods -n kserve -l infernex.io/runtime=true

查看推理实例（InferNexService部署入口）。

kubectl get insvc -n infernex-bridge-system
kubectl get pods -n infernex-bridge-system

附录 ​

Hermes Router容器命名约定 ​

Hermes Router（Endpoint Picker，EPP）与tokenizer等sidecar同Pod部署。InferencePool.endpointPickerRef指向EPP Service时，控制器按固定容器名与端口名解析后端；命名不符合约定时，流量可能误连到sidecar（如tokenizer的8000），对外常表现为HTTP 500。

表7 Hermes Router EPP模板约束

KServe + LLMInferenceService路径下，Mutating Webhook会清理KServe预设kserve-config-llm-scheduler中的llm-d启动命令与探针，仅保留main/tokenizer容器骨架；须在LLMISVC的router.scheduler.template中写回Hermes镜像、main的args及tokenizer配置。同时建议显式声明tokenizer-tmp、tokenizer-cache等可写卷（与Chart示例一致），详见技术规格 — scheduler 配置修改说明。

最小EPP片段示例（tokenizer与main顺序可互换）：

containers:
  - name: tokenizer
    image: cr.openfuyao.cn/openfuyao/hermes-tokenizer:latest
  - name: main
    image: cr.openfuyao.cn/openfuyao/hermes-router:latest
    ports:
      - name: grpc
        containerPort: 9002

推理引擎的副本与扩缩容 ​

PD-Orchestrator（含Elastic-Scaler、Tidal Controller、ResourceScalingGroup）已在KServe + InferNex Bridge双入口适配。扩缩能否生效取决于推理引擎是否在YAML中省略replicas（不写该字段，而非写0）。Hermes Router、增强组件等仍可写replicas: 1。

表6 两种部署方式下推理引擎扩缩支持对照

说明：
component/InferNex-Bridge/config/examples中replicas: 1仅用于固定副本演示。启用扩缩前请删除engine.replicas（aggregate或decode）、engine.prefill.replicas，以及LLMISVC spec.replicas、spec.prefill.replicas等engine/template相关replicas字段。多Pod DP（dataParallelSize/dataParallelSizeLocal使groupSize>1）时Bridge使用LeaderWorkerSet，此时replicas表示LWS组数而非单Pod数。

省略engine.replicas后，各扩缩能力的使用方式请参见以下文档。

• AI推理弹性伸缩 — 配置伸缩策略
• ResourceScalingGroup — 使用ResourceScalingGroup
• AI推理潮汐算法 — 使用AI推理潮汐算法