私有化部署大模型方案书怎么看:先核对这六处

看私有化部署大模型方案书,先核对六处:交付清单、算力口径、模型授权、数据与日志落点、复核边界、运维交接。只停留在口头的内容,签约前都应补成书面条款。

要点速览

• 看方案书先看范围,再看口径,价格放在后面比
• 交付清单要逐层标明包含、不包含或客户自备
• 算力配置要写明模型规模、并发与时延等测算条件
• 文档、向量库、调用记录的落点与导出方式须写进合同
• 口头承诺签约前都要补成书面条款

拿到私有化部署大模型的方案书,不要先比价格和品牌,先逐项核对六处:交付清单写到了哪一层,算力按什么条件测算,模型授权能不能更换,数据与日志存在哪里、谁能导出,AI 和人工的复核边界有没有写明,上线后的运维与交接由谁负责。这六处写得越具体,后期出现范围扯皮、追加费用、数据落点说不清的可能就越小。凡是只停留在口头上的内容,都应在签约前补成书面条款。

方案书里没写的部分,往往就是后期要补钱的部分

很多企业收到两份方案,报价相差不小,第一反应是比较谁更便宜。实际翻下去常会发现,两份方案的交付范围并不相同:一份只写到服务器和操作系统,模型怎么接、知识库怎么建、账号怎么管都没有提;另一份把这些写进了范围,价格自然不同。

所以读方案书的顺序,建议是先看范围,再看口径,然后才看价格。范围决定你买到的是什么,口径决定这些东西在什么条件下能达到承诺的效果,价格只有在前两项对齐之后才有比较意义。服务商是谁当然重要,但方案书里写了什么、没写什么,往往更能说明对方准备交付到哪一步。

下面六处,每处按三个问题来看:方案书里应该出现什么,缺了会出什么问题,以及一句可以直接发给服务商的追问。

六处逐项核对:应写什么、缺了会怎样、怎么追问

一、交付清单:写到了哪一层

应该出现什么。一套能用的私有化大模型,通常可以拆成几层:硬件(型号、数量、放在客户现场还是机房)、操作系统与驱动、模型管理(模型接入、调用路由、调用记录)、知识库(文档导入、切分、检索、更新)、权限与统一管理(账号、角色、部门隔离)。方案书应当把每一层标成「本次包含」「不包含」或「需客户自备」。

缺了会怎样。常见情况是硬件和系统写得很细,往上几层只有一句「支持知识库」「支持权限管理」。到了实施阶段才发现知识库需要另外采购,权限要客户自己开发,预算和工期都被打乱。各层怎么拆、每层验收看什么,可以参考私有化部署大模型如何实现:硬件、系统、模型、知识四层拆开做。

追问:请把硬件、系统、模型管理、知识库、权限管理逐层标出,哪些在本次报价内,哪些需要我们自行准备或另行采购。

二、算力口径:不能只写一个卡数

应该出现什么。算力配置要写明测算条件:按多大规模的模型、多少人同时使用、期望的响应时延、单次输入输出的大致长度来估算。条件写清楚了,配置才有依据,也才有办法在验收时对照。

缺了会怎样。方案书只写「配置若干张加速卡」,看起来很具体,其实无法验证。上线后用户一多就排队,或者换了更大的模型就跑不动,双方各说各的:服务商认为配置符合合同,客户认为达不到使用要求。算力估算涉及哪些变量,可以先看私有化部署大模型算力怎么估?先问清三个变量。

追问:这套配置是按什么模型规模、多少并发、多长时延测算的?在这个条件下能否做一次现场测试作为验收依据?

三、模型清单与授权:能不能换、换了要不要重签

应该出现什么。方案书应列出本次部署的模型名称与版本,说明每个模型的授权条件(是否可商用、有无用户数或部署数限制),以及后续更换或新增模型的方式和费用。

缺了会怎样。大模型更新很快,一两年后很可能需要换模型。如果系统只适配某一个模型,或者合同把模型和整体方案绑在一起,换模型就意味着重新签约、重新实施。授权条件不清,还可能在商用场景里留下合规隐患。

追问:方案里用了哪些模型、授权条款是什么?以后要换模型或加模型,是否需要改动系统、重新签约,费用怎么算?

四、数据与日志落点:存在哪、谁能导出、谁来保管

应该出现什么。私有化部署的意义很大程度在于数据留在自己可控的范围内。方案书应写明三类数据的位置:原始文档、知识库向量数据、调用与问答记录。每一类都要说清存放在哪台设备或哪个机房,保存多长时间,谁有权限查看和导出,合同结束后如何移交或销毁。

缺了会怎样。文档在本地,但调用记录被回传到服务商的平台;或者向量库格式封闭,换服务商时无法迁移。这些问题平时看不出来,一到审计、离场或安全检查时就会暴露。涉及个人信息或重要数据的,还要结合《中华人民共和国数据安全法》《中华人民共和国个人信息保护法》以及等保 2.0 的要求,确认存放与访问方式是否满足企业自身的合规义务。

追问:原始文档、向量库、调用记录分别存在哪里?是否有任何数据会离开我方环境?合同结束时这些数据如何交还给我们?

五、复核边界:AI 做到哪,人从哪里接手

应该出现什么。在法律、财税、金融等专业场景,方案书应写明 AI 的职责范围:资料整理、初步审核、风险标记与提示;关键判断与签字确认由专业人员完成。同时写清复核的方式,例如哪些输出必须人工确认后才能使用,复核记录如何留存。

缺了会怎样。如果方案只写「自动审查」「智能出具意见」,业务部门可能直接采用 AI 的结论,出了差错才发现没有人对结果负责。边界不写清,既是业务风险,也会让后续验收失去标准。

追问:在我们的场景里,AI 的输出哪些可以直接参考、哪些必须人工复核?系统是否支持记录复核人和复核结果?

六、运维与交接:上线之后谁接电话

应该出现什么。上线后的告警由谁接收,模型和系统如何升级,故障的响应方式和处理时限,知识库内容由谁更新,账号权限由谁维护。另外要列出交接材料:部署文档、账号清单、配置说明、常见故障处理手册,以及客户方需要具备的运维人员和技能。

缺了会怎样。项目验收之后服务商撤场,企业内部没人知道系统怎么维护,知识库渐渐过时,问答质量下降,系统慢慢被闲置。模型、知识、权限三条线各由谁管,可以参考企业AI上线后运维谁来管?模型、知识、权限三条线与交接清单。

追问:上线后的告警、升级、故障分别由谁处理?交接时会提供哪些文档?我们需要配几个人、具备什么技能?

一张可打印的方案书核对表

收到多份方案时,可以把下面这张表打印出来,每份方案填一张。每一项按三种状态勾选:已写明(方案书或合同里有明确文字)、口头承诺(沟通中提到但文件里没有)、未提及。填完之后横向对照,「口头承诺」和「未提及」越多,后期变数越大。

1. 交付清单:硬件、系统、模型管理、知识库、权限管理逐层是否标明包含与否 —— 已写明 / 口头承诺 / 未提及
2. 算力口径:模型规模、并发人数、响应时延、测试验收方式 —— 已写明 / 口头承诺 / 未提及
3. 模型清单与授权:模型名称版本、授权条件、更换与新增方式及费用 —— 已写明 / 口头承诺 / 未提及
4. 数据与日志落点:文档、向量库、调用记录的位置、保存期限、导出与移交方式 —— 已写明 / 口头承诺 / 未提及
5. 复核边界:AI 职责范围、必须人工确认的环节、复核记录留存 —— 已写明 / 口头承诺 / 未提及
6. 运维与交接:告警、升级、故障处理的责任方与时限,交接文档清单,客户方人员要求 —— 已写明 / 口头承诺 / 未提及

填表时有两个小建议。一是每项后面留一行备注,写下对方的原话或页码,方便回头核对。二是把「口头承诺」集中整理成一份清单,在下一轮沟通时请对方逐条确认能否写进合同附件。

一种参照:润迅 MaxDeploy 的交付层次

为方便读者理解「交付清单写到哪一层」,这里如实列出润迅 MaxDeploy 的交付层次,作为对照方案书时的一个参照,而不是比较结论。

• 硬件层:R30 AI 一体机,放在客户现场使用;或 R500 AI 服务器,适合放在机房、承担更高的算力需求。需要放在机房的,润迅自建并运营前海云与田心两个数据中心。
• 系统层:XunOS,AI 操作系统。
• 模型层:MaxModel,模型统一管理平台,用一个 Key 接入多个大模型,提供多模型路由与调用审计,便于后续更换或新增模型。
• 应用层:其上运行 MaxKnow 企业知识库与 MaxControl 统一管理。

在法律、财税等场景,润迅的做法同样是:AI 只承担资料整理、初步审核、风险标记与提示,关键判断与确认由专业人员完成。拿这套分层去对照手里的方案书,可以更快看出哪一层写进了范围、哪一层还空着。

拿到方案后的下一步

1. 先用核对表把每份方案过一遍,标出「口头承诺」和「未提及」的项目。
2. 把六句追问整理成一封邮件,统一发给各家服务商,要求书面回复。
3. 算力口径和复核边界两项,争取在试点阶段用真实业务数据验证一次,再进入正式采购。
4. 签约前确认所有口头承诺都已进入合同或附件,数据移交与运维交接条款单独列出。

如果想把润迅的交付层次与手中的方案逐层对照,可以查看 MaxDeploy 交付方案,或拨打业务热线 400-854-5566,带着核对表与我们逐项沟通。

→ 联系润迅,聊聊你的场景,获取适合的方案