过去几年，国产化平台选型逐渐形成了一套相对成熟的评估方法。

企业通常会先核对兼容清单：服务器和处理器是否支持，操作系统、存储、网络能否适配，数据库、中间件和业务应用能否稳定运行。随后再评估高可用、迁移工具、运维能力、安全合规以及厂商服务体系。

这些指标决定平台能否承接现有业务，也是国产化建设顺利落地的基础。

AI 的加速落地，正在扩展国产化平台的能力边界。企业需要管理 GPU、NPU 等异构算力，需要同时运行算法开发、模型复现、训练微调和在线推理，还要把模型转化为能够被业务系统调用的服务。资源形态从 CPU 扩展到异构加速器，运行环境从云主机扩展到容器，交付对象也从计算实例延伸到模型与 API。

传统评估体系已经无法完整衡量一套国产化平台在 AI 时代的长期价值。

面向未来五到十年的平台选型，需要进一步回答四个问题：

这四个问题，可以作为企业评估国产化平台长期价值的关键维度。

ZStack 以 Cloud 和 Zaku 为基础承载，以 AIOS 智塔连接异构算力与模型服务，并通过 CMP 和 Zentrix 衔接基础设施运营与 AI 调用治理，形成从传统基础设施到 AI Infra、再到 AI 服务的连续技术体系。

ZStack Cloud 可以继续承载企业已有业务和通用云工作负载，AIOS 智塔则直接建立在 Cloud 与 Zaku 之上，通过云主机和容器双引擎承载 AI 工作负载：

Cloud 云主机引擎承接复杂依赖、模型复现、固定运行环境和较强隔离要求；

Zaku 容器引擎承接快速部署、弹性推理、开发测试和云原生 AI 应用。

AI 工作负载本身存在明显的运行环境差异。算法开发、模型复现和部分长期运行的推理服务，通常依赖完整操作系统、特定 CUDA 与 PyTorch 版本、复杂工具链或较强系统隔离；弹性推理、开发测试和云原生 AI 应用，则更强调镜像化交付、快速创建与按负载扩缩。

无论模型运行在 Cloud 云主机还是 Zaku 容器中，模型文件、推理模板和已发布服务都由 AIOS 统一管理。企业可以根据依赖环境、隔离强度和弹性需求选择底层承载方式，上层的服务发布与调用方式保持一致。

ZStack AIOS 将不同 GPU 纳入统一资源视图，并根据 ZStack Cloud 与 Zaku 的运行特点提供差异化交付。

AI 基础设施增加了 GPU、NPU 及其他加速器，不同品牌和型号对应不同驱动、软件栈、切分方式与适用场景。企业除了确认设备能否接入，还要决定一张 GPU 应该交付给哪个任务、采用整卡还是切分方式、显存如何回收、多个部门如何共享，以及设备状态如何持续监控。

在 Cloud 云主机侧，平台支持四类 GPU 管理方式：

dGPU 采用 CUDA API 拦截转发机制，在云主机与 NVIDIA 物理 GPU 之间实现软件层的资源控制。管理员可以根据 GPU 型号和任务需求预设多档显存规格，例如分别匹配 7B、14B、32B 模型或 Embedding 服务，无需预先把一张物理卡固化为 2、4 或 8 个等份。云主机启动时，平台从资源池中分配相应规格的 dGPU 实例；云主机停机或卸载后，已占用的显存随即释放，重新进入资源池供其他任务使用。

对云主机里的应用来说，dGPU 的使用方式与 GPU 直通基本一致。CUDA、PyTorch 和 vLLM 等现有软件可以直接运行，业务代码也不需要针对 dGPU 重新改写。一张物理 GPU 因此可以按需承接不同显存规模的算法开发、模型验证和轻量推理任务，减少固定切分形成的资源碎片，也避免低负载任务长期独占整卡。

在 Zaku 容器侧，平台同时支持整卡 GPU 和显存切分。容器显存切分粒度细至 1%，适合开发测试、Embedding、Rerank、小模型推理以及多个轻量任务共享单卡资源。

平台还可以统一查看 GPU 型号、工作状态、分配关系、利用率、显存与功耗，并对异常状态进行告警。异构设备从硬件清单进入可分配、可回收和可观测的资源体系，企业能够根据性能、隔离、授权和资源颗粒度选择合适的交付方式。

AIOS 在算力之上建立模型服务层，将模型、数据集、推理模板和计算资源组织到同一条交付链路中。

GPU 分配完成后，企业仍要准备模型文件、数据集、推理框架和依赖环境，完成参数调试、服务发布、运行监控与性能评测。各项目分别搭建环境，会使模型版本、软件栈和部署方式逐渐分散，也会让平台交付长期停留在基础设施层。AIOS 通过以下流程将算力继续转化为模型服务：

AIOS 还提供模型能力评测和推理性能评测。企业可以使用标准或自定义数据集检查模型效果，并通过并发压力测试评估服务表现，为模型选择、GPU 规格比较、容量规划和生产上线提供依据。

这套链路还把项目中反复出现的环境准备工作沉淀为可复用资产。模型文件和数据集进入仓库后，可以在同一账户或项目的推理、精调和评测任务之间共享，减少重复存储；经过验证的推理框架、依赖和参数可以固化在模板中，后续团队无需重新拼装运行环境。模型服务发布为 OpenAI 兼容 API 后，应用侧可以使用相对稳定的调用方式接入，在接口兼容的范围内降低底层模型或承载引擎调整对业务系统的影响。

ZStack Cloud 与 Zaku 最终输出一致的模型 API。底层引擎可以根据任务阶段调整，业务应用继续通过稳定接口调用模型，算力环境的变化被控制在平台内部。

ZStack 将传统基础设施与 AI Infra 纳入同一运营框架，并按照管理对象形成相互衔接的运营层级：

ZStack CMP 负责基础设施运营，将 Cloud、Zaku 及其使用的 GPU 纳入组织、权限、配额、申请和审批流程，同时可对其他厂商的异构云平台进行统一运营纳管；

ZStack AIOS 负责模型、数据集、推理模板和模型服务的生命周期管理；

ZStack Zentrix 作为企业级 AI 网关，负责 AI 能力接入与调用治理，管理访问凭证、权限与配额、路由策略、用量计量和全链路审计。

AI Infra 的建设，覆盖异构加速器、云主机与容器运行环境、模型与数据集、推理服务及其调用过程。AI 从单个项目扩展到多个部门后，这些新增对象需要与服务器、存储、网络和传统云资源沿用一致的组织、权限、配额和成本口径。不同层级由相应产品专业管理，同时保持基础设施供给、模型服务交付与 AI 消费之间的运营衔接。

业务部门可以沿用企业云入口申请所需算力，平台团队在 AIOS 中发布模型服务，应用通过 Zentrix 统一访问 AIOS 或第三方 AI 基础设施提供的模型服务。管理者可以分别掌握各部门获得的基础设施资源以及实际产生的模型调用量，并据此调整资源配额、模型渠道和成本分摊策略。

企业增加模型和 AI 应用时，原有云运营体系仍然可以继续发挥作用，新增的 AI 服务治理也能够沿着统一的组织与成本关系扩展。

某省财经大学：以利旧方式建立面向多部门的 AI 算力底座。

该校已有服务器、存储以及 8 张 NVIDIA A40、8 张 NVIDIA L20，不同课题和部门对性能、隔离与资源颗粒度的要求各不相同，同时还需要持续掌握 GPU 状态和负载，并将模型能力提供给校园应用。

ZStack 将原有硬件和两类 GPU 统一纳入 AIOS 算力资源池，根据任务分别提供 GPU 透传、vGPU 和显存切分，并通过统一监控掌握设备状态与负载。在此基础上，AIOS 完成大语言模型及多模态模型的部署，通过标准推理 API 对接行政与教学科研应用。目前平台已承载校内 AI 服务、智能问答、体育数智管理和学科大模型等多类业务，原有基础设施也由分散资源转化为可以持续交付的 AI 能力。

某省级智算中心：在千卡规模下统一多种算力形态。

该项目面向省级政务智算中心建设，需要统一管理多个算力集群中的 2000 多张 GPU。中心内同时存在 NVIDIA、AMD 等不同厂商设备，业务任务既要运行在容器和虚拟机中，也有使用弹性裸金属的需求；有的任务需要整卡性能，有的则需要 vGPU 或显存切分。随着设备型号、运行环境和交付方式同时增加，跨集群调度、资源状态监控和统一运维成为项目建设的关键。

ZStack 方案统一纳管 NVIDIA、AMD 等 GPU，并以容器、虚拟机和弹性裸金属承接不同工作负载；资源交付侧同时提供 GPU 直通、vGPU 和容器精细显存切分，运维侧集中呈现设备状态与使用情况。智算中心由此可以根据任务的性能、隔离与弹性要求调度资源，并在统一视图中完成大规模异构算力的持续管理。

当 AI 建设从部门试点扩展到区域级智算中心，管理对象会从十余张 GPU 增长到千卡集群，计算环境也会从单一形态走向云主机、容器和裸金属并存。依托统一技术栈，企业可以在资源规模和使用范围扩大时保持架构与运营的连续性，使早期形成的资源池化、服务交付和管理体系继续承接新增硬件、模型与使用部门。

兼容性仍然是国产化平台的基础能力。它保障处理器、操作系统、服务器、存储和业务应用能够稳定运行，也决定项目能否顺利起步。

然而，AI 时代需要进一步考验平台吸收变化的能力：工作负载会在云主机和容器之间分化，算力路线会随着国产 GPU、NPU 和模型生态持续变化，平台交付对象会从基础设施资源延伸到模型 API，使用范围也会从少量技术人员扩展到多个业务部门。