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 目录下的完整示例系统讲解如何在火山引擎 VKEVolcano Engine Kubernetes集群上部署 AIBrix并通过五个可复现的 Demo 场景验证其核心能力模型路由与请求策略、基于 PodAutoscaler 的自动扩缩容、Grafana 可观测性仪表盘、DeepSeek-R1 671B 分布式推理以及基于 InfiniStore 的 KV Cache 集成。读完本文你将能够从零开始搭建一套端到端的 AIBrix 推理集群并用 vLLM 基准测试脚本压测验证每一项能力。一、环境准备安装与卸载 AIBrixAIBrix 采用双清单安装方式先安装依赖组件Dependency再安装核心组件Core。本示例对应 v0.4.1 版本安装命令如下kubectl apply -f aibrix-dependency-v0.4.1.yaml --server-side kubectl apply -f aibrix-core-v0.4.1.yamlaibrix-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 -ojsonpath{.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: 8000AIBrix 网关正是依据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-beijingInit 容器使用 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 三重探针全部探测/healthstartupProbe 容忍 150 秒30 次 × 5s的冷启动等待避免大模型加载期间被误杀。4. 指标暴露与 ServicePod 与 Service 上带有prometheus.io/scrape: true等注解用于让 Prometheus 自动抓取 vLLM 的/metricsService 暴露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. 客户端指定路由策略——randomAIBrix 网关允许客户端通过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.ipynbJupyter 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. KPAKubernetes-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 算法区别于原生 HPAminReplicas: 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 策略面向 RayClusterFleetsamples/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_KEYsk-*** 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 3Grafana 可观测性仪表盘1. 部署 Grafanasamples/volcano-engine/grafana.yaml 提供了一个完整的 VKE 持久化部署方案包含四个资源对象StorageClassebs-essd基于火山引擎 EBS 云盘ebs.csi.volcengine.com类型ESSD_PL0、按量付费ChargeType: PostPaid、可用区cn-beijing-cPVCgrafana-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-serviceClusterIP 类型暴露 3000 端口。部署后通过端口转发访问kubectl port-forward svc/grafana-service 3000:3000 -n kube-system浏览器访问http://localhost:3000。2. 配置数据源与导入仪表盘Prometheus 数据源需要在集群的 Prometheus 中配置VMPVolcano Managed Prometheusbasic auth认证信息让 Grafana 能通过带认证的方式访问指标导入仪表盘AIBrix 在 observability/grafana 目录下提供了全套现成仪表盘 JSON包括AIBrix_Control_Plane_Runtime_Dashboard.json控制面运行时AIBrix_Envoy_Gateway_Dashboard.jsonEnvoy 网关流量AIBrix_Envoy_Gateway_Plugins_Dashboard.json网关插件AIBrix_ModelClaim_Runtime_Dashboard.jsonModelClaim 运行时AIBrix_vLLM_Engine_Dashboard.jsonvLLM 引擎性能将这些 JSON 逐个导入 Grafana即可同时观察网关路由行为、vLLM 引擎指标如gpu_cache_usage_perc与扩缩容效果与 Demo 1、Demo 2 的实验形成闭环验证。六、Demo 4DeepSeek-R1 671B 分布式推理1. 宿主机准备初始化 NVMe671B 模型权重体积大示例方案将其放在节点本地 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 的RayClusterFleetCRDAPI 见 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_INDEX7、NCCL_IB_DISABLE0、NCCL_DEBUGINFO并通过IPC_LOCKcapability 规避 RDMA 内存锁定限制vLLM 启动参数head 容器执行vllm serve /models/DeepSeek-R1 --tensor-parallel-size 16 --distributed-executor-backend ray --served-model-name deepseek-r1-671b16 卡张量并行共享内存/dev/shm使用emptyDirmedium: Memory供 Ray 与 vLLM 进程间通信健康检查startupProbe 探测/metricsinitialDelaySeconds: 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 5KV 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_BARoff 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-urlhttps://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.yamlkvcache.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: EthernetRoCE与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 网络同时将显存上限提升到 120GKV 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为信号同时支持 KPA0~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），仅供参考