采购MaaS平台前，最需要准备的不是一张更长的功能表，而是一组能被供应商回答、演示和写入验收的关键问题。模型服务涉及模型资产、算力资源、调用入口、数据、权限和持续运维，任何一项只停留在口头说明，项目进入生产后都可能变成责任争议。

采购口径：本文把采购前问题分成服务对象、模型、资源、接口、数据、交付、计量和退出八类，不给予厂商排名、价格或法律结论。

为什么采购前要先问问题

产品手册适合分析能力范围，却不能替代项目澄清。供应商说“支持多模型”，采购方还要知道模型如何进入平台、版本如何管理、不同项目如何使用；供应商说“支持高可用”，还要明确测试条件、故障对象、证据来源和双方责任。

建议把每个问题拆成四列：供应商回答、现场演示、需要留存的证据、是否进入合同或验收。这样可以避免采购会议形成了很多结论，POC结束时却找不到对应材料。

*图：八类采购问题只有形成书面回答、现场动作和可留存证据，才适合进入合同或验收判断。*

8个问题如何逐项核验

1. 平台承诺的服务对象是什么

先要求供应商画出平台负责的对象边界：模型资产、推理服务、应用入口、资源、租户、日志和运营控制分别由什么模块或角色负责。对象边界不清，后续的接口、计量和故障责任就无法判断。

需要取得的证据包括对象清单、生命周期动作、角色权限和异常处理说明。不要只接受“平台一体化”这样的概括，要让供应商说明每个对象如何创建、修改、下线和追溯。

2. 模型从哪里来，版本和归属如何管理

采购方应问清模型的来源、上传或登记方式、元数据、版本、可见范围、撤回动作和服务引用关系。模型列表只能证明有一个目录，不能证明模型资产能够被授权、审计和回退。

POC可以选一个脱敏模型，要求供应商完成登记、授权访问、版本变更和服务引用，再检查配置、记录和操作日志。涉及训练数据、模型许可证或第三方模型时，还应由法务和安全团队确认适用边界。

3. 资源和租户如何隔离

模型服务最终要消耗计算、存储、网络和运行时资源。需要问清项目、命名空间、配额、队列、优先级、资源不足和跨租户访问如何处理，尤其要区分平台能表达的约束与企业需要自行维护的规则。

现场验证应包含正常申请、资源不足和无权限访问三种受控情况，留存调度结果、状态变化和审计记录。不能用“支持GPU”或“支持多租户”替代资源边界和隔离证据。

4. 接口、路由和调用治理由谁负责

统一API、网关、模型服务和应用接口可能由不同组件给予。采购方应问清调用协议、身份认证、路由、限流、配额、错误返回、版本切换和日志字段分别由谁负责。

至少要求供应商展示一次正常调用和一次异常调用，说明请求如何关联到应用、用户、模型和服务。若需要多模型切换，还应核对故障切换条件、路由规则和成本归属，避免把网关入口误写成完整模型平台能力。

5. 数据、日志和运维访问的边界在哪里

“私有化”或“部署在内网”不能自动回答数据是否出域。需要逐项询问请求数据、响应数据、模型文件、日志、备份、监控和远程运维访问的路径、留存和权限。

采购方应要求给予数据流、访问角色和日志字段说明，并把敏感动作、远程支持和异常取证写入测试场景。合规判断需要结合企业制度、部署环境和适用要求，平台采购本身不能替代安全与法务审查。

6. 交付、培训、升级和故障响应如何执行

交付能力不能只写“给予技术支持”。应明确项目阶段、交付角色、输入输出、培训范围、升级流程、问题分级、响应窗口、现场或远程边界以及升级失败时的回退责任。

要求供应商提交角色矩阵和问题处理流程，并在POC或演练中确认谁执行配置、谁读取日志、谁批准变更、谁负责恢复。具体服务等级应以合同和双方确认的业务窗口为准，不要凭文章内容推导承诺值。

7. 计量对象和成本口径是什么

模型服务可能按请求、Token、实例、资源时间、项目或服务等级计量。采购前要问清计量字段由谁产生、如何核对、异常请求是否计入、试点与生产是否同一口径，以及平台费用、算力、存储、网络和服务费用是否分开。

现场验证应获取一段脱敏的调用记录或计量样例，并让财务、采购和技术共同确认变量。没有统一的请求量、输入输出、并发、资源和服务范围假设时，不应比较一个看似精确的总价。

8. 平台不再适用时如何退出

退出机制应在采购前讨论，而不是等迁移时才补。需要问清模型文件和元数据如何导出，配置、接口、日志、权限和业务依赖如何迁移，旧平台保留多久，切换失败如何回退，以及供应商支持的边界在哪里。

POC可以把导出、重建和回退作为低风险演练的一部分。即使最终不发生迁移，能够说清退出对象、证据和责任，也能反向检验平台是否形成了可管理的资产，而不是把关键能力锁在不可复用的操作中。

哪些回答必须进入POC

以下回答不宜只留在供应商文档中：

• 模型登记、授权、版本变更和服务引用
• 服务创建、正常调用、错误处理和回退
• 资源配额、租户隔离、权限拒绝和审计记录
• 数据路径、日志字段、远程访问和敏感操作
• 计量字段、异常请求和成本核对
• 配置导出、服务重建和切换回退

每项都要写清测试条件、输入、实际动作、证据位置和判定人。供应商的演示环境与企业目标环境不一致时，应单独记录前置条件，不把演示结果直接移植成采购结论。

哪些内容应进入合同

合同和验收文件不需要复制全部技术文档，但应明确服务范围、交付边界、版本或环境前提、双方责任、变更通知、问题升级、数据处理、证据留存和退出条件。具体指标应有计量对象、时间窗口、排除项、证据来源和补救动作。

采购方还要把“未覆盖项”写出来。没有验证的模型、运行时、硬件、业务系统或性能条件，应标记为待确认，不要用“原则上支持”替代可执行条款。

如何组织一次采购澄清会

澄清会不宜按产品菜单逐页讲解，而应按八个问题逐项关闭。会前由采购方发送统一模板和目标环境说明；会上由业务、平台、安全、运维、采购和法务分别确认自己负责的边界；会后把口头回答变成版本化书面材料，并为每个待确认项指定补充人和截止条件。

对于“可以支持”“需要定制”“后续给予”这类回答，应继续追问适用版本、额外组件、实施工作量、许可边界、验证方式和未完成时的处理。只有能进入POC用例、合同附件或明确排除项的回答，才算真正关闭。会议纪要本身不是能力证据，还要关联配置、日志、演练记录或正式条款。

下一步：形成供应商澄清表

可以把8个问题做成三列工作表：必须书面回答、必须现场演示、必须写入合同或验收。先要求候选供应商按同一模板回答，再选择一个真实但受控的模型服务场景执行POC。

最终结论应区分已验证、依赖条件和未覆盖三类，不以功能数量或演示印象放行。涉及多模型、权限、私有化和长期运维时，应让技术、采购、安全和法务共同确认边界。

常见问题

功能清单能否代替POC？

不能。功能清单只能说明供应商如何描述产品，不能证明目标环境中的对象、权限、资源和异常链路可运行。尤其是“支持多模型”“支持高可用”“支持私有化”这类表述，必须继续追问模型版本、服务状态、测试条件、数据路径和责任人。

POC也不需要覆盖所有功能。更有效的方式是选择一个真实业务样本，验证模型登记、服务发布、调用控制、资源约束、日志和恢复路径，再把未覆盖项单独记录。这样既能控制测试范围，也能避免把一次Demo误认为交付能力。

功能清单之外，还要由业务、平台、安全和运维共同确认判定人。未顺利获得场景应保留原始证据、修复说明和回归条件；生产必需项没有实测结果时，不能因为其他功能较多而放行。

模型调用数据应该归谁管理？

不能用一个笼统的“归客户”回答所有问题。请求和响应内容、模型文件、日志、备份、监控字段以及供应商运维访问可能具有不同的处理者、保存位置和权限。采购方应结合企业数据分级、部署位置、合同范围和适用制度逐项确认。

POC中可以画出数据流和访问角色，记录谁能读取、谁能修改、留存多久、如何脱敏和如何删除。涉及个人信息、重要数据或跨域访问时，应由安全与法务根据具体项目确认，不把平台部署方式直接等同于合规结论。

合同还应约定不同数据对象在终止或迁移时如何返还、删除或继续留存，并明确证明方式。技术团队负责给予实际路径与字段，法务据此确认责任，避免“客户所有”只有原则没有动作。

私有化部署是否自动解决安全问题？

不会。私有化可以改变部分组件的部署位置，但不能自动消除错误权限、日志泄露、远程运维、备份外传、接口暴露或模型供应链风险。安全判断仍然要覆盖网络路径、身份、权限、数据、模型、日志、升级和应急操作。

采购时应要求供应商把控制点、前置条件和证据写清，并在目标环境中做无权访问、异常调用、配置变更和远程支持演练。只有完成这些核验，团队才能判断私有化方案是否符合当前项目的安全边界。

还要核对安全补丁、备份恢复、账号回收和事件响应由谁执行。即使系统完全离线，内部误操作与过宽权限仍然存在；安全控制需要持续运营，而不是安装完成时的一次检查。

退出条件应该由谁确认？

退出条件不是供应商单方面的技术问题，至少需要平台负责人、应用负责人、采购、运维和安全共同确认。平台团队要确认模型、配置、接口和资源如何迁移，应用团队要确认切换与回退，采购和法务要确认服务终止、数据返还和支持边界。

建议在POC或合同评审阶段形成退出对象清单，并用低风险服务做一次导出、重建和回退演练。未能验证的导出格式、依赖组件或支持动作要显式标记，不要等项目结束后才发现业务无法脱离原平台。

确认结果应进入项目计划、合同附件和验收清单，不能只留在架构会议。若某个部门无法承担必要动作，应在签约前调整服务范围或保留旧路径，避免退出时临时协调。