AI Engine Runtime 详解AIBrix 推理引擎统一管理 Sidecar 的指标标准化、模型下载与 LoRA 动态加载实战【免费下载链接】aibrixCost-efficient and pluggable Infrastructure components for GenAI inference项目地址: https://gitcode.com/GitHub_Trending/ai/aibrixAI Engine Runtimeaibrix-runtime是 AIBrix 控制平面与推理引擎 Pod 之间的统一管理边车sidecar它把 vLLM 等推理引擎差异化的指标、模型与适配器管理能力收敛为控制平面可稳定调用的 HTTP API。本文将从架构原理、Sidecar 注入部署、指标标准化、多源模型下载、LoRA 动态加载到完整配置与 API 参考逐层讲透这个组件的安装与实战用法。AI Engine Runtime 是什么AI Engine Runtime 是一个运行在推理引擎旁边的小型 HTTP 服务通常以同一 Pod 内的 sidecar 容器形式存在。它存在的根本原因是不同的推理引擎vLLM、SGLang、TRT-LLM 等对外暴露的能力各不相同而 AIBrix 控制平面自动扩缩容控制器、LoRA 适配器控制器、网关等需要一套稳定的接口来读写这些引擎。Runtime 恰好充当了这层翻译器。从 设计文档 的定位来看它为控制平面提供三大类能力指标标准化Metric standardization抓取引擎自身的/metrics在自身端口上以统一命名重新导出让自动扩缩容器和网关只面对一种指标形状。模型与适配器管理Model and adapter management从 HuggingFace、S3、TOS 下载模型权重并在引擎上加载/卸载 LoRA 适配器。LoRA 动态加载 控制器正是通过它的端点完成适配器生命周期管理。运行时模型生命周期Runtime model lifecycle一组实验性端点供 ModelClaim 在共享 Pod 中启动、休眠、唤醒和停用引擎进程。需要特别澄清的是Runtime 不代理推理流量。Envoy 网关直接把请求转发给引擎容器本身网关与 Runtime 的唯一接触点是对休眠中的 ModelClaim 引擎发起 wake 调用。因此大多数部署并不需要安装 Runtime只有在使用动态 LoRA 加载或ModelClaim时才需要安装它。同样值得注意的是它与 Istio 之类的数据面 sidecar 有本质区别——数据面流量完全不会经过它它只提供控制平面交互所需的管理能力。工作原理Runtime 的整体架构与数据流可以用下图概括其核心交互逻辑如下Runtime 监听8080端口通过INFERENCE_ENGINE_ENDPOINT默认http://localhost:8000访问引擎。控制平面ModelAdapter / ModelClaim 控制器通过:8080的 HTTP 接口驱动 RuntimePrometheus / 自动扩缩容器则抓取:8080/metrics。Runtime 内部再向引擎的/metrics、/v1/load_lora_adapter等端点发起请求完成指标采集与适配器操作。控制平面如何使用 Runtime控制器管理器有一个全局开关--enable-runtime-sidecar它只影响 ModelAdapterLoRA控制器的行为开启时当 Pod 中存在名为aibrix-runtime的容器时LoRA 控制器通过 8080 端口的 Runtime API 工作否则回退到引擎自身 8000 端口的 API。关闭时默认始终直接调用引擎 API。ModelClaim 控制器和网关的 wake 路径则始终使用 8080 端口的 Runtime不受该 flag 影响。从源码看这条分支逻辑实现在 pkg/controller/modeladapter/lora_client.go 中useSidecar : c.runtimeConfig.EnableRuntimeSidecar DetectRuntimeSidecar(targetPod)即全局开关开启且Pod 中检测到 Runtime 容器两个条件同时满足时才走 sidecar 路径。LoRA 相关端点路径也定义于此文件/v1/lora_adapter/load、/v1/lora_adapter/unload、/v1/models。引擎支持边界两个关键事实必须牢记指标在每个抓取周期都会重新采集Runtime 抓取引擎的 metrics 页面应用INFERENCE_ENGINE对应的标准化规则后提供服务。代码中虽然存在sglang和trtllm的规则集但Runtime 只支持以INFERENCE_ENGINEvllm启动——启动时初始化的引擎客户端会拒绝任何其他值。模型管理 API/v1/lora_adapter/*、/v1/models仅为 vLLM 0.6.1 及以上版本实现其他引擎暂不支持这些端点。安装与部署AIBrix Runtime 可以通过基于 Webhook 的 sidecar 自动注入推荐或手动添加到 Deployment 清单中两种方式部署。自动 Sidecar 注入推荐最简单的启用方式是通过自动 sidecar 注入只需在 Deployment 或 StormService 上添加注解model.aibrix.ai/sidecar-injection: trueapiVersion: apps/v1 kind: Deployment metadata: name: vllm-server annotations: model.aibrix.ai/sidecar-injection: true # Enable automatic runtime injection spec: template: spec: containers: - name: vllm image: vllm/vllm-openai:latest # Your container configuration...Webhook 会自动把aibrix-runtimesidecar 容器注入到你的 Pod 中。相关的注解与容器名常量定义在 pkg/webhook/sidecar_injection.goSidecarInjectionAnnotation model.aibrix.ai/sidecar-injectionSidecarName aibrix-runtime。注入后的 Pod spec 里会出现什么了解注入内容有助于你核对最终生成的 Pod 规格一个名为aibrix-runtime的容器以aibrix_runtime --port 8080启动镜像为aibrix/runtime:v0.5.0可通过下方 image 注解覆盖环境变量INFERENCE_ENGINE当工作负载设置了model.aibrix.ai/engine注解时取自该注解否则根据引擎容器镜像名推断vllm、sglang、tgi、triton、llamacpp其余推断为unknown同时注入INFERENCE_ENGINE_ENDPOINThttp://localhost:8000。注意只有vllm能产出一个可以正常启动的 Runtime所以请只把它注入到 vLLM 工作负载容器端口metrics8080、存活探针/healthz和就绪探针/ready一个挂载在/tmp/aibrix/adapters的adapter-storage卷用于存放下载的适配器资源请求100mCPU /256Mi内存上限500m/512Mi。Webhook 注册在Deployment和StormService对象上且failurePolicy: Ignore——Webhook 故障绝不会阻塞工作负载创建最多只是 sidecar 没有被注入。在 StormService 上启用Sidecar 注入同样适用于 StormService 自定义资源会注入到每个 role 的 Pod 模板中apiVersion: orchestration.aibrix.ai/v1alpha1 kind: StormService metadata: name: my-service annotations: model.aibrix.ai/sidecar-injection: true spec: template: spec: roles: - name: worker template: spec: containers: - name: vllm image: vllm/vllm-openai:latest # ...自定义 Runtime 镜像通过注解可以指定自定义的 Runtime 镜像apiVersion: apps/v1 kind: Deployment metadata: name: vllm-server annotations: model.aibrix.ai/sidecar-injection: true model.aibrix.ai/sidecar-runtime-image: aibrix/runtime:v0.5.0 # Custom image spec: # ...启用全局 Runtime Flag要让控制器使用 sidecar 的 API需要在启动 controller-manager 时打开全局开关# Enable runtime sidecar globally ./bin/controller-manager --enable-runtime-sidecartrueRuntime 检测逻辑如下表所示EnableRuntimeSidecar行为false控制器始终使用引擎直连 API8000 端口即使 sidecar 已被注入true控制器检测 Pod 中是否存在aibrix-runtime容器存在则走 Runtime API8080 端口不存在则回退到引擎直连 API8000 端口这种设计保证了无论是否注入 sidecar功能都能正常工作提供了最大灵活性。手动安装 Sidecar如果偏好手动控制可以直接把 Runtime sidecar 加入 Deployment YAMLcontainers: - name: vllm image: vllm/vllm-openai:latest # Your main container configuration... - name: aibrix-runtime image: aibrix/runtime:v0.5.0 command: - aibrix_runtime - --port - 8080 env: - name: INFERENCE_ENGINE value: vllm # only vllm is supported - name: INFERENCE_ENGINE_ENDPOINT value: http://localhost:8000 ports: - containerPort: 8080 protocol: TCP volumeMounts: - mountPath: /models name: model-hostpath volumes: - name: model-hostpath hostPath: path: /root/models type: DirectoryOrCreate独立安装Kubernetes 之外如果你希望在 Kubernetes 之外的其他场景使用 Runtime可以通过 pip 安装python3 -m pip install aibrix如需使用 nightly 版本可以从源码安装cd $AIBRIX_HOME/python/aibrix python3 -m pip install -e .指标标准化不同的推理引擎暴露的指标各不相同AI Engine Runtime 负责把它们标准化。与推理引擎相关的信息通过容器环境变量定义。例如若 vLLM 在http://localhost:8000/metrics提供指标服务可用如下命令启动 RuntimeINFERENCE_ENGINEvllm INFERENCE_ENGINE_ENDPOINThttp://localhost:8000 aibrix_runtime --port 8080Runtime 随后在http://localhost:8080/metrics提供结果引擎暴露的每个指标都会原样透传而对于有标准化规则的指标Runtime 会额外输出一份以引擎无关的aibrix:前缀命名的副本。下表列出了完整的标准化映射。SGLang 与 TRT-LLM 列描述的是代码中已存在的规则集定义于 python/aibrix/aibrix/metrics/engine_rules.py由于 Runtime 目前只能以INFERENCE_ENGINEvllm启动这两列暂时无法被选中启用标准名称vLLM 来源SGLang 来源TRT-LLM 来源aibrix:queue_sizevllm:num_requests_waitingsglang:num_queue_reqsN/Aaibrix:gpu_cache_usage_percvllm:gpu_cache_usage_percN/AN/Aaibrix:kv_cache_usage_percvllm:kv_cache_usage_percN/Akv_cache_utilizationaibrix:token_usageN/Asglang:token_usageN/Aaibrix:prompt_tokens_totalvllm:prompt_tokens_totalsglang:prompt_tokens_totalN/Aaibrix:generation_tokens_totalvllm:generation_tokens_totalsglang:generation_tokens_totalN/Aaibrix:generation_throughputN/Asglang:gen_throughputN/Aaibrix:time_to_first_token_secondsvllm:time_to_first_token_secondssglang:time_to_first_token_secondstime_to_first_token_secondsaibrix:time_per_output_token_secondsvllm:time_per_output_token_secondssglang:time_per_output_token_secondstime_per_output_token_secondsaibrix:e2e_request_latency_secondsvllm:e2e_request_latency_secondssglang:e2e_request_latency_secondse2e_request_latency_secondsaibrix:request_success_totalvllm:request_success_totalN/Arequest_success_totalaibrix:cache_hit_rateN/Asglang:cache_hit_rateN/Aaibrix:kv_cache_hit_rateN/AN/Akv_cache_hit_rate从 engine_rules.py 的实现细节看vLLM 规则中除了核心的queue_size、gpu_cache_usage_perc、kv_cache_usage_perc、token 与延迟类指标外还通过PassthroughStandardRule保留了vllm:num_requests_running、vllm:request_prompt_tokens、vllm:request_generation_tokens等调试指标SGLang 也透传了sglang:num_running_reqs、sglang:num_used_tokens、sglang:func_latency_seconds。TRT-LLM 的映射则特意保持克制仅覆盖 AIBrix 当前消费的指标。透传模式与故障兜底设置METRICS_RAW_PASSTHROUGH_MODE1或METRICS_ENABLE_TRANSFORMATION0可以跳过标准化副本直接按引擎原始形态提供指标。如果某次抓取中某条规则执行失败Runtime 会记录错误并在该次抓取回退到原始透传而不是丢弃指标。vLLM 指标输出样例以下是 Runtime 提供的 vLLM 指标输出样例该样例采集于aibrix:命名引入之前仅展示透传指标当前版本还会额外输出上表所列的标准化副本# TYPE vllm:cache_config_info gauge vllm:cache_config_info{block_size16,cache_dtypeauto,calculate_kv_scalesFalse,cpu_offload_gb0,enable_prefix_cachingFalse,gpu_memory_utilization0.9,is_attention_freeFalse,num_cpu_blocks9362,num_gpu_blocks81767,num_gpu_blocks_overrideNone,sliding_windowNone,swap_space_bytes4294967296} 1.0 # HELP vllm:num_requests_running Number of requests currently running on GPU. # TYPE vllm:num_requests_running gauge vllm:num_requests_running{model_nameQwen/Qwen2.5-Coder-1.5B-Instruct} 0.0 # HELP vllm:num_requests_swapped Number of requests swapped to CPU. # TYPE vllm:num_requests_swapped gauge vllm:num_requests_swapped{model_nameQwen/Qwen2.5-Coder-1.5B-Instruct} 0.0 # HELP vllm:num_requests_waiting Number of requests waiting to be processed. # TYPE vllm:num_requests_waiting gauge vllm:num_requests_waiting{model_nameQwen/Qwen2.5-Coder-1.5B-Instruct} 0.0 # HELP vllm:gpu_cache_usage_perc GPU KV-cache usage. 1 means 100 percent usage. # TYPE vllm:gpu_cache_usage_perc gauge vllm:gpu_cache_usage_perc{model_nameQwen/Qwen2.5-Coder-1.5B-Instruct} 0.0 # HELP vllm:cpu_cache_usage_perc CPU KV-cache usage. 1 means 100 percent usage. # TYPE vllm:cpu_cache_usage_perc gauge vllm:cpu_cache_usage_perc{model_nameQwen/Qwen2.5-Coder-1.5B-Instruct} 0.0 # HELP vllm:cpu_prefix_cache_hit_rate CPU prefix cache block hit rate. # TYPE vllm:cpu_prefix_cache_hit_rate gauge vllm:cpu_prefix_cache_hit_rate{model_nameQwen/Qwen2.5-Coder-1.5B-Instruct} -1.0 # HELP vllm:gpu_prefix_cache_hit_rate GPU prefix cache block hit rate. # TYPE vllm:gpu_prefix_cache_hit_rate gauge vllm:gpu_prefix_cache_hit_rate{model_nameQwen/Qwen2.5-Coder-1.5B-Instruct} -1.0 # HELP vllm:lora_requests_info Running stats on lora requests. # TYPE vllm:lora_requests_info gauge vllm:lora_requests_info{max_lora0,running_lora_adapters,waiting_lora_adapters} 1.7382173358407154e09 # HELP vllm:num_preemptions_total Cumulative number of preemption from the engine. # TYPE vllm:num_preemptions_total counter vllm:num_preemptions_total{model_nameQwen/Qwen2.5-Coder-1.5B-Instruct} 0.0 # HELP vllm:prompt_tokens_total Number of prefill tokens processed. # TYPE vllm:prompt_tokens_total counter vllm:prompt_tokens_total{model_nameQwen/Qwen2.5-Coder-1.5B-Instruct} 148.0 # HELP vllm:generation_tokens_total Number of generation tokens processed. # TYPE vllm:generation_tokens_total counter vllm:generation_tokens_total{model_nameQwen/Qwen2.5-Coder-1.5B-Instruct} 955.0 # HELP vllm:request_success_total Count of successfully processed requests. # TYPE vllm:request_success_total counter vllm:request_success_total{finished_reasonstop,model_nameQwen/Qwen2.5-Coder-1.5B-Instruct} 4.0 # HELP vllm:iteration_tokens_total Histogram of number of tokens per engine_step. # TYPE vllm:iteration_tokens_total histogram vllm:iteration_tokens_total_sum{model_nameQwen/Qwen2.5-Coder-1.5B-Instruct} 1103.0 vllm:iteration_tokens_total_bucket{le1.0,model_nameQwen/Qwen2.5-Coder-1.5B-Instruct} 994.0 vllm:iteration_tokens_total_bucket{le2.0,model_nameQwen/Qwen2.5-Coder-1.5B-Instruct} 994.0 vllm:iteration_tokens_total_bucket{le4.0,model_nameQwen/Qwen2.5-Coder-1.5B-Instruct} 994.0 vllm:iteration_tokens_total_bucket{le8.0,model_nameQwen/Qwen2.5-Coder-1.5B-Instruct} 994.0 vllm:iteration_tokens_total_bucket{le16.0,model_nameQwen/Qwen2.5-Coder-1.5B-Instruct} 994.0 vllm:iteration_tokens_total_bucket{le24.0,model_nameQwen/Qwen2.5-Coder-1.5B-Instruct} 994.0 vllm:iteration_tokens_total_bucket{le32.0,model_nameQwen/Qwen2.5-Coder-1.5B-Instruct} 994.0 vllm:iteration_tokens_total_bucket{le40.0,model_nameQwen/Qwen2.5-Coder-1.5B-Instruct} 998.0 vllm:iteration_tokens_total_bucket{le48.0,model_nameQwen/Qwen2.5-Coder-1.5B-Instruct} 998.0 vllm:iteration_tokens_total_bucket{le56.0,model_nameQwen/Qwen2.5-Coder-1.5B-Instruct} 998.0 vllm:iteration_tokens_total_bucket{le64.0,model_nameQwen/Qwen2.5-Coder-1.5B-Instruct} 998.0 vllm:iteration_tokens_total_bucket{le72.0,model_nameQwen/Qwen2.5-Coder-1.5B-Instruct} 998.0 vllm:iteration_tokens_total_bucket{le80.0,model_nameQwen/Qwen2.5-Coder-1.5B-Instruct} 998.0 vllm:iteration_tokens_total_bucket{le88.0,model_nameQwen/Qwen2.5-Coder-1.5B-Instruct} 998.0 vllm:iteration_tokens_total_bucket{le96.0,model_nameQwen/Qwen2.5-Coder-1.5B-Instruct} 998.0模型下载AI Engine Runtime 支持从 HuggingFace、S3、TOS 等多个远程源下载模型。当控制平面需要与 Pod 交互以动态加载新模型时这一能力非常关键。下载逻辑的底层实现在 python/aibrix/aibrix/runtime/downloaders.py它按 URL schemes3://、gcs://、tos://、huggingface://、http(s)://分发到对应的ArtifactDownloader实现下载文件时统一先写.part临时文件再原子替换目录下载则按 prefix 遍历并重建相对路径。从 HuggingFace 下载首先定义 HuggingFace 模型所需的环境变量# General settings export DOWNLOADER_ALLOW_FILE_SUFFIXjson, safetensors export DOWNLOADER_NUM_THREADS16 # HuggingFace settings export HF_ENDPOINThttps://hf-mirror.com # set it when env is in CN region然后使用 AI Engine Runtime 从 HuggingFace 下载模型python -m aibrix.downloader \ --model-uri deepseek-ai/deepseek-coder-6.7b-instruct \ --local-dir /tmp/aibrix/models_hf/从 S3 下载首先定义 S3 模型所需的环境变量# General settings export DOWNLOADER_ALLOW_FILE_SUFFIXjson, safetensors export DOWNLOADER_NUM_THREADS16 # AWS settings export AWS_ACCESS_KEY_IDINPUT YOUR AWS ACCESS KEY ID export AWS_SECRET_ACCESS_KEYINPUT YOUR AWS SECRET ACCESS KEY export AWS_ENDPOINT_URLINPUT YOUR AWS ENDPOINT URL # e.g. https://s3.us-west-2.amazonaws.com export AWS_REGIONINPUT YOUR AWS REGION # e.g. us-west-2然后使用 AI Runtime 从 AWS S3 下载模型python -m aibrix.downloader \ --model-uri s3://aibrix-model-artifacts/deepseek-coder-6.7b-instruct/ \ --local-dir /tmp/aibrix/models_s3/从 TOS 下载首先定义 TOS 模型所需的环境变量# General settings export DOWNLOADER_ALLOW_FILE_SUFFIXjson, safetensors export DOWNLOADER_NUM_THREADS16 # AWS settings export TOS_ACCESS_KEYINPUT YOUR TOS ACCESS KEY export TOS_SECRET_KEYINPUT YOUR TOS SECRET KEY export TOS_ENDPOINTINPUT YOUR TOS ENDPOINT # e.g. https://tos-s3-cn-beijing.volces.com export TOS_REGIONINPUT YOUR TOS REGION # e.g. cn-beijing然后使用 AI Runtime 从 TOS 下载模型python -m aibrix.downloader \ --model-uri tos://aibrix-model-artifacts/deepseek-coder-6.7b-instruct/ \ --local-dir /tmp/aibrix/models_tos/上述所有DOWNLOADER_*环境变量都在 python/aibrix/aibrix/envs.py 中被集中解析包括下载目录、线程数、分片阈值DOWNLOADER_PART_THRESHOLD默认 64MB、文件后缀过滤、S3/TOS 凭据与端点等是理解下载器行为的第一手入口。LoRA 适配器管理Model Configuration API前置条件此功能需要引擎以--enable-lora启动并设置环境变量export VLLM_ALLOW_RUNTIME_LORA_UPDATINGtrue。更多细节可参考 vLLM 官方文档 Dynamically serving LoRA Adapters。假设你已部署好一个基础模型和 Runtime现在想为它加载一个 LoRA 适配器。首先启动引擎与 Runtime# start the engine VLLM_ALLOW_RUNTIME_LORA_UPDATINGtrue vllm serve Qwen/Qwen2.5-Coder-1.5B-Instruct --enable-lora # start the runtime INFERENCE_ENGINEvllm INFERENCE_ENGINE_ENDPOINThttp://localhost:8000 aibrix_runtime --port 8080加载 LoRA 适配器curl -X POST http://localhost:8080/v1/lora_adapter/load \ -H Content-Type: application/json \ -d {lora_name: lora-2, lora_path: bharati2324/Qwen2.5-1.5B-Instruct-Code-LoRA-r16v2}卸载 LoRA 适配器curl -X POST http://localhost:8080/v1/lora_adapter/unload \ -H Content-Type: application/json \ -d {lora_name: lora-1}查询引擎当前模型curl -X GET http://localhost:8000/v1/models | jq { object: list, data: [ { id: Qwen/Qwen2.5-Coder-1.5B-Instruct, object: model, created: 1738218097, owned_by: vllm, root: Qwen/Qwen2.5-Coder-1.5B-Instruct, parent: null, max_model_len: 32768, permission: [ { id: modelperm-c2e9860095b745b6b8be7133c5ab1fcf, object: model_permission, created: 1738218097, allow_create_engine: false, allow_sampling: true, allow_logprobs: true, allow_search_indices: false, allow_view: true, allow_fine_tuning: false, organization: *, group: null, is_blocking: false } ] }, { id: lora-1, object: model, created: 1738218097, owned_by: vllm, root: bharati2324/Qwen2.5-1.5B-Instruct-Code-LoRA-r16v2, parent: Qwen/Qwen2.5-Coder-1.5B-Instruct, max_model_len: null, permission: [ { id: modelperm-c21d06b59af0435292c70cd612e68b01, object: model_permission, created: 1738218097, allow_create_engine: false, allow_sampling: true, allow_logprobs: true, allow_search_indices: false, allow_view: true, allow_fine_tuning: false, organization: *, group: null, is_blocking: false } ] }, { id: lora-2, object: model, created: 1738218097, owned_by: vllm, root: bharati2324/Qwen2.5-1.5B-Instruct-Code-LoRA-r16v2, parent: Qwen/Qwen2.5-Coder-1.5B-Instruct, max_model_len: null, permission: [ { id: modelperm-bf2af850171242f7a9f4ccd9ecd313cd, object: model_permission, created: 1738218097, allow_create_engine: false, allow_sampling: true, allow_logprobs: true, allow_search_indices: false, allow_view: true, allow_fine_tuning: false, organization: *, group: null, is_blocking: false } ] } ] }输出中可以看到三个模型条目基础模型Qwen/Qwen2.5-Coder-1.5B-Instruct以及挂载在其下的lora-1、lora-2两个适配器parent指向基础模型。制品委托Artifact Delegation机制当请求体携带artifact_url而非本地lora_path时Runtime 会先下载制品再加载——这正是 ModelAdapter 控制器实际发送的请求形态。这一逻辑实现在 python/aibrix/aibrix/runtime/artifact_service.py 的ArtifactDelegationService中它按lora_name在本地目录默认/tmp/aibrix/adapters落盘、写入.aibrix_download_complete完成标记实现断点续传与并发去重通过正则^[A-Za-z0-9][A-Za-z0-9._-]{0,127}$校验名称并阻止路径穿越随后把本地路径转发给引擎加载卸载时还可按需清理本地制品。凭证则支持从请求直传或从 Kubernetes Secret 挂载目录默认/var/run/secrets/aibrix读取。配置参考命令行参数aibrix_runtime接受如下命令行参数实现在 python/aibrix/aibrix/app.py 的parse_runtime_args中参数默认值说明--host0.0.0.0监听地址--port8080监听端口--enable-fastapi-docsfalse开启 FastAPI 的 OpenAPI schema 与 Swagger UI环境变量变量默认值含义INFERENCE_ENGINEvllm引擎类型。必须是vllm设为其他值 Runtime 将启动失败。INFERENCE_ENGINE_VERSION0.6.1引擎版本。对 vLLM 而言0.6.1 及以上版本才启用 LoRA 端点。INFERENCE_ENGINE_ENDPOINThttp://localhost:8000引擎的基础 URL。METRIC_SCRAPE_PATH/metrics在引擎上抓取的路径。METRICS_ENABLE_TRANSFORMATION1是否应用标准化规则。0强制原始透传。METRICS_RAW_PASSTHROUGH_MODE0按引擎原始形态提供服务指标。PROMETHEUS_MULTIPROC_DIR/tmp/aibrix/metrics/Prometheus 客户端的临时目录。DOWNLOADER_LOCAL_DIR/tmp/aibrix/models/请求未指定目录时模型的下载位置。DOWNLOADER_NUM_THREADS32并行下载线程数。DOWNLOADER_ALLOW_FILE_SUFFIX全部文件要拉取的后缀列表逗号分隔例如json, safetensors。DOWNLOADER_PART_THRESHOLD/DOWNLOADER_PART_CHUNKSIZE67108864文件超过该字节数时按分片拉取以及分片大小。DOWNLOADER_FORCE_DOWNLOAD0即使文件已存在于本地也重新下载。DOWNLOADER_CHECK_FILE_EXIST1跳过本地已存在的文件。HF_TOKEN、HF_ENDPOINT、HF_REVISION未设置HuggingFace 凭据、镜像端点和 revision。AWS_ACCESS_KEY_ID、AWS_SECRET_ACCESS_KEY、AWS_ENDPOINT_URL、AWS_REGION未设置S3 凭据与端点。DOWNLOADER_S3_MAX_IO_QUEUE100与DOWNLOADER_S3_IO_CHUNKSIZE16777216可调优传输。TOS_ACCESS_KEY、TOS_SECRET_KEY、TOS_ENDPOINT、TOS_REGION未设置TOS 凭据与端点。DOWNLOADER_TOS_VERSIONv2选择客户端 APITOS_ENABLE_CRC启用校验和。注解与 Flags设置含义model.aibrix.ai/sidecar-injection: true注解请求 Webhook 向Deployment或StormService注入 Runtime。model.aibrix.ai/sidecar-runtime-image注解要注入的 Runtime 镜像覆盖默认值。--enable-runtime-sidecarcontroller-manager flag默认false当 Pod 中存在aibrix-runtime容器时让控制器使用 Runtime API。HTTP API 参考所有端点都通过 Runtime 端口默认 8080提供服务端点说明GET /healthz存活探针。进程启动后恒返回200。GET /ready就绪探针。注入时用作 Pod 就绪探针。GET /metricsPrometheus 格式的标准化引擎指标。POST /v1/lora_adapter/loadBody 为{lora_name: ..., lora_path: ...}在引擎上加载适配器。lora_path原样传给引擎因此必须是引擎能打开的路径。另一种 body 形态{lora_name: ..., artifact_url: ...}会让 Runtime 先下载制品再加载这是 ModelAdapter 控制器发送的形态。POST /v1/lora_adapter/unloadBody 为{lora_name: ...}。GET /v1/models引擎当前服务的模型列表从引擎代理转发。POST /v1/model/downloadBody 为{model_uri: ..., local_dir: ..., model_name: ..., download_extra_config: {...}}。仅model_uri为必填。GET /v1/model/list列出本地目录中的模型。接受可选 JSON body{local_dir: ...}注意尽管是 GET但参数通过 body 而非 query 传递不传则列出 Runtime 默认下载目录。/v1/runtime/models/*与GET /v1/runtime/snapshot实验性引擎生命周期端点activate、deactivate、sleep、wake、kv-limit供 ModelClaim 使用。不建议直接调用。深入Runtime 模型生命周期与 ModelClaim 协作最后一组实验性端点背后是 python/aibrix/aibrix/runtime/model_runtime.py 中的ModelRuntime引擎生命周期管理器以及 python/aibrix/aibrix/runtime/model_runtime_api.py 中对应的 FastAPI 路由/v1/runtime/models/activate、/deactivate、/sleep、/wake、/kv-limit、/v1/runtime/models列表与/v1/runtime/snapshot。从源码结构看这套机制包含几个值得关注的设计可插拔的执行器EngineLauncher启动/停止/休眠/唤醒引擎进程与KVController通过kvctlCLI 设置 kvcached 共享内存段的容量上限均为抽象基类生产环境使用SubprocessEngineLauncher以独立 session 拉起 vLLM/SGLang 进程并为每个模型分配独立的KVCACHED_IPC_NAME同时提供MockEngineLauncher供无 GPU 的本地测试使用。崩溃安全的本地状态engine_registry.py 的EngineRegistry以同目录临时文件 os.replace的方式原子持久化引擎元数据使 sidecar 重启后能重新收养re-adopt存活下来的引擎进程。抓取时只读的指标采集model_runtime_metrics.py 挂载在同一个/metrics上输出每个 Pod 常驻模型数、各模型的 kvcached KV 用量、HBM 峰值、引擎状态与重启/收养/生命周期操作结果等aibrix:modelclaim_*指标且collect()只读、不产生副作用。小结AI Engine Runtime 把多引擎差异化这一复杂性收拢到了 sidecar 内部向上它为控制平面提供指标、模型、适配器、生命周期四类稳定 API向下它封装了 vLLM 的指标标准化、多源模型下载与 LoRA 动态加载。安装上首选注解驱动的自动注入配合--enable-runtime-sidecar开关即可让 LoRA 控制器按需走 sidecar 路径。需要进一步了解其内部设计可阅读 AI Engine Runtime 设计文档相关的 LoRA 控制器工作流与 ModelClaim 使用方式分别见 LoRA 动态加载 与 ModelClaim。【免费下载链接】aibrixCost-efficient and pluggable Infrastructure components for GenAI inference项目地址: https://gitcode.com/GitHub_Trending/ai/aibrix创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考