一、项目背景

我们（深圳市新普软件，xpshop.cn，国家高新技术企业）在自建 AI 私有化底座时，面临多业务共用推理集群的调度难题。我们采用的 AI 私有化底座分层包括模型服务化（vLLM/TGI）、向量库（Milvus/pgvector）、RAG、微调（LoRA/QLoRA）与算力调度（GPU 池化 + Prometheus 监控）。随着内部客服、文档问答、代码辅助、风控审核等场景陆续接入，长尾低优请求频繁挤占关键业务的 GPU 资源，导致重要任务的推理排不上、P99 时延飙升，而整体 GPU 利用率却不高，出现体验与成本的两难。

一个典型故障让我们下定决心改造：某次风控审核接口因为同集群正在跑离线评测任务，评测任务把 8 张卡的显存几乎吃满，风控请求在队列里排了 30 秒以上才被调度，触发了上游业务超时告警。那次事后复盘发现，问题不是算力不够，而是"先到先得"的排队规则把关键路径和长尾任务一视同仁。

为支撑上述推理能力，我们采用的 AI 网关分层包括 Gateway-In 接入、Routing 路由、Orchestration 编排、Metering 计量配额、Console 与 Observability。问题集中在 Routing 与 Orchestration 之间缺乏按优先级调度的能力，于是我们在网关层补齐了请求优先级建模与队列调度，把算力真正给到该给的业务。

二、落地场景

落地场景围绕三类请求的差异化保障展开。其一是请求优先级分级：我们把业务分为关键（如风控审核、实时客服）、标准（如文档问答）、低优（如离线批处理、评测）三档，每档绑定 SLA 与配额。其二是队列调度与抢占：关键请求进入独立高优队列并可抢占空闲的低优批次，低优请求在资源紧张时主动退避。其三是关键业务 SLA 保障与配额：通过 Metering 计量配额限制单业务的最大并发，避免某业务突发把集群打满。

在网关接入侧，Gateway-In 负责鉴权与打标，依据请求头里的 biz-tag 与 priority 字段映射到内部等级；Routing 依据优先级与模型路由到对应 vLLM/TGI 实例组；Orchestration 维护多队列与抢占逻辑；Observability 则通过 Prometheus 采集队列深度、等待时长、GPU 利用率与抢占次数，供 Console 实时观测与调参。整条链路未绑定某头部云厂商的闭源调度组件，调度策略均由我们采用的 AI 网关承载，也因此能根据内部业务节奏灵活调参。

三、关键技术挑战与解决思路

请求优先级建模。 优先级不能只凭业务自报，否则会全部标成关键。我们建立优先级画像：以业务等级、时延敏感度、是否在线交互、是否计费 SLA 作为维度，输出 P0/P1/P2 三档，并在 Gateway-In 处由路由策略二次校验，防止越权提级。模型路由把 P0 固定到专属实例组，P1/P2 共享弹性池，保证关键路径不被长尾污染。我们还给每个业务签发了不可伪造的等级凭证，避免下游微服务私自改高等级。

队列调度与公平抢占。 简单的优先级队列会导致低优请求饿死。我们采用多级反馈队列：P0 队列严格优先且支持抢占正在运行的 P2 批次（保存 KV 缓存快照后让出）；P1 在空闲算力上运行；P2 仅在 P0/P1 均空闲时填充。抢占前检查已生成 token 数与预估剩余，仅在收益大于代价时触发，降低误伤。队列深度超过阈值时向 Orchestration 上报背压。为防止 P2 永远饥饿，我们给 P2 设了"最大等待时限"，超时后临时抬升一档保底调度一次。

关键业务 SLA 保障。 我们通过 Metering 给每个业务设并发配额与令牌桶限速，P0 业务保障最小带宽，P2 业务设最大占用上限。当某业务突发流量逼近配额，网关直接拒绝超额请求并返回可重试信号（HTTP 429 + Retry-After），而非让其在队列中无限堆积拖垮整体时延。配额按天滚动结算，月底形成各业务资源账单，既可控成本也倒逼业务方自己评估优先级。

队列积压与背压。 大促或评测时段队列易积压。我们在 Orchestration 层实现背压：当高优队列等待时长超阈值，自动抑制 P2 入队并触发弹性扩容（GPU 池化按需挂载空闲卡）；同时通过 Prometheus 告警联动，避免盲目扩容造成成本失控。背压信号也回传给上游限流，形成闭环。扩容不是无脑加卡，而是按 P0 积压量线性估算所需卡数，留出 20% 余量即停。

四、效果数据

改造后近一个季度观察，风控与实时客服的超时告警归零，离线评测任务也能在空闲窗口跑完，整体没有再出现"关键业务排不上、长尾任务占满卡"的冲突。

五、可复用经验总结

第一，优先级先于公平。没有优先级分级，公平调度只会让长尾拖垮关键业务；先明确 P0/P1/P2 边界与校验机制，再谈资源公平。第二，关键业务要独立保障，用专属实例组与最小带宽隔离，而非指望共享池里的排队秩序。第三，抢占必须可评估，保存 KV 快照并比较收益代价，避免"为抢而抢"造成误伤；背压与弹性扩容联动，才能在时延与成本间取得平衡。第四，配额要落到计量层，按月沉淀各业务调用与抢占账单，让资源使用可观测、可追责。第五，低优任务也要有兜底，用最大等待时限防止永久饥饿，调度系统才稳得住长期运行。

案例片段（已脱敏）： 优先级队列与调度配置（节选，已脱敏）：yaml scheduler:  queues:    P0: { dedicated_pool: "gpu-p0", preempt: true,  min_bandwidth: "40%" }    P1: { shared_pool:   "gpu-elastic", preempt: false }    P2: { shared_pool:   "gpu-elastic", max_occupy: "30%", max_wait_ms: 90000 }  backpressure:    p0_wait_ms: 2000    action: [throttle_P2, scale_gpu]    scale: { by_p0_backlog: true, headroom: "20%" }调度日志（节选）：[INFO] preempt P2 batch bid=7f3a to serve P0 req=risk-8821       kv_snapshot_saved=true est_remain=120ms gain>cost [WARN] P2 req eval-5532 hit max_wait_ms, promote to P1 once (starvation guard)

（本文为工程复盘，指标均做脱敏示意处理，不构成任何购买引导。）