MaaS平台选型时，模型目录数量只是候选池的入口，不能直接代表企业能否把模型变成稳定、可治理的服务。技术管理者、AI平台负责人和采购影响者更需要比较模型资产、推理服务、资源约束、调用治理与长期运营，再用真实场景完成POC。

评估口径：本文只讨论企业MaaS平台的能力边界和验证方法，不给予厂商排名、价格、性能或兼容承诺。

为什么模型数量不能代表平台能力

模型目录可以帮助团队发现可选能力，但它无法回答几个决定生产成败的问题：模型由谁登记和维护，版本如何识别，服务如何发布，资源如何分配，调用是否经过权限控制，异常是否有日志和回退。一个模型列表解决的是“有什么”，而采购需要回答“能否持续给予服务”。

因此，初筛时应把模型数量降为一个输入项，而不是总分。还要询问模型来源、版本元数据、可见范围、服务化方式、调用协议、资源前置条件和交付责任。只有这些问题能被同一套证据回答，平台之间才具备比较基础。

先定义企业真正需要的模型服务场景

没有业务场景的功能表，往往会把所有平台都评成“支持”。建议先固定一个低风险、可复现的场景，例如内部知识问答、文本处理或受控的应用调用，并写清输入、输出、调用身份和失败处理。场景不需要一开始覆盖所有模型，但必须能够暴露模型、服务、资源和运营之间的关系。

场景说明至少包含：

• 使用哪个模型或模型类型，模型版本如何标识
• 谁发起调用，应用和用户权限如何区分
• 服务运行在哪类资源上，资源不足时如何处理
• 需要观察哪些日志、状态、延迟或错误信息
• 出现版本问题、服务异常或权限错误时如何回退

如果候选平台只展示控制台菜单，却不愿意按同一场景给予配置、日志和异常证据，说明评估对象仍停留在演示层。

*图：MaaS选型应先按共享规模与特殊数据或资源边界分流，再用同一组POC证据比较候选方案。*

五类能力如何进入同一张评估表

以下表格用于初筛和POC准备，不是任何产品的支持矩阵。

表格的重点不是给每项简单打分，而是确认每个判断都能对应对象、动作和证据。比如“支持多模型”至少要继续追问模型如何登记、不同模型如何发布、调用方如何选择以及故障时怎样切换。

POC要验证哪些可复现证据

POC建议从一个模型服务和一个业务调用开始，按顺序检查：

1. 模型能否被授权用户登记、查看、共享和识别版本。
2. 服务能否按记录的配置重复创建，并取得清晰的状态和访问入口。
3. 资源、项目、命名空间、配额或队列能否表达约束，权限错误是否可定位。
4. 调用日志能否关联身份、模型、服务、结果和异常，必要时能回放问题。
5. 服务配置或模型版本变化后，是否有审批、变更记录和回退动作。

单次成功调用不能证明持续运行能力；展示硬件名称也不能证明驱动、运行时和模型兼容；给出性能数字但不说明模型、输入、并发和环境，也不能用于横向结论。

哪些场景不适合直接采购MaaS平台

如果团队只有一次性实验，模型数量少、调用范围明确且已有成熟运行环境，直接采购完整MaaS平台可能带来不必要的建设和运营负担。此时可以先评估现有平台缺少的对象和动作，再决定补充服务管理、网关或观测能力。

如果业务涉及多部门共享、模型持续变更、权限隔离、异构资源、审计或多种调用方式，则不应只按单点接口采购。需要把平台、组件和企业责任拆开，并要求供应商明确版本、前置条件、问题升级与退出边界。

采购评审要收哪些证据

采购证据应能让不同角色在会后独立复核，而不是依赖演示人员解释。建议为每个候选平台建立证据索引，至少关联需求编号、目标版本、测试环境、操作账号、配置快照、原始日志、问题单和判定人。模型登记、服务发布、权限拒绝、资源约束、异常恢复和版本回退分别留证，才能判断平台覆盖的是界面入口还是完整链路。

证据还要区分三种状态：现场已经验证、依赖特定条件、当前没有覆盖。采购评审不能用其他高分抵消权限越界、关键服务无法恢复或数据路径不明等缺口。商务承诺如果没有对应技术条件，应先转成补测项或合同前置条件，再决定是否纳入最终范围。

POC责任与退出如何落表

POC开始前应由业务方给予脱敏样本和结果判定，平台团队准备环境、身份与资源，安全团队审查数据和远程访问，供应方说明版本、依赖与恢复动作，采购负责把已验证结论映射到合同。任何对象没有主责人，都不宜进入生产承诺。

还应提前验证最小退出路径：模型及元数据能否导出，服务配置能否在隔离环境重建，调用方需要改哪些接口，旧入口保留到什么条件，失败后由谁批准回退。退出演练不要求完成整个平台迁移，但必须暴露专有格式、隐含依赖和支持边界，避免采购后才发现关键资产无法脱离。

下一步如何形成候选池

候选池不宜从厂商名单开始，而应从场景和证据开始。建议先选两个代表性模型或模型服务，写出同一套输入、权限、资源和异常条件，再要求候选平台逐项回答并安排受控POC。

评估结果应至少保留三类结论：已验证的能力、依赖现场或版本确认的能力、当前不覆盖的能力。这样既能支撑采购判断，也能避免把演示内容误写成平台承诺。若需要进一步比较模型入口、推理服务和平台治理，可继续进入AI基础设施相关内容的评估路径。

常见问题

模型数量多是否一定代表MaaS平台更好？

不一定。模型数量只能说明候选资产的广度，不能说明模型是否能在目标环境中被登记、部署、授权调用和持续运营。企业还要看模型来源、版本管理、服务化方式、资源条件、访问控制和异常恢复。如果目录中模型很多，但缺少元数据、服务状态或责任记录，数量反而可能增加管理复杂度。

比较时应固定真实业务样本和代表模型，要求不同平台给予同口径的配置、调用、日志和回退证据。模型数量可以作为筛选条件，但不应替代平台对象、服务链路和运营责任的验收。

此外要核对目录中的模型是否适用于目标部署方式、许可证和数据边界，并把无法验证的条目标为条件项。最终评分由平台、业务和采购共同确认，避免市场展示数量直接成为采购权重。

已有K8s集群，还需要单独评估MaaS平台吗？

要看现有K8s覆盖到哪一层。K8s可以给予容器编排、项目或命名空间等承载能力，但不会自动补齐模型资产管理、推理服务生命周期、统一调用、应用接入和AI运营责任。已有集群的企业应先列出现有对象、角色、配额、网络入口、日志来源和故障响应人，再识别模型到业务应用之间的缺口。

如果团队只需要少量服务，补充必要组件可能比采购完整平台更合适；如果需要多项目共享模型、统一发布服务、治理调用并持续运营，则值得把MaaS能力纳入POC。最终判断应以真实场景和新增责任为依据。

还应检查现有集群的版本、资源隔离、网络、存储、监控和运维能力能否满足模型服务。若需要新增运行时、网关或专门值守，应把这些依赖和投入写入方案，而不是假定K8s会自动承接。

MaaS与AI网关如何分工？

MaaS通常关注模型和推理服务如何成为可管理、可调用和可运营的对象，AI网关更关注统一入口、路由、配额、策略和调用治理。两者可能在同一解决方案中协作，但并不因为存在网关就自动完成模型资产和服务生命周期管理。

POC中应分别验证模型登记与服务发布、入口访问与路由策略、身份和权限、调用日志、异常降级以及责任归属。若一个组件被描述为“统一平台”，仍要要求供应商把对象、动作、证据和企业责任分栏说明。

责任表还要写明网关策略变化如何影响模型服务、故障由谁先定位，以及两侧日志如何关联。若入口与服务分属不同供应方，应在POC中演练超时或切换，验证升级路径。

采购前最少准备哪些业务样本？

至少准备一个可以脱敏、可重复执行且风险可控的真实请求，并写清模型或模型类型、输入规模、期望输出、调用身份、资源条件和失败处理。若平台要服务多个部门，再补充一个权限不同或资源竞争不同的场景，用来验证隔离和治理。

样本不宜只准备“能成功回答”的问题，还应包含超时、无权访问、版本变化或资源不足等受控情况。这样才能在POC中同时观察正常链路和异常链路，形成可以供采购、平台和业务共同确认的证据。

样本还应明确数据分级、可接受延迟、人工复核和成功判定，并由业务负责人签字。测试结束后保留样本版本与执行记录，确保候选平台使用相同输入，结果才有比较意义。