AIBrix 在火山引擎（Volcano Engine）上的实战部署指南：路由、自动扩缩容、可观测性与 KV Cache 全场景演示-创锋一号

AIBrix 在火山引擎（Volcano Engine）上的实战部署指南：路由、自动扩缩容、可观测性与 KV Cache 全场景演示

【免费下载链接】aibrixCost-efficient and pluggable Infrastructure components for GenAI inference项目地址: https://gitcode.com/GitHub_Trending/ai/aibrix

本指南基于 samples/volcano-engine 目录下的完整示例，系统讲解如何在火山引擎 VKE（Volcano Engine Kubernetes）集群上部署 AIBrix，并通过五个可复现的 Demo 场景验证其核心能力：模型路由与请求策略、基于 PodAutoscaler 的自动扩缩容、Grafana 可观测性仪表盘、DeepSeek-R1 671B 分布式推理，以及基于 InfiniStore 的 KV Cache 集成。读完本文，你将能够从零开始搭建一套端到端的 AIBrix 推理集群，并用 vLLM 基准测试脚本压测验证每一项能力。

一、环境准备：安装与卸载 AIBrix

AIBrix 采用双清单安装方式：先安装依赖组件（Dependency），再安装核心组件（Core）。本示例对应 v0.4.1 版本，安装命令如下：

kubectl apply -f aibrix-dependency-v0.4.1.yaml --server-side kubectl apply -f aibrix-core-v0.4.1.yaml

aibrix-dependency清单包含 Envoy Gateway、KubeRay Operator 等基础依赖（仓库内对应 config/dependency 目录，由 kustomize 组装）；
aibrix-core清单包含 AIBrix 控制器管理器、网关插件等核心组件（仓库内对应 config/default 与 config/manager 等目录）；
--server-side用于服务端应用，避免依赖清单中 CRD 与资源对象同时提交时出现顺序问题。

卸载时按相反顺序执行：

kubectl delete -f aibrix-core-v0.4.1.yaml kubectl delete -f aibrix-dependency-v0.4.1.yaml

安装完成后，获取 Envoy 网关的负载均衡 IP 并拼装出推理端点：

LB_IP=$(kubectl get svc/envoy-aibrix-system-aibrix-eg-903790dc -n envoy-gateway-system -o=jsonpath='{.status.loadBalancer.ingress[0].ip}') ENDPOINT="${LB_IP}:80"

后续所有推理请求都统一打到http://${ENDPOINT}，由 AIBrix 网关负责认证、路由与转发。若 VKE 为 LoadBalancer Service 分配的是域名而非 IP，可相应改用{.status.loadBalancer.ingress[0].hostname}。

二、模型部署：以 DeepSeek-R1-Distill-Llama-8B 为例

部署一个 8B 规模的模型：

kubectl apply -f deepseek-8b-naive.yaml

该文件（samples/volcano-engine/deepseek-8b-naive.yaml）是理解 AIBrix 模型接入规范的最佳入门样例，其关键设计如下：

1. 模型发现标签（路由的前提）

Deployment 与 Service 上都带有两个核心标签：

labels: model.aibrix.ai/name: deepseek-r1-distill-llama-8b model.aibrix.ai/port: "8000"

AIBrix 网关正是依据model.aibrix.ai/name标签识别后端模型、依据model.aibrix.ai/port找到推理端口进行转发。文件末尾的注释特别强调：Service 名称必须与 Deployment 上的model.aibrix.ai/name标签值保持一致，这是路由能否命中的硬性约束。

2. Init 容器：从 TOS 并行下载模型

initContainers: - command: - aibrix_download - --model-uri - tos://aibrix-artifact-testing/models/DeepSeek-R1-Distill-Llama-8B/ - --local-dir - /models/ env: - name: DOWNLOADER_NUM_CONNECTIONS value: "16" - name: DOWNLOADER_NUM_THREADS value: "16" - name: DOWNLOADER_ALLOW_FILE_SUFFIX value: json, safetensors - name: TOS_ACCESS_KEY valueFrom: secretKeyRef: { key: TOS_ACCESS_KEY, name: tos-credential } - name: TOS_SECRET_KEY valueFrom: secretKeyRef: { key: TOS_SECRET_KEY, name: tos-credential } - name: TOS_ENDPOINT value: https://tos-s3-cn-beijing.ivolces.com - name: TOS_REGION value: cn-beijing

Init 容器使用 AIBrix 自带的aibrix_download工具从火山引擎对象存储 TOS 拉取模型权重，通过DOWNLOADER_NUM_CONNECTIONS/DOWNLOADER_NUM_THREADS控制并行度加速下载，DOWNLOADER_ALLOW_FILE_SUFFIX限定只下载需要的文件类型。TOS 凭证通过tos-credentialSecret 注入。

3. vLLM 推理容器

command: - vllm - serve - --port 8000 - --model /models/DeepSeek-R1-Distill-Llama-8B/ - --trust-remote-code - --served-model-name deepseek-r1-distill-llama-8b - --max-model-len 32000 - --enable-prefix-caching - --disable-log-requests - --disable-fastapi-docs - --swap-space 0 - --api-key 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

几个值得注意的点：

--served-model-name对外暴露的模型名必须与model.aibrix.ai/name标签一致；
--enable-prefix-caching开启 vLLM 前缀缓存，为后面的前缀缓存路由演示打基础；
--api-key设置 API 密钥，网关会据此校验请求的Authorization头；
--max-model-len 32000按 GPU 显存余量调整；
容器还配置了 liveness/readiness/startup 三重探针，全部探测/health，startupProbe 容忍 150 秒（30 次 × 5s）的冷启动等待，避免大模型加载期间被误杀。

4. 指标暴露与 Service

Pod 与 Service 上带有prometheus.io/scrape: "true"等注解，用于让 Prometheus 自动抓取 vLLM 的/metrics；Service 暴露8000（推理）与8080（指标）两个端口，类型为 ClusterIP，供 AIBrix 网关集群内转发。

模型就绪后，验证是否被网关正确发现：

curl http://${ENDPOINT}/v1/models | jq

三、Demo 1：模型路由与请求策略

AIBrix 网关对每个请求都会执行认证、模型路由和后端选择三层处理，下面的演示可以直观看到每一层的行为。

1. 认证失败——401

不带 API Key 直接请求：

curl -v http://${ENDPOINT}/v1/completions \ -H "Content-Type: application/json" \ -d '{ "model": "deepseek-r1-distill-llama-8b", "prompt": "San Francisco is a", "max_tokens": 128, "temperature": 0 }' | jq

请求缺少Authorization: Bearer <api-key>头，网关会直接拒绝并返回401 Unauthorized。这是因为部署时给 vLLM 设置了--api-key，而 AIBrix 网关在转发前会先完成密钥校验。

2. 模型不存在——400

使用错误的模型名请求：

curl -v http://${ENDPOINT}/v1/completions \ -H "Content-Type: application/json" \ -H "Authorization: Bearer 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" \ -d '{ "model": "deepseek-r1-distill-llama-10b", "prompt": "San Francisco is a", "max_tokens": 128, "temperature": 0 }' | jq

模型名应为deepseek-r1-distill-llama-8b，写成deepseek-r1-distill-llama-10b时网关在路由表中找不到对应后端，返回400。这验证了网关基于model.aibrix.ai/name标签建立的路由表是严格精确匹配的。

3. 客户端指定路由策略——random

AIBrix 网关允许客户端通过routing-strategy请求头控制后端选择策略。连续运行三次下面的命令，观察响应头中target-pod字段的变化：

curl -v http://${ENDPOINT}/v1/completions \ -H "Content-Type: application/json" \ -H "Authorization: Bearer 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" \ -H "routing-strategy: random" \ -d '{ "model": "deepseek-r1-distill-llama-8b", "prompt": "San Francisco is a", "max_tokens": 128, "temperature": 0 }' | jq

因为deepseek-8b-naive.yaml部署了 3 个副本，random策略会从 3 个 Pod 中随机挑选一个，三次请求的target-pod大概率各不相同。从源码看，routing-strategy是客户端可控的路由策略字符串，并且可以嵌入任意的权重系数参与加权选择（参见 pkg/plugins/gateway/algorithms/router.go 中关于 "client-controlled routing-strategy string — which may embed an arbitrary weight coefficient" 的实现注释），这意味着负载分配的粒度可以由调用方按需调节。

4. 前缀缓存策略演示

运行仓库自带的 prefix-cache-routing.ipynb（Jupyter Notebook）脚本，对同一前缀的请求连续调用三次，观察结果：

三次请求的target-pod应完全相同——前缀缓存路由会把相同前缀的请求稳定调度到同一 Pod，以最大化缓存命中率；
第 2、3 次的 TTFT（首 token 延迟）应明显低于第 1 次——因为部署时开启了--enable-prefix-caching，相同前缀的 KV Cache 在第二次起被直接复用，省去了重复 prefill 的计算。

这一能力是 AIBrix 面向多租户共享前缀（如系统提示词、Few-shot 示例）场景的核心优化手段。

四、Demo 2：基于 PodAutoscaler 的自动扩缩容

AIBrix 的自动扩缩容由自定义 CRDPodAutoscaler驱动（API 定义见 api/autoscaling/v1alpha1/podautoscaler_types.go，控制器实现见 pkg/controller/podautoscaler）。本示例提供了两种策略的配置。

1. KPA（Kubernetes-native Pod Autoscaler）策略

samples/volcano-engine/autoscaler.yaml 使用 KPA 策略，基于 vLLM 暴露的gpu_cache_usage_perc指标进行扩缩容：

apiVersion: autoscaling.aibrix.ai/v1alpha1 kind: PodAutoscaler metadata: name: deepseek-r1-distill-llama-8b-kpa namespace: default annotations: autoscaling.aibrix.ai/scale-down-cooldown-window: 5m spec: scalingStrategy: KPA minReplicas: 1 maxReplicas: 8 metricsSources: - metricSourceType: pod protocolType: http port: '8000' path: metrics targetMetric: gpu_cache_usage_perc targetValue: '0.3' scaleTargetRef: apiVersion: apps/v1 kind: Deployment name: deepseek-r1-distill-llama-8b

关键字段说明：

scalingStrategy: KPA：使用 AIBrix 自研的 KPA 算法（区别于原生 HPA）；
minReplicas: 1/maxReplicas: 8：副本数伸缩边界；
metricsSources：指标来源配置。metricSourceType: pod表示直接抓取每个 Pod 的指标，protocolType: http、port: '8000'、path: metrics指向 vLLM 的/metrics端点（对应部署时 Pod 上的prometheus.io注解）；
targetMetric: gpu_cache_usage_perc、targetValue: '0.3'：以 GPU KV Cache 使用率作为扩缩容信号，KPA 使用 0~1 的小数比例，0.3 表示 30%；
autoscaling.aibrix.ai/scale-down-cooldown-window: 5m：缩容冷却窗口 5 分钟，防止抖动导致频繁缩容；
scaleTargetRef：指向目标 Deploymentdeepseek-r1-distill-llama-8b。

2. HPA 策略（面向 RayClusterFleet）

samples/volcano-engine/hpa-r1.yaml 展示了针对分布式推理单元RayClusterFleet的 HPA 策略：

spec: scalingStrategy: HPA minReplicas: 1 maxReplicas: 4 metricsSources: - metricSourceType: pod protocolType: http port: '8000' path: metrics targetMetric: gpu_cache_usage_perc targetValue: '50' scaleTargetRef: apiVersion: orchestration.aibrix.ai/v1alpha1 kind: RayClusterFleet name: deepseek-r1-671b

注意这里的差异：scalingStrategy: HPA走兼容原生 HPA 语义的路径，targetValue使用百分比数值'50'（即 50%）；scaleTargetRef的类型是RayClusterFleet而非 Deployment，说明同一个 PodAutoscaler 机制可以统一作用于单副本 Deployment 和分布式 Ray 集群两类工作负载。

3. 压测验证

使用 vLLM 官方基准脚本benchmark_serving.py发起高并发请求，触发扩容：

OPENAI_API_KEY=sk-*** python benchmark_serving.py \ --backend vllm \ --model deepseek-ai/DeepSeek-R1-Distill-Llama-8B \ --trust-remote-code \ --served-model-name deepseek-r1-distill-llama-8b \ --base-url http://14.103.140.67:80 \ --endpoint /v1/completions \ --num-prompts 10000 \ --request-rate 50 \ --metric_percentiles '50,90,95,99' \ --goodput ttft:1000 tpot:100 \ --max-concurrency 200 \ --random-input-len 4096 \ --random-output-len 200 \ --dataset-name sharegpt \ --dataset-path /Users/bytedance/Downloads/ShareGPT_V3_unfiltered_cleaned_split.json \ --ignore-eos

参数解读：--num-prompts 10000共发送 1 万条请求、--request-rate 50每秒注入 50 条、--max-concurrency 200最大并发 200；--goodput ttft:1000 tpot:100定义服务质量目标（TTFT ≤ 1000ms、TPOT ≤ 100ms），超出目标即视为未达标。压测过程中可通过kubectl get pods观察副本数从 1 逐步向maxReplicas扩展。

五、Demo 3：Grafana 可观测性仪表盘

1. 部署 Grafana

samples/volcano-engine/grafana.yaml 提供了一个完整的 VKE 持久化部署方案，包含四个资源对象：

StorageClassebs-essd：基于火山引擎 EBS 云盘（ebs.csi.volcengine.com），类型ESSD_PL0、按量付费（ChargeType: PostPaid）、可用区cn-beijing-c；
PVCgrafana-pvc：申请 20Gi 存储，挂到kube-system命名空间；
Deploymentgrafana-dashboard：使用aibrix-cn-beijing.cr.volces.com/aibrix/grafana:latest镜像，fsGroup: 472保证 Grafana 对 PVC 有写权限（Grafana 容器默认以 UID 472 运行），数据目录/var/lib/grafana挂载到 PVC，重启不丢数据；
Servicegrafana-service：ClusterIP 类型，暴露 3000 端口。

部署后通过端口转发访问：

kubectl port-forward svc/grafana-service 3000:3000 -n kube-system

浏览器访问http://localhost:3000。

2. 配置数据源与导入仪表盘

Prometheus 数据源：需要在集群的 Prometheus 中配置VMP（Volcano Managed Prometheus）basic auth认证信息，让 Grafana 能通过带认证的方式访问指标；
导入仪表盘：AIBrix 在 observability/grafana 目录下提供了全套现成仪表盘 JSON，包括：
- AIBrix_Control_Plane_Runtime_Dashboard.json（控制面运行时）
- AIBrix_Envoy_Gateway_Dashboard.json（Envoy 网关流量）
- AIBrix_Envoy_Gateway_Plugins_Dashboard.json（网关插件）
- AIBrix_ModelClaim_Runtime_Dashboard.json（ModelClaim 运行时）
- AIBrix_vLLM_Engine_Dashboard.json（vLLM 引擎性能）
将这些 JSON 逐个导入 Grafana，即可同时观察网关路由行为、vLLM 引擎指标（如gpu_cache_usage_perc）与扩缩容效果，与 Demo 1、Demo 2 的实验形成闭环验证。

六、Demo 4：DeepSeek-R1 671B 分布式推理

1. 宿主机准备：初始化 NVMe

671B 模型权重体积大，示例方案将其放在节点本地 NVMe 盘上，需先登录目标节点完成格式化与挂载：

lsblk sudo mkfs.ext4 /dev/nvme0n1 sudo mkdir -p /mnt/nvme0 sudo mount /dev/nvme0n1 /mnt/nvme0 mkdir /mnt/nvme0/models

对应到 deepseek-r1.yaml 中，Pod 通过hostPath将宿主机/mnt/nvme0/models挂载进容器/models，模型下载与读取全部走本地 NVMe。

2. 拉起分布式推理集群

kubectl apply -f deepseek-r1.yaml

该文件基于 AIBrix 的RayClusterFleetCRD（API 见 api/orchestration/v1alpha1/rayclusterfleet_types.go，控制器见 pkg/controller/rayclusterfleet）编排一个 16 卡规模的 Ray 集群，要点如下：

RDMA 网络：head 与 worker 的 Pod 均通过k8s.volcengine.com/pod-networks注解为每个容器申请 8 个rdmaCNI 网络接口，这是多机 16 卡 Tensor Parallel 通信（NCCL 走 InfiniBand/RoCE）的基础；
NCCL 环境变量：NCCL_IB_HCA明确列出 8 个 IB 网卡（mlx5_1~mlx5_8）、NCCL_IB_GID_INDEX=7、NCCL_IB_DISABLE=0、NCCL_DEBUG=INFO，并通过IPC_LOCKcapability 规避 RDMA 内存锁定限制；
vLLM 启动参数：head 容器执行vllm serve /models/DeepSeek-R1 --tensor-parallel-size 16 --distributed-executor-backend ray --served-model-name deepseek-r1-671b，16 卡张量并行；
共享内存：/dev/shm使用emptyDir（medium: Memory）供 Ray 与 vLLM 进程间通信；
健康检查：startupProbe 探测/metrics，initialDelaySeconds: 180，容忍最长 25 分钟的启动等待（150 次 × 10s），适配 671B 模型的超长加载时间；
worker 生命周期：worker 配置preStop钩子执行ray stop，保证缩容或滚动更新时优雅退出 Ray 集群。

模型下载同样由aibrix_downloadInit 容器完成，区别是DOWNLOADER_ALLOW_FILE_SUFFIX额外包含py以拉取自定义代码（DeepSeek-R1 需要--trust-remote-code）。

3. 压测验证

python benchmark_serving.py \ --backend vllm \ --model deepseek-ai/DeepSeek-R1 \ --served-model-name deepseek-r1-671b \ --base-url http://115.190.25.67:80 \ --endpoint /v1/completions \ --num-prompts 100 \ --request-rate 1 \ --metric_percentiles '50,90,95,99' \ --goodput ttft:5000 tpot:50 \ --max-concurrency 200 \ --random-input-len 2000 \ --random-output-len 200 \ --dataset-name random \ --ignore-eos \ --seed 61

这里--goodput ttft:5000反映 671B 模型首 token 延迟的合理预期（5 秒），--dataset-name random配合固定--seed 61保证可复现。

七、Demo 5：KV Cache 场景（InfiniStore 解耦缓存）

最后一个场景演示 AIBrix 的 KV Cache 解耦能力：把 vLLM 的 KV Cache 卸载到独立的 InfiniStore 服务集群，实现缓存共享与扩容解耦。

1. 准备带 KV 卸载能力的推理镜像

基础镜像为火山引擎镜像仓库中的专用版本：

aibrix-cn-beijing.cr.volces.com/aibrix/vllm-openai:aibrix-kvcache-v0.8.5-20250510

由于基础镜像未内置 InfiniStore 客户端，需要基于它重新构建，安装infinistorePython 包：

FROM aibrix-cn-beijing.cr.volces.com/aibrix/vllm-openai:aibrix-kvcache-v0.8.5-20250510 # required ENV PIP_PROGRESS_BAR=off RUN wget https://test-files.pythonhosted.org/packages/f9/31/f9dbdfc77eadafaff9e882b501d0490625c113e3834891cd59d3223b747d/infinistore-0.2.42-cp312-cp312-manylinux_2_28_x86_64.whl RUN pip3 install infinistore-0.2.42-cp312-cp312-manylinux_2_28_x86_64.whl --index-url=https://mirrors.ivolces.com/pypi/simple/

如果本机安装了火山引擎tosutil工具，也可以先从 TOS 对象存储下载该 wheel 包再本地安装：

./tosutil cp tos://aibrix-artifact-testing/artifacts/infinistore-0.2.42-cp312-cp312-manylinux_2_28_x86_64.whl .

2. 启动 KV Cache 服务

kubectl apply -f kvcache.yaml

kvcache.yaml 定义了一个KVCache自定义资源（API 见 api/orchestration/v1alpha1/kvcache_types.go，控制器见 pkg/controller/kvcache），核心配置：

apiVersion: orchestration.aibrix.ai/v1alpha1 kind: KVCache metadata: name: kvcache-cluster namespace: default annotations: kvcache.orchestration.aibrix.ai/backend: infinistore infinistore.kvcache.orchestration.aibrix.ai/link-type: "Ethernet" infinistore.kvcache.orchestration.aibrix.ai/hint-gid-index: "7" spec: metadata: redis: # 集群元数据服务 runtime: image: aibrix-cn-beijing.cr.volces.com/aibrix/redis:7.4.2 replicas: 1 service: # ClusterIP，端口 12345(service) / 8088(admin) type: ClusterIP ports: - { name: service, port: 12345, targetPort: 12345, protocol: TCP } - { name: admin, port: 8088, targetPort: 8088, protocol: TCP } watcher: # 缓存节点状态监听 image: aibrix-cn-beijing.cr.volces.com/aibrix/kvcache-watcher:v0.3.0 cache: replicas: 3 # 3 个 InfiniStore 缓存节点 image: aibrix-cn-beijing.cr.volces.com/aibrix/infinistore:v0.2.42-20250506 resources: requests: { cpu: "10000m", memory: "30Gi", vke.volcengine.com/rdma: "1" } limits: { cpu: "10000m", memory: "30Gi", vke.volcengine.com/rdma: "1" }

要点：

kvcache.orchestration.aibrix.ai/backend: infinistore声明缓存后端类型；
每个缓存节点申请 1 个 RDMA 网卡资源（vke.volcengine.com/rdma: "1"），配合link-type: Ethernet（RoCE）与hint-gid-index: 7完成 RDMA 通信配置；
redis作为集群元数据服务（记录缓存节点地址），watcher组件持续监听缓存节点健康状态并上报元数据。

3. 推理引擎连接 KV Cache：两种方式

本示例提供了两种连接模式，均需在 vLLM 启动参数中携带 KV 卸载配置：

--kv-transfer-config '{"kv_connector":"AIBrixOffloadingConnector", "kv_role":"kv_both"}'

以及关闭 chunked prefill 的--no-enable-chunked-prefill等参数。

方式一：直连（direct）模式—— deepseek-8b-kv-direct.yaml

推理 Pod 通过环境变量直接指定 InfiniStore 服务地址：

env: - name: VLLM_USE_V1 value: "0" - name: AIBRIX_KV_CACHE_OL_L1_CACHE_ENABLED value: "0" - name: AIBRIX_KV_CACHE_OL_L2_CACHE_BACKEND value: "infinistore" - name: AIBRIX_KV_CACHE_OL_INFINISTORE_HOST_ADDR value: "192.168.0.46" # InfiniStore 服务地址 - name: AIBRIX_KV_CACHE_OL_INFINISTORE_SERVICE_PORT value: "12345" - name: AIBRIX_KV_CACHE_OL_INFINISTORE_CONNECTION_TYPE value: "RDMA" - name: AIBRIX_KV_CACHE_OL_INFINISTORE_IB_PORT value: "1" - name: AIBRIX_KV_CACHE_OL_INFINISTORE_LINK_TYPE value: "Ethernet" - name: AIBRIX_KV_CACHE_OL_INFINISTORE_VISIBLE_DEV_LIST value: "mlx5_1,mlx5_2,mlx5_3,mlx5_4"

该模式下推理 Pod 需要额外申请 1 个 RDMA 网卡（vke.volcengine.com/rdma: "1"），并在 Pod 注解中声明rdmaCNI 网络，同时将显存上限提升到 120G（KV Cache 卸载后本机显存占用降低，可支撑更大 batch）。直连适合缓存服务地址固定的场景。

方式二：集群（cluster）模式—— deepseek-8b-kv-cluster.yaml

推理 Pod 不再写死缓存服务 IP，而是通过 Redis 元数据服务动态发现缓存节点：

env: - name: AIBRIX_KV_CACHE_OL_L2_CACHE_BACKEND value: "infinistore" - name: AIBRIX_KV_CACHE_OL_INFINISTORE_CONNECTION_TYPE value: "RDMA" - name: AIBRIX_KV_CACHE_OL_INFINISTORE_IB_PORT value: "1" - name: AIBRIX_KV_CACHE_OL_INFINISTORE_LINK_TYPE value: "Ethernet" - name: AIBRIX_KV_CACHE_OL_INFINISTORE_VISIBLE_DEV_LIST value: "mlx5_1:7,mlx5_2:7,mlx5_3:7,mlx5_4:7" - name: AIBRIX_KV_CACHE_OL_META_SERVICE_BACKEND value: "redis" - name: AIBRIX_KV_CACHE_OL_META_SERVICE_URL value: "redis://kvcache-cluster-redis:6379" - name: AIBRIX_KV_CACHE_OL_META_SERVICE_CLUSTER_META_KEY value: "kvcache_nodes"

引擎启动时从redis://kvcache-cluster-redis:6379读取kvcache_nodes键获取缓存集群节点列表，缓存节点增减无需改动推理配置，适合缓存集群弹性伸缩的场景。此外，仓库还提供了 deepseek-8b-kv-dram.yaml，从文件命名可以推断它是将 KV Cache 驻留在 DRAM 内存中的变体配置，结构与 cluster 模式一致，可按硬件条件选择使用。

八、小结

通过以上五个 Demo，可以完整验证 AIBrix 在火山引擎 VKE 环境中的核心价值链路：

接入即路由：只需打上model.aibrix.ai/name/model.aibrix.ai/port标签，vLLM 服务即可被网关自动发现并纳管，认证（401）、模型校验（400）与多策略路由（random、前缀缓存路由）开箱即用；
按需扩缩容：PodAutoscaler统一以 vLLM 的gpu_cache_usage_perc为信号，同时支持 KPA（0~1 比例）与 HPA（百分比）两种语义，并可直接作用于RayClusterFleet分布式推理单元；
全链路可观测：Grafana + VMP 组合，配合 observability/grafana 下的五套现成仪表盘，路由、引擎与扩缩容状态一目了然；
千亿级模型落地：RayClusterFleet+ RDMA 多网卡注解 + NVMe hostPath 的组合，支撑 DeepSeek-R1 671B 的 16 卡张量并行部署；
KV Cache 解耦：KVCacheCRD 一键拉起 InfiniStore 缓存集群，direct / cluster 两种连接模式兼顾固定地址与动态发现两种运维形态。

所有演示的清单文件与 Notebook 均位于 samples/volcano-engine 目录，可直接在火山引擎 VKE 集群中按序复现。

【免费下载链接】aibrixCost-efficient and pluggable Infrastructure components for GenAI inference项目地址: https://gitcode.com/GitHub_Trending/ai/aibrix

创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考

企业官网建设流程全解析