AIBrix是一个为大型语言模型(LLM)推理设计的云原生平台，其架构分为两个主要维度：控制平面(Control Plane)和数据平面(Data Plane)。
d6a063b5340b9b3a0b73a983a2f88e62.png
控制平面组件
控制平面负责资源编排和管理，主要由以下Kubernetes控制器组成：
1、Controller Manager - 所有控制器的核心管理组件，负责协调各个控制器的运行。
2、PodAutoscaler Controller - 自动扩缩容控制器，根据不同指标和策略自动扩缩容资源。支持三种扩缩容策略：
- HPA (Horizontal Pod Autoscaler) - 标准Kubernetes HPA
- KPA (Knative-style Pod Autoscaler) - 具有稳定和紧急扩缩容模式，适合处理流量突发。
- APA (Application Pod Autoscaler) - 应用特定的扩缩容逻辑，提供可配置的容忍带，适合应用特定的扩缩容需求。
3、ModelAdapter Controller - 管理LoRA适配器的生命周期，包括调度（将LoRA适配器调度到合适的模型Pod上）、加载和卸载LoRA模型及创建必要的svc服务使适配器可访问。
4、RayClusterFleet Controller 和 RayClusterReplicaSet Controller - 管理分布式推理的Ray集群，RayClusterFleet Controller管理具有滚动更新能力的Ray集群舰队；RayClusterReplicaSet Controller管理具有特定副本计数的Ray集群集合
5、ModelRoute Controller - 管理模型路由，创建HTTP路由规则。
6、KVCache Controller - 管理分布式KV缓存，实现高容量、跨引擎的KV重用。
数据平面组件
数据平面处理实际的请求处理和模型执行：
1、Gateway Plugins - 基于Envoy的网关扩展，提供动态路由、用户配置和高级路由策略，其中也包括用户请求计数和令牌使用预算配置、流式处理和高级路由策略，并支持多种路由算法：随机、最少请求、吞吐量、前缀缓存感知。
2、AI Engine Runtime - 推理容器的统一管理层，提供指标标准化、模型下载和管理功能。
3、Metadata Service - 提供元数据服务。
4、Redis - 用于存储指标和状态信息，如用户速率相关信息。
[root@system-test-102-94 lgy]# kubectl get po -n aibrix-system
NAME READY STATUS RESTARTS AGE
aibrix-controller-manager-7557f875bf-xxhmn 1/1 Running 1 (33h ago) 2d23h
aibrix-gateway-plugins-6f76c4ccf7-bhg6g 1/1 Running 0 2d23h
aibrix-gpu-optimizer-78cfdb6dc7-vnbtb 1/1 Running 0 2d23h
aibrix-kuberay-operator-5586cd8976-mm884 1/1 Running 1 (33h ago) 2d23h
aibrix-metadata-service-79cc7786b9-dxdtm 1/1 Running 0 2d23h
aibrix-redis-master-84c69b7d5d-dwtdw 1/1 Running 0 2d23h
[root@system-test-102-94 lgy]# kubectl get svc -n aibrix-system
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
aibrix-controller-manager-metrics-service ClusterIP 10.96.104.139 <none> 8080/TCP 2d23h
aibrix-gateway-plugins ClusterIP 10.96.134.7 <none> 50052/TCP 2d23h
aibrix-gpu-optimizer ClusterIP 10.96.249.205 <none> 8080/TCP 2d23h
aibrix-kuberay-operator ClusterIP 10.96.60.14 <none> 8080/TCP 2d23h
aibrix-lora-controller-manager-metrics-service ClusterIP 10.96.89.16 <none> 8080/TCP 74m
aibrix-metadata-service NodePort 10.96.246.18 <none> 8090:32004/TCP 2d23h
aibrix-redis-master ClusterIP 10.96.149.47 <none> 6379/TCP 2d23h
推理示例
apiVersion: apps/v1
kind: Deployment
metadata:
labels:
model.aibrix.ai/name: deepseek-r1-distill-llama-8b # 和svc一致
model.aibrix.ai/port: "8000"
name: deepseek-r1-distill-llama-8b
namespace: default
spec:
replicas: 1
selector:
matchLabels:
model.aibrix.ai/name: deepseek-r1-distill-llama-8b
template:
metadata:
labels:
model.aibrix.ai/name: deepseek-r1-distill-llama-8b
spec:
containers:
- command:
- python3
- -m
- vllm.entrypoints.openai.api_server
- --host
- "0.0.0.0"
- --port
- "8000"
- --uvicorn-log-level
- warning
- --model
- /models/DeepSeek-R1-Distill-Llama-8B
- --served-model-name
- deepseek-r1-distill-llama-8b # 和svc一致
- --max-model-len
- "12288"
image: docker.1ms.run/vllm/vllm-openai:v0.7.1
imagePullPolicy: IfNotPresent
name: vllm-openai
volumeMounts:
- name: models
mountPath: /models/DeepSeek-R1-Distill-Llama-8B
ports:
- containerPort: 8000
protocol: TCP
resources:
limits:
nvidia.com/nvidia-rtx-3090-24GB: "1"
requests:
nvidia.com/nvidia-rtx-3090-24GB: "1"
livenessProbe:
httpGet:
path: /health
port: 8000
scheme: HTTP
failureThreshold: 3
periodSeconds: 5
successThreshold: 1
timeoutSeconds: 1
readinessProbe:
httpGet:
path: /health
port: 8000
scheme: HTTP
failureThreshold: 5
periodSeconds: 5
successThreshold: 1
timeoutSeconds: 1
startupProbe:
httpGet:
path: /health
port: 8000
scheme: HTTP
failureThreshold: 30
periodSeconds: 5
successThreshold: 1
timeoutSeconds: 1
volumes:
- name: models
hostPath:
path: /root/lgy/models/DeepSeek-R1-Distill-Llama-8B
type: Directory
---
apiVersion: v1
kind: Service
metadata:
labels:
model.aibrix.ai/name: deepseek-r1-distill-llama-8b
prometheus-discovery: "true"
annotations:
prometheus.io/scrape: "true"
prometheus.io/port: "8080"
name: deepseek-r1-distill-llama-8b # 需和model.aibrix.ai/name一致
namespace: default
spec:
ports:
- name: serve
port: 8000
protocol: TCP
targetPort: 8000
- name: http
port: 8080
protocol: TCP
targetPort: 8080
selector:
model.aibrix.ai/name: deepseek-r1-distill-llama-8b
type: ClusterIP
Gateway Route
de69443616c1e36753f1690875f6e254.png
[root@system-test-102-94 lgy]# kubectl get po -n envoy-gateway-system
NAME READY STATUS RESTARTS AGE
envoy-aibrix-system-aibrix-eg-903790dc-fccbb99cd-4b9jg 2/2 Running 0 2d23h
envoy-gateway-748f68f8f5-c55xx 1/1 Running 1 (33h ago) 2d23h
[root@system-test-102-94 lgy]# kubectl get svc -n envoy-gateway-system
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
envoy-aibrix-system-aibrix-eg-903790dc NodePort 10.96.192.76 <none> 80:1422/TCP 3d
envoy-gateway ClusterIP 10.96.18.242 <none> 18000/TCP,18001/TCP,18002/TCP,19001/TCP 3d
[root@system-test-102-94 lgy]# kubectl get gateway -n aibrix-system
NAME CLASS ADDRESS PROGRAMMED AGE
aibrix-eg aibrix-eg 10.0.100.16 True 3d
[root@system-test-102-94 lgy]# kubectl get httproute -n aibrix-system
NAME HOSTNAMES AGE
aibrix-reserved-router 2d23h
deepseek-r1-distill-llama-8b-router 2d16h
访问策略
- random：将请求路由到随机 pod。
- least-request：将请求路由到正在进行的请求最少的 pod。
- throughput：将请求路由到已处理最低总加权令牌的 pod。
- prefix-cache：将请求路由到已经具有与请求的提示前缀匹配的 KV 缓存的 pod。
- least-busy-time：将请求路由到累计繁忙处理时间最短的 pod。
- least-kv-cache：将请求路由到当前 KV 缓存大小最小（使用的 VRAM 最少）的 pod。
- least-latency：将请求路由到平均处理延迟最低的 pod。
- prefix-cache-and-load：路由请求时同时考虑前缀缓存命中和 pod 负载。
- vtc-basic：使用平衡公平性（用户令牌计数）和 Pod 利用率的混合评分来路由请求。它是虚拟令牌计数器 (VTC) 算法的一个简单变体
curl -v http://10.0.102.94:1422/v1/chat/completions \
-H "routing-strategy: least-request" \
-H "Content-Type: application/json" \
-d '{
"model": "deepseek-r1-distill-llama-8b",
"messages": [{"role": "user", "content": "Say this is a test!"}],
"temperature": 0.7
}'
限速
设置用户速率
curl http://10.0.102.94:32004/CreateUser -H "Content-Type: application/json" -d '{"name": "lgy","rpm": 100,"tpm": 1000}'
RPM：每分钟最大请求数（Requests Per Minute）
TPM：每分钟最大令牌数（Tokens Per Minute）
查看用户配置
curl http://10.0.102.94:32004/ReadUser -H "Content-Type: application/json" -d '{"name": "lgy"}'
更新配额
curl http://10.0.102.94:32004/UpdateUser -H "Content-Type: application/json" -d '{"name": "lgs","rpm": 3,"tpm": 1000}'
请求
发起请求，请求头携带-H "user: your-user-id"
curl -v 10.0.102.94:1422/v1/chat/completions \
-H "user: lgy" \
-H "Content-Type: application/json" \
-d '{
"model": "deepseek-r1-distill-llama-8b",
"messages": [{"role": "user", "content": "Say this is a test!"}],
"temperature": 0.7
}'
速率限制的实现细节
当请求到达网关时，系统会执行以下检查：
- 检查RPM限制：验证用户当前的请求数是否已超过RPM限制
- 增加RPM计数：如果未超过限制，增加用户的RPM计数
- 检查TPM限制：验证用户当前的令牌使用量是否已超过TPM限制
如果任何一项检查失败，请求将被拒绝并返回429 Too Many Requests状态码。
{"error":{"code":429,"message":"user: lgy has exceeded RPM: 3"}}
AI Engine Runtime
AI Engine Runtime 是统一的管理层，作为推理容器的 sidecar运行，提供了指标标准化、模型下载和本地模型管理功能。
控制平面集成 API：确保控制平面和推理 Pod 之间通信。这允许 LoRA 适配器控制器、自动扩缩容器和冷启动管理器等组件与推理容器动态交互。
抽象特定供应商的推理引擎：为支持多种推理引擎，包括最流行的引擎。然而，不同引擎的 API 各不相同。抽象了关键操作，如模型加载/卸载、适配器配置和性能监控，使新的推理后端能够以最小的摩擦集成。
可观察性：统一的监控接口，允许一致的性能跟踪和故障排除。
- name: aibrix-runtime
image: docker.1ms.run/aibrix/runtime:v0.2.1
command:
- aibrix_runtime
- --port
- "8080"
env:
- name: INFERENCE_ENGINE
value: vllm # 指定推理引擎交互（目前主要支持 vLLM）
- name: INFERENCE_ENGINE_ENDPOINT
value: http://localhost:8000 # 指定推理引擎的 API 端点
ports:
- containerPort: 8080
protocol: TCP
Multi-Node Inference
8dc8cae63f1b5c97328c2ae3e730d398.png
使用Ray作为底层分布式计算框架，允许将大型模型的推理工作负载分散到多个GPU节点上。
apiVersion: orchestration.aibrix.ai/v1alpha1
kind: RayClusterFleet
metadata:
name: qwen-coder-7b-instruct
labels:
app.kubernetes.io/name: aibrix
app.kubernetes.io/managed-by: kustomize
spec:
replicas: 1
selector:
matchLabels:
model.aibrix.ai/name: qwen-coder-7b-instruct
strategy:
type: RollingUpdate
rollingUpdate:
maxSurge: 25%
maxUnavailable: 25%
template:
metadata:
labels:
model.aibrix.ai/name: qwen-coder-7b-instruct
annotations:
ray.io/overwrite-container-cmd: "true"
spec:
rayVersion: "2.10.0"
headGroupSpec:
rayStartParams:
dashboard-host: "0.0.0.0"
template:
metadata:
labels:
model.aibrix.ai/name: qwen-coder-7b-instruct
spec:
containers:
- name: ray-head
image: vllm/vllm-openai:v0.7.1
command: ["/bin/bash", "-c"]
args:
- >
ulimit -n 65536 &&
echo "[INFO] Starting Ray head node..." &&
eval "$KUBERAY_GEN_RAY_START_CMD" &
echo "[INFO] Waiting for Ray dashboard to be ready..." &&
until curl --max-time 5 --fail http://127.0.0.1:8265 > /dev/null 2>&1; do
echo "[WAITING] $(date -u +'%Y-%m-%dT%H:%M:%SZ') - Ray dashboard not ready yet...";
sleep 2;
done &&
echo "[SUCCESS] Ray dashboard is available!" &&
vllm serve Qwen/Qwen2.5-Coder-7B-Instruct \
--served-model-name qwen-coder-7b-instruct \
--tensor-parallel-size 2 \
--distributed-executor-backend ray \
--host 0.0.0.0 \
--port 8000 \
--dtype half
ports:
- containerPort: 6379
name: gcs-server
- containerPort: 8265
name: dashboard
- containerPort: 10001
name: client
- containerPort: 8000
name: service
resources:
limits:
cpu: "4"
nvidia.com/nvidia-rtx-3090-24GB: 1
requests:
cpu: "4"
nvidia.com/nvidia-rtx-3090-24GB: 1
- name: aibrix-runtime
image: docker.1ms.run/aibrix/runtime:v0.2.1
command:
- aibrix_runtime
- --port
- "8080"
env:
- name: INFERENCE_ENGINE
value: vllm
- name: INFERENCE_ENGINE_ENDPOINT
value: http://localhost:8000
- name: PYTORCH_CUDA_ALLOC_CONF
value: "expandable_segments:True"
ports:
- containerPort: 8080
protocol: TCP
livenessProbe:
httpGet:
path: /healthz
port: 8080
initialDelaySeconds: 3
periodSeconds: 2
readinessProbe:
httpGet:
path: /ready
port: 8080
initialDelaySeconds: 5
periodSeconds: 10
resources:
limits:
cpu: "1"
requests:
cpu: "1"
workerGroupSpecs:
- groupName: small-group
replicas: 1
minReplicas: 1
maxReplicas: 5
rayStartParams: {}
template:
metadata:
labels:
model.aibrix.ai/name: qwen-coder-7b-instruct
spec:
containers:
- name: ray-worker
image: docker.1ms.run/vllm/vllm-openai:v0.7.1
env:
- name: MY_POD_IP
valueFrom:
fieldRef:
fieldPath: status.podIP
command: [ "/bin/bash", "-c" ]
args:
- >
ulimit -n 65536 &&
eval "$KUBERAY_GEN_RAY_START_CMD --node-ip-address=$MY_POD_IP" &&
tail -f /dev/null
lifecycle:
preStop:
exec:
command: [ "/bin/sh", "-c", "ray stop" ]
resources:
limits:
cpu: "4"
nvidia.com/nvidia-rtx-3090-24GB: 1
requests:
cpu: "4"
nvidia.com/nvidia-rtx-3090-24GB: 1
---
apiVersion: v1
kind: Service
metadata:
name: qwen-coder-7b-instruct
labels:
model.aibrix.ai/name: qwen-coder-7b-instruct
prometheus-discovery: "true"
annotations:
prometheus.io/scrape: "true"
prometheus.io/port: "8080"
spec:
selector:
model.aibrix.ai/name: qwen-coder-7b-instruct
ports:
- name: serve
port: 8000
protocol: TCP
targetPort: 8000
- name: http
port: 8080
protocol: TCP
targetPort: 8080
---
apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
name: qwen-coder-7b-instruct-router
namespace: aibrix-system
spec:
parentRefs:
- group: gateway.networking.k8s.io
kind: Gateway
name: aibrix-eg
namespace: aibrix-system
rules:
- backendRefs:
- group: ""
kind: Service
name: qwen-coder-7b-instruct
namespace: default
port: 8000
weight: 1
matches:
- headers:
- name: model
type: Exact
value: qwen-coder-7b-instruct
path:
type: PathPrefix
value: /v1/completions
- headers:
- name: model
type: Exact
value: qwen-coder-7b-instruct
path:
type: PathPrefix
value: /v1/chat/completions
timeouts:
request: 120s
可选组建
Lora Dynamic Loading
c42ecbcaae3e47fc2b218a95b98b783f.png
LoRA动态加载允许在已部署的基础模型上动态加载和卸载LoRA适配器。LoRA（Low-Rank Adaptation）是一种高效的大型语言模型（LLM）微调技术，它通过在冻结的预训练模型上添加小型、可训练的适配器模块来实现模型的定制化，而不需要重新训练整个模型。
参数量：秩【8-64】a * r + b * r
作用
- 提高模型密度和降低推理成本：通过在共享基础模型上动态加载不同的LoRA适配器，可以更高效地部署多个模型变体。
- 优化GPU内存使用：多个LoRA适配器可以共享同一个基础模型，减少了重复加载基础模型的需要，从而节省GPU内存。
- 减少冷启动时间：由于只需加载轻量级的LoRA适配器而不是整个模型，启动新模型变体的时间大大缩短。
- 提高可扩展性：使系统能够支持更多的模型变体，适合高密度部署和成本效益高的生产环境推理。
实现机制
- ModelAdapter控制器：负责管理LoRA适配器的生命周期，包括调度、加载和服务发现。
- 服务发现：使用Kubernetes Service作为每个LoRA模型的抽象层，允许单个Pod上的多个LoRA适配器属于多个服务。
- vLLM引擎集成：需要vLLM引擎支持LoRA元数据的可见性、动态加载和卸载、远程注册表支持以及可观察性。（现阶段局限性）
示例
# 基础模型
apiVersion: apps/v1
kind: Deployment
metadata:
labels:
model.aibrix.ai/name: qwen-coder-1-5b-instruct # 需和svc保持一致
model.aibrix.ai/port: "8000"
adapter.model.aibrix.ai/enabled: "true" # 启用适配器功能
name: qwen-coder-1-5b-instruct
spec:
replicas: 1
selector:
matchLabels:
model.aibrix.ai/name: qwen-coder-1-5b-instruct
template:
metadata:
labels:
model.aibrix.ai/name: qwen-coder-1-5b-instruct
spec:
volumes:
- name: models
hostPath:
path: /root/lgy/models
type: Directory
containers:
- command:
- python3
- -m
- vllm.entrypoints.openai.api_server
- --host
- "0.0.0.0"
- --port
- "8000"
- --uvicorn-log-level
- warning
- --model
- /models/DeepSeek-R1-Distill-Llama-8B
- --served-model-name
- qwen-coder-1-5b-instruct # 需和svc一致
- --enable-lora # 启用LoRA功能
image: docker.1ms.run/vllm/vllm-openai:v0.7.1
imagePullPolicy: Always
name: vllm-openai
env:
- name: VLLM_ALLOW_RUNTIME_LORA_UPDATING # 允许运行时更新LoRA
value: "True"
ports:
- containerPort: 8000
protocol: TCP
resources:
limits:
nvidia.com/nvidia-rtx-3090-24GB: "1"
requests:
nvidia.com/nvidia-rtx-3090-24GB: "1"
volumeMounts:
- name: models
mountPath: /models
- name: aibrix-runtime
image: docker.1ms.run/aibrix/runtime:v0.2.1
command:
- aibrix_runtime
- --port
- "8080"
env:
- name: INFERENCE_ENGINE
value: vllm
- name: INFERENCE_ENGINE_ENDPOINT
value: http://localhost:8000
volumeMounts:
- name: models
mountPath: /models
ports:
- containerPort: 8080
protocol: TCP
livenessProbe:
httpGet:
path: /healthz
port: 8080
initialDelaySeconds: 3
periodSeconds: 2
readinessProbe:
httpGet:
path: /ready
port: 8080
initialDelaySeconds: 5
periodSeconds: 10
---
apiVersion: v1
kind: Service
metadata:
labels:
model.aibrix.ai/name: qwen-coder-1-5b-instruct
prometheus-discovery: "true"
annotations:
prometheus.io/scrape: "true"
prometheus.io/port: "8080"
name: qwen-coder-1-5b-instruct
namespace: default
spec:
ports:
- name: serve
port: 8000
protocol: TCP
targetPort: 8000
- name: http
port: 8080
protocol: TCP
targetPort: 8080
selector:
model.aibrix.ai/name: qwen-coder-1-5b-instruct
type: ClusterIP
---
# lora适配器
apiVersion: model.aibrix.ai/v1alpha1
kind: ModelAdapter
metadata:
name: qwen-code-lora # lora模型的服务名称
labels:
model.aibrix.ai/name: "qwen-code-lora"
model.aibrix.ai/port: "8000"
spec:
baseModel: qwen-coder-1-5b-instruct # 部署的基础模型名称
podSelector:
matchLabels:
model.aibrix.ai/name: qwen-coder-1-5b-instruct # 与基础模型的标签匹配
artifactURL: huggingface://ai-blond/Qwen-Qwen2.5-Coder-1.5B-Instruct-lora # lora模型路径，可以从hf、S3、hostPath加载
schedulerName: default
- 部署一个基础模型（如LLAMA、Qwen等），这个基础模型运行在独立的Pod中。
- 基础模型Pod必须启用LoRA支持：容器需要配置特定的参数来支持LoRA，包括--enable-lora参数和VLLM_ALLOW_RUNTIME_LORA_UPDATING=True环境变量。
- 创建ModelAdapter资源：创建ModelAdapter自定义资源，指定LoRA模型的位置和要应用到哪个基础模型上。
- 控制器加载LoRA到基础模型Pod：ModelAdapter控制器会找到匹配的基础模型Pod，然后通过API调用将LoRA模型加载到该Pod中。
Autoscaling
PodAutoscaler自定义资源定义了自动扩缩容的行为，包括以下关键字段：
- spec.scaleTargetRef: 要扩缩容的目标资源引用（如Deployment、StatefulSet）
- spec.minReplicas: 最小副本数（可选，默认为1）
- spec.maxReplicas: 最大副本数
- spec.metricsSources: 要监控的指标源列表
- spec.scalingStrategy: 使用的扩缩容策略（HPA、KPA、APA）
****HPA****
HPA策略利用Kubernetes原生的Horizontal Pod Autoscaler。当选择此策略时，PodAutoscaler控制器会基于PodAutoscaler规范创建和管理一个Kubernetes HPA资源。
apiVersion: autoscaling.aibrix.ai/v1alpha1
kind: PodAutoscaler
metadata:
name: deepseek-r1-distill-llama-8b-hpa
namespace: default
labels:
app.kubernetes.io/name: aibrix
app.kubernetes.io/managed-by: kustomize
spec:
scalingStrategy: HPA
minReplicas: 1
maxReplicas: 10
metricsSources:
- metricSourceType: pod
protocolType: http
port: '8000'
path: /metrics
targetMetric: gpu_cache_usage_perc
targetValue: '50'
scaleTargetRef:
apiVersion: apps/v1
kind: Deployment
name: deepseek-r1-distill-llama-8b
****KPA****
KPA策略实现了一个受Knative Pod Autoscaler启发的自动扩缩容算法。它具有"稳定"和"紧急"两种模式，以处理不同的流量模式。
主要特点：
- 稳定模式：在正常情况下，使用60秒的稳定窗口计算平均指标值，平稳地调整副本数
- 紧急模式：当指标值超过目标值的2倍（可配置）时，切换到紧急模式，使用10秒的短窗口快速响应流量峰值。
- 扩容保护：防止在紧急模式期间快速缩容
- 延迟缩容：在负载减少后，维持较高的副本数一段时间（默认30分钟），防止频繁的扩缩容操作。
apiVersion: autoscaling.aibrix.ai/v1alpha1
kind: PodAutoscaler
metadata:
name: deepseek-r1-distill-llama-8b-kpa
namespace: default
labels:
app.kubernetes.io/name: aibrix
app.kubernetes.io/managed-by: kustomize
annotations:
kpa.autoscaling.aibrix.ai/target-burst-capacity: "2.0"
kpa.autoscaling.aibrix.ai/activation-scale: "2"
kpa.autoscaling.aibrix.ai/panic-threshold: "2.0"
kpa.autoscaling.aibrix.ai/stable-window: "60s"
kpa.autoscaling.aibrix.ai/panic-window: "10s"
kpa.autoscaling.aibrix.ai/scale-down-delay: "30m"
spec:
scalingStrategy: KPA
minReplicas: 1
maxReplicas: 8
metricsSources:
- metricSourceType: pod
protocolType: http
port: '8000'
path: metrics
targetMetric: gpu_cache_usage_perc
targetValue: '0.5'
scaleTargetRef:
apiVersion: apps/v1
kind: Deployment
name: deepseek-r1-distill-llama-8b
****APA****
APA策略实现了一个自定义的自动扩缩容算法，专注于维持稳定的扩缩容，具有可配置的容忍度。
主要特点：
- 波动容忍度：可配置的扩容和缩容阈值
- 扩缩容速率：对扩缩容速率的限制
- 指标窗口：使用时间窗口进行指标平均
apiVersion: autoscaling.aibrix.ai/v1alpha1
kind: PodAutoscaler
metadata:
name: deepseek-r1-distill-llama-8b-apa
namespace: default
labels:
app.kubernetes.io/name: aibrix
app.kubernetes.io/managed-by: kustomize
annotations:
autoscaling.aibrix.ai/up-fluctuation-tolerance: '0.1' # 上波动容忍度：扩容前的阈值（例如，目标值上方10%）
autoscaling.aibrix.ai/down-fluctuation-tolerance: '0.2' # 下波动容忍度：缩容前的阈值（例如，目标值下方20%）
apa.autoscaling.aibrix.ai/window: 30s # 计算指标的时间窗口
spec:
scalingStrategy: APA
minReplicas: 1
maxReplicas: 8
metricsSources:
- metricSourceType: pod
protocolType: http
port: '8000'
path: metrics
targetMetric: gpu_cache_usage_perc
targetValue: '0.5'
scaleTargetRef:
apiVersion: apps/v1
kind: Deployment
name: deepseek-r1-distill-llama-8b
分布式KV缓存
目前分布式KV缓存仅支持FlashAttention。0.2版本开始支持，目前使用问题较多，扔在持续优化中
b83f2635af97ed3f7e735d3b5c8ddd2e.png
部署模式
- 集中式模式：使用 Vineyard 作为 KV 缓存实现，etcd 作为元数据存储。
- 分布式模式：计划中但尚未完全实现，旨在用于更具可扩展性的场景。
apiVersion: orchestration.aibrix.ai/v1alpha1
kind: KVCache
metadata:
name: example-kvcache
annotations:
kvcache.orchestration.aibrix.ai/node-affinity-gpu-type: "A100"
kvcache.orchestration.aibrix.ai/pod-anti-affinity: "true"
# kvcache.orchestration.aibrix.ai/mode：缓存模式（集中式/分布式）
# kvcache.orchestration.aibrix.ai/node-affinity-key：节点亲和性标签键
# kvcache.orchestration.aibrix.ai/node-affinity-gpu-type：节点亲和性的 GPU 类型,异构GPU使用
# kvcache.orchestration.aibrix.ai/pod-affinity-workload：必须与metadata.name下面的推理服务部署相匹配
# kvcache.orchestration.aibrix.ai/pod-anti-affinity：启用 Pod 反亲和性
spec:
mode: centralized
replicas: 3
etcdReplicas: 1
metadata:
etcd:
image: "quay.io/coreos/etcd:v3.5.0"
storage:
size: "10Gi"
cacheSpec:
image: "docker.1ms.run/aibrix/kvcache:20241120"
resources:
requests:
cpu: "2000m"
memory: "4Gi"
limits:
cpu: "2000m"
memory: "4Gi"
service:
type: ClusterIP
ports:
- name: service
port: 9600
targetPort: 9600
protocol: TCP
NAME READY STATUS RESTARTS AGE
deepseek-coder-7b-instruct-85664648c7-xgp9h 1/1 Running 0 2m41s
deepseek-coder-7b-kvcache-7d5896cd89-dcfzt 1/1 Running 0 2m31s
deepseek-coder-7b-kvcache-etcd-0 1/1 Running 0 2m31s
分布式 KV 缓存指标可以在 AIBrix 引擎仪表板中查看。以下是分布式 KV 缓存仪表板面板的示例：
4d3a0f8dcaf1c805ea484288e8565c40.png
总结
优点
- 原生支持 vLLM：AIBrix 对 vLLM 有很好的支持，包括配置示例和集成功能。
- 模块化设计：AIBrix 采用模块化设计，允许您根据需求选择性地部署组件，如自动扩缩容、LoRA 动态加载等。
- 高密度 LoRA 管理：支持在同一基础模型上动态加载和卸载多个 LoRA 适配器，提高资源利用率。
- 灵活的自动扩缩容：提供多种扩缩容策略（HPA、KPA、APA），适应不同的工作负载模式。
- 分布式推理支持：通过 Ray 集群支持跨多个节点的分布式推理，适合部署大型模型。
- 统一的 AI Runtime：提供统一的接口来管理不同的推理引擎，标准化指标，支持模型的动态加载。
- 异构 GPU 支持：支持在不同类型的 GPU 上部署相同的模型，解决 GPU 可用性和成本优化挑战。
缺点
- SGLang和其他推理框架支持有限：从代码库中没有看到对 SGLang 的明确支持。AIBrix 主要针对 vLLM 进行了优化，对于 SGLang 可能需要额外的配置或自定义集成。
- 仍在开发中：AIBrix 仍处于开发阶段（当前版本 0.2.1），某些功能可能不完善或存在稳定性问题。
- 分布式 KV Cache 实现不完整：分布式模式尚未完全实现，目前主要支持集中式模式。
- 文档和示例可能不足：对于某些高级功能，可能缺乏详细的文档和使用示例，增加了学习和使用的难度。
- 依赖 Kubernetes 特定功能：深度集成 Kubernetes，可能对 Kubernetes 版本或特定功能有依赖，增加了部署的复杂性。
