#部署容量规划

本页用于估算部署 Alauda AI 基础功能所需的组件资源，以及 MaaS 长流式 SSE 场景所需的额外资源。

#1. Alauda AI 平台资源

下列资源覆盖 Alauda AI 基础功能和固定平台组件，不包含 ACP 和 Kubernetes 资源。不同的 ACP 和 Kubernetes 版本、集群规模以及启用特性具有不同的基线资源需求，因此请在 Alauda AI 资源之外单独规划这些部分。

Alauda AI 平台资源还不包括以下工作负载：

• 训练、微调和评估任务；
• 模型推理服务和推理副本；
• Notebook、Workspace、PipelineRun 和 Agent 实例；
• 模型权重、训练数据、镜像、日志和备份的存储。

训练任务、推理服务及其他 AI 工作负载需要根据任务类型、模型大小、并发数和性能目标额外分配资源，例如 GPU/NPU 卡、CPU、内存、节点和业务存储。

#1.1 资源建议

下表仅展示 Alauda AI 组件的参考值，而不是物理服务器的最终数量或规格。在准备服务器时，请在这些数值之上叠加 ACP、Kubernetes、操作系统、容器运行时、存储、监控和日志以及其他平台特性所需的资源。

高可用形态包含 Alauda AI 基础平台组件以及训练、微调和 Agent 控制平面，并在组件资源之上额外预留约 50% 的余量，用于应对节点故障后的重新调度、滚动升级、监控和日志波动以及业务增长。建议 Alauda AI 部署在 3 台服务器上，每台为 Alauda AI 预留约 16 核 CPU / 24 GiB 内存；ACP 和 Kubernetes 基线资源需根据实际环境在此基础上额外增加。

Demo / 试用形态采用单副本部署形态，包含 Alauda AI 基础平台组件以及训练、微调和 Agent 控制平面，并预留演示数据和演示工作负载空间；不具备高可用性。如果 Demo 或高可用部署同时运行真实训练任务、推理服务、MaaS 并发、用户 Notebook/Workspace/PipelineRun、Agent 实例或大规模业务数据，请根据实际工作负载额外增加资源。

以上数值仅代表 Alauda AI 组件资源，不包含 ACP 和 Kubernetes 的基线资源。

#1.2 存储规划

Alauda AI 平台资源不包括业务数据存储容量。请根据数据量、增长速率、保留周期、IOPS、吞吐量和恢复目标，单独规划模型权重、训练数据、模型镜像、Workspace/PVC、Pipeline 制品、日志和备份。

#2. MaaS SSE 容量参考

压测数据有助于确定各并发级别下 MaaS 组件的合理资源配置。它是在基础平台资源之外对 MaaS 容量进行定容的参考。数据来源于长流式 SSE 测试：每个流返回 200 个内容块，间隔约 100 ms，每次测试持续 600 秒，并使用关闭连接模式。测试使用集群内的 mock-llm 作为后端替代真实模型服务，以减少模型响应内容和持续时间的不确定性对结果的影响。

#2.1 未启用 Guardrail

下表展示了各并发级别的压测结果；每次测试都在 600 秒内完成了全部请求，且无中断或错误。延迟单位为毫秒。TTFT 表示首个 token 时间，流持续时间表示单个 SSE 流从开始到结束的时长；两者均以 avg / p95 形式给出。

#2.2 启用 Guardrail

Gateway、Authorino 和 Ratelimit 采用与未启用 Guardrail 的测试相同的配置：

• Gateway：2 个副本；每个 1 CPU / 512 MiB
• Authorino：2 个副本；每个 0.5 CPU / 256 MiB
• Ratelimit：2 个副本；每个 0.25 CPU / 256 MiB

Guardrail 测试额外引入了 NeMo engine 和 Guardrail ext_proc shim。每次测试都在 600 秒内完成了全部请求，且无中断或错误。延迟单位为毫秒；TTFT 和流持续时间均以 avg / p95 形式给出。

#2.3 解读压测数据

CPU 是一种弹性资源。单个 CPU 的实际处理能力在不同 CPU 型号、微架构、主频、NUMA 拓扑、虚拟化模式和运行环境之间可能存在显著差异。因此：

• 压测数据仅作为容量规划参考，不作为通用配置承诺；
• 不同 CPU 型号上的 1 CPU 并不一定带来相同的吞吐量和延迟；
• 请根据目标 CPU 型号、模型大小、请求长度、输出速度、连接模式、Guardrail 策略和目标并发数调整 CPU 配置；
• 在 ARM64、Kunpeng 或其他目标硬件上，请在目标硬件上运行业务压测；
• 当测试结果与本页面不一致时，以实际业务测试结果为准。

MaaS 压测不包含真实模型推理服务、模型权重或 GPU/NPU 资源。在部署真实推理服务时，请根据模型大小、量化方式、上下文长度、并发数和目标延迟，增加 GPU/NPU、CPU、内存和存储资源。

#2.4 MaaS 扩缩容参考

关于各 MaaS 组件的扩缩容方式和资源配置入口，请参见 MaaS 组件扩缩容。

在扩缩容层面：

• Gateway：CPU 密集型组件。较高的 CPU 利用率属于正常现象；请配置告警以避免误报，并在利用率过高时增加副本数以保持性能；
• Authorino：对鉴权延迟较为敏感。即使 CPU 尚未饱和，请求也可能排队并超时，返回 403；此时应通过增加副本数进行横向扩展；
• NeMo engine：采用 Python 实现，因此单个实例无法高效利用多个 CPU 核；应通过增加副本数进行横向扩展。