ACK Gateway with AI Extension:面向Kubernetes大模型推理的智能路由实践

简介: 本文介绍了如何利用阿里云容器服务ACK推出的ACK Gateway with AI Extension组件,在Kubernetes环境中为大语言模型(LLM)推理服务提供智能路由和负载均衡能力。文章以部署和优化QwQ-32B模型为例,详细展示了从环境准备到性能测试的完整实践过程。

【阅读原文】戳:ACK Gateway with AI Extension:面向Kubernetes大模型推理的智能路由实践

在当今大语言模型(LLM)推理场景中,Kubernetes已经成为LLM推理服务部署不可获取的基础设施,但在LLM流量管理方面、由于LLM推理服务和推理流量的特殊性,传统的负载均衡和路由调度算法已难以满足该类服务的高性能、高可靠性需求。阿里云容器服务ACK推出ACK Gateway with AI Extension组件,基于Kubernetes社区的Gateway API及Inference Extension规范,为LLM推理服务提供了一系列生产级的智能路由和负载均衡能力。

 

本文主要介绍如何通过ACK Gateway with AI Extension插件为阿里云ACK集群中部署的QwQ-32B模型提供生产级的复杂均衡和智能路由能力。

 

 

 

 

环境准备:部署QwQ-32B推理服务

 

 

 

在本文中,我们基于QwQ-32B推理服务展示ACK Gateway with AI Extension能力。QwQ-32B是阿里云最新发布的高效能大语言模型,拥有32亿参数,性能可媲美DeepSeek-R1 671B。该模型在数学、代码生成等核心指标上表现出色,能够以更低的资源消耗提供卓越的推理能力。

 

前提条件

 

已创建包含GPU的Kubernetes集群,具体操作请参考创建包含GPU的Kubernetes集群[1]

 

至少准备一个ecs.gn7i-c32g1.32xlarge(4xA10)GPU节点,本文示例使用了包含5个ecs.gn7i-c32g1.32xlargeGPU节点的集群。

 

步骤一:准备模型数据

 

1. 下载模型。

 

GIT_LFS_SKIP_SMUDGE=1 git clone https://www.modelscope.cn/Qwen/QwQ-32B.git
cd QwQ-32B
git lfs pull

 

2. 上传模型至OSS。

 

ossutil mkdir oss://<Your-Bucket-Name>/QwQ-32B
ossutil cp -r ./QwQ-32B oss://<Your-Bucket-Name>/QwQ-32B

 

3. 为目标集群配置存储卷PV和PVC。

具体操作请参考使用OSS静态存储卷[2]。以下为示例PV的配置信息:

 

配置项 说明
存储卷类型 OSS
名称 llm-model
访问证书 配置用于访问OSS的AccessKey ID和AccessKey Secret。
Bucket ID 选择已创建的OSS Bucket。
OSS Path 选择模型所在的路径,如/models/Qwen1.5-4B-Chat。

 

以下为示例PVC的配置信息:

 

配置项 说明
存储声明类型 OSS
名称 llm-model
分配模式 选择已有存储卷
已有存储卷 单击选择已有存储卷链接,选择已创建的存储卷PV。

 

步骤二:部署推理服务

 

以下命令基于vLLM框架部署QwQ-32B模型的推理服务:

 

kubectl apply -f- <<EOF
apiVersion: apps/v1
kind: Deployment
metadata:
  labels:
    app: qwq-32b
  name: qwq-32b
  namespace: default
spec:
  replicas: 5 # 根据GPU节点数量进行调整
  selector:
    matchLabels:
      app: qwq-32b
  template:
    metadata:
      labels:
        app: qwq-32b
      annotations:
        prometheus.io/path: /metrics
        prometheus.io/port: "8000"
        prometheus.io/scrape: "true"
    spec:
      volumes:
        - name: model
          persistentVolumeClaim:
            claimName: llm-model
        - name: dshm
          emptyDir:
            medium: Memory
            sizeLimit: 30Gi
      containers:
      - command:
        - sh
        - -c
        - vllm serve /models/QwQ-32B --port 8000 --trust-remote-code --served-model-name qwq-32b --tensor-parallel=4 --max-model-len 8192 --gpu-memory-utilization 0.95 --enforce-eager
        image: registry-cn-hangzhou.ack.aliyuncs.com/dev/vllm:v0.7.2
        name: vllm
        ports:
        - containerPort: 8000
        readinessProbe:
          tcpSocket:
            port: 8000
          initialDelaySeconds: 30
          periodSeconds: 30
        resources:
          limits:
            nvidia.com/gpu: "4"
        volumeMounts:
          - mountPath: /models/QwQ-32B
            name: model
          - mountPath: /dev/shm
            name: dshm
---
apiVersion: v1
kind: Service
metadata:
  name: qwq-32b-v1
spec:
  type: ClusterIP
  ports:
  - port: 8000
    protocol: TCP
    targetPort: 8000
  selector:
    app: qwq-32b
EOF

 

 

 

 

使用ACK Gateway with AI Extension进行模型灰度与智能负载均衡

 

 

 

ACK Gateway with AI Extension概述

 

ACK Gateway with AI Extension组件专为LLM推理场景设计,支持四层/七层流量路由,并提供基于模型服务器负载智能感知的负载均衡能力。此外,通过InferencePool和InferenceModel自定义资源(CRD),可以灵活定义推理服务的流量分发策略,包括模型灰度发布。

 

步骤一:开启ACK Gateway with AI Extension组件

 

1. 在ACK集群的组件管理中开启ACK Gateway with AI Extension组件,并启用“Gateway API推理扩展”选项。

 

image.png

 

2. 创建网关实例:使用kubectl连接到ACK集群,并使用以下指令来创建一个具有8080和8081端口的网关。其中8080端口将部署一个标准的HTTP路由、路由到后端推理服务,而8081端口则将基于推理服务扩展向后端推理服务进行路由。

 

kubectl apply -f- <<EOF
apiVersion: gateway.networking.k8s.io/v1
kind: GatewayClass
metadata:
  name: inference-gateway
spec:
  controllerName: gateway.envoyproxy.io/gatewayclass-controller
---
apiVersion: gateway.networking.k8s.io/v1
kind: Gateway
metadata:
  name: inference-gateway
spec:
  gatewayClassName: inference-gateway
  listeners:
    - name: http
      protocol: HTTP
      port: 8080
    - name: llm-gw
      protocol: HTTP
      port: 8081
---
apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: backend
spec:
  parentRefs:
    - name: inference-gateway
      sectionName: http
  rules:
    - backendRefs:
        - group: ""
          kind: Service
          name: vllm-llama2-7b-pool
          port: 8000
      matches:
        - path:
            type: PathPrefix
            value: /
      timeouts:
        request: "24h"
        backendRequest: "24h"
EOF

步骤二:在网关8081端口上启用推理扩展

 

通过InferencePool和InferenceModel资源来启用AI推理扩展能力。在推理扩展提供的CRD中:InferencePool资源通过标签选择器声明一组在集群中运行的LLM推理服务工作负载,而InferenceModel指定了InferencePool中具体模型的流量分发策略。

 

1. 创建InferencePool。

InferencePool通过标签选择器声明一组推理服务工作负载:

 

kubectl apply -f- <<EOF
apiVersion: inference.networking.x-k8s.io/v1alpha1
kind: InferencePool
metadata:
  annotations:
    inference.networking.x-k8s.io/attach-to: |
      name: inference-gateway
      port: 8081
  name: reasoning-pool
spec:
  targetPortNumber: 8000
  selector:
    app: qwq-32b
EOF

 

2. 创建InferenceModel。

InferenceModel定义了模型的流量分发策略,支持灰度发布。以下示例展示了一个基本用例:将模型名为qwq的请求全部转发给qwq-32b模型。

 

kubectl apply -f- <<EOF
apiVersion: inference.networking.x-k8s.io/v1alpha1
kind: InferenceModel
metadata:
  name: inferencemodel-sample
spec:
  criticality: Critical
  modelName: qwq
  poolRef:
    group: inference.networking.x-k8s.io
    kind: InferencePool
    name: reasoning-pool
  targetModels:
  - name: qwq-32b
    weight: 100
EOF

 

语义说明:

 

targetModels字段定义了目标模型及其权重比例。例如,上述配置表示100%的请求将路由到QwQ-32B模型。

 

criticality字段用于标记模型的重要性,影响流量调度优先级。

 

执行以下命令验证智能路由是否生效:

 

GATEWAY_IP=$(kubectl get gateway/inference-gateway -o jsonpath='{.status.addresses[0].value}')
curl -X POST ${GATEWAY_IP}/v1/chat/completions \
-H 'Content-Type: application/json' \
-d '{
    "model": "qwq",
    "messages": [
      {
        "role": "user",
        "content": "你是谁?" 
      }
    ]
}' -v

 

步骤三:压测推理服务、观测推理服务性能和负载均衡效果

 

1. 通过Prometheus实例默认的服务发现机制采集推理服务相关指标。具体操作,请参见默认服务发现[3]

 

2. 通过Grafana大盘来观测基于vLLM部署的LLM推理服务:将vllm的Grafana JSON model导入到Grafana,创建LLM推理服务的可观测大盘。导入的JSON model请参见vllm官方网站[4]。具体导入操作,请参见如何导出和导入Grafana仪表盘[5]

 

3. 执行以下命令创建压测工具

 

kubectl apply -f- <<EOF 
apiVersion: apps/v1 
kind: Deployment
metadata:
  name: vllm-benchmark
  labels:
    app: vllm-benchmark
spec:
  replicas: 1
  selector:
    matchLabels:
      app: vllm-benchmark
  template:
    metadata:
      labels:
        app: vllm-benchmark
    spec:
      volumes:
      - name: llm-model
        persistentVolumeClaim:
          claimName: llm-model
      containers:
      - name: vllm-benchmark
        image: kube-ai-registry.cn-shanghai.cr.aliyuncs.com/kube-ai/vllm-benchmark:v1
        command:
        - "sh"
        - "-c"
        - "sleep inf"
        volumeMounts:
        - mountPath: /models/QwQ-32B
          name: llm-model
EOF

 

4. 下载压测数据集。

 

# 执行以下命令进入Benchmark Pod
PODNAME=$(kubectl get po -o custom-columns=":metadata.name"|grep "vllm-benchmark")
kubectl exec -it $PODNAME -- bash
# 下载压测数据集
pip3 install modelscope
modelscope download --dataset gliang1001/ShareGPT_V3_unfiltered_cleaned_split ShareGPT_V3_unfiltered_cleaned_split.json --local_dir /root/

 

5. 使用以下指令分别向网关的8080端口(采用网关默认服务路由)和8081端口(采用推理扩展的服务路由)发起两次压测。

 

• 压测网关默认服务路由

 

python3 /root/vllm/benchmarks/benchmark_serving.py \
--backend vllm \
--model /models/QwQ-32B \
--served-model-name qwq-32b \
--trust-remote-code \
--dataset-name random \
--dataset-path /root/ShareGPT_V3_unfiltered_cleaned_split.json \
--random-prefix-len 1000 \
--random-input-len 4000 \
--random-output-len 3000 \
--random-range-ratio 0.2 \
--num-prompts 3000 \
--max-concurrency 60 \
--host 172.16.12.92 \ # ACK Gateway 网关内网ip
--port 8080 \ # 请求8080端口,网关通过默认方式对推理服务进行路由
--endpoint /v1/completions \
--save-result \
2>&1 | tee benchmark_serving.txt
============ Serving Benchmark Result ============
Successful requests:                     2990      
Benchmark duration (s):                  5822.60   
Total input tokens:                      10071917  
Total generated tokens:                  5334789   
Request throughput (req/s):              0.51      
Output token throughput (tok/s):         916.22    
Total Token throughput (tok/s):          2646.02   
---------------Time to First Token----------------
Mean TTFT (ms):                          2456.44   
Median TTFT (ms):                        1366.07   
P99 TTFT (ms):                           23509.43  
-----Time per Output Token (excl. 1st token)------
Mean TPOT (ms):                          63.50     
Median TPOT (ms):                        63.33     
P99 TPOT (ms):                           75.22     
---------------Inter-token Latency----------------
Mean ITL (ms):                           63.47     
Median ITL (ms):                         55.49     
P99 ITL (ms):                            59.16     
==================================================

 

• 压测推理扩展的服务路由

 

python3 /root/vllm/benchmarks/benchmark_serving.py \
--backend vllm \
--model /models/QwQ-32B \
--served-model-name qwq-32b \
--trust-remote-code \
--dataset-name random \
--dataset-path /root/ShareGPT_V3_unfiltered_cleaned_split.json \
--random-prefix-len 1000 \
--random-input-len 4000 \
--random-output-len 3000 \
--random-range-ratio 0.2 \
--num-prompts 3000 \
--max-concurrency 60 \
--host 172.16.12.92 \
--port 8081 \ # 请求8081端口,网关基于推理扩展对推理服务进行路由
--endpoint /v1/completions \
--save-result \
2>&1 | tee benchmark_serving_ext.txt
============ Serving Benchmark Result ============
Successful requests:                     2990      
Benchmark duration (s):                  5755.77   
Total input tokens:                      10071917  
Total generated tokens:                  5332890   
Request throughput (req/s):              0.52      
Output token throughput (tok/s):         926.53    
Total Token throughput (tok/s):          2676.41   
---------------Time to First Token----------------
Mean TTFT (ms):                          1796.93   
Median TTFT (ms):                        1470.97   
P99 TTFT (ms):                           8857.07   
-----Time per Output Token (excl. 1st token)------
Mean TPOT (ms):                          63.10     
Median TPOT (ms):                        63.03     
P99 TPOT (ms):                           70.68     
---------------Inter-token Latency----------------
Mean ITL (ms):                           63.06     
Median ITL (ms):                         55.37     
P99 ITL (ms):                            59.17     
==================================================

 

 

 

 

性能对比与总结

 

 

 

分别对普通网关(8080端口)和ACK Gateway with AI Extension(8081端口)进行了压测,关键指标结果如下:

 

指标 普通网关路由 ACK Gateway with AI Extension智能路由
平均TTFT (ms) 2456.44 1796.93
P99 TTFT (ms) 23509.43 8857.07
输出吞吐量 (tok/s) 916.22 926.53

 

同时可以观测到两次压测对应时间段内,vLLM服务器可观测大盘的可视化对比。

 

image.png

 

通过压测数据和大盘可以直观地发现基于ACK Gateway的推理扩展对推理服务进行路由和负载均衡时,QwQ-32B推理服务拥有更好的延迟、吞吐量和缓存利用率表现,生产性能更佳。其中请求和token吞吐略有提升,平均TTFT缩短26.8%,P99 TTFT降低62.32%,KV Cache利用率在不同工作负载之间更加均匀。

 

相比传统网关,ACK Gateway with AI Extension显著提升了推理服务的延迟、吞吐量和缓存利用率,为LLM推理场景提供了更优的解决方案。同时还能够针对LLM推理服务提供模型灰度、流量镜像等场景化能力。如果您对ACK Gateway with AI Extension感兴趣,欢迎参考官方文档[6]来进行进一步探索!

 

注:测试结果与多种因素有关,上述结果仅供参考。

 

相关链接:

 

[1] 创建包含GPU的Kubernetes集群

https://help.aliyun.com/zh/ack/ack-managed-and-ack-dedicated/user-guide/create-an-ack-managed-cluster-with-gpu-accelerated-nodes?spm=a2c4g.171073.0.0.4c78f95a00Mb5P

 

[2] 使用OSS静态存储卷

https://help.aliyun.com/zh/ack/ack-managed-and-ack-dedicated/user-guide/mount-statically-provisioned-oss-volumes

 

[3] 默认服务发现

https://help.aliyun.com/zh/arms/prometheus-monitoring/default-pod-service-discovery

 

[4] vllm官方网站

https://docs.vllm.ai/en/latest/getting_started/examples/prometheus_grafana.html

 

[5] 如何导出和导入Grafana仪表盘

https://help.aliyun.com/zh/grafana/support/how-to-export-and-import-the-grafana-dashboard

 

[6] 官方文档

https://help.aliyun.com/zh/ack/product-overview/ack-gateway-with-ai-extension?scm=20140722.S_help%40%40%E6%96%87%E6%A1%A3%40%402872965.S_RQW%40ag0%2BBB2%40ag0%2BBB1%40ag0%2Bos0.ID_2872965-RL_ACKGatewaywithAI-LOC_doc%7EUND%7Eab-OR_ser-PAR1_212a5d3e17418618038791691d75c4-V_4-P0_0-P1_0&spm=a2c4g.11186623.help-search.i20


我们是阿里巴巴云计算和大数据技术幕后的核心技术输出者。

欢迎关注 “阿里云基础设施”同名微信微博知乎

获取关于我们的更多信息~

相关实践学习
通过Ingress进行灰度发布
本场景您将运行一个简单的应用,部署一个新的应用用于新的发布,并通过Ingress能力实现灰度发布。
容器应用与集群管理
欢迎来到《容器应用与集群管理》课程,本课程是“云原生容器Clouder认证“系列中的第二阶段。课程将向您介绍与容器集群相关的概念和技术,这些概念和技术可以帮助您了解阿里云容器服务ACK/ACK Serverless的使用。同时,本课程也会向您介绍可以采取的工具、方法和可操作步骤,以帮助您了解如何基于容器服务ACK Serverless构建和管理企业级应用。 学习完本课程后,您将能够: 掌握容器集群、容器编排的基本概念 掌握Kubernetes的基础概念及核心思想 掌握阿里云容器服务ACK/ACK Serverless概念及使用方法 基于容器服务ACK Serverless搭建和管理企业级网站应用
目录
打赏
0
16
17
0
233
分享
相关文章
ACK Gateway with AI Extension:大模型推理的模型灰度实践
本文介绍了如何使用 ACK Gateway with AI Extension 组件在云原生环境中实现大语言模型(LLM)推理服务的灰度发布和流量分发。该组件专为 LLM 推理场景设计,支持四层/七层流量路由,并提供基于模型服务器负载感知的智能负载均衡能力。通过自定义资源(CRD),如 InferencePool 和 InferenceModel,可以灵活配置推理服务的流量策略,包括模型灰度发布和流量镜像。
使用容器服务ACK快速部署QwQ-32B模型并实现推理智能路由
阿里云最新发布的QwQ-32B模型,通过强化学习大幅度提升了模型推理能力。QwQ-32B模型拥有320亿参数,其性能可以与DeepSeek-R1 671B媲美。
领先AI企业经验谈:探究AI分布式推理网络架构实践
当前,AI行业正处于快速发展的关键时期。继DeepSeek大放异彩之后,又一款备受瞩目的AI智能体产品Manus横空出世。Manus具备独立思考、规划和执行复杂任务的能力,其多智能体架构能够自主调用工具。在GAIA基准测试中,Manus的性能超越了OpenAI同层次的大模型,展现出卓越的技术实力。
|
3月前
|
利用Spring Cloud Gateway Predicate优化微服务路由策略
Spring Cloud Gateway 的路由配置中,`predicates`​(断言)用于定义哪些请求应该匹配特定的路由规则。 断言是Gateway在进行路由时,根据具体的请求信息如请求路径、请求方法、请求参数等进行匹配的规则。当一个请求的信息符合断言设置的条件时,Gateway就会将该请求路由到对应的服务上。
223 69
利用Spring Cloud Gateway Predicate优化微服务路由策略
🛡️Spring Boot 3 整合 Spring Cloud Gateway 工程实践
本文介绍了如何使用Spring Cloud Alibaba 2023.0.0.0技术栈构建微服务网关,以应对微服务架构中流量治理与安全管控的复杂性。通过一个包含鉴权服务、文件服务和主服务的项目,详细讲解了网关的整合与功能开发。首先,通过统一路由配置,将所有请求集中到网关进行管理;其次,实现了限流防刷功能,防止恶意刷接口;最后,添加了登录鉴权机制,确保用户身份验证。整个过程结合Nacos注册中心,确保服务注册与配置管理的高效性。通过这些实践,帮助开发者更好地理解和应用微服务网关。
82 0
🛡️Spring Boot 3 整合 Spring Cloud Gateway 工程实践
深入 Spring Cloud Gateway 过滤器
Spring Cloud Gateway 是新一代微服务网关框架,支持多种过滤器实现。本文详解了 `GlobalFilter`、`GatewayFilter` 和 `AbstractGatewayFilterFactory` 三种过滤器的实现方式及其应用场景,帮助开发者高效利用这些工具进行网关开发。
512 1
项目中用的网关Gateway及SpringCloud
Spring Cloud Gateway 是一个功能强大、灵活易用的API网关解决方案。通过配置路由、过滤器、熔断器和限流等功能,可以有效地管理和保护微服务。本文详细介绍了Spring Cloud Gateway的基本概念、配置方法和实际应用,希望能帮助开发者更好地理解和使用这一工具。通过合理使用Spring Cloud Gateway,可以显著提升微服务架构的健壮性和可维护性。
129 0
SpringCloud基础2——Nacos配置、Feign、Gateway
nacos配置管理、Feign远程调用、Gateway服务网关
SpringCloud基础2——Nacos配置、Feign、Gateway
实现微服务网关:Zuul与Spring Cloud Gateway的比较分析
实现微服务网关:Zuul与Spring Cloud Gateway的比较分析
299 5
Spring Cloud Gateway 中,过滤器的分类有哪些?
Spring Cloud Gateway 中,过滤器的分类有哪些?
171 3