2000 人研发团队月省 20 万算力费：深信服 AI 算力网关与 vGPU 生产级调度实录
核心亮点
- 智能路由引擎让 2000 人研发团队月调用外部模型费用从 40 万降至 20 万（成本减半）
- vGPU 1%/256MB 级精细切分，单卡模型承载量翻 8 倍+，资源利用率提升 3 倍+
- 云上云下弹性调度，故障中断从 1 小时降到 10 分钟以内
- Volcano + HAMi 四大调度控制面优化，覆盖 gang/LWS 全场景
「不卷算力卷效率 | HAMi 社区 Meetup」深圳站由 HAMi 社区发起，密瓜智能主办，2026 年 4 月 25 日在深圳圆满结束。本文为 HAMi 社区 Meetup 深圳站回顾系列第六篇。深信服云 AI 总架构师贾毫杰分享了企业级 AI 算力治理的完整实践——从 Agent 时代的算力挑战出发，深入解析 AI 算力网关的智能路由与安全护栏，再到基于 Volcano + HAMi 的 vGPU 生产级调度方案。
演讲嘉宾： 贾毫杰（深信服云 AI 总架构师）
视频回放及 PPT 下载
Agent 时代的算力风暴：四个核心挑战
Agent 应用发展迅猛，AI 算力消耗呈指数级增长。IDC 预测 2030 年 token 消耗将比 2025 年增长 600 倍以上。企业必须在成本、安全、可靠性和管控四个维度上找到系统性解法。
算力消耗爆发
Agent 应用正在重塑 AI 算力需求格局。OpenClaw 全球爆火，3 个月内 GitHub Star 数成为历史第一；Kimi 在 2026 年头 20 天的订阅收入就超过了 2025 年全年。开放式 AI-Agent 应用在后台自动「思考」和「执行」，带来不可控的突发流量，让算力消耗呈指数级增长。
成本失控
效果好了，成本却指数级飙升。AI Coding、数字员工等明星 AI 场景，普遍使用最好效果的模型——要么 Token 调用费用极高（1 万/人/月起步），要么本地显卡成本极高（X 万/人起步）。各部门都说 GPU/Tokens 不够用，但是否真的用在了价值 AI 场景，管理层看不清晰。
安全风险高
应用「裸奔」现象普遍：隐私数据无管控，权限管理松懈，企业核心数据资产面临被盗窃的风险。Agent 明文传输导致数据泄密，使用公共 MaaS 服务时客户数据可能被用来训练模型进而导致数据泄露。
算力供给可靠性差
单算力供应商和模型服务，单点故障风险高；多算力供应商性能不一致且存在波动，业务不稳定；专属算力难以支撑突发业务流量，影响业务稳定和用户体验。
AI 算力网关：企业自己的「算力调度与优化中心」
深信服 AI 算力网关定位为企业统一的 AI 模型接入层，向上对接各类 Agent 应用，向下聚合多元化算力与模型服务，实现全模型服务接入统一、全局算力用量可视、智能路由成本优化三大目标。
五层架构总览
AI 算力网关采用分层架构设计：
| 层级 | 核心能力 | 说明 |
|---|---|---|
| 应用层 | 开放/垂直 Agent、生产级业务 Agent | 销售 Agent、AI Coding、数字员工、智能客服等 |
| 网关层 | 统一接入、智能路由、自适应优化、安全护栏 | AI 算力网关核心，提供全方位治理能力 |
| MaaS 层 | 多元化模型服务聚合 | 统一管理各类模型服务的接入与分发 |
| 云端服务 | 公有云 Token（按调用量计费） | OpenAI、Anthropic、Kimi、DeepSeek、Qwen、GLM 等 |
| 本地算力 | GPU 服务器 + 托管云专属算力 | 自建算力中心、运营商算力中心、裸金属租赁 |
全局可视与精准管控
网关实现全局模型服务统一分发和管理，全局用量按部门、按路由、按模型、API-Key 可视。监控维度覆盖：调用供应商、输入输出 Token 和内容、费用、API 类型、吞吐、首 Token 时延、端到端时延等指标全面可视。
基于请求频率、输入输出 Token、并发连接数、访问限制进行精准限流和限额，基于 API Key 将权限精细化到组织和部门，让每个部门的算力得到精准控制。
智能路由引擎：让每一分算力花在刀刃上
实战成果： 使用智能路由引擎对接 Claude Code，2000 人研发团队月调用外部模型费用从 40 万降至 20 万，成本下降 50%，同时服务质量不降。
核心问题
以 Claude Code 为例——所有问题都使用 Claude 4.6 Opus 顶尖模型，成本非常高。实际上用户请求中存在大量简单问题（如「帮我写一篇护网通知」），完全可以用低成本模型处理，只有复杂问题（如「帮我重构这个代码模块，提升性能」）才真正需要顶级模型。
智能路由引擎原理
智能路由引擎通过多维度特征分析进行决策分流：
| 特征维度 | 说明 |
|---|---|
| 语义与表示特征 | 分析请求的语义复杂度和表达意图 |
| 句法与结构特征 | 评估代码逻辑、推理链条的结构复杂度 |
| 文本与统计特征 | 基于文本长度、关键词等统计信息辅助判断 |
决策因子综合以上三类特征输出「复杂」或「简单」标签，路由到对应模型。该引擎支持可配置的语义路由与普通路由聚合，可按业务需求灵活配置——不是所有请求都需要经过语义分析。
路由效果
| 指标 | 优化前 | 优化后 |
|---|---|---|
| 月模型调用费用 | ¥40 万 | ¥20 万 |
| 模型选择 | 全部使用 Claude Opus | 复杂→Claude Opus，简单→GLM 等 |
| 服务质量 | 高 | 高（降本不降智） |
| 路由准确率 | — | 高，可解释性强 |
简单问题占比通常在 60%-80%，这意味着大部分请求可以用低成本模型处理，从而实现显著的成本优化。
安全护栏：以 AI 保护 AI
深信服提出「以 AI 保护 AI」的安全策略，构建了包含大模型安全护栏（前护栏 + 后护栏）、零信任系统和风险治理平台的三层防护体系。
前护栏（请求前）
在请求到达大模型之前进行拦截和检测：
- 敏感词过滤： 拦截包含敏感信息的请求
- Prompt Injection 防御： 检测和拦截提示注入攻击
- 合规检查： 确保请求内容符合企业安全策略
后护栏（响应后）
在大模型返回结果之后进行过滤和检测：
- 内容安全检测： 检查输出内容是否包含违法有害信息
- 敏感数据过滤： 防止模型输出泄露个人敏感信息
- 格式校验： 确保输出符合预期格式
安全架构特点
- 核心能力构建于大模型之上，采用专业垂域模型 + 大小模型组合架构
- 推理算法优化，安全检测性能强、效果好
- 内置安全护栏，一键开启，按需选择保护范围
- 调用日志与告警联动，风险研判处置基于 Agent 协助完成
模型聚合路由：算力供给高可用
为避免多来源模型单点故障，深信服实现了模型聚合路由能力，保障服务流畅稳定，云上云下模型弹性切换，提升 AI 业务健壮性。
| 策略 | 说明 |
|---|---|
| 跨资源池轮询调度 | 配置跨本地资源池、跨模型供应商的轮询调度策略，避免业务高峰单点模型服务过载故障 |
| 云上云下优先级策略 | 优先使用私有算力，达到负载阈值自动分流云端模型，缓解高峰压力 |
实战效果：
- 单点故障风险大幅降低，主模型故障时业务中断时间从 1 小时降到 10 分钟以内
- 在 3 倍峰值流量压测下，采用云上云下弹性策略，模型调用成功率维持在 95%+
本地算力治理：vGPU 精细化运营
智能融合架构（SFA）
深信服推出智能融合架构（Smart Fusion Architecture），屏蔽多卡多模型的复杂性。核心组件包括：
- 自适应硬件屏蔽层 Smart HAS： 屏蔽底层 GPU 异构差异，统一调度管理
- vGPU 切分： 支持 1%、256MB 级显存资源精细切分
- 模型仓库 + API Key 管理： 多 KEY 精细化运营，模型服务高效共享
vGPU 切分效果
| GPU 型号 | 未切分 | vGPU 切分后 | 节省 |
|---|---|---|---|
| 4090D | 3 张卡 | 1~2 张卡 | 节约 1~2 张 |
| H20 | 3 张卡 | 1~2 张卡 | 节约 1~2 张 |
| L20 | 3 张卡 | 1~2 张卡 | 节约 1~2 张 |
核心收益：
- 单卡承载模型数量翻 8 倍+
- 现有资源利用率同比提升 3 倍+
- N 部门 N 模型，模型服务高效共享，一键限流非关键业务
- 重要 Agent 体验保障，模型使用越多越省钱
自适应推理引擎
面向重载 Agent 应用落地，深信服打造了自适应推理架构 Smart Arc，包括：
- 自适应多版本推理引擎： 自动选择最优推理引擎版本
- 一键最佳实践配置： 基于业务场景自动调优
- 多项性能优化原子能力： 基于检索的投机解码优化、场景化分块调度优化、GPU 间/节点间数据传输优化、长输入性能优化、基于场景语义感知的 Cache 智能负载等
- 专属算力 ROI 提升 2~5 倍，已在金融、医疗、政务、AI Coding、销售 Agent 等多行业落地
Volcano + HAMi：vGPU 生产级调度的四大优化
vGPU 调度整体思路：工作负载请求 → Volcano 调度控制面 → HAMi vGPU 设备能力底座。Volcano 负责作业编排（batch/gang/LWS），HAMi 负责设备共享与细粒度切分。共享 GPU 进入 gang 和 LWS 场景后，控制面需要同时兼顾设备侧管理和作业侧调度。
社区共建
深信服的实践不只是单个厂商的算力平台优化案例，也反映了开源 vGPU 调度能力在生产环境中的演进方向：把设备共享、细粒度资源隔离、异构设备适配和 Kubernetes 调度语义结合起来，形成可复用的基础设施能力。
| 社区关注点 | HAMi 提供的基础能力 | 企业实践中的验证价值 |
|---|---|---|
| 开放标准化 | 以 Kubernetes 原生资源声明和调度扩展承载 vGPU 语义 | 避免能力只绑定在单一平台实现中，降低迁移和集成成本 |
| 异构设备支持 | 围绕 NVIDIA、昇腾、寒武纪、海光、沐曦等多类设备持续扩展 | 让企业能在多厂商、多代际算力并存时保持统一调度入口 |
| 生产级可运维性 | 通过设备状态维护、资源配额、监控指标和调度生命周期协同提升稳定性 | 把"能切分 GPU"推进到"能长期稳定运营共享 GPU 池" |
深信服的案例是 HAMi 社区能力在企业级 AI 基础设施中的落地样本：企业侧贡献了复杂场景和工程反馈，社区侧沉淀通用能力、接口语义和可复用实现，两者共同推动 vGPU 调度从功能可用走向生产可用。
平台选型：作业级调度能力是共享 GPU 落地的上层约束
| 场景 | 调度单位 | 调度重点 | 关键语义 |
|---|---|---|---|
| Single Pod | 单个 Pod | 一张卡如何切分 | — |
| Gang jobs | 一组任务 | 成员同时就绪 | PodGroup / queue / topology |
| LWS | leader / worker 组 | 跨节点推理调度与生命周期 | group start / place / lifecycle |
设备状态维护：从一次性快照升级为持续维护
问题： 旧模式中节点一次性上报设备状态，调度器被动读取，过期 handshake、异常设备和残留 metrics 继续留在系统里。控制面只在读取时刻看到状态，之后缺少持续维护动作。
方案： 维护链路将设备状态接入周期检查与结果收敛，包括：
- 握手超时处理： 握手超时进入过期处理
- 健康检查过滤： 故障卡从可调度视图中剔除
- 监控数据清理： 清理与节点状态不一致的指标残留
入口准入与资源治理：统一共享 GPU 资源语义
问题： 资源声明字段不完整时仍进入调度链路，配额与调度使用的资源口径不一致。
方案： 在入口 webhook 层完成资源字段补齐、派生总量和一致性校验：
- 系统自动补齐缺失字段（如 vgpu-number 默认为 1），生成对应派生总量（vgpu-total-memory、vgpu-total-cores），用于适配配额计算
- 配额治理与调度判断共享统一资源口径，不完整资源声明直接拒绝
- 资源声明时可通过 UUID 预选设备绑定指定 GPU
调度事务收敛：隔离预分配计算与生命周期同步
问题： 旧模式中调度试算和真实占用共用同一份状态，预分配计算阶段与运行阶段相互影响。
方案： 调度试算和真实占用分层组织：
- 隔离预分配计算： 基于基线状态创建快照，在快照上完成节点选择和资源分配计算，不污染真实状态
- 生命周期同步： 分配、绑定、释放等阶段发生的资源变化持续同步回基线状态，两者逐步收敛回统一资源视图
整组任务放置：联合判断拓扑与 vGPU 可分配性
问题： 常规资源满足条件，不代表整组任务在当前设备布局下可以成功分配。例如某节点 CPU/内存充足，但受限于 GPU 的独立性，整组任务无法完整放入。
方案： 判断单位从单个 Pod 转为整组任务，task-multi-dimen 多维度判断与 vGPU 可分配性联合筛选节点，在同一轮调度决策中完成计算。
现场问答精选
Q1：智能路由的语义判断是否全局生效？
该功能是可配置的，支持语义路由和普通路由聚合。不是所有请求都需要经过语义分析，可根据业务需求灵活配置。
Q2：智能路由会引入多少延迟？
目标延迟要求是 50ms 以内，目前仍在优化中。延迟主要来自语义分析环节，底层技术方案（小模型分类或规则引擎）的选择会影响延迟表现。
Q3：推理场景是否需要拓扑感知？
目前尚未针对 LWS（Leader-Worker）跨机部署做专门的拓扑感知优化。训练场景对此需求强烈，但推理场景因模型和设备量级相对较小，该需求的优先级不高，目前仅做了预演但未落地。
总结：AI 算力治理的两大维度
深信服的实践可以从三个层面理解：向上治理，通过智能路由和安全护栏让大模型用得安全、用得省；向下优化，通过 Volcano + HAMi 的生产级调度让 GPU 用得满、用得稳；向外沉淀，通过 HAMi 社区把企业场景中的设备共享、资源隔离和调度协同经验转化为更通用的开源能力。
| 维度 | 核心能力 | 关键成果 |
|---|---|---|
| 向上治理 | 智能路由 + 安全护栏 + 模型聚合 | 成本减半、故障恢复从 1h 到 10min、AI 安全闭环 |
| 向下优化 | Volcano + HAMi + vGPU 切分 | 单卡承载 8x、资源利用率 3x、共享 GPU 池生产级调度 |
| 开源社区视角 | HAMi 社区的设备共享、异构设备适配、资源隔离与调度扩展 | 把企业实践中的复杂场景反馈沉淀为可复用、可协作演进的开源基础设施能力 |
对于正在面临 AI 算力成本失控、安全隐患和调度效率问题的企业，这类实践提供了一个从网关治理到硬件调度的全栈参考；对于 HAMi 社区，它也提供了来自真实生产场景的反馈：共享 GPU 不应只停留在单卡切分，而要继续围绕异构设备、作业级调度、配额治理、可观测性和生命周期一致性演进。核心思路值得借鉴：企业把复杂场景带给社区，社区把通用能力沉淀回生态，最终让每一分算力花在刀刃上，也让每一块 GPU 跑满价值。