POC 做完了。模型选定，卡也测过，推理延迟在可接受范围，业务部门认可效果。然后采购问：具体买什么？
这个问题往往卡住。因为跑通一个 POC 需要的东西，和支撑一套长期运行的私有化 AI 平台需要的东西，不是一回事。
POC 阶段一台机器、一个推理进程、一个 Web 界面就够了。到了生产阶段，问题变成：多个业务方共用这些卡怎么分、模型版本怎么管、谁在调用怎么统计、成本怎么分摊到部门、新模型上线要不要停服。这些问题没有一个能靠“买几张卡”解决。
企业大模型私有化部署选型的难点在于，市面上的方案分布在一个很宽的区间：一端是开源组件自己攒，另一端是整套商业平台，中间还有只做其中一层的产品。要选得对，先得知道自己缺的是哪一层。
一、先拆层：私有化 AI 平台的四层能力
不管选哪家，一套能长期运行的私有化 AI 平台，功能上都要覆盖这四层。用它做选型坐标系，比对着功能列表逐条打钩有用。
四个自查问题
在看任何一家方案之前，先回答：
1. 这四层里，我现在缺哪几层？如果已有成熟的 K8s 平台和监控体系，可能只缺网关层和模型层。
2. 缺的层是自己攒还是采购？开源组件都能找到对应物，代价是集成和长期维护。
3. 采购的话，要一家覆盖多层还是分别采购？分别采购的风险在层与层之间的对接；一家覆盖的风险在某一层不够强。
4. 三年后这四层会长成什么样？现在只做推理，两年后要不要做微调、要不要多租户对外提供服务。
二、三条路线的成本形态对比
拆完层，接下来是怎么建。三条路的成本形态完全不同。
三条路没有普遍适用的答案。判断依据是团队能力、已有基建和三年后的规模预期，不是产品参数。
一个观察：自建路线里最常被跳过的是网关层——因为 POC 阶段只有一个调用方，感觉不到需要。等到三个业务部门接进来，账已经算不清了，这时候补建的成本远高于一开始就规划。
三、三轴决策树：配置档位怎么定
四层是“要什么”，这一节是“要多少”。三条轴交叉决定档位。
常见误判是只按模型规模一轴配置，忽略隔离与并发两轴——结果是卡买够了，但多租户隔离做不了、并发一上来服务就雪崩。
跨机通信补充：多机多卡场景通常依赖高速互联网络或 RDMA 网络，方案设计阶段应确认你的硬件环境走哪条路径——这直接影响卡的采购型号和网络投入。
四、网关层：私有化之后，账怎么算
这一层单独讲，因为它是选型时最容易漏、上线后最难补的一层。
为什么 POC 阶段感觉不到
POC 只有一个调用方、一个模型、一个人看结果。“谁在调、调了多少、成本算给谁”都不是问题——答案都是同一个。
生产环境不同。三个业务部门接进来，各自调不同模型，有的用大模型有的用小模型，有的白天调有的批量跑。这时候会出现三类问题：
网关层该具备什么
ZStack AIOS 的具体实现
AIOS 智塔为四层架构：智算底座、模型层、网关层、应用层。各层的具体能力如下。
智算底座：
模型层：支持 Qwen、DeepSeek、Kimi、GLM、MiniMax 等主流大模型；模型评测覆盖能力与性能两个维度；新模型适配周期 30 天（产研确认口径，实际周期视模型复杂度而定）。
网关层（AIOS AI 网关）：
应用层：预置 Dify、ComfyUI 等平台的一键部署（以实际发布版本为准；实例创建仍涉及模型绑定与资源配置，建议在 POC 中实测完整流程）。
计量计费的归属要分清：算力计量计费归智算底座，模型调用计量计费归网关层。这是两套不同的账，选型时经常被合并成一个问题问，结果两边都没答清楚。
五、四个常见误判
误判一：把 GPU 切分当成降低调用成本的手段
这一条值得单独说清楚，因为它在行业讨论里被混淆得很厉害。
GPU 切分提高的是卡的利用效率——一张卡原本只跑一个小模型，算力闲置明显，切分之后可以承载多个业务，同样的硬件投入承载更多负载。这是真实的收益。
但它不改变单位 Token 的模型成本。Token 成本主要由模型定价决定：私有化部署场景采用人工自助定价，公有云场景取官方价格源。切分让你少买几张卡，不让你每次调用变便宜。
把这两件事混为一谈的后果是：预期“切分之后 AI 调用成本会降下来”，结果季度末发现账单没变，因为调用量本身在涨。降卡的钱和降调用的钱是两笔账，需要两套办法。
误判二：按训练的逻辑规划推理
企业先落地的通常是推理，但行业里关于 AI 基础设施的讨论由训练主导。这两者要的不是同一套东西——训练比的是带宽和大规模并行效率，推理吃紧的是延迟稳定性和长期稳态表现。
按训练逻辑采购的典型后果是：钱花在了用不上的指标上，而推理真正敏感的那部分没人管。
误判三：只在单模型、单调用方下做 POC
POC 通过了不代表生产能跑。建议在 POC 里增加三个用例：
这三项能把生产环境里最集中的那批问题提前暴露。
误判四：把平台选型和模型选型绑在一起
模型迭代速度远快于基础设施。今天选定的模型，一年后大概率会换。所以平台选型的核心标准不是“支持不支持某个模型”，而是换模型时要改多少东西——业务侧代码要不要动、调用统计的历史数据还在不在、权限配置要不要重配。
六、尽调清单（十问）
建议要求书面答复。
1. GPU 切分支持到什么粒度？切分后的实例之间如何隔离？隔离效果怎么验证？
2. 不同品牌的加速卡能否进同一资源池统一调度？各品牌的功能覆盖是否一致？
3. 支持多机多卡运行同一个推理服务吗？跨机通信的方案是什么？
4. 模型从哪些来源导入？多个版本能否并存？切换版本是否中断服务？
5. 是否提供统一的模型 API 接入层？是否兼容 OpenAI 协议？接入新模型业务侧要改代码吗？
6. 调用统计支持哪些维度？输入输出是否分别计量？能否导出用于内部分摊？历史数据保留多久？
7. 限流、熔断、优先级调度如何配置？单个业务方超量会影响其他人吗？
8. 多租户隔离到什么程度？数据、模型、调用记录是否彼此不可见？
9. 等保、密评相关的能力覆盖到什么程度？审计日志包含哪些字段？
10. 平台自身升级是否需要停止推理服务？失败如何回退？
七、需要如实说明的几点
每条配一个核实动作。
一、异构 GPU 的跨品牌统一池化仍在完善。 多品牌加速卡的统一纳管与调度已经支持，但跨品牌显存的统一池化与细粒度切分，在不同芯片平台上的成熟度不一致。核实方法：用你实际要用的那两种卡做混合池化验证，不要用单一品牌的演示环境推断。
二、各层的成熟度不完全一致。 越靠近应用层的模块投入时间越短。核实方法：把你最看重的那一层单独做深度 POC，要求提供该模块的首个商用版本时间与在网客户情况，不要用整体方案的完整度推断单层强度。
三、大规模训练场景的实践积累少于推理场景。 我们在企业推理与微调场景的落地较多，大规模训练集群的公开案例相对少。核实方法：如果核心诉求是训练，要求提供同等规模的可核实案例并做现场走访。
四、模型效果不由平台决定。 平台负责的是让模型跑得起来、管得住、算得清账，不负责让模型答得更准。选型时如果听到平台侧对模型效果的承诺，建议追问具体的实现机制。
五、私有化部署的总成本需要单独核算。 硬件、电力、机房条件、运维人力、模型授权（如有）都要计入，不能只比平台软件的报价。核实方法：要求所有候选方案按统一口径给出三年总成本，并明确标注哪些是一次性、哪些是年费。
八、小结
企业大模型私有化部署选型，本质上是在回答三个问题：
• 缺哪几层。智算底座、模型层、网关层、应用层，先确定自己的空缺位置，再去看方案覆盖了哪些。功能列表打钩打不出这个答案。
• 要多少。模型规模、数据敏感度、并发量三轴交叉决定配置档位。只按模型规模一轴配置，是这里最常见的误判。
• 换的时候疼不疼。模型会换、业务会长、团队会变。平台选型真正该看的是变化发生时的迁移成本，而不是当下的功能齐不齐。
还有一条贯穿始终：账要算得清。私有化部署把成本从“按量付费的明账”变成了“一次性投入加持续运维的暗账”，如果没有一层负责统计和归属，AI 投入很快会变成一笔说不清的钱——而说不清的投入，通常撑不过第二个预算周期。
数据来源与说明
• 产品能力与参数数据来自 ZStack 官方产品资料与产研确认口径；标注为内部测试环境的数据，实际表现以现场 POC 实测为准。
• 具体模块覆盖与版本对应关系以实际发布版本为准。
• 本文为选型方法参考，不构成采购结论；具体能力与性能表现以各平台实际发布版本及用户 POC 实测为准。
申请创业报道，分享创业好点子。点击此处，共同探讨创业新机遇！
