企业官网建设流程全解析

• 后端
• API网关
• 模型推理服务
• AI Agent

本文基于 semantic-router 仓库 v0.2 版文档，系统讲解如何将 vLLM Semantic Router（vsr）与 LLM-D 分布式推理平台联合部署在 Kubernetes 上，构建"模型选择器（Model Picker）+ 端点选择器（Endpoint Picker）"的双层路由体系。读完本文你将掌握：LLM-D 与 vsr 各自承担的决策边界、基于 Istio Gateway + Gateway API Inference Extension 的完整部署流程、InferencePool/HTTPRoute 等清单文件的字段含义，以及显式指定模型与model: auto语义路由两种模式下的测试方法。

为什么需要双层路由：Model Picker 与 Endpoint Picker

在大规模 LLM 推理场景中，"路由"通常包含两个完全不同层级的决策：

• 模型选择器（Model Picker）：把一次 LLM 查询路由到多个彼此完全不同的 LLM 模型之一。例如把编程问题发给 code 模型、把数学问题发给 math 模型、把闲聊发给通用模型。这正是 vLLM Semantic Router 的职责——它通过语义信号（如 domain 分类）智能决策。
• 端点选择器（Endpoint Picker）：在提供等价模型（通常是同一 base model）的多个端点之间挑选一个，用于负载均衡、KV Cache 命中优化等。这正是 LLM-D 分布式推理平台的职责。

两者是天然互补的：vsr 负责"选对模型"，LLM-D 负责"在选定的模型池里挑最优实例"。本文演示的部署正是这一互补关系的完整落地，即vsr 作为模型选择器、LLM-D 作为端点选择器。

由于 LLM-D 有多种部署形态（部分需要较大的硬件规模），本文演示的是 LLM-D 的基线版本，用于引入核心概念；这些概念同样适用于 LLM-D 仓库 guides 目录中描述的更复杂配置与生产级 well-lit path。同时，本文使用 Istio 作为 Inference Gateway，以便复用仓库中 Istio 部署示例 的步骤与硬件环境——Istio 也是 LLM-D 有无 vsr 场景下的常用默认网关。

架构总览

本部署由以下五部分组成：

• vLLM Semantic Router：向 Envoy 类网关提供智能请求路由与处理决策；
• LLM-D：用于横向扩展（scaleout）LLM 推理的分布式推理平台；
• Istio Gateway：Istio 对 Kubernetes Gateway API 的实现，底层使用 Envoy Proxy；
• Gateway API Inference Extension：通过 ExtProc 服务器扩展 Gateway API 的推理扩展 API；
• 两个 vLLM 实例，各服务一个模型：用于在本拓扑中演示语义路由的后端 LLM。

整体请求链路可概括为：

client -> Istio Gateway -> Semantic Router model choice | +-> HTTPRoute -> InferencePool -> llm-d EPP -> replica

即：请求先经 Istio 网关，由 vsr 通过 ExtProc 接口完成模型选择，网关依据选择结果把请求交给对应的HTTPRoute，路由到InferencePool，最终由池内的 LLM-D 端点选择器（EPP）挑选出具体副本。

前置条件

动手之前请确认已安装以下工具：

• Docker：容器运行时；
• minikube：本地 Kubernetes；
• kind：Docker 中的 Kubernetes（minikube 与 kind 二选一即可，下文以 minikube 为例）；
• kubectl：Kubernetes CLI；
• Helm：Kubernetes 包管理器；
• istioctl：Istio CLI。

本文建立在 vsr + Istio 部署指南 之上，公共部分直接引用该指南，本文只补充增量步骤。与 Istio 指南一致，你需要一台至少 2 块 GPU的机器来运行本练习，以便部署并测试 vsr 在两个不同 LLM 基础模型之间的模型路由。

Step 1：Istio 指南中的公共步骤

首先按照 Istio 指南 的 Step 1 创建本地 minikube 集群（含 GPU 支持）：

# Create cluster minikube start \ --driver docker \ --container-runtime docker \ --gpus all \ --memory no-limit \ --cpus no-limit # Verify cluster is ready kubectl wait --for=condition=Ready nodes --all --timeout=300s

Step 2：安装 Istio Gateway、Gateway API 与 Inference Extension CRDs

按照 Istio 指南 的描述，完整安装以下组件（使用该指南文档中记录的同一 Istio 版本）：

• Kubernetes Gateway API 的 CRD；
• Gateway API Inference Extension 的 CRD（该扩展提供了InferencePool等 API，详见下文 Step 4）；
• Istio 控制面（istiod）；
• 一个 Istio Gateway 实例。

如果你遵循 LLM-D 的 well-lit path，这一部分原本会由 LLM-D 仓库提供的 Gateway provider Helm chart 完成；本文手动安装是为了与仓库中的 Istio 指南保持公共与可复用，也有助于读者理解 GIE/EPP 部署与 LLM-D 部署之间的公共部分，以及 vsr 如何在两种场景下工作。

安装完成后，用以下命令验证 gateway api 与 inference extension 的 CRD，以及 Istio gateway 与 istiod 的 Pod 是否正常运行：

kubectl get crds | grep gateway

kubectl get crds | grep inference

kubectl get pods | grep istio

kubectl get pods -n istio-system

Step 3：部署 LLM 模型

按照 Istio 指南 部署两个 LLM。该步骤在 LLM-D 部署文档中的对应物是 LLM-D Model Service 的搭建；为保持简单，本指南不需要 LLM-D Model Service。

首先为你的 HuggingFace token（已存入环境变量HF_TOKEN）创建 Secret：

kubectl create secret generic hf-token-secret --from-literal=token=$HF_TOKEN

然后创建运行 llama3-8b 的 vLLM 服务（对应清单文件 vLlama3.yaml）：

kubectl apply -f deploy/kubernetes/istio/vLlama3.yaml

首次运行时，模型下载可能需要 10 分钟以上，直到运行该模型的 vLLM Pod 进入 READY 状态。随后部署第二个 LLM（phi4-mini，对应 vPhi4.yaml），同样等待若干分钟直至 Pod READY：

kubectl apply -f deploy/kubernetes/istio/vPhi4.yaml

从清单文件看，两个模型 Pod 均使用vllm/vllm-openai:v0.17.0镜像、各申请 1 张nvidia.com/gpu、各挂载一个 PVC（llama-8b 为 40Gi、phi4-mini 为 20Gi），并通过HUGGING_FACE_HUB_TOKEN引用hf-token-secret。llama3-8b 以--served-model-name llama3-8b暴露meta-llama/Llama-3.1-8B-Instruct，phi4-mini 以--served-model-name phi4-mini暴露microsoft/Phi-4-mini-instruct，均启用--enable-chunked-prefill。两个 Deployment 都通过httpGet /health:8000做存活与就绪探针（initialDelaySeconds 600），并各对应一个 ClusterIP 类型的 Kubernetes Service（端口 80 → targetPort 8000）。

部署完成后，用下面的命令确认两个 vLLM Pod 处于 READY 状态并查看暴露模型的 Service IP/端口：

# Verify that vLLM pods running the two LLMs are READY and serving kubectl get pods NAME READY STATUS RESTARTS AGE llama-8b-57b95475bd-ph7s4 1/1 Running 0 9d phi4-mini-887476b56-74tvw 1/1 Running 0 9d # View the IP/port of the Kubernetes services on which these models are being served kubectl get service NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE kubernetes ClusterIP 10.96.0.1 <none> 443/TCP 36d llama-8b ClusterIP 10.108.250.109 <none> 80/TCP 18d phi4-mini ClusterIP 10.97.252.33 <none> 80/TCP 9d

上例中 llama3-8b 模型通过 Service IP10.108.250.109、端口80提供服务（实际 IP 以你的集群为准）。

Step 4：部署 InferencePool 与 LLM-D 调度器

LLM-D（以及 Kubernetes IGW）使用名为InferencePool的 API 资源，配合一个调度器（称为 LLM-D inference scheduler，有时等价地称为 EndPoint Picker / EPP）。

按顺序应用本仓库 deploy/kubernetes/llmd-base 目录下提供的清单，为本次练习用到的两个基础模型各创建一个 InferencePool 与对应的 LLM-D inference scheduler：

# Create the LLM-D scheduler and InferencePool for the Llama3-8b model kubectl apply -f deploy/kubernetes/llmd-base/inferencepool-llama.yaml

# Create the LLM-D scheduler and InferencePool for the phi4-mini model kubectl apply -f deploy/kubernetes/llmd-base/inferencepool-phi4.yaml

为什么每个池只放 1 个端点？要完整展示"模型选择 + 端点选择"的组合，理论上需要至少 2 个 InferencePool、每个池至少 2 个端点，这需要 4 个 vLLM 服务 Pod 和 4 块 GPU。本指南为每个 InferencePool 部署 1 个模型端点，足以演示 vsr 的模型选择如何与 LLM-D 调度器的端点选择配合互补的核心设计。

清单文件深度解析

以 inferencepool-llama.yaml 为例，一份清单实际包含了多个资源：

① InferencePool（API 组inference.networking.k8s.io/v1）——声明一个模型池及其端点选择器：

apiVersion: inference.networking.k8s.io/v1 kind: InferencePool metadata: name: vllm-llama3-8b-instruct spec: targetPorts: - number: 8000 selector: matchLabels: app: vllm-llama3-8b-instruct endpointPickerRef: name: vllm-llama3-8b-instruct-epp kind: Service port: number: 9002

• targetPorts：池内后端副本暴露的端口（与 vLLM 的 8000 端口一致）；
• selector.matchLabels：通过 Pod 标签（app: vllm-llama3-8b-instruct）圈定池内成员，与 vLlama3.yaml 中 Deployment 的标签一致；
• endpointPickerRef：引用负责本池端点选择的 EPP Service（vllm-llama3-8b-instruct-epp，端口 9002）。

② EPP Service + ServiceAccount + Deployment——即 LLM-D inference scheduler 本体：镜像为ghcr.io/llm-d/llm-d-router-endpoint-picker:v0.10.0，通过命令行参数声明--pool-name、--pool-namespace、--pool-group（inference.networking.k8s.io）、gRPC 端口--grpc-port 9002与健康端口--grpc-health-port 9003，并通过--config-file /config/default-plugins.yaml加载调度插件配置。

③plugins-configConfigMap——EPP 的调度策略核心（llm-d.ai/v1alpha1的EndpointPickerConfig），默认配置了 5 类插件与一个加权调度 profile：

apiVersion: llm-d.ai/v1alpha1 kind: EndpointPickerConfig plugins: - type: queue-scorer - type: kv-cache-utilization-scorer - type: prefix-cache-scorer - type: metrics-data-source parameters: scheme: http path: /metrics insecureSkipVerify: true - type: core-metrics-extractor schedulingProfiles: - name: default plugins: - pluginRef: queue-scorer weight: 2 - pluginRef: kv-cache-utilization-scorer weight: 2 - pluginRef: prefix-cache-scorer weight: 3

可以看到默认调度优先考虑前缀缓存命中（prefix-cache-scorer，权重 3），其次均衡队列长度（queue-scorer）与 KV Cache 利用率（kv-cache-utilization-scorer，权重各 2），metrics-data-source通过http://<endpoint>/metrics拉取指标供打分使用。这就是 LLM-D 端点选择的实际工作方式。

④ Role / RoleBinding——授予 EPP 读取inferencepools、inferenceobjectives、inferencemodelrewrites（含inference.networking.x-k8s.io与llm-d.ai两组 API 组）以及pods资源的权限，供调度器感知池内副本状态。

两份清单（llama / phi4）结构完全一致，仅名称、选择器与roleRef的绑定名不同。

Step 5：为 LLM-D 连接添加额外的 Istio 配置

添加 DestinationRule，允许每个 EPP / LLM-D 调度器在不使用 TLS的情况下使用 ExtProc（当前 Istio 的限制）：

# Istio destinationrule for the Llama3-8b pool scheduler kubectl apply -f deploy/kubernetes/llmd-base/dest-rule-epp-llama.yaml

# Istio destinationrule for the phi4-mini pool scheduler kubectl apply -f deploy/kubernetes/llmd-base/dest-rule-epp-phi4.yaml

对应清单 dest-rule-epp-llama.yaml 的内容是：

apiVersion: networking.istio.io/v1 kind: DestinationRule metadata: name: epp-llama-8b-insecure-tls spec: host: vllm-llama3-8b-instruct-epp trafficPolicy: tls: mode: SIMPLE insecureSkipVerify: true

即对 EPP 主机启用SIMPLETLS 模式但跳过证书校验，规避 Istio 对 ExtProc 的 TLS 限制。

Step 6：更新 vsr 配置

由于本指南复用了 Istio 指南 的同一组后端模型，因此可以复用该指南的 vsr 配置，无需修改 deploy/kubernetes/istio/config.yaml。若你在 LLM-D 部署中使用了不同的后端模型，则需要更新该文件。

关于配置内容：vsr 的模型卡片、domain 信号与路由决策都集中在该配置（以及 Helm values 文件）中。本示例共定义了 14 个 domain 信号（business、law、psychology、biology、chemistry、history、other、health、economics、math、physics、computer science、philosophy、engineering），两张模型卡（llama3-8b、phi4-mini），以及对应每个 domain 的路由决策（decision）。以math决策为例，它通过type: domain / name: math条件匹配，并modelRefs指向phi4-mini——这正是下文测试中"2+2 是多少"被路由到 phi4-mini 的原因；而computer science决策则指向llama3-8b，对应"Linux 开源内核"类问题。other决策优先级（priority: 5）低于其他决策（priority: 10），作为兜底。

Step 7：部署 vLLM Semantic Router

使用 Helm 部署语义路由器服务及其所有必需组件：

# Install with custom values from GHCR OCI registry # (Optional) If you use a registry mirror/proxy, append: --set global.imageRegistry=<your-registry> helm install semantic-router oci://ghcr.io/vllm-project/charts/semantic-router \ --version v0.0.0-latest \ --namespace vllm-semantic-router-system \ --create-namespace \ -f deploy/kubernetes/llm-d/semantic-router-values/values.yaml # Wait for deployment to be ready (this may take several minutes for model downloads) kubectl wait --for=condition=Available deployment/semantic-router -n vllm-semantic-router-system --timeout=600s # Verify deployment status kubectl get pods -n vllm-semantic-router-system

注意：values 文件（semantic-router-values/values.yaml）包含语义路由器的完整配置——模型设置、分类与路由规则。可先下载到本地再按需定制。该 values 文件的关键结构为：

• gateway.mode: extproc：声明网关通过 ExtProc 调用路由器；
• config.providers：定义模型卡llama3-8b、phi4-mini及其backend_refs（provider: vllm，endpoint 分别为llama-8b:80、phi4-mini:80，weight 1）；
• config.routing.decisions：14 个按 domain 匹配的决策，每个决策可带modelRefs（含use_reasoning开关）与plugins（如system_prompt、response_cache）；
• global.services.api.batch_classification：批处理分类参数（max_batch_size: 100、max_concurrency: 8）及直方图监控桶（duration/size buckets）；
• global.stores：response_cache（默认 memory 后端、similarity_threshold: 0.8、max_entries: 1000、ttl_seconds: 3600、eviction_policy: fifo）、memory与vector_store的 embedding 模型均默认mmbert。

Step 8：为 VSR 连接添加额外的 Istio 配置

安装 Istio 网关通过 ExtProc 接口与 vLLM Semantic Router 通信所需的 destinationrule 与 envoy filter：

kubectl apply -f deploy/kubernetes/istio/destinationrule.yaml kubectl apply -f deploy/kubernetes/istio/envoyfilter.yaml

其中 destinationrule.yaml 将semantic-router.vllm-semantic-router-system.svc.cluster.local的 TLS 设为DISABLE（禁用 mTLS 以直连 vsr 的 gRPC 服务）。

envoyfilter.yaml 则通过workloadSelector选中标签为gateway.networking.k8s.io/gateway-name: inference-gateway的网关工作负载，向HTTP_FILTER链INSERT_FIRST注入envoy.filters.http.ext_proc外部处理器，其关键配置包括：

• mutation_rules.allow_expression：仅允许 ext_proc 设置x-envoy-upstream-rq-timeout-ms、x-envoy-upstream-rq-per-try-timeout-ms、x-envoy-max-retries、x-envoy-retry-on、x-envoy-retriable-status-codes这几个 per-request 可靠性相关头（决策的 reliability block 通过它们到达 Envoy router，ext_proc 不得设置其他 x-envoy-* 头）；
• failure_mode_allow: true与allow_mode_override: true：外部处理器故障时放行、允许覆盖处理模式，保证网关可用性；
• message_timeout: 300s：ExtProc 消息超时；
• processing_mode：请求头SEND、响应头SEND、请求体BUFFERED、响应体与 trailer 均SKIP；
• grpc_service.envoy_grpc.cluster_name：指向outbound|50051||semantic-router.vllm-semantic-router-system.svc.cluster.local，即 vsr 的 gRPC 服务。

Step 9：安装网关路由

在 Istio 网关中安装 HTTPRoute。注意与先前 vsr + Istio 指南中 HTTPRoute 的关键区别：此处路由的backendRefs指向InferencePool（再由池指向其 LLM-D 调度器），而不是像无 LLM-D 的 Istio 指南那样直接指向模型的 vllm 服务端点：

kubectl apply -f deploy/kubernetes/llmd-base/httproute-llama-pool.yaml kubectl apply -f deploy/kubernetes/llmd-base/httproute-phi4-pool.yaml

以 httproute-llama-pool.yaml 为例：

apiVersion: gateway.networking.k8s.io/v1 kind: HTTPRoute metadata: name: vsr-llama8b spec: parentRefs: - group: gateway.networking.k8s.io kind: Gateway name: inference-gateway rules: - backendRefs: - group: inference.networking.k8s.io kind: InferencePool name: vllm-llama3-8b-instruct matches: - path: type: PathPrefix value: / headers: - type: Exact name: x-selected-model value: llama3-8b timeouts: request: 300s

关键点：

• parentRefs指向inference-gateway（对应 gateway.yaml 中创建的 Istio Gateway，监听 HTTP 80 端口）；
• 匹配条件为请求头x-selected-model: llama3-8b精确匹配——该头正是 vsr 通过 ExtProc 决策后注入请求、用于通知网关"该去哪个模型"的信令头；
• 命中后请求转发到InferencePool（vllm-llama3-8b-instruct）而不是直接到某个 Service，从而让 LLM-D EPP 在池内做端点选择；
• request: 300s超时与 ExtProcmessage_timeout保持一致。

phi4 版本（httproute-phi4-pool.yaml）结构相同，仅名称（vsr-phi4-mini）、池名与匹配头值不同。

注意：不要同时应用 Istio 示例中的直连 Service 路由（httproute-llama3-8b.yaml 等）。两套路由匹配的是相同的x-selected-model值，会造成归属歧义（ambiguous ownership）。

Step 10：测试部署

要对外暴露 Istio 网关监听客户端请求的 IP，可以选择任意标准的 Kubernetes 外部负载均衡方案。仓库测试时采用在集群中部署并配置metallb作为 LoadBalancer 提供方（安装过程参见 metallb 官方文档）。在 minikube 场景下，按如下方式获取外部 URL：

minikube service inference-gateway-istio --url http://192.168.49.2:32293

现在即可通过 curl 向http://192.168.49.2:32293发送 LLM 提示词，访问 Istio 网关；网关会利用 vLLM Semantic Router 的信息动态路由到两个后端 LLM 之一。请将 curl 示例中的端口替换为你minikube service命令实际输出的端口。

发送测试请求

分别尝试显式指定模型与model: "auto"自动选择两类用例，以确认 Istio + vsr 能将查询路由到正确模型。响应中会包含本次请求由哪个模型服务的信息。

用例 1：显式指定 llama3-8b（不做模型改写，直接交给 llama EPP 做端点选择）：

curl http://192.168.49.2:32293/v1/chat/completions -H "Content-Type: application/json" -d '{ "model": "llama3-8b", "messages": [ {"role": "user", "content": "Linux is said to be an open source kernel because "} ], "max_tokens": 100, "temperature": 0 }'

用例 2：model: "auto"（应分类为 "computer science" 并路由到 llama3-8b）：

curl http://192.168.49.2:32293/v1/chat/completions -H "Content-Type: application/json" -d '{ "model": "auto", "messages": [ {"role": "user", "content": "Linux is said to be an open source kernel because "} ], "max_tokens": 100, "temperature": 0 }'

用例 3：显式指定 phi4-mini（不做模型改写，直接交给 phi4-mini EPP 做端点选择）：

curl http://192.168.49.2:32293/v1/chat/completions -H "Content-Type: application/json" -d '{ "model": "phi4-mini", "messages": [ {"role": "user", "content": "2+2 is "} ], "max_tokens": 100, "temperature": 0 }'

用例 4：model: "auto"（应分类为 "math" 并路由到 phi4-mini）：

curl http://192.168.49.2:32293/v1/chat/completions -H "Content-Type: application/json" -d '{ "model": "auto", "messages": [ {"role": "user", "content": "2+2 is "} ], "max_tokens": 100, "temperature": 0 }'

这四个用例恰好覆盖双层路由的两条路径：显式指定模型时，网关直接按x-selected-model头路由到对应池，由 LLM-D EPP 做端点选择；model: auto时，vsr 先对提示词做 domain 分类并改写模型名、注入选择头，网关再据此路由。仓库 llmd-base/README.md 还提供了一个更稳健的测试写法——动态获取网关 URL 并使用curl --fail-with-body：

GATEWAY_URL="$(minikube service inference-gateway-istio --url)" curl --fail-with-body "$GATEWAY_URL/v1/chat/completions" \ -H 'Content-Type: application/json' \ -d '{ "model": "auto", "messages": [{"role": "user", "content": "Explain a Linux process."}], "max_tokens": 64, "temperature": 0 }'

建议先用model: llama3-8b/model: phi4-mini验证显式路由解析，再用model: auto验证语义模型选择；只有当你需要验证池内端点选择时，才为池添加多个后端副本。

故障排查

基本 Pod 校验

按上述步骤操作后，应看到类似下面的 Pod 均处于 READY 状态（快速初验）：LLM 模型 Pod、Istio gateway Pod、LLM-D/EPP 调度器 Pod、vsr Pod 与 istiod 控制器 Pod；同时应能看到 InferencePool 与 HTTPRoute 实例，且路由状态为 resolved：

$ kubectl get pods -n default NAME READY STATUS RESTARTS AGE inference-gateway-istio-6fc8864bfb-gbcz8 1/1 Running 0 14h llama-8b-6558848cc8-wkkxn 1/1 Running 0 3h26m phi4-mini-7b94bc69db-rnpkj 1/1 Running 0 17h vllm-llama3-8b-instruct-epp-7f7ff88677-j7lst 1/1 Running 0 134m vllm-phi4-mini-epp-6f5dd6bbb9-8pv27 1/1 Running 0 14h

$ kubectl get pods -n vllm-semantic-router-system NAME READY STATUS RESTARTS AGE semantic-router-bf6cdd5b9-t5hpg 1/1 Running 0 5d23h

$ kubectl get pods -n istio-system NAME READY STATUS RESTARTS AGE istiod-6f5ccc65c-vnbg5 1/1 Running 0 15h

$ kubectl get inferencepools NAME AGE vllm-llama3-8b-instruct 139m vllm-phi4-mini 15h

$ kubectl get httproutes NAME HOSTNAMES AGE vsr-llama8b 13h vsr-phi4-mini 13h

$ kubectl get httproute vsr-llama8b -o yaml | grep -A 1 "reason: ResolvedRefs" reason: ResolvedRefs status: "True"

ResolvedRefs: True表示路由引用的对象（InferencePool）已成功解析。更通用的做法是直接查看路由与池的状态条件，而不是拿 Pod 名与示例硬比对：

kubectl describe httproute vsr-llama8b kubectl describe inferencepool vllm-llama3-8b-instruct

常见问题

网关 / 前端不工作：

# Check istio gateway status kubectl get gateway # Check istio gw service status kubectl get svc inference-gateway-istio # Check Istio's Envoy logs kubectl logs deploy/inference-gateway-istio -c istio-proxy

语义路由器无响应或路由不正确：

# Check semantic router pod kubectl get pods -n vllm-semantic-router-system # Check semantic router service kubectl get svc -n vllm-semantic-router-system # Check semantic router logs kubectl logs -n vllm-semantic-router-system deployment/semantic-router

结合仓库 llmd-base/README.md 的排障建议，还可按以下思路定位：

• HTTPRoute 引用未解析：检查所安装的 Inference Extension API 版本与InferencePool名称是否匹配；
• EPP 未就绪：查看 EPP Deployment 日志及其 RBAC 资源（EPP 需要读取inferencepools与pods的权限，缺失会导致无法感知池内副本）；
• 请求绕过池：删除针对同一选中模型（x-selected-model）的直连 Service 路由（两套路由同时存在会造成归属歧义）；
• 选错模型池：对比 Router 的模型别名与发出的x-selected-model值是否与HTTPRoute的 header match 一致。

kubectl logs deployment/llm-d-inference-scheduler-llama3-8b kubectl logs deployment/inference-gateway-istio -c istio-proxy kubectl logs deployment/semantic-router \ --namespace vllm-semantic-router-system

清理

移除整个部署：

# Remove gateway routes kubectl delete -f deploy/kubernetes/llmd-base/httproute-llama-pool.yaml kubectl delete -f deploy/kubernetes/llmd-base/httproute-phi4-pool.yaml # Remove Istio VSR configuration kubectl delete -f deploy/kubernetes/istio/envoyfilter.yaml kubectl delete -f deploy/kubernetes/istio/destinationrule.yaml # Remove semantic router helm uninstall semantic-router -n vllm-semantic-router-system # Remove LLM-D DestinationRules kubectl delete -f deploy/kubernetes/llmd-base/dest-rule-epp-phi4.yaml kubectl delete -f deploy/kubernetes/llmd-base/dest-rule-epp-llama.yaml # Remove InferencePools kubectl delete -f deploy/kubernetes/llmd-base/inferencepool-phi4.yaml kubectl delete -f deploy/kubernetes/llmd-base/inferencepool-llama.yaml # Remove LLMs kubectl delete -f deploy/kubernetes/istio/vPhi4.yaml kubectl delete -f deploy/kubernetes/istio/vLlama3.yaml # Remove Istio istioctl uninstall --purge # Stop minikube cluster minikube stop # Delete minikube cluster minikube delete

共享的 Router、Gateway 与模型资源，按 Istio 指南 的清理步骤处理即可。

下一步：向生产形态演进

完成基线部署后，可以沿着以下方向继续：

• 测试 / 实验 vLLM Semantic Router 的更多特性（PromptGuard、ToolCalling 等，建议先掌握基础的 prompt 分类与模型路由）；
• 测试 / 实验更复杂的 LLM-D 配置与 well-lit path（每池多端点，真正验证端点选择收益）；
• 建立监控与可观测性（values 中已预留 OpenTelemetry / OTLP tracing 配置项，可将global.services.observability.tracing.enabled打开并指向 Jaeger 等收集端）；
• 实现认证与授权（Istio 侧）；
• 为生产工作负载扩展语义路由器部署。

仓库中的参考材料：LLM-D 集成的完整说明见 deploy/kubernetes/llmd-base/README.md；如果还想在同一拓扑中接入 OpenAI 兼容的托管模型（如gpt-4o-mini），可以进一步参考 llmd+public-llm 示例，该示例展示了本地 InferencePool 与托管端点（通过 Istio egress Service + HTTPRoute 表示）由 vsr 统一选择的路由形态，注意其中涉及凭据注入，务必遵循集群内的安全注入机制。

• 后端
• API网关
• 模型推理服务
• AI Agent