私有化部署大模型需求怎么写:一页纸列清五项再找服务商

服务商替你定义不了需求。先用一页纸写清场景、数据、算力、人员、验收五项,再找服务商,报价和方案才能逐项比较。

要点速览

• 需求要由买方先写,服务商方案才能横向比较
• 一页纸写清场景、数据、算力、人员、验收五项
• 算力只写并发与响应要求,型号留给方案推算
• 专业场景写明AI只做整理初审标记,判断归人
• 收到方案按五项逐条对照,含糊处列为追问

私有化部署大模型的采购需求,建议用一页纸写清五项:场景、数据、算力与部署位置、人员与运维、验收。先由买方自己写,再拿去找服务商。原因很直接:服务商熟悉的是自己的产品,不熟悉你的业务,需求如果交给对方来定义,每家写出来的方案口径都不一样,报价无法横向比较,上线后也说不清什么算做完。一页纸不追求完整,目标是把对比和验收需要的信息先固定下来。

为什么要先写需求,再找服务商

不少企业的流程是反过来的:先约几家服务商来讲方案,听完再决定要什么。这样做的问题在于,每家都会从自己擅长的部分讲起。有的强调算力配置,有的强调模型数量,有的强调知识库功能,三份方案摆在一起,看起来都合理,但比的根本不是同一件事。

自己先写一页需求,至少有三个好处:

• 报价口径统一:每家都按同样的场景、并发和数据范围报价,差异才有意义。
• 方案缺项一眼可见:哪家没回答数据放在哪、上线后谁来运维,对照需求就能看出来。
• 验收有依据:合同里引用这页需求,交付时按条核对,而不是凭演示效果下结论。

这页纸不需要技术细节。写不出来的地方,就如实写「待确认」,这本身也是需要服务商回答的问题。

五项需求逐项怎么填

一、场景:只写一个,写到具体问题

场景写得越泛,方案越难落地。「提升办公效率」「建设智能平台」这类写法,服务商只能按自己的理解去发挥。建议只写一个具体业务场景,并补上三个信息:

• 场景名称:例如「内部制度与流程问答」「合同初审」「客服工单辅助回复」。
• 使用人数:有多少人会用,其中高峰时段同时在用的大约多少人。
• 典型问题:列出五到十个员工真实会问的问题,附上期望得到的回答形式,比如要不要给出处、要不要列条目。

常见漏项是只写场景名称,不写典型问题。典型问题后面会直接变成测试题,在验收时用得上。如果想先小范围验证再扩大,可以参考私有化部署大模型试点怎么做中「一个场景四条标准」的做法。

二、数据:写清入库、不入库与存放位置

私有化部署的出发点通常是数据不想外流,但需求里往往只写一句「数据要安全」。建议拆成三问来写:

• 哪些资料可以入库:例如已发布的制度、产品手册、公开过的合同模板,注明大致数量和格式。
• 哪些资料不入库:例如含个人信息的档案、未定稿的文件、涉及商业秘密的报价,明确排除。
• 数据和调用记录放在哪:原始资料、向量索引、提问与回答记录分别存放在什么位置,保留多久,谁能查看。

常见漏项是调用记录。员工问了什么、模型答了什么,这部分同样可能含敏感信息,要和原始资料一样写明存放与权限。涉及个人信息和重要数据的,可以在需求里注明需符合《中华人民共和国数据安全法》《中华人民共和国个人信息保护法》等要求,请服务商说明对应做法。

三、算力与部署位置:先写要求,不预设型号

这一项很容易被写成「需要某型号显卡若干张」。型号是方案的结果,不是需求。买方要写的是业务要求,让服务商据此给出配置:

• 并发:高峰时段同时提问的人数。
• 响应要求:一般问题期望多久内开始出字,长文档处理可以接受多久。
• 部署位置倾向:放在办公现场,还是放在机房;有没有现成的机房条件,包括供电、散热和网络。
• 扩展预期:一年内会不会增加场景或使用人数。

现场部署适合人数不多、希望设备就在身边的情况;机房部署适合并发较高、需要稳定供电和网络的情况。并发和响应要求怎么换算成算力,可以参考私有化部署大模型算力怎么估一文中的三个变量。

四、人员与运维:谁提问、谁复核、上线后谁管

很多项目卡在上线之后:没人更新资料,没人看异常记录,回答慢慢变旧。需求里建议写清三类角色:

• 使用者:哪些部门、哪些岗位可以提问,权限是否按部门区分。
• 复核者:哪些类型的回答必须由人复核后才能使用,复核人是谁。
• 运维者:上线后模型更新、知识库资料更新、账号权限调整分别由谁负责,是企业自己,还是服务商,还是双方分工。

常见漏项是知识库资料更新。制度改版后没人同步,AI 就会继续按旧版回答。三条线怎么分、交接时要交哪些东西,可以参考企业AI上线后运维谁来管中的交接清单。

五、验收:可测的标准与抽检方式

验收标准如果写成「效果良好」「满足业务需要」,交付时就只能靠主观感受。建议写成能测的条目:

• 测试题集:用场景一节里的典型问题扩充成一组测试题,约定回答正确、给出出处的比例要求由双方在测试后商定。
• 响应表现:在约定并发下实测响应时间,是否达到算力一节写下的要求。
• 数据与权限:不入库的资料确实没有入库;不同部门账号只能看到各自范围的内容;调用记录能查到。
• 复核抽检:上线后按固定频率抽查一定数量的回答,由复核人记录问题并反馈。

常见漏项是抽检方式。验收当天的表现只代表那一天,写进需求的抽检机制,才能让后续质量有人盯着。

法律、财税等场景:把 AI 的边界写进需求

如果场景涉及法律、财税、合规这类需要专业判断的工作,需求里要单独写一句话,明确 AI 的职责范围:AI 只做资料整理、初步审核、风险标记与提示,关键判断与确认由专业人员完成。

写进需求有两层作用。对内,它提醒使用者不要把 AI 的输出直接当结论使用;对外,它约束服务商的方案设计,比如界面上要标出哪些内容是 AI 生成的提示、哪些需要律师或会计复核,复核留痕放在哪里。没有这句话,方案很可能被设计成「AI 直接出结论」,看起来省事,实际上把风险转给了使用者。

拿到方案后,按清单逐项对照

需求写好、发给几家服务商之后,收回来的方案可以按下面的清单逐项检查。不需要比较厂商名气,只看每一项有没有正面回答:

1. 场景:方案是否针对你写的那个场景,有没有用你的典型问题做过演示或测试。
2. 数据:是否说明了原始资料、索引和调用记录各放在哪里,不入库的资料如何排除。
3. 算力与部署位置:配置是否从你的并发和响应要求推算出来,有没有说明推算依据;部署在现场还是机房,对场地有什么要求。
4. 人员与运维:上线后的模型更新、资料更新、权限调整分别由谁负责,服务商提供哪些支持,交接时交付哪些文档。
5. 验收:是否同意用你的测试题集和抽检方式验收,有没有补充自己的验收项。
6. 边界:在专业场景里,方案是否体现了 AI 只做整理、初审、标记与提示,复核留痕是否可查。

某一项回答含糊,就把它列为追问问题,在下一轮沟通时请对方补充。几轮下来,各家方案的差别会比单纯听介绍清楚得多。

一个可对照的交付范围示例

为方便对照,这里以润迅的 MaxDeploy 为例,说明一份交付方案通常会覆盖到哪些层。它的基础分三层:硬件上,R30 AI 一体机放在客户现场,R500 AI 服务器用于机房级的高性能算力;系统上是 XunOS(AI 操作系统);模型上是 MaxModel,负责模型的统一管理、多模型路由和调用审计。在这三层之上,运行企业知识库 MaxKnow 和统一管理产品 MaxControl。

把它放回五项需求里看:部署位置对应 R30 与 R500 的选择;数据与调用记录对应 MaxKnow 的知识管理和 MaxModel 的调用审计;运维和权限对应 MaxControl。这只是一种组织方式,你拿到的任何方案,都可以按同样的方法逐层对上自己的需求。

行动建议:本周就可以开始的三步

1. 召集一次半小时的会:业务负责人、IT 负责人和一位未来的复核人坐在一起,选定一个场景,写下五到十个典型问题。
2. 按五项填完一页纸:写不清的地方标「待确认」,不必等全部想清楚再发出去。
3. 发给服务商并逐项对照回复:用上文的清单检查方案,把含糊之处列成追问。

如果希望拿一份完整的交付范围做参考,可以查看 MaxDeploy 交付方案,也可以拨打润迅业务热线 400-854-5566,带着这页需求直接沟通。

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