后端云原生运维虚拟化人工智能AI 应用【免费下载链接】cloudpods开源、云原生的多云管理及混合云融合平台项目地址https://gitcode.com/yunionio/cloudpods点击查看免费下载在 CloudPods 的多云管理平台中本地 GPU 推理集群与统一 API 网关是两套天然分离的资源llm侧负责在物理机上拉起 vLLM/Ollama/SGLang 推理实例llm_deployment而aiproxy侧负责以 OpenAI 兼容协议对外提供统一的model寻址、密钥鉴权与选路能力。CloudPods 通过auto_register_aiproxy开关与LLMAiproxySyncTask同步任务把两者打通——创建部署后无需手工维护 catalog副本 running 后网关侧会自动生成对应的ai_provider、ai_model、ai_routing资源。本文基于仓库文档docs/llm/llm-deployment-aiproxy.md并结合pkg/llm/models/llm_aiproxy_sync.go、pkg/llm/tasks/llm/llm_aiproxy_sync_task.go等源码实现完整讲清这一自动关联机制的命令行用法、字段对应关系、命名规则与客户端接入方式。机制总览默认开启的自动关联创建llm_deployment时默认开启auto_register_aiproxy。创建任务完成后会调度LLMAiproxySyncTask副本变为 running 后自动在 aiproxy 中创建 catalog 与路由资源。从源码结构可以印证这一链路。在 创建任务 中当AutoRegisterAiproxy为 true 时调用model.StartAiproxySyncTask(...)该任务最终由 LLMAiproxySyncTask 消费OnInit中根据参数分三种路径——带unregister参数时调用UnregisterDeploymentAiproxy做清理带llm_id时先对该副本执行SyncLlmInstance再做整体ReconcileDeploymentAiproxy否则直接执行整体调和。部署模型定义 中AutoRegisterAiproxy *bool字段的注释也明确写着registers running replicas with aiproxy catalog when true (default true; pass false to disable)。创建 deployment默认已关联 aiproxy最基础的操作是使用climc创建推理部署climc llm-deployment-create my-qwen \ --llm-sku-id sku \ --net net \ --replicas 2这条命令走的是LLMDeploymentCreateInput的 Mode A引用已有 SKU路径--llm-sku-id指定复用已存在的 LLM SKU--net指定实例网络--replicas指定 SLLM 推理实例副本数。由于未传--auto-register-aiproxyfalseAutoRegisterAiproxy取默认值 true副本拉起后会自动进入 aiproxy 同步流程。若不希望该部署暴露到网关可显式关闭自动关联climc llm-deployment-create my-qwen \ --auto-register-aiproxyfalse \ --llm-sku-id sku \ --net net该命令由 climc 资源命令注册代码 提供同一个资源命令组还注册了register-aiproxy、unregister-aiproxy、restart、syncstatus等 Perform 动作。此外AutoRegisterAiproxy也可在创建后通过 update 输入auto_register_aiproxy字段修改见 LLMDeploymentUpdateInput。同步任务内部做了什么理解自动关联的关键在于ReconcileDeploymentAiproxy的调和逻辑其源码位于 llm_aiproxy_sync.go状态置位先调用SetAiproxySyncStatus将aiproxy_sync_status置为syncing仅状态变化时落库并写 ops logaiproxy_sync事件枚举 running 副本listRunningDeploymentLlms按llm_deployment_id statusrunning查询 SLLM 实例若一个都没有则清空 bindings 并回落到pending状态waiting for running replicas逐副本 upsert catalogbuildRoutingModelItems对每个副本调用SyncLlmInstance内部依次执行mapLLMTypeToProviderKey将 SKU 的llm_type映射为 aiproxy 的provider_keyvllm/ollama/sglang其他类型报不支持resolveLlmAccessBaseURL通过GetLLMAccessUrlInfo取推理实例的内网访问地址优先InternalUrl回退LoginUrlcollectUpstreamModelKeys收集该副本实际 serve 的模型 key见下文upstream model keyupsertAiProvider按llm_id过滤做存在即更新、不存在即创建的幂等操作同时写入llm_deployment_id、llm_id、config.base_urlensureAiKeyForProvider保证该 provider 下存在一条 enabled 的ai_key——若无用户自建 key则创建占位 keysecret固定为常量aiproxyPlaceholderAPIKey unused见 llm_aiproxy_sync.go 顶部注释本地 vLLM/Ollama/SGLang 一般不校验真实密钥而上游转发 resolve 需要一条 secret 非空的 enabled keyupsertAiModel按ai_provider_id model_key幂等创建/更新每个 catalog model最终按副本顺序生成ai_routing_model条目priority 从 10 起步、每副本递增 10写入路由ensureAiRouting创建或更新 deployment 级ai_routing初始priority100model_pattern置空再经applyRoutingModels对 routing 执行set-models动作批量挂载各副本的 provider/model 条目持久化与状态收敛persistDeploymentAiproxyBindings把aiproxy_routing_id与aiproxy_bindings写回 deployment 行并按各副本绑定结果计算整体同步状态全部成功为synced部分失败为partial附各副本last_error明细可由AiproxySyncFailureReason汇总全部失败为failed。值得注意的幂等设计若 deployment 尚未记录aiproxy_routing_id同步时会按llm-dep-{slug(name)}名称查找已有ai_routing并转为更新路径findAiRoutingIdByNameUpdate避免同名 deployment 重建或并发同步时触发 409 重名错误。手动重同步 / 取消注册climc llm-deployment-register-aiproxy my-qwen climc llm-deployment-unregister-aiproxy my-qwen两条命令分别对应LLMAiproxySyncTask的unregisterfalse与unregistertrue分支register-aiproxy走整体ReconcileDeploymentAiproxy会重新调和所有 running 副本的 provider/model 资源并对已注册资源同步更新命名命名规则见下文适合部署改名、副本变更后刷新网关侧资源unregister-aiproxy调用UnregisterDeploymentAiproxy先删除 aiproxy 侧全部关联资源routing、按llm_deployment_id/llm_id找到的 provider 及其级联 model/key再执行clearDeploymentAiproxyRegistrationState——将auto_register_aiproxy置为 false、清空aiproxy_routing_id与aiproxy_bindings、aiproxy_sync_status置为disabled。此后 deployment 的status保持副本健康态ready/partial/deploying等不再被网关同步结果覆盖。从源码结构看副本停止、重启这类离开 running 态的操作并不会删除网关 catalogshouldUnsyncAiproxyOnLeaveRunning恒返回 falserouting ID 保持稳定catalog 只在删除 deployment 或手动 unregister 时才被清理。aiproxy_sync_status 状态机网关同步进度通过独立字段aiproxy_sync_status表达与副本健康态解耦取值定义在 llm_deployment.go 的AIPROXY_SYNC_STATUS_*常量组中状态含义disabled自动关联已关闭默认值即空串时按 disabled 处理pending已开启但尚无 running 副本 / 等待首次同步syncing同步任务执行中synced所有 running 副本均已注册成功partial部分副本注册成功其余失败可查 bindings 中的last_errorfailed同步整体失败每个副本粒度还有aiproxy_bindings[].sync_statuspending/synced/failedAiproxyInstanceBinding结构定义见包含llm_id、client_model_alias、ai_provider_id、ai_provider_name、base_url、sync_status、last_error七个字段是排查单副本注册问题的直接入口。查看对应关系deployment 详情中的aiproxy_bindings列出每个副本的客户端 model 别名与 provider idclimc llm-deployment-show my-qwenshow输出对应的 LLMDeploymentDetails 结构中包含auto_register_aiproxy、aiproxy_routing_id、aiproxy_sync_status等字段。aiproxy 侧也可按来源 id 反查 providerclimc ai-provider-list --llm-deployment-id deployment_id climc ai-provider-list --llm-id llm_iddeployment 与 routing 的关联保存在llm_deployment.aiproxy_routing_id这是双向追溯的核心外键。字段对应关系llm 侧aiproxy 侧llm_deployment.aiproxy_routing_idai_routing.idllm.idai_provider.llm_idllm_deployment.idai_provider.llm_deployment_id每个同步出的 provider无用户自建 enabled key 时ai_key占位secretunused名{ai_provider.name}-keyupstream served model namevLLM/SGLang 为 model 目录 basenameOllama 为name:tagai_model.model_key{deployment_name}-{upstream_model_key}ai_routing.model_key与aiproxy_bindings[].client_model_alias同值客户端 model 精确匹配选路与列表优先{ai_routing.model_key}/{upstream_model_key}层级 model idrouting 有model_key且挂多个 catalog model 时推荐GET /v1/models与请求解析均支持手工通配/前缀规则ai_routing.model_patternLLM 自动注册时留空ai_routing_model.model_pattern几点由源码印证的关键细节upstream model key 的推导upstreamModelKeyForBackend对 vLLM/SGLang 取挂载模型全名最后一段即--served-model-name使用的目录 basenameOllama 则为name:tag形式与后端实际 serve 的模型 id 保持一致别名生成deploymentClientModelAlias返回{deployment_name}-{model_key}副本/部署名为空时回退为 iddeploymentRoutingModelKey与其同值即ai_routing.model_key与client_model_alias永远一致关联不存冗余外键ai_routing/ai_routing_model不保存llm_deployment_id/llm_id而是通过ai_provider持有llm_deployment_id/llm_id与ai_routing_model.ai_provider_id间接关联推理实例因此清理逻辑只需按 provider 维度级联即可。客户端访问接入网关需先创建项目级ai_virtual_key网关入口鉴权不是上游 provider secret再通过 aiproxy 的 OpenAI 兼容接口访问。LLM 自动注册会为每个同步出的ai_provider确保一条占位ai_keysecretunused本地 vLLM/Ollama/SGLang 一般不校验真实密钥上游转发依赖该ai_key与客户端 Bearer 携带的 virtual key 是两套独立的密钥。请求解析链路在 chat_completions.go 中概括为ai_virtual_key → project ai_routing → ai_routing_model → ai_key (by catalog model_key)。使用扁平 model idcurl -k $AIPROXY/openai/v1/chat/completions \ -H Authorization: Bearer $VK \ -d {model:deployment_name-upstream_model_key,messages:[{role:user,content:hi}]}model填 deployment 详情里aiproxy_bindings[].client_model_alias格式{deployment_name}-{upstream_model_key}同一 deployment 下各副本相同与ai_routing.model_key同值。LLM 自动注册/重同步会写入model_key并清空model_pattern。使用层级 model id当同一ai_routing下挂多个 catalog model 时可用斜杠分隔的层级形式精确定位到某条 modelcurl -k $AIPROXY/openai/v1/chat/completions \ -H Authorization: Bearer $VK \ -d {model:ai_routing.model_key/upstream_model_key,messages:[{role:user,content:hi}]}多副本选路规则仅发扁平ai_routing.model_key无/时若 routing 下有多条ai_routing_model默认选用priority 最低最高优先级的条目。从同步源码看副本按顺序写入时 priority 依次为 10、20、30……buildRoutingModelItems中priority : 10; ...; priority 10因此编号靠前的副本天然获得更高优先级。删除 deployment 与资源清理删除llm_deployment时会自动清理关联的 aiproxy 资源ai_provider、ai_model、ai_routingprovider 按llm_deployment_id/llm_id查找routing 按llm_deployment.aiproxy_routing_id删除无需auto_register_aiproxy为 true。对应实现为 DeleteDeploymentAiproxyResources先按dep.AiproxyRoutingId删除 routing再按llm_deployment_id过滤列出全部 provider 逐一删除同时遍历该 deployment 下的每个 SLLM 实例按llm_id兜底清理可能遗留的 provider单条资源删除失败仅记 warning 不阻断整体流程保证清理操作的健壮性。命名规则自动注册时 aiproxy catalog 资源名称基于推理部署名与副本实例名{deployment_name}-{index}不再使用 UUID 后缀aiproxy 资源命名规则示例部署my-qwen副本my-qwen-0ai_routing.namellm-dep-{slug(deployment.name)}llm-dep-my-qwenai_provider.namellm-{slug(llm.name)}llm-my-qwen-0ai_key.name{ai_provider.name}-keyllm-my-qwen-0-keyai_model.namellm-{slug(llm.name)}-{slug(model_key)}llm-my-qwen-0-qwen3-0-6bslug(...)将名称规范为小写并将/、.等特殊字符转为-。部署名或副本名为空时回退为对应 id。实现上上述规则分别对应 llm_aiproxy_sync.go 中的aiRoutingNameForDeploymentllm-dep-前缀、aiProviderNameForLlmllm-前缀、aiKeyNameForProvider-key后缀、aiModelNameForLlmprovider 名 slug 化 model key四个函数底层的slugAiproxyName仅保留[a-z0-9]字符将-、_、.、/、:折叠为单个-并修剪首尾连字符与文档描述完全一致。对已注册资源执行climc llm-deployment-register-aiproxy会同步更新上述名称即重命名 deployment/副本后重同步即可让网关侧资源名跟随更新。小结CloudPods 的 LLM 部署与 aiproxy 网关自动关联机制本质是一个以llm_deployment为源、以LLMAiproxySyncTask为驱动的最终一致性调和流程aiproxy_sync_status独立表达网关侧进度aiproxy_bindings记录逐副本绑定结果幂等 upsert 名称回查保证了重建与并发场景下不产生重复资源而{deployment_name}-{upstream_model_key}这一稳定别名让客户端可以用同一个 OpenAI 兼容model字段无缝访问任意副本。实际运维中建议以llm-deployment-show输出的aiproxy_sync_status与aiproxy_bindings[].sync_status为第一观察面遇到partial/failed时结合last_error与 aiproxy 侧 provider/model 资源状态定位问题。赞分享后端云原生运维虚拟化人工智能AI 应用【免费下载链接】cloudpods开源、云原生的多云管理及混合云融合平台项目地址https://gitcode.com/yunionio/cloudpods点击查看免费下载相关推荐在 Laradock 中部署 LiteLLM一个 OpenAI 兼容的 LLM 网关统一路由多 Provider在 Laradock 中部署 LiteLLM一个 OpenAI 兼容的 LLM 网关统一路由多 Provider 导读 本文讲解如何在 Laradock 中后端开发工具DevOpsAIBrix 快速上手在 Kubernetes 集群中部署并调用 LLM 推理网关AIBrix 快速上手在 Kubernetes 集群中部署并调用 LLM 推理网关 本指南完整复现 AIBrix 的 Quickstart 流程从在 Kub人工智能大模型云原生模型推理服务LLM 网关API网关弹性伸缩litellm Docker部署容器化LLM网关解决方案litellm Docker部署容器化LLM网关解决方案 在AI开发中你是否正面临多模型API集成繁琐、环境配置复杂、部署流程重复的问题本文将详细介绍如何后端API网关LLM 网关大模型人工智能创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
