AGIOne 多算力池异构推理调度最佳实践
适用场景: AGIOne 统一协调多个异构计算池,共同承载在线推理、批处理和弹性溢出任务
覆盖内容: 计算池接入 · 故障隔离与恢复 · 推理引擎适配 · 聚合调度 · 运营监控
AGIOne 是本文描述的平台。计算池名称、拓扑、模型名称和组织信息均使用合成参考环境,不对应任何特定客户或生产部署。
本文提供的参数值和阈值是初始调优示例,不代表 AGIOne 默认配置、实测结果、服务等级或承诺。使用前必须在目标环境完成验证和审批。
第一章 背景与架构总览
1.1 业务背景
当多个计算池分布在不同的网络区域并使用不同类型的加速设备时,AGIOne 需要为资源接入、模型部署、请求调度、故障隔离和容量调整提供统一方法。
本文使用三个合成计算池:
- 计算池 A: 通过私有网络承载低时延在线请求和较小模型。
- 计算池 B: 通过受控链路承载吞吐优先的批处理任务。
- 计算池 C: 使用裸金属或独立管理的资源承载非高峰批处理、弹性扩展和故障转移任务。
部署可从少量验证实例开始,例如 4 个实例,再逐步扩展到较大范围,例如 20-36 个实例。后端容量变化时,服务入口应保持稳定,但扩缩容仍可能影响队列、缓存和时延。每个部署都必须根据自身硬件、网络、安全边界和工作负载重新验证示例。
1.2 核心挑战
- 资源异构: 不同加速设备需要不同的驱动、运行时、设备插件、通信库和推理引擎。
- 节点分散: 算力可能分布在私有云、托管算力和裸金属环境中,网络路径和故障域不同。
- 节点重建: 部分环境在节点故障后会自动重装操作系统,因此注册、存储挂载、服务启动和流量恢复必须能够重复执行。
- 容量增长: 实例可能从少量验证规模扩展到数十个,后端变化不应要求调用方更换服务入口。
- 负载时段: 在线请求、日间批处理和非高峰全量批处理需要采用不同的资源分配方式。
- 任务耗时不均: 推理任务的输入输出长度不同时,简单轮询可能产生负载不均。
- 联动排查: 请求吞吐、队列状态、路由权重、实例负载和设备指标需要关联分析。
- 证据约束: 性能、恢复和扩缩容阈值必须来自目标环境测试,不能把示例值当作服务承诺。
1.3 总体架构
AGIOne 参考设计采用集中管理、分布执行的模式。
| 架构层 | 主要职责与参考组件 |
|---|---|
| AGIOne 管理平面 | 维护计算池、集群、模型、模板、权限和审计记录;相关模块启用后,还可以提供 API 网关、模型发布、计量和统一管理入口。 |
| 调度平面 | 部署在计算池内或邻近位置,注册资源信息,接收构建或部署任务,并根据标签、健康状态、队列和策略约束选择后端实例。 |
| 执行平面 | 运行推理实例,加载经过批准的模型权重和运行时,并提供受控的推理接口;所选引擎支持时可使用 OpenAI 兼容接口。 |
| 聚合调度层 | 将兼容的后端实例组合到同一个逻辑模型 ID 下,并根据容量、健康状态、正在运行的任务和策略约束调整流量分布。 |
| 可观测平面 | 采集请求、调度、实例、节点和设备指标,为故障定位与容量决策提供证据。 |
| 安全治理平面 | 管理身份、证书、密钥、网络策略、日志留存和变更审批。 |
AGIOne 管理平面可以通过私有网络、受控专线或经过批准的站点间路由连接计算池。参考架构只描述功能边界,不规定真实站点、云服务、设备型号或内部端点。
1.4 网络连接矩阵
| 合成计算池 | 参考连接方式 | 适用任务 | 设计要求 |
|---|---|---|---|
| 计算池 A | 同一安全区域内的私有连接 | 低时延在线推理和较小模型 | 验证端到端时延、故障域和容量上限。 |
| 计算池 B | 受控专线或等效连接 | 吞吐优先的批处理 | 验证独占带宽、数据传输策略和任务重试机制。 |
| 计算池 C | 经批准的内网或站点间路由 | 非高峰全量批处理、弹性溢出和故障转移 | 验证路由收敛、证书、降级、回切和裸金属恢复机制。 |
任何计算池都不应直接暴露管理端口或推理实例端口。网络、身份和数据流应由安全负责人按目标环境审批。
第二章 多算力池接入与管理
2.1 集群纳管策略
每个计算池可以维护独立的 Kubernetes 控制平面,并通过标准代理或任务构建 API 与 AGIOne 管理平面通信。接入前先完成以下检查:
- 确认加速设备、驱动、运行时、设备插件和操作系统版本之间的兼容关系。
- 确认管理平面与计算池之间的网络路径、域名解析、时间同步和证书信任。
- 确认节点初始化方式、镜像来源、制品校验和回滚方案。
- 确认模型权重、缓存、日志和备份的存储位置及访问权限。
- 使用无生产数据的测试任务验证注册、调度、启动、调用和删除流程。
2.1.1 计算池 A:私有网络在线服务池
- 在经过批准的私有网络中创建 Kubernetes 集群,并安装与加速器类型 A 匹配的设备插件。
- 部署调度、监控和日志采集组件。
- 向 AGIOne 管理平面注册集群 ID、加速器系列、可用设备数量和受控服务端点。
- 配置心跳。验证阶段可以从
60秒间隔开始,再根据实测发现和恢复时间调整。 - 使用小规模测试模型验证资源发现、实例启动、健康检查和在线请求路由。
- 通过验证门禁后,再逐步接入在线工作负载。
2.1.2 计算池 B:受控链路批处理服务池
- 在托管或独立管理的节点上部署 Kubernetes 基础服务,并安装与加速器类型 B 匹配的驱动和设备插件。
- 配置受控管理端点,验证带宽、重试、超时和大文件传输策略。
- 部署经过批准的设备指标采集组件,采集利用率、设备内存、温度和设备错误信息。
- 注册集群并添加通用资源标签,例如
accelerator-family=type-b和workload-class=batch。 - 配置批处理队列、任务优先级和资源上限。
- 使用合成数据验证长任务、失败重试、结果留存以及与在线工作负载的资源隔离。
2.1.3 计算池 C:裸金属弹性与故障转移池
- 安装经过批准的操作系统,并执行经过评审的节点初始化脚本,安装容器运行时、Kubernetes 节点组件和加速设备驱动。
- 确认计算池 C 使用独立故障域,避免与主计算池共享单点依赖。
- 配置到管理平面的受控内网或站点间路由,并使用只读探测验证证书状态。
- 部署调度、监控和日志采集组件,完成集群注册。
- 将持久化模型缓存和重要可恢复数据挂载到独立于系统盘的存储。
- 执行故障转移演练,并记录触发条件、回切条件、人工终止方法和回滚结果。
- 未完成演练前,不把计算池 C 标记为可用的生产后端。
2.2 集群资源标签与调度
使用稳定、可审计的标签描述资源能力。示例值必须保持通用,不得使用客户、项目、地域或内部资产名称。
| 标签键 | 合成示例值 | 用途 |
|---|---|---|
accelerator-family | type-a / type-b | 区分加速器系列。 |
memory-class | class-1 / class-2 | 描述可用设备内存等级。 |
workload-class | online / batch / overflow | 区分工作负载类型。 |
failure-domain | zone-a / zone-b | 避免副本集中在同一故障域。 |
environment | validation / production | 隔离验证和生产工作负载。 |
调度选择器示例:
accelerator-family: type-a
memory-class: class-2
workload-class: online
failure-domain: zone-a
environment: production调度策略至少应同时检查标签、剩余容量、健康状态、配额和模板约束。标签只能表达能力,不能代替运行验证。
第三章 节点故障隔离与恢复
3.1 故障触发与恢复流程
部分基础设施环境可以自动重建故障节点。AGIOne 应把该能力作为受控恢复流程中的一个步骤,不能把操作系统重建完成当作服务已经恢复的证据。
推荐使用以下状态流转:
- 监控系统发现连续异常并生成可追溯事件。
- 调度平面停止向异常实例分配新请求。
- 对仍在处理的请求执行等待、重试或失败返回策略。
- 运维系统按照已批准的方式修复或重建节点。
- 节点重新注册后执行驱动、设备、存储、网络和推理服务检查。
- 健康检查达到批准条件后,以受控方式逐步恢复流量。
- 若指标异常,立即回退到隔离状态并保留人工接管入口。
首次演练可以使用以下非约束性恢复预算:操作系统重建约 10 分钟、基础服务恢复少于 5 分钟、推理服务启动少于 15 分钟。这些数值只是测试目标;心跳间隔、失败次数、实际恢复时间和流量递增速度必须由目标环境演练确定。
3.2 基础镜像制作规范
| 镜像层 | 要求及技术内容 |
|---|---|
| 操作系统层 | 固定受支持的长期支持版本,记录安全补丁、时区、DNS 和安全加固信息。 |
| 驱动与固件层 | 固定加速设备驱动、固件和通信库版本,并记录兼容性结果。 |
| 容器运行时层 | 固定 Docker 或 containerd、Kubernetes 节点组件和设备插件版本,禁止使用未审核的浮动标签。 |
| AGIOne 组件层 | 只包含经过批准的监控代理、日志采集器和节点注册组件;凭证从批准的密钥机制读取。 |
| 推理引擎层 | 固定引擎 A 或引擎 B、Python 环境和依赖;模型权重与镜像分离,并在运行时挂载。 |
镜像发布前应生成制品清单、校验值、漏洞扫描结果和回滚说明。
3.3 重要数据存储规范
- 模型权重: 存储在受控模型仓库或独立数据卷中;完成访问控制和完整性校验后,可以使用
/data/models/<model-name>/等通用挂载路径。 - 集群配置: 将受保护的配置备份以及适用时的加密
etcd快照保存在系统盘之外;不得公开真实kubeconfig或内部对象名称。 - AGIOne 配置: 使用访问受限且加密的备份,不在客户文档中公开真实内部路径或对象名称。
- 密钥与证书: 使用批准的密钥管理机制,禁止写入镜像、脚本和示例。
- 日志与指标: 按数据分类设置留存期限、访问权限和脱敏规则。
- 恢复证据: 保存演练时间、环境、版本、结果和未解决问题。
3.4 流量摘除与恢复联动
流量控制应设计为显式状态机,而不是依赖单个探测结果。以下数值是参考参数,不是默认值:
Healthy:实例接收正常流量,每60秒上报一次心跳。Suspect:连续2次心跳失败后限制新增流量,并继续采集证据。Draining:将调度权重设置为0,停止新请求,等待在途任务结束或执行受控重试。Isolated:实例完全隔离,等待节点修复或重建。Registering:节点重建后验证集群注册、驱动、存储、网络和服务进程状态。Warming:调用受控的HTTP /health接口;连续3次成功后,以低权重接收测试流量。Healthy:满足恢复门禁后逐步增加权重并恢复正常运行。
每次状态变化都应记录触发原因、操作者、策略版本和回滚结果。
第四章 推理引擎适配与性能基线
4.1 加速器类型 A 的推理引擎
4.1.1 基础镜像构建
- 从经过批准的引擎 A 镜像或内部制品库开始,固定镜像摘要或明确版本。
- 安装与加速器类型 A 匹配的驱动接口、通信库和推理框架依赖。
- 仅在模型许可证和制品策略允许时预置分词器,避免首次启动时进行未经审核的网络下载。
- 将模型路径、服务端口、并行度、并发和上下文参数通过受控配置注入。
- 不在镜像中保存客户模型、生产数据、凭证或内部端点。
- 使用代表性测试模型验证启动、停止、健康检查、日志输出和多设备通信。
4.1.2 关键参数
| 参考参数 | 初始示例值 | 调整依据 |
|---|---|---|
max-seq-len | 目标最大上下文长度 | 不得超过模型、引擎或设备内存限制。 |
max-input-token-len | 目标最大输入长度 | 根据实际提示词长度分布验证。 |
max-iter-times | 目标最大输出长度 | 与 API 限制和终止策略保持一致。 |
world-size | 参与设备数量,例如 8 | 与进程数、设备数和通信拓扑匹配。 |
block-size | 引擎支持时使用 16 或 32 | 比较设备内存碎片和吞吐变化。 |
max-batch-size | 根据压测结果确定 | 逐步增加,并在时延或内存门禁失败前停止。 |
| 内存利用上限 | 以 0.90 作为测试起点 | 为缓存增长、监控和异常恢复保留空间。 |
4.2 加速器类型 B 的推理引擎
4.2.1 基础镜像构建
- 从支持加速器类型 B 且经过批准的引擎 B 镜像开始。
- 固定依赖版本,保存许可证、来源、补丁和漏洞扫描结果。
- 仅在加速设备、精度模式和引擎版本支持时启用优化注意力计算内核。
- 当实例跨多个设备或节点时,配置经过批准的多设备通信库。
- 将设备插件、运行时、通信库和引擎版本纳入兼容性矩阵。
- 通过相同的测试协议验证在线和批处理工作负载。
4.2.2 关键参数
| 参考参数 | 初始示例值 | 调整依据 |
|---|---|---|
dtype | bfloat16 或 float16 | 根据设备支持范围和经过批准的精度评估选择。 |
max-model-len | 目标最大上下文长度 | 不得超过模型、引擎或设备内存限制。 |
tensor-parallel-size | 双设备验证配置可从 2 开始 | 与模型规模、设备数量和互联带宽匹配。 |
gpu-memory-utilization | 0.90 | 保留足够空间,避免内存不足故障。 |
max-num-seqs | 将 256 作为压测候选值 | 长上下文或排队时延超过门禁时应降低。 |
quantization | 引擎支持时使用 awq 或 gptq | 确认模型质量、引擎兼容性和许可证条件。 |
类型 B 应使用与类型 A 相同的指标定义和证据模板。不能仅根据理论算力设置并发、吞吐或调度权重。
4.3 性能压测方法
使用经过批准的负载测试工具模拟目标请求分布。压测环境、工具版本、模型、精度、输入长度、输出长度、并发、持续时间和失败重试策略必须记录在测试报告中,同时保留原始结果文件以及完整命令或场景配置。
4.3.1 压测场景配置
| 压测场景 | Prompt Token 参考值 | 最大 Output Token 参考值 | 主要目的 |
|---|---|---|---|
| 短文本 | 少于 1k | 少于 1k | 建立单请求基线,验证流式响应和错误处理。 |
| 中等文本 | 少于 10k | 5k | 验证阶梯并发和常见业务长度请求。 |
| 长文本 | 少于 32k | 10k | 验证设备内存、队列增长和长上下文时延。 |
| 混合负载 | 使用目标分布 | 使用目标分布 | 同时运行在线和批处理请求,验证资源隔离。 |
| 故障场景 | 使用代表性请求 | 使用代表性请求 | 隔离实例或节点,验证请求重试、流量摘除和恢复。 |
| 稳定性场景 | 使用目标分布 | 使用目标分布 | 持续观察资源泄漏、队列累积和性能漂移。 |
4.3.2 关键性能指标与证据
下表提供说明性调优基线,不代表任何产品或客户环境的实测结果。
| 指标 | 含义 | 类型 A 示例 | 类型 B 示例 | 发布前证据要求 |
|---|---|---|---|---|
| TTFT | 从发送请求到收到首个 Token 的时间。 | FP16 配置下 < 2.5 s | AWQ INT4 配置下 < 1.8 s | 记录分位数、负载、模型、硬件、精度和版本。 |
| TPS | 单实例每秒生成的 Token 数。 | FP16/TP8 配置下约 180 tokens/s | INT4/TP4 配置下约 120 tokens/s | 记录输入输出长度、并行度、合批和并发。 |
| RPM | 单实例每分钟完成的请求数。 | 20-40 RPM | 30-60 RPM | 定义请求长度、超时、重试和成功标准。 |
| TPM | 单实例每分钟处理的 Token 数。 | 8,000-15,000 TPM | 6,000-12,000 TPM | 保存原始 Token 数和计算方法。 |
| 设备利用率 | 负载下的加速设备计算利用率。 | 将 > 70% 作为测试候选值 | 将 > 65% 作为测试候选值 | 记录采样周期和监控来源。 |
| TPOT | 首个 Token 后生成每个 Token 的平均时间。 | 根据目标压测得到 | 根据目标压测得到 | 记录统计方法和异常值处理。 |
| 成功率与错误率 | 成功和失败请求比例。 | 根据目标压测得到 | 根据目标压测得到 | 定义超时、重试、取消和错误类型的计算口径。 |
不同计算池的调度权重只能基于同一测试协议下的结果。在把数值作为性能目标、服务等级或默认能力发布前,必须使用目标环境证据替换全部示例值。
第五章 聚合模型与动态调度策略
5.1 聚合模型设计
在 AGIOne 中,聚合模型为多个兼容的推理实例提供统一的逻辑模型 ID 和服务入口,调用方不需要了解后端分布。设计时应确保:
- 后端实例使用兼容的模型、版本、分词器和接口协议。
- 调度策略能够识别计算池、故障域、健康状态和工作负载类型。
- 后端变更、权重调整和故障转移都有审计记录和回滚方法。
- 聚合入口不暴露内部实例地址或客户网络信息。
5.2 三类合成工作负载配置
5.2.1 低时延在线服务
| 配置项 | 参考示例及使用条件 |
|---|---|
| 后端实例 | 从 3-5 个已验证实例开始,根据实际峰值和冗余要求调整。 |
| 优先计算池 | 选择网络时延和稳定性已验证的计算池。 |
| 调度策略 | 使用加权轮询,并结合正在运行的任务数、健康状态和时延分位数。 |
| 请求超时 | 3000 s 是长请求参考示例,不是推荐默认值;应设置满足已验证请求配置的最小值。 |
| 限流 | 从经过测试的数值开始,例如 20 QPS,并验证队列和错误行为。 |
| 启用时段 | 使用实际观测到的在线服务时段,不公开客户工作时间表。 |
| 降级策略 | 无健康后端时返回明确错误或切换到批准的备用池。 |
5.2.2 吞吐优先批处理
| 配置项 | 参考示例及使用条件 |
|---|---|
| 后端实例 | 工作负载和可用容量合理时,可使用 10-30 个实例作为测试范围。 |
| 优先计算池 | 选择吞吐、存储和长任务稳定性已验证的计算池。 |
| 调度策略 | 综合加权分发、正在运行的任务数、可用容量、任务优先级和预计完成时间。 |
| 请求超时 | 长文本生成可以评估 3000 s,同时验证取消和重试行为。 |
| 并发上限 | 工作点应低于压测故障边界;没有证据时不得使用 99%。 |
| 数据要求 | 只处理经过批准的数据,并记录输入输出留存策略。 |
5.2.3 非高峰全量批处理、弹性溢出与故障转移
| 配置项 | 参考示例及使用条件 |
|---|---|
| 后端实例 | 只有在在线服务冗余不受影响时,才使用全部已验证可用实例。 |
| 启用条件 | 进入非高峰窗口、达到经过验证的容量门限或确认主计算池故障。 |
| 后端要求 | 备用池已完成模型、网络、权限、存储和性能验证。 |
| 调度策略 | 引擎支持时启用合批;故障转移从小比例流量开始,满足门禁后逐步增加。 |
| 请求超时 | 仅对已验证的长任务评估 3000 s 参考示例。 |
| 回切条件 | 主计算池恢复并通过稳定性观察,且不存在未处理告警。 |
5.3 动态分发调度机制
以下简化公式可作为动态权重的参考算法:
Weight(i) = BaseCapacity(i) × HealthScore(i) / (RunningTasks(i) + 1)
BaseCapacity:使用同一测试协议得到的标准化 TPM 或吞吐基线。HealthScore:取值范围为0.0到1.0;实例隔离时设置为0。RunningTasks:实例当前正在处理的请求数。
动态调度还可以参考以下信号:
- 同一测试协议下得到的容量基线。
- 当前健康状态和连续错误情况。
- 正在运行的任务数和队列长度。
- 时延、成功率和错误率趋势。
- 配额、故障域和数据驻留约束。
该公式只是参考,不是完整生产策略。还需要加入队列时延、配额、故障域和数据驻留约束。调度权重应设置上下限、冷却时间和变化速率,并保存每次调整的输入信号、策略版本和结果。自动策略必须提供人工暂停和回滚能力。
可以把 1 分钟作为初始评估周期,只有在检查指标新鲜度、路由振荡和恢复速度后才能缩短或延长。
第六章 横向扩缩容最佳实践
6.1 扩容操作流程
- 根据同一监控口径确认容量不足,而不是仅依据单个瞬时指标。
- 检查目标计算池的配额、设备、镜像、模型、网络、存储和许可证条件。
- 使用批准的基础镜像准备节点,并以初始调度权重
0完成注册。 - 创建推理实例并关联目标聚合模型,但暂不接收正常业务流量。
- 执行启动、模型加载、
HTTP /health和代表性测试请求检查。 - 以小比例流量开始预热;
5分钟是参考值,应根据模型加载和缓存行为调整。 - 满足批准门禁后逐步提高流量,并记录扩容前后的 RPM、TTFT、错误率、队列和资源指标。
- 若任一门禁失败,将权重恢复为
0,隔离新实例并执行回滚。
扩容可能影响队列、缓存和后端分布,不能承诺对调用方完全无影响。应提前定义可接受影响和回滚条件。
6.2 缩容操作流程
- 确认剩余容量能够覆盖目标负载和已批准的冗余要求。
- 将目标实例切换到流量摘除状态,把权重设置为
0,并停止接收新请求。 - 等待正在运行的任务数降为
0;最大等待时间可将request-timeout × 2作为参考保护值,但必须受失败策略约束。 - 验证队列和错误率正常后,从聚合后端列表摘除实例并停止推理容器。
- 如需下线节点,先确认节点上没有其他受影响的工作负载;只有在检查中断预算、本地存储和守护进程工作负载后才能使用
kubectl drain。 - 保存缩容前后指标和变更记录,并验证重新扩容路径。
第七章 运营监控与可观测性
7.1 监控指标体系
7.1.1 应用层指标
| 指标 | 用途 |
|---|---|
| RPM / RPH / RPD | 观察每分钟、每小时和每天的请求量。 |
| TPM / TPH / TPD | 观察每分钟、每小时和每天的 Token 量。 |
| TTFT 和 TPOT | 观察首 Token 响应速度和后续生成速度。 |
| P50 / P95 / P99 端到端时延 | 观察时延分布,而不是只查看平均值。 |
| 成功率与分类错误率 | 区分调用方、平台、网络和推理实例错误。 |
| 输入输出长度分布 | 解释性能变化并校准压测场景。 |
7.1.2 调度层指标
| 指标 | 用途 |
|---|---|
| 后端健康状态 | 确认实例是否满足接收流量的门禁。 |
| 正在运行的任务与队列长度 | 判断是否存在排队和负载失衡。 |
| 实例权重分布 | 判断权重是否与容量和健康状态一致。 |
| 实际路由分布 | 验证请求分发是否符合策略。 |
| 熔断与降级事件 | 记录后端、触发原因、持续时间和恢复结果。 |
| 故障转移与回切事件 | 追踪触发原因、持续时间和结果。 |
7.1.3 基础设施层指标
以下阈值是初始告警候选值,必须根据硬件规格、实测基线和运维策略替换。
| 指标 | 告警候选示例 | 用途 |
|---|---|---|
| 加速设备利用率 | 持续空闲时 < 20%;> 90% 持续 5 分钟时评估容量 | 发现资源闲置和持续压力。 |
| 加速设备内存 | > 90% | 发现内存碎片和内存不足风险。 |
| 设备温度 | > 85°C 告警;> 90°C 紧急检查 | 发现温度异常;硬件厂商限制更严格时以其为准。 |
| CPU 利用率 | > 80% | 发现预处理或运行时瓶颈。 |
| 主机内存 | > 85% | 发现主机内存压力。 |
| 网络和存储 | 根据实测带宽、时延和队列深度确定 | 发现数据链路瓶颈。 |
| 节点状态与重启 | 将 NotReady > 60 s 作为初始触发条件 | 关联基础设施事件和服务异常。 |
7.2 异常联动排查流程
- 从应用层的 RPM、成功率、时延和错误类型趋势中确认异常时间窗。
- 查看调度层的后端健康、正在运行的任务、队列长度、权重和实际路由分布。
- 将高任务数与加速设备利用率、设备内存和温度关联分析;高利用率可能表示容量瓶颈,低利用率但队列持续增长可能表示运行时阻塞、内存故障或下游依赖异常。
- 查看推理服务日志中的内存不足、超时、连接拒绝、设备和通信错误;错误分类应以所选引擎为准。
- 对比同一版本下的正常基线,区分容量、配置、模型、网络和硬件问题。
- 必要时隔离异常后端、临时调整路由,并使用无副作用请求验证恢复结果。
- 记录根因、修复、验证证据和预防措施。
7.3 运营分析与容量决策
- 吞吐趋势: 按小时、天和周观察 RPM/RPH/RPD 与 TPM/TPH/TPD,识别周期性峰值。
- 资源热力图: 按实例和时段比较加速设备利用率,发现长期负载不均或缩容候选。
- 时延分布: 调整容量前查看 P50/P95/P99 TTFT 和端到端时延。
- 容量分析: 结合压测基线、实际峰值、队列增长和冗余要求评估扩缩容需求。
- 成本分析: 在相同服务质量和测试口径下比较单请求或单 Token 成本。
- 预测分析: 规划模型可以使用未来
30天等窗口以及提前7天等告警周期;这些是可配置示例,不代表平台必然具备该功能或预测准确性承诺。
告警阈值、扩缩容阈值和预测周期应由产品、运维和测试负责人根据目标环境证据批准。
第八章 安全与合规
8.1 网络安全
- 使用经过批准的 TLS 版本、密码套件和证书管理流程保护跨区域通信;可以把
TLS 1.2作为最低兼容基线,在目标安全策略和组件支持时使用TLS 1.3。 - 管理平面与计算池组件之间使用双向 TLS 或等效的身份认证通道。
- 使用平台支持的调用方身份认证方式,例如 API Key 或 OAuth 2.0,并为不同调用方分配独立凭证和权限范围。
- 仅开放完成业务所需的端口和方向,并定期审计私有网络、防火墙和安全组规则。
- 推理实例端口不直接暴露给不受信任网络,统一通过受控的聚合模型或服务入口访问。
- 保存网络、证书、凭证权限范围和权限变更记录,并验证回滚方法。
8.2 数据安全
- 对模型、输入、输出、日志和指标进行数据分类,并执行最小权限控制。
- 对静态数据和传输数据使用经过批准的加密方式。
- 凭证、密钥、证书、客户标识或私有端点不得出现在文档、镜像、日志或测试数据中。
- 普通运维日志默认不记录 Prompt 和输出正文;确需记录时,必须明确合法目的、访问控制、脱敏、留存、删除和审计规则。
- 常规可观测性优先记录请求 ID、Token 数、时延、状态和错误分类。
- 验证遥测、更新、许可证、模型下载和远程支持等外联行为与交付说明及部署策略一致。
- 对外示例只能使用合成组织、拓扑、账号、模型标识和经批准的测试数据。
附录
附录 A 核心术语表
| 术语 | 定义 |
|---|---|
| AGIOne | 本文描述的平台,用于管理计算池、模型、推理服务、调度、监控和权限。 |
| 计算池 | 具有明确资源能力、网络边界和故障域的一组计算资源。 |
| 加速器类型 A / B | 用于表达技术差异但不暴露客户硬件组合的合成加速器系列。 |
| 引擎 A / B | 与两类加速器关联的合成推理引擎配置。 |
| 聚合模型 | 将多个兼容推理实例组合为统一服务入口的逻辑对象。 |
| 推理实例 | 运行模型并处理推理请求的服务进程或容器。 |
| TTFT | 从发送请求到收到首个 Token 的时间。 |
| TPOT | 首个 Token 后生成每个 Token 的平均时间。 |
| RPM / TPM | 每分钟请求数和每分钟 Token 数。 |
| 正在运行的任务 | 一个推理实例当前正在处理的请求。 |
| 在途任务 | 当前正在执行且尚未完成的请求或批处理任务。 |
| 流量摘除 | 停止向目标实例分配新请求,并处理在途任务的过程。 |