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

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

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

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

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

兼容性决定平台今天能否顺利落地，AI 承载能力决定它能否支撑企业未来五到十年的技术升级与业务演进。

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

1. 平台是否具备足够的架构连续性，能够支撑传统业务与 AI 工作负载长期共存、持续演进；

2. 平台是否具备异构算力的组织能力，能够统一纳管不同技术路线的加速器，并根据任务需求高效交付；

3. 平台是否具备 AI ，能够贯通算力、模型、推理服务与业务调用，缩短从技术验证到生产应用的距离；

4. 平台是否具备运营体系的延展性，能够将传统基础设施与 AI Infra 纳入统一、可持续的运营体系。

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

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

架构连续性：以 ZStack Cloud 与 Zaku 双引擎承接 AI 演进

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

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

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

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

CNCF 2025 年度调查显示，82% 的容器用户已经在生产环境运行 Kubernetes；在托管生成式 AI 模型的组织中，66% 使用 Kubernetes 管理部分或全部推理工作负载。容器正在成为 AI 生产化的重要基础，云主机仍然承载着大量既有环境与复杂任务。

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

选择 ZStack Cloud 与 Zaku，企业同时获得了面向 AIOS 的双引擎基础。现有云能力与未来 AI 建设沿着同一套技术栈连续演进。

异构算力资源化：从兼容接入走向统一纳管与按需交付

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

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

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

1. GPU 透传：物理 GPU 直接交付给云主机，适合持续高负载的大模型推理和 HPC 任务。

2. 厂商 vGPU：依托厂商虚拟化能力切分 GPU，适合具备相应授权条件并要求硬件级强隔离的环境。

3. MIG：利用 NVIDIA GPU 的硬件切分能力建立多个隔离实例，适用于支持 MIG 的型号。

4. dGPU 动态切分：通过软件动态分配显存和算力，不依赖 NVIDIA vGPU 授权，也不要求 GPU 支持 MIG。

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、小模型推理以及多个轻量任务共享单卡资源。

几种方式对应着不同的决策条件。持续高负载、性能优先的任务可以使用整卡透传；具备厂商授权条件、强调硬件级隔离的环境可以选择 vGPU，支持 MIG 的设备也可以采用硬件切分；显存需求差异较大、任务启停频繁时，可以使用 dGPU 或容器显存切分提高资源颗粒度。企业可以根据性能、隔离、硬件条件和使用周期组合交付方式，而不必让所有任务共享同一种 GPU 分配策略。

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

AI 时代的算力兼容，需要继续延伸到算力交付。ZStack AIOS 将异构 GPU 转化为能够按任务分配的资源池，让不同型号和不同规格的设备持续服务于实际负载。

AI 生产化：打通从算力分配到业务调用的交付链路

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

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

1. 模型通过本地上传、URL 或开源社区进入模型仓库，并按照账户和项目进行隔离与共享；

2. 推理模板管理 vLLM、SGLang、Transformers、Diffusers 等框架和运行环境；

3. 用户根据模型特点选择 Cloud 云主机或 Zaku 容器，平台计算推理所需算力并创建服务；

4. 服务发布后生成标准 API，Notebook 用于部署前的参数和环境调试；

5. 平台持续提供请求日志、负载监控、弹性调度、故障后的秒级自恢复和模型文件多级缓存。

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

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

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

ZStack 将国产化平台的交付对象从云主机和容器扩展到模型服务。算力资源经过标准化部署、运行保障和评测后，能够直接进入企业应用。

统一运营：将传统基础设施与 AI Infra 纳入同一体系

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

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

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

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

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

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

例如，同一个模型服务可以面向多个部门开放，并为不同组织或用户配置访问凭证和调用额度，按组织、业务线等维度应用路由策略。基础设施团队关注 GPU 的分配、利用率和故障状态，模型团队关注服务版本、性能与可用性，运营团队则依据调用量和日志掌握实际消费。资源分配较多但调用长期偏低，或者调用持续增长而服务容量不足时，管理者可以分别从算力供给和模型消费两侧调整配置。

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

ZStack Cloud 与 Zaku 提供运行环境，AIOS 交付模型服务，CMP 与 Zentrix 分别负责基础设施运营和 AI 调用治理。ZStack 让 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 时代，国产化平台的选择标准正在延伸

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

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

ZStack 以 Cloud、Zaku、AIOS、CMP 与 Zentrix 组成面向 AI Ready 的连续产品体系：兼容国产化软硬件生态，承载多样化工作负载，组织异构算力，交付模型服务，并将传统基础设施与 AI Infra 纳入协同运营。企业今天选择的国产化平台，也在决定未来 AI 建设需要走多远的路。