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

本文是一份围绕 Semantic Router 项目中Milvus 语义缓存后端的完整技术指南：从为什么需要把默认的内存缓存替换为 Milvus 向量库，到如何在 Kubernetes 中通过 Helm 或 Milvus Operator 完成独立（Standalone）与集群（Cluster）两种模式的部署，再到客户端配置、网络安全（NetworkPolicy / TLS / 认证）、从内存缓存平滑迁移、备份恢复与故障排查的完整运维闭环。读完本文，你将能够在 vllm-semantic-router-system 命名空间下独立搭建一套持久化、可横向扩展、支持多副本共享的语义缓存，并理解 Milvus 缓存命中的底层检索原理（HNSW 索引、IP 相似度、阈值过滤）。

Milvus 语义缓存是什么：为什么需要它

Semantic Router 默认开箱即用的缓存后端是进程内内存缓存，速度快但存在三个明显短板：数据不持久（重启即失）、无法横向扩展（容量受单 Pod 内存限制）、无法跨副本共享（每个 Router 副本各持一份缓存，命中率被稀释）。将 Milvus 作为语义缓存后端，正好解决这三个问题：

• 持久化：请求-响应对写入 Milvus 后落盘存储，Router 重启后缓存依然可用；
• 横向扩展：Milvus 是独立的分布式向量数据库，缓存容量只受 Milvus 集群资源约束；
• 缓存共享：多个 Semantic Router 副本读写同一个 Milvus 集合（Collection），任意副本写入的缓存其余副本都能命中。

Milvus 是可选项。Router 不依赖它也能运行；只有当你的场景需要持久化、水平扩展或跨副本共享时，才引入 Milvus。文档明确指出：Milvus is optional. The router works with the default memory backend out of the box.（见 website/versioned_docs/version-v0.2/installation/milvus.md）。

从源码结构看，Milvus 缓存实现位于 src/semantic-router/pkg/cache/ 目录，核心文件包括：

• milvus_cache.go：MilvusCache主实现，负责连接、集合初始化、条目写入（Upsert）与精确缓存；
• milvus_cache_similar.go：语义相似检索（FindSimilar/LookupSimilarWithThreshold）与相似度阈值过滤；
• milvus_cache_admin.go：连接健康检查、关闭与 RAG 文档检索；
• exact_cache_milvus.go：基于确定性指纹的精确响应缓存；
• lifecycle.go：连接（gRPC）与集合创建/加载/重试的共享生命周期工具。

部署前置条件

在开始部署之前，请确认以下条件满足：

• Kubernetes 集群：kubectl已正确配置并可以访问目标集群；
• 默认 StorageClass：集群中存在可用的默认StorageClass，因为 Milvus 的 Helm Chart 与 Operator 会自动为 etcd 和 MinIO 创建 PVC；
• Helm 3.x：已安装 Helm 3 或更高版本。

此外，默认的 Helm values 会启用 ServiceMonitor 用于 Prometheus 指标采集，这要求集群中预先安装 Prometheus Operator。如果只是测试环境、没有 Prometheus Operator，务必在安装命令中加入--set metrics.serviceMonitor.enabled=false（下文所有部署命令均已体现这一差异）。

部署方案选型：Helm 还是 Milvus Operator

文档给出两种官方途径：

两种方案都支持 Standalone 与 Cluster 两种形态，下文分别给出完整命令与配置。

方式一：Helm 部署 Milvus

Standalone 模式（开发与小规模）

先添加并更新官方 Helm 仓库：

helm repo add milvus https://zilliztech.github.io/milvus-helm/ helm repo update

无 Prometheus Operator（测试/开发）：

helm install milvus-semantic-cache milvus/milvus \ --set cluster.enabled=false \ --set etcd.replicaCount=1 \ --set minio.mode=standalone \ --set pulsar.enabled=false \ --set metrics.serviceMonitor.enabled=false \ --namespace vllm-semantic-router-system --create-namespace

有 Prometheus Operator（生产并带监控）：

helm install milvus-semantic-cache milvus/milvus \ --set cluster.enabled=false \ --set etcd.replicaCount=1 \ --set minio.mode=standalone \ --set pulsar.enabled=false \ --namespace vllm-semantic-router-system --create-namespace

两个命令的唯一区别是后者省略了metrics.serviceMonitor.enabled=false，从而启用 ServiceMonitor。

Cluster 模式（生产高可用）

Milvus 2.4+ 默认使用 Pulsar v3。下方的 values 显式禁用旧版 Pulsar，避免新旧两个消息队列组件同时运行产生冲突。

helm repo add milvus https://zilliztech.github.io/milvus-helm/ helm repo update

无 Prometheus Operator（测试）：

helm install milvus-semantic-cache milvus/milvus \ --set cluster.enabled=true \ --set etcd.replicaCount=3 \ --set minio.mode=distributed \ --set pulsar.enabled=false \ --set pulsarv3.enabled=true \ --set metrics.serviceMonitor.enabled=false \ --namespace vllm-semantic-router-system --create-namespace

有 Prometheus Operator（生产带监控）：

helm install milvus-semantic-cache milvus/milvus \ --set cluster.enabled=true \ --set etcd.replicaCount=3 \ --set minio.mode=distributed \ --set pulsar.enabled=false \ --set pulsarv3.enabled=true \ --namespace vllm-semantic-router-system --create-namespace

两个模式的关键参数差异汇总如下：

方式二：Milvus Operator 部署

1. 安装 Milvus Operator

先按照 Milvus Operator 官方说明安装 Operator 本体。安装完成后，集群中会出现milvus.io/v1beta1这个 API 组，用于管理Milvus自定义资源。

2. 应用自定义资源（CR）

Standalone 形态：

kubectl apply -n vllm-semantic-router-system -f - <<EOF apiVersion: milvus.io/v1beta1 kind: Milvus metadata: name: milvus-standalone spec: mode: standalone components: disableMetrics: false dependencies: storage: inCluster: values: mode: standalone deletionPolicy: Delete pvcDeletion: true etcd: inCluster: values: replicaCount: 1 config: {} EOF

Cluster 形态：

kubectl apply -n vllm-semantic-router-system -f - <<EOF apiVersion: milvus.io/v1beta1 kind: Milvus metadata: name: milvus-cluster spec: mode: cluster components: disableMetrics: false dependencies: storage: inCluster: values: mode: distributed deletionPolicy: Retain pvcDeletion: false etcd: inCluster: values: replicaCount: 3 pulsar: inCluster: values: broker: replicaCount: 1 config: {} EOF

注意 Standalone 与 Cluster 在 CR 中的关键差异：

• 存储删除策略：Standalone 使用deletionPolicy: Delete+pvcDeletion: true（删除 CR 时连数据一起清理，适合开发）；Cluster 使用deletionPolicy: Retain+pvcDeletion: false（保留数据，生产必须如此）；
• etcd 副本数：Standalone 为1，Cluster 为3（保证元数据高可用）；
• Pulsar：Cluster 形态显式声明pulsar.inCluster.values.broker.replicaCount: 1。

配置 Semantic Router 客户端

1. 写入 Milvus 客户端 ConfigMap

将 Milvus 客户端配置以 ConfigMap 形式下发到集群：

kubectl apply -n vllm-semantic-router-system -f - <<EOF apiVersion: v1 kind: ConfigMap metadata: name: milvus-client-config data: milvus.yaml: | connection: host: "milvus-semantic-cache.vllm-semantic-router-system.svc.cluster.local" port: 19530 timeout: 60 auth: enabled: false tls: enabled: false collection: name: "semantic_cache" description: "Semantic cache" vector_field: name: "embedding" dimension: 384 metric_type: "IP" index: type: "HNSW" params: M: 16 efConstruction: 64 search: params: ef: 64 topk: 10 consistency_level: "Session" development: auto_create_collection: true verbose_errors: true EOF

这份配置与仓库中自带的 config/runtime/response-cache/milvus.yaml 结构一致，后者额外给出了database、logging.level、development.drop_collection_on_startup等字段的完整注释说明。各字段含义与源码中的配置结构（见 src/semantic-router/pkg/config/runtime_config.go 的MilvusConfig）一一对应：

需要特别说明dimension与metric_type的底层行为。从 milvus_cache.go 的源码可以看到，启动时会对配置做两件事：

1. normalizeMilvusMetricType将度量类型规范化；若最终不是IP/COSINE/L2三者之一，会告警并将得分直接当作相似度使用而不做转换；
2. resolveCacheDimension结合嵌入 Provider 解析真实维度——当dimension配置为0时取嵌入模型自身维度；创建集合（createCollection）时会把解析出的actualDimension写回配置并用于建 schema。

此外，milvus_cache_similar.go 展示了命中判定逻辑：Milvus 返回的原始得分先经milvusScoreToSimilarity按度量类型转换为相似度，再与similarity_threshold（如仓库默认配置中的0.86）比较，只有超过阈值的候选才会被选中并返回缓存响应。因此metric_type的选择直接影响阈值语义与命中率。

2. 更新 Router 主配置

在 Router 的配置文件中启用 Milvus 后端并指向客户端配置：

semantic_cache: backend_type: "milvus" backend_config_path: "config/semantic-cache/milvus.yaml"

从当前仓库的完整参考配置（config/config.yaml）可以看出，实际生产形态会把semantic_cache（源码中类型别名为ResponseCacheStoreConfig，见 runtime_config.go）展开为更细的stores.response_cache结构，并把 Milvus 配置直接内联：

stores: response_cache: backend_type: milvus enabled: true similarity_threshold: 0.86 max_entries: 50000 ttl_seconds: 7200 eviction_policy: lru embedding_model: mmbert milvus: connection: host: milvus port: 19530 database: default timeout: 30 auth: enabled: true username: root password: "${MILVUS_PASSWORD}" tls: enabled: false cert_file: certs/milvus.crt key_file: certs/milvus.key ca_file: certs/ca.crt collection: name: semantic_cache description: Semantic cache vectors. vector_field: name: embedding dimension: 768 metric_type: COSINE index: type: HNSW params: M: 16 efConstruction: 200 search: params: ef: 64 topk: 10 consistency_level: Bounded logging: level: info development: drop_collection_on_startup: false auto_create_collection: true

两者是同一配置的两个表达层次：文档给出的semantic_cache.backend_config_path用于"分离配置文件"的加载方式——源码中NewMilvusCache在Config == nil时会回退到loadMilvusConfig(options.ConfigPath)从独立 YAML 读取并解析（见 milvus_cache.go），并标注该路径为 Deprecated；内联进stores.response_cache.milvus才是当前推荐做法。同时注意仓库注释提到：启用 Milvus 后端需要以-tags=milvus构建（见 config/runtime/response-cache/milvus.yaml）。

3. 关于集合与索引的自动初始化

不需要手工建集合。NewMilvusCache在连接成功后调用initializeCollection（见 milvus_cache.go），其流程是：

1. HasCollection检查集合是否存在；
2. 若配置了drop_collection_on_startup且集合已存在，先 Drop（仅开发模式）；
3. 通过EnsureCollectionLoadedWithRetry（见 lifecycle.go）保证集合存在并已 Load 进入内存可查询状态——集合缺失时若auto_create_collection=true则自动创建，否则报错；创建/加载失败会按 3 次、2 秒退避的重试策略收敛。

自动创建的集合 schema（createCollection）包含：主键id（VARCHAR，max_length=64）、request_id、model、query、request_body、response_body（VARCHAR 65535）、向量字段embedding（FLOAT_VECTOR，维度由嵌入模型解析）、timestamp/ttl_seconds/expires_at（INT64），并自动为向量字段创建 HNSW 索引。这也解释了为什么文档排障章节里手建集合的示例（FieldSchema(name="embedding", dtype=DataType.FLOAT_VECTOR, dim=384)）必须与自动 schema 保持一致。

网络与安全加固

网络策略（NetworkPolicy）

限制只有 Semantic Router 命名空间内的 Router Pod 能访问 Milvus 的 19530 端口：

kubectl apply -n vllm-semantic-router-system -f - <<EOF apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: allow-router-to-milvus spec: podSelector: matchLabels: app.kubernetes.io/name: milvus policyTypes: - Ingress ingress: - from: - namespaceSelector: matchLabels: kubernetes.io/metadata.name: vllm-semantic-router-system podSelector: matchLabels: app.kubernetes.io/name: semantic-router ports: - protocol: TCP port: 19530 EOF

TLS 与认证

1. 创建凭证与证书 Secret：

# 认证凭据 kubectl create secret generic milvus-auth -n vllm-semantic-router-system \ --from-literal=username="YOUR_USERNAME" \ --from-literal=password="YOUR_PASSWORD" # TLS 证书 kubectl create secret generic milvus-tls -n vllm-semantic-router-system \ --from-file=ca.crt=/path/to/ca.crt \ --from-file=client.crt=/path/to/client.crt \ --from-file=client.key=/path/to/client.key

2. 更新 Milvus 客户端配置以启用认证与 TLS：

connection: host: "milvus-cluster.vllm-semantic-router-system.svc.cluster.local" port: 19530 timeout: 60 auth: enabled: true username: "${MILVUS_USERNAME}" password: "${MILVUS_PASSWORD}" tls: enabled: true

技巧：将环境变量或投影式（projected）Secret 卷挂载到 Router 的 Deployment，并在配置中引用。仓库参考配置中正是用username: root+password: "${MILVUS_PASSWORD}"的方式从环境变量注入密码（见 config/config.yaml），TLS 侧则支持cert_file/key_file/ca_file三个文件路径（对应MilvusConfig.Connection.TLS结构，见 runtime_config.go）。

监控与可观测性

安装 Prometheus Operator（如未安装）

kubectl apply -f https://raw.githubusercontent.com/prometheus-operator/prometheus-operator/main/bundle.yaml # 等待 CRD 就绪 kubectl wait --for condition=established --timeout=60s \ crd/servicemonitors.monitoring.coreos.com

部署带监控的 Milvus

ServiceMonitor 默认启用，只需省略--set metrics.serviceMonitor.enabled=false标志：

helm install milvus-semantic-cache milvus/milvus \ --set cluster.enabled=false \ --set etcd.replicaCount=1 \ --set minio.mode=standalone \ --set pulsar.enabled=false \ --namespace vllm-semantic-router-system --create-namespace

验证 ServiceMonitor

kubectl get servicemonitor -n vllm-semantic-router-system

可选：关闭监控

测试环境没有 Prometheus 时，加上--set metrics.serviceMonitor.enabled=false即可（命令与"无 Prometheus Operator 的 Standalone 安装"完全相同）。

从内存缓存迁移到 Milvus

迁移前检查清单

• Milvus 已部署且健康：kubectl get pods -l app.kubernetes.io/name=milvus；
• Router 与 Milvus 之间的网络连通性已验证；
• 已为预期的缓存规模预置足够的存储。

分阶段灰度切换

# 第 1 步：部署 Milvus（这里用 Helm 简化） helm install milvus-semantic-cache milvus/milvus \ --set cluster.enabled=false \ --set etcd.replicaCount=1 \ --set minio.mode=standalone \ --set pulsar.enabled=false \ --set metrics.serviceMonitor.enabled=false \ --namespace vllm-semantic-router-system --create-namespace # 第 2 步：等待就绪 kubectl wait --for=condition=ready pod -l app.kubernetes.io/name=milvus \ -n vllm-semantic-router-system --timeout=300s # 第 3 步：更新 Router 配置（将 backend_type 改为 "milvus"） kubectl edit configmap semantic-router-config -n vllm-semantic-router-system # 第 4 步：滚动重启 Router kubectl rollout restart deployment/semantic-router -n vllm-semantic-router-system

验证缓存生效

# 检查日志中的 Milvus 连接 kubectl logs -l app=semantic-router -n vllm-semantic-router-system | grep -i milvus # 发送请求 curl -X POST http://<router-endpoint>/v1/chat/completions \ -H "Content-Type: application/json" \ -d '{"model": "test", "messages": [{"role": "user", "content": "Hello"}]}' # 重复相同请求，验证缓存命中 curl -X POST http://<router-endpoint>/v1/chat/completions \ -H "Content-Type: application/json" \ -d '{"model": "test", "messages": [{"role": "user", "content": "Hello"}]}'

迁移后的指标观察

• 缓存命中率（hit ratio）在预热后应趋于稳定；
• 延迟：与内存缓存相比，每次查询 Milvus 大约增加 1~5ms；
• 错误率应保持在基线水平。

回滚方案

# 切回内存后端 kubectl patch configmap semantic-router-config -n vllm-semantic-router-system \ --type merge -p '{"data":{"config.yaml":"semantic_cache:\n backend_type: \"memory\""}}' # 重启 Router kubectl rollout restart deployment/semantic-router -n vllm-semantic-router-system # 验证 kubectl logs -l app=semantic-router -n vllm-semantic-router-system | grep -i "cache"

重要：切回内存后端不会删除 Milvus 中的数据，之后切回时缓存数据仍可复用。

备份与恢复

备份策略

策略 1：Milvus 原生备份（推荐），使用 milvus-backup 工具：

# 安装 wget https://github.com/zilliztech/milvus-backup/releases/latest/download/milvus-backup_Linux_x86_64.tar.gz tar -xzf milvus-backup_Linux_x86_64.tar.gz # 创建备份 ./milvus-backup create -n semantic_cache_backup \ --milvus.address milvus-cluster.vllm-semantic-router-system.svc.cluster.local:19530 # 列出 / 恢复 ./milvus-backup list ./milvus-backup restore -n semantic_cache_backup

策略 2：存储层备份，使用卷快照（需 CSI snapshot controller）：

apiVersion: snapshot.storage.k8s.io/v1 kind: VolumeSnapshot metadata: name: milvus-data-snapshot namespace: vllm-semantic-router-system spec: volumeSnapshotClassName: csi-snapclass source: persistentVolumeClaimName: milvus-data

策略 3：MinIO/S3 备份（Cluster 模式），为存储桶开启版本控制与复制：

mc version enable myminio/milvus-bucket mc replicate add myminio/milvus-bucket --remote-bucket milvus-bucket-dr \ --arn "arn:minio:replication::..."

恢复流程

从 milvus-backup 恢复：

# 停掉 Router kubectl scale deployment/semantic-router -n vllm-semantic-router-system --replicas=0 # 恢复（含索引） ./milvus-backup restore -n semantic_cache_backup --restore_index # 重启 Router kubectl scale deployment/semantic-router -n vllm-semantic-router-system --replicas=3

从卷快照恢复：

kubectl apply -f - <<EOF apiVersion: v1 kind: PersistentVolumeClaim metadata: name: milvus-data-restored namespace: vllm-semantic-router-system spec: dataSource: name: milvus-data-snapshot kind: VolumeSnapshot apiGroup: snapshot.storage.k8s.io accessModes: - ReadWriteOnce resources: requests: storage: 20Gi EOF

备份频率建议

故障排查实战

旧 Pulsar 与 Pulsar v3 同时运行

• 症状：Cluster 模式下同时出现milvus-semantic-cache-pulsar-*和milvus-semantic-cache-pulsarv3-*两类 Pod；
• 原因：Helm values 同时启用了旧版 Pulsar 与 Pulsar v3；
• 解决：只使用 Pulsar v3（Milvus 2.4+ 推荐）。卸载后按正确配置重装：

helm uninstall milvus-semantic-cache -n vllm-semantic-router-system helm install milvus-semantic-cache milvus/milvus \ --set cluster.enabled=true \ --set etcd.replicaCount=3 \ --set minio.mode=distributed \ --set pulsar.enabled=false \ --set pulsarv3.enabled=true \ --set metrics.serviceMonitor.enabled=false \ --namespace vllm-semantic-router-system --create-namespace

ServiceMonitor CRD 不存在

• 症状：Helm 安装失败，报错no matches for kind "ServiceMonitor" in version "monitoring.coreos.com/v1"；
• 解决：二选一——测试环境禁用 ServiceMonitor，或先安装 Prometheus Operator：

# 方案 1：禁用 ServiceMonitor（测试推荐） helm install milvus-semantic-cache milvus/milvus \ --set cluster.enabled=false \ --set etcd.replicaCount=1 \ --set minio.mode=standalone \ --set pulsar.enabled=false \ --set metrics.serviceMonitor.enabled=false \ --namespace vllm-semantic-router-system --create-namespace # 方案 2：先装 Prometheus Operator kubectl apply -f https://raw.githubusercontent.com/prometheus-operator/prometheus-operator/main/bundle.yaml

连接问题

• 症状：failed to connect to Milvus: context deadline exceeded；
• 排查：

# 确认 Milvus 在运行 kubectl get pods -l app.kubernetes.io/name=milvus -n vllm-semantic-router-system # 检查 Service 端点 kubectl get svc -l app.kubernetes.io/name=milvus -n vllm-semantic-router-system # 从 Router Pod 内测试连通性 kubectl exec -it deploy/semantic-router -n vllm-semantic-router-system -- \ nc -zv milvus-cluster.vllm-semantic-router-system.svc.cluster.local 19530 # 检查 NetworkPolicy kubectl get networkpolicy -n vllm-semantic-router-system # 验证 DNS 解析 kubectl exec -it deploy/semantic-router -n vllm-semantic-router-system -- \ nslookup milvus-cluster.vllm-semantic-router-system.svc.cluster.local

从源码看，连接阶段有两条路径：无认证走ConnectGRPC（lifecycle.go，内部调用client.NewGrpcClient），带用户名/密码走Connect（基于client.Config）；连接上下文会应用配置的timeout（见 milvus_cache.go）。连接建立后还会通过ListCollections做健康检查（CheckConnection，见 milvus_cache.go），失败即返回错误。因此timeout过小或网络策略拦截都会直接体现为上述症状。

认证失败

• 症状：authentication failed或access denied；
• 排查：

# 核对凭据 kubectl get secret milvus-auth -n vllm-semantic-router-system -o jsonpath='{.data.username}' | base64 -d # 查看 Milvus proxy 日志中的认证记录 kubectl logs -l app.kubernetes.io/component=proxy -n vllm-semantic-router-system | grep -i auth # 核对 Router 配置 kubectl get configmap milvus-client-config -n vllm-semantic-router-system -o yaml

性能问题

• 症状：高延迟或超时；
• 排查：

# 查看资源占用 kubectl top pods -l app.kubernetes.io/name=milvus -n vllm-semantic-router-system # 查看指标 kubectl port-forward svc/milvus-cluster 9091:9091 -n vllm-semantic-router-system # 访问 http://localhost:9091/metrics

用 pymilvus 检查集合状态：

from pymilvus import connections, Collection connections.connect(host="localhost", port="19530") col = Collection("semantic_cache") print(col.num_entities) print(col.index())

性能调优要点可以对照配置中的 HNSW 参数：efConstruction影响建索引质量（建索引慢但召回更高），search.params.ef影响查询精度与耗时，topk决定每次检索的候选规模——仓库参考配置在efConstruction: 200、similarity_threshold: 0.86、topk: 10的组合下工作（见 config/config.yaml）。

集合异常

• 症状：collection not found或 schema 不匹配；
• 排查：

# 列出集合 kubectl exec -it deploy/milvus-cluster-proxy -n vllm-semantic-router-system -- \ curl -s localhost:9091/api/v1/collections # 检查自动创建设置 kubectl get configmap milvus-client-config -n vllm-semantic-router-system -o yaml | grep auto_create

手工创建集合（schema 必须与自动创建的保持一致）：

from pymilvus import connections, Collection, FieldSchema, CollectionSchema, DataType connections.connect(host="localhost", port="19530") fields = [ FieldSchema(name="id", dtype=DataType.VARCHAR, is_primary=True, max_length=64), FieldSchema(name="embedding", dtype=DataType.FLOAT_VECTOR, dim=384), FieldSchema(name="response", dtype=DataType.VARCHAR, max_length=65535), ] schema = CollectionSchema(fields, description="Semantic cache") collection = Collection("semantic_cache", schema) collection.create_index("embedding", { "index_type": "HNSW", "metric_type": "IP", "params": {"M": 16, "efConstruction": 64} })

存储问题

• 症状：PVC 处于 Pending 或存储已满；
• 排查：

# 检查 PVC 状态 kubectl get pvc -n vllm-semantic-router-system # 检查 StorageClass kubectl get sc # 查看可用存储 kubectl exec -it deploy/milvus-cluster-datanode -n vllm-semantic-router-system -- df -h # 扩容 PVC kubectl patch pvc milvus-data -n vllm-semantic-router-system \ -p '{"spec":{"resources":{"requests":{"storage":"50Gi"}}}}'

Pod 崩溃 / OOM

• 症状：CrashLoopBackOff或OOMKilled；
• 排查：

# 查看事件 kubectl describe pod -l app.kubernetes.io/name=milvus -n vllm-semantic-router-system # 查看崩溃前日志 kubectl logs -l app.kubernetes.io/name=milvus -n vllm-semantic-router-system --previous # 调大内存 kubectl patch deployment milvus-cluster-proxy -n vllm-semantic-router-system \ --type='json' -p='[{"op": "replace", "path": "/spec/template/spec/containers/0/resources/limits/memory", "value":"4Gi"}]'

通用诊断命令

# 整体健康 kubectl get all -l app.kubernetes.io/name=milvus -n vllm-semantic-router-system # 各组件日志 kubectl logs -l app.kubernetes.io/component=proxy -n vllm-semantic-router-system --tail=100 kubectl logs -l app.kubernetes.io/component=datanode -n vllm-semantic-router-system --tail=100 kubectl logs -l app.kubernetes.io/component=querynode -n vllm-semantic-router-system --tail=100 # etcd 健康检查（Cluster 模式） kubectl exec -it milvus-cluster-etcd-0 -n vllm-semantic-router-system -- etcdctl endpoint health # MinIO 健康检查（Cluster 模式） kubectl exec -it milvus-cluster-minio-0 -n vllm-semantic-router-system -- mc admin info local

进一步阅读

• Semantic Cache 配置指南：语义缓存的完整配置项说明；
• 监控与指标：缓存命中率、延迟等指标的可观测性方案；
• 仓库内参考：Milvus 响应缓存配置模板、完整参考配置；
• 源码实现：Milvus 缓存核心、相似检索、精确缓存、Milvus 生命周期工具、配置结构定义。

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