AIBrix 多引擎Multi-Engine支持实战指南一套集群统一调度 vLLM、SGLang、xLLM 与 TRT-LLM【免费下载链接】aibrixCost-efficient and pluggable Infrastructure components for GenAI inference项目地址: https://gitcode.com/GitHub_Trending/ai/aibrix本文围绕 AIBrix 的多引擎调度Multi-Engine Scheduling能力展开介绍如何在同一套 AIBrix 实例下同时部署 vLLM、SGLang、xLLM、TRT-LLM 等多种推理引擎通过 Pod 标签label完成引擎识别与指标适配并让路由策略Router基于各引擎真实导出的 Prometheus 指标做请求分发。读完本文你将掌握model.aibrix.ai/engine系列标签的完整配置方法、跨引擎指标映射原理、TRT-LLM 的接入要点以及如何为 AIBrix 扩展新的引擎类型。为什么需要多引擎支持在引入多引擎能力之前AIBrix 在模型服务阶段只支持 vLLM 单一引擎。这带来的直接限制是在同一个工作负载或基准测试benchmarking场景中无法灵活地在不同引擎之间进行实验与对比。多引擎支持为 AIBrix 带来了三方面价值并排对比Side-by-side comparisons在同一套集群中横向对比不同引擎的端到端延迟、吞吐与行为特征为引擎选型提供一手数据部署灵活性Deployment flexibility支持模型分片model sharding或迁移策略例如将部分流量导向 SGLang、部分导向 TRT-LLM指标适配Metrics Adaptation不同引擎导出的 Prometheus 指标名不同AIBrix 通过统一的抽象指标名 引擎映射表来正确解读每种引擎的指标。系统工作方式标签驱动 指标映射多引擎调度的核心设计是标签驱动入站请求会借助 Deployment 上的标签决定如何解读从 Prometheus API 拉取到的指标而这些指标随后被 Router 用于请求委派delegate execution。配置某个引擎时只需在 Deployment 的 Pod 模板template上添加如下标签labels: model.aibrix.ai/name: deepseek-llm-7b-chat model.aibrix.ai/engine: sglang model.aibrix.ai/metric-port: 8000 # 当 Prometheus 端口与默认端口不同时配置 model.aibrix.ai/port: 8000AIBrix 使用model.aibrix.ai/engine标签确定该 Deployment 使用哪个引擎并据此在所有从 Prometheus 拉取的指标中查找正确的指标名格式。目前支持的引擎标签取值为vllm、sglang、xllm、trtllm。完整工作流程三步Pod 监听与引擎识别AIBrix 缓存cache监听携带model.aibrix.ai/name标签的 Pod并从同一 Pod 上读取model.aibrix.ai/engine。AIBrix 内部使用的每一个指标都有一个抽象名称例如num_requests_waiting并对应一张“引擎 → 引擎实际导出的指标名”的映射表该映射定义在 pkg/metrics/metrics.go 中完整映射见下文跨引擎指标映射表一节。指标抓取指标从每个 Pod 的model.aibrix.ai/metric-port端口缺省为8000的/metrics路径抓取对于trtllm引擎路径为/prometheus/metrics。请求则被转发到model.aibrix.ai/port端口。路由策略取值与降级路由策略向缓存请求抽象指标名。当某个引擎没有提供策略所需的指标映射时大多数策略least-request、least-kv-cache、least-latency、least-busy-time、least-gpu-cache、least-util、throughput会为该请求回退到随机 Pod而 SLO 系列策略slo-least-load、slo-pack-load、slo-least-load-pulling则直接返回错误该错误会以 HTTP 503 的形式呈现给客户端。说明可选的 runtime sidecar 是一套独立的机制它会在自己的端口上以标准化形态重新导出引擎指标引擎标签的使用并不依赖该 sidecar。从源码看实现细节在 pkg/cache/cache_metrics.go 中可以看到完整的数据通路常量MetricPortLabel constants.ModelLabelMetricPort、engineLabel constants.ModelLabelEngine、defaultMetricPort 8000、defaultEngineLabelValue vllmpkg/cache/cache_metrics.go定义了标签与默认值getPodMetricPort解析 Pod 的model.aibrix.ai/metric-port标签解析失败或缺失时回退到默认端口8000pkg/cache/utils.go指标抓取工作线程worker以pod.Status.PodIP:podMetricPort作为 endpoint调用metrics.GetEngineType(*pod.Pod)获取引擎类型再经FetchAllTypedMetrics统一抓取所有类型化指标pkg/cache/cache_metrics.go引擎指标路径由 pkg/metrics/engine_fetcher.go 的metricsPathForEngine决定trtllm使用prometheus/metrics其余引擎统一使用metrics当引擎指标自带engine_type/model_name标签缺失或为undefined时sanitizeMetricLabels会使用 Pod 标签model.aibrix.ai/engine、model.aibrix.ai/name回填保证指标归属正确pkg/cache/cache_metrics.go。所有标签键在 pkg/constants/model.go 中以常量形式统一声明ModelLabelName、ModelLabelEngine、ModelLabelMetricPort、ModelLabelPortpkg/constants/model.go格式遵循resource.aibrix.ai/attribute约定。配置参考四个核心标签多引擎的一切配置都通过 Pod 标签完成。注意请将这些标签设置在Deployment的 Pod 模板pod template上如果是 StormService则设置在 role 上而不是设置在 workload 对象如 Deployment 本身的 metadata 上——这与 samples/quickstart/tensorrt/tensor-rt.yaml 中的写法一致Deployment 顶层metadata.labels只放app与模型名model.aibrix.ai/engine放在spec.template.metadata.labels。标签默认值含义model.aibrix.ai/name必填请求中使用的模型名同时用于 Pod 发现。model.aibrix.ai/enginevllm引擎类型取值为vllm、sglang、xllm、trtllm之一决定选用哪张指标映射表。model.aibrix.ai/port8000引擎对外提供推理服务的端口。model.aibrix.ai/metric-port8000引擎暴露/metrics的端口当指标端口与推理服务端口不同时配置例如引擎与 HTTP 代理分离部署的场景见 pkg/cache/cache_metrics.go 的注释。跨引擎指标映射表Supported MetricsAIBrix 目前只支持各引擎有限数量的指标且会持续扩充。对于通过 routing policy API 实现的路由算法位于 pkg/plugins/gateway/algorithms请确保使用的指标在你的目标引擎上受支持。如上文工作流程所述大多数现有路由策略在无法获取目标指标时会回退到默认随机策略SLO 系列策略除外。下表完整列出了 AIBrix 抽象指标名到各引擎实际导出指标名的映射N/A 表示该引擎不提供此指标AIBrix 指标vLLMSGLangxLLMTRT-LLMnum_requests_runningvllm:num_requests_runningsglang:num_running_reqsN/AN/Anum_requests_waitingvllm:num_requests_waitingsglang:num_queue_reqsN/AN/Anum_requests_swappedvllm:num_requests_swappedsglang:num_retracted_reqsN/AN/Aengine_sleep_statevllm:engine_sleep_stateN/AN/AN/Ahttp_requests_totalvllm:http_requests_totalN/AN/AN/Anum_preemptions_totalvllm:num_preemptions_totalN/AN/AN/Arequest_success_totalvllm:num_requests_success_totalsglang:num_requests_totalN/Atrtllm_request_success_totalnum_prefill_prealloc_queue_reqsN/Asglang:num_prefill_prealloc_queue_reqsN/AN/Anum_decode_prealloc_queue_reqsN/Asglang:num_decode_prealloc_queue_reqsN/AN/Ae2e_request_latency_secondsvllm:e2e_request_latency_secondssglang:e2e_request_latency_secondsN/Atrtllm_e2e_request_latency_secondsrequest_queue_time_secondsvllm:request_queue_time_secondsN/AN/Atrtllm_request_queue_time_secondsrequest_inference_time_secondsvllm:request_inference_time_secondsN/AN/AN/Aper_stage_req_latency_secondsN/Asglang:per_stage_req_latency_secondsN/AN/Ahttp_request_duration_secondshttp_request_duration_secondsN/AN/AN/Ahttp_request_duration_highr_secondshttp_request_duration_highr_secondsN/AN/AN/Aprompt_tokens_totalvllm:prompt_tokens_totalN/AN/AN/Arequest_prompt_tokensvllm:request_prompt_tokensN/AN/AN/Ageneration_tokens_totalvllm:generation_tokens_totalN/AN/AN/Arequest_generation_tokensvllm:request_generation_tokensN/AN/AN/Arequest_max_num_generation_tokensvllm:request_max_num_generation_tokensN/AN/AN/Aiteration_tokens_totalvllm:iteration_tokens_totalN/AN/AN/Atime_to_first_token_secondsvllm:time_to_first_token_secondssglang:time_to_first_token_secondsN/Atrtllm_time_to_first_token_secondstime_per_output_token_secondsvllm:time_per_output_token_secondssglang:inter_token_latency_secondsN/Atrtllm_time_per_output_token_secondsinter_token_latency_secondsvllm:inter_token_latency_secondssglang:inter_token_latency_secondsN/Atrtllm_time_per_output_token_secondsrequest_decode_time_secondsvllm:request_decode_time_secondsN/AN/AN/Arequest_prefill_time_secondsvllm:request_prefill_time_secondsN/AN/AN/Arequest_time_per_output_token_secondsvllm:request_time_per_output_token_secondsN/AN/AN/Agpu_cache_usage_percvllm:gpu_cache_usage_percsglang:token_usagekv_cache_utilizationN/Aengine_utilizationN/AN/Aengine_utilizationN/Acpu_cache_usage_percvllm:cpu_cache_usage_percN/AN/AN/Akv_cache_usage_percvllm:kv_cache_usage_percsglang:token_usagekv_cache_utilizationtrtllm_kv_cache_utilizationkv_cache_hit_rateN/AN/AN/Atrtllm_kv_cache_hit_rateprefix_cache_queries_totalvllm:prefix_cache_queries_totalN/AN/AN/Aprefix_cache_hits_totalvllm:prefix_cache_hits_totalN/AN/AN/Aexternal_prefix_cache_queries_totalvllm:external_prefix_cache_queries_totalN/AN/AN/Aexternal_prefix_cache_hits_totalvllm:external_prefix_cache_hits_totalN/AN/AN/Anixl_xfer_time_secondsvllm:nixl_xfer_time_secondsN/AN/AN/Anixl_post_time_secondsvllm:nixl_post_time_secondsN/AN/AN/Anixl_bytes_transferredvllm:nixl_bytes_transferredN/AN/AN/Anixl_num_descriptorsvllm:nixl_num_descriptorsN/AN/AN/Anixl_num_failed_transfers_totalvllm:nixl_num_failed_transfersN/AN/AN/Anixl_num_failed_notifications_totalvllm:nixl_num_failed_notificationsN/AN/AN/Aavg_prompt_throughput_toks_per_svllm:avg_prompt_throughput_toks_per_sN/AN/AN/Aavg_generation_throughput_toks_per_svllm:avg_generation_throughput_toks_per_ssglang:gen_throughputN/AN/Amax_loravllm:lora_requests_infoN/AN/AN/Arunning_lora_adaptersvllm:lora_requests_infoN/AN/AN/Awaiting_lora_adaptersvllm:lora_requests_infoN/AN/AN/A补充说明两点SGLang 的gpu_cache_usage_perc与kv_cache_usage_perc均映射到sglang:token_usage这一点在 pkg/metrics/metrics.go 与 pkg/metrics/metrics.go 的源码注释中也有明确标注// Based on ...。time_per_output_token_seconds在 AIBrix 内部已被标记为 deprecated推荐使用inter_token_latency_seconds替代见 pkg/metrics/metrics.go 的注释但两者的引擎映射均被保留以兼容现有策略。指标的类型化抓取从源码看AIBrix 将指标分为三类分别抓取pkg/cache/cache_metrics.gocounter/gauge 类counterGaugeMetricNames如num_requests_running、kv_cache_usage_perc等直接读取原始值histogram 类histogramMetricNames如time_to_first_token_seconds、e2e_request_latency_seconds等涉及_sum/_bucket/_count序列PromQL 查询类prometheusMetricNames如P95TTFT5m、AvgRequestsPerMinPod等需要在 pkg/metrics/metrics.go 中预定义 PromQL 模板再由缓存按instance、model_name标签实时查询。需要留意的是部分 PromQL 查询类指标例如P95TTFT5m的模板目前仍硬编码引用vllm:前缀的指标名源码中以// TODO: make it agnostic to the enginepkg/metrics/metrics.go标注了待办——也就是说原始指标raw metric已完全引擎无关化但少量查询类指标的引擎无关化仍在推进中。TRT-LLM 快速上手将 TRT-LLM 作为推理引擎时在 Deployment 上设置model.aibrix.ai/engine: trtllm标签即可。TRT-LLM 必须在服务端配置中显式开启性能指标暴露return_perf_metrics: true、enable_iter_perf_stats: true、enable_iter_req_stats: true。官方示例配置位于samples/quickstart/tensorrt/tensor-rt.yaml — 标准单实例部署samples/quickstart/tensorrt/tensor-rt-pd.yaml — 基于 StormService 的 prefill/decode 分离部署。TRT-LLM 的部署标签配置示例labels: model.aibrix.ai/name: Qwen3-8B model.aibrix.ai/engine: trtllm model.aibrix.ai/port: 8000参考 samples/quickstart/tensorrt/tensor-rt.yaml 的完整写法一个可运行的 TRT-LLM Deployment 形如apiVersion: apps/v1 kind: Deployment metadata: name: qwen-tensorrt-llm labels: app: qwen-llm model.aibrix.ai/name: Qwen3-8B model.aibrix.ai/port: 8000 spec: replicas: 1 selector: matchLabels: app: qwen-llm template: metadata: labels: app: qwen-llm model.aibrix.ai/name: Qwen3-8B model.aibrix.ai/port: 8000 model.aibrix.ai/engine: trtllm spec: containers: - name: tensorrt-llm image: tensorrt-llm 镜像 command: [/bin/bash, -c] args: - | cat EOF /tmp/config.yaml backend: pytorch kv_cache_config: free_gpu_memory_fraction: 0.85 max_num_tokens: 8192 max_batch_size: 16 trust_remote_code: true return_perf_metrics: true enable_iter_perf_stats: true enable_iter_req_stats: true perf_metrics_max_requests: 1000 EOF trtllm-serve serve /models/Qwen3-8B \ --host 0.0.0.0 \ --port 8000 \ --extra_llm_api_options /tmp/config.yaml ports: - containerPort: 8000 resources: limits: nvidia.com/gpu: 1 requests: nvidia.com/gpu: 1注意model.aibrix.ai/engine: trtllm位于spec.template.metadata.labelsPod 模板而model.aibrix.ai/name同时出现在 Deployment 顶层 metadata 与 Pod 模板上——这与前文标签应设置在 Pod 模板上的约定一致。TRT-LLM 的已知限制没有队列深度指标TRT-LLM 不暴露num_requests_running或num_requests_waiting。依赖队列深度的路由策略例如least-request将回退到随机路由fall back to random routing。指标依赖显式配置只有当 TRT-LLM 服务端配置设置了return_perf_metrics: true、enable_iter_perf_stats: true、enable_iter_req_stats: true时性能指标才会被导出。指标路径不同TRT-LLM 的指标抓取路径是/prometheus/metrics而非/metrics该逻辑由 pkg/metrics/engine_fetcher.go 的metricsPathForEngine统一处理用户无需额外配置。如何新增引擎Adding New Engines若要支持一个新的引擎或新的指标类型需要完成两步在指标名映射表中添加引擎类型修改 pkg/metrics/metrics.go 中EngineMetricsNameMapping映射例如为某个指标增加newengine: newengine:some_metric条目并补充引擎名常量参考EngineNameVLLM、EngineNameSGLang、EngineNameTRTLLM的定义pkg/metrics/metrics.go在 Deployment YAML 中允许新的引擎标签值在model.aibrix.ai/engine标签上使用新引擎名。更完整的实现细节可参考pkg/cache/cache_metrics.go — 指标抓取、调度、回退与标签清洗逻辑pkg/metrics/metrics.go — 指标注册表与引擎名映射。从代码结构看指标抓取层EngineMetricsFetcher.FetchAllTypedMetrics已经按引擎类型 → 指标路径/映射做了抽象pkg/metrics/engine_fetcher.go因此新增引擎时主要工作集中在映射表补充与标签值合法化无需改动路由策略本身——这也是多引擎设计即插即用的关键所在。小结AIBrix 的多引擎支持通过Pod 标签识别引擎 抽象指标名统一映射 路由策略自动降级三层机制让开发者在同一套集群内自由混排 vLLM、SGLang、xLLM 与 TRT-LLM 等引擎既可用于引擎横向对比与基准测试也可服务于模型分片与迁移等生产场景。接入新引擎时只需补齐 pkg/metrics/metrics.go 中的指标映射并在 Deployment 上声明引擎标签即可复用现有的缓存抓取与路由调度体系。【免费下载链接】aibrixCost-efficient and pluggable Infrastructure components for GenAI inference项目地址: https://gitcode.com/GitHub_Trending/ai/aibrix创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考