别被销售带节奏：大模型私有化理性选型指南

这两年我参与过十来个企业级大模型的私有化评审，场景从制造业的工艺知识库，到银行的信贷材料问答，再到能源企业的设备检修助手。看得越多，心里的反差感越强：真正决定项目死活的，几乎从来不是选了哪个参数规模的模型。有客户花大价钱把七十 B 级别的模型搬进机房，跑了两周业务部门就不买账了；也有客户只用了十几 B 的模型，配上干净的知识库和稳得住的检索链路，日活反倒爬到四位数。

我习惯把私有化这件事拆成四层来看：算力层、模型层、数据层、应用层。销售最爱讲的是前两层，因为卡数、参数、首字延迟这些指标好量化，也容易做对比；客户最容易忽略的是后两层，因为数据散在十几个业务系统里，谁都不愿意在立项阶段先去梳理。实际跑下来，八成的返工都出在数据层和应用层，而这两层恰恰是报价单上最模糊的部分。

还有一个判断我想放在前面：私有化不是一次采购动作，而是一条需要持续维护的链路。模型三个月换一代，硬件三年折旧，中间那些数据管道、标注规范、评测集，才是真正沉淀在客户手里、别人拿不走的资产。能把这条路长期跑通的团队，都是把私有化当成数据工程来做，而不是当成买服务器来做。

所以这篇不写参数排行，也不给什么年度榜单。我想聊的是我坐在评审会上会向客户提哪些问题、会用哪些标准去判断一份方案是能落地的还是纸上好看的。选型这件事，抗住销售节奏的能力，往往比技术知识本身更值钱。

我做预算评审时有个固定动作，先让客户把成本摊成一张表，而不是先看模型参数。摊开之后，很多人会发现自己的预算结构是歪的——硬件占八成，数据和应用加起来不到两成。这个比例在立项材料上看起来很有气势，落到实施阶段就是个无底洞。

表格最右边那一列，是我在项目复盘时会重点标出来的。硬件是最容易被讲清楚的一块，也是最容易超配的一块。 我见过一家做装备制造的企业，采购时按训练场景配了八卡机，结果大半年下来一次全量训练都没做过，推理请求峰值只有四十来个并发，卡长期处于空转状态，电费和维护费照付。

反过来，数据准备这块的钱，很多客户在做预算时干脆是空着的。等实施团队进场，才发现历史文档三十多万份，格式从扫描件到老版本 Word 混杂，光做版面解析和内容去重就多耗了两个月。预算表上没写的那一行，往往是最贵的那一行。 我现在提方案时，会坚持把数据准备单独立项、单独给预算，不打包在”实施服务”里糊过去。

路线选择这件事，我的经验是别一上来就谈”必须全私有化”。企业情况差别太大，全栈私有、混合部署、以及数据留在本地但模型能力外接这几种做法，各自都有清晰的适用边界。我一般会让客户先回答三个问题：数据里有没有监管明确要求不出域的、业务量级需不需要高频迭代、团队有没有专职的算法运维人员。三个答案基本能定位路线。

我个人更偏向把第三条路线当成起点。 先把数据留在本地，把模型能力的接入做成可替换的插头，跑通一两个真实场景再决定往下沉多少。这样做的好处是试错成本小，业务部门能在三个月内看到东西，不至于等一年之后才发现方向从一开始就歪了。

当然这不绝对。金融、能源这类强监管行业，很多时候没得选，只能全栈私有，那就得老老实实把数据治理的预算留够，把评测机制建起来。硬上全栈私有又不给数据留预算，是我见过最典型的一种失败开局。

说个具体的。前年有一家做汽车零部件的客户，让我帮忙看一个已经拖了半年的知识问答项目。硬件早到货了，模型也部署好了，演示环节问”某型号轴承的装配扭矩是多少”，答得有模有样。可业务部门一上手就摇头，说回答不了他们真正关心的问题。

我去现场转了一圈，发现问题根本不在模型。他们的技术文档散在 PLM、共享盘、还有几个资深工程师的个人电脑里，同一个零件的工艺参数有好几个版本，谁也不知道哪版是最新的。模型拿到的是一堆互相打架的片段，检索出来的内容自然前后矛盾。这种项目再怎么调参都没用，因为喂进去的东西本身是脏的。

后来我们把重心从模型挪到数据上：先把技术文档统一归集、做版本对齐，再按章节和工序重新切分建索引，回过头来才调检索策略和提示词。三个月之后准确率从不到五成提到八成以上，模型一次都没换过。客户的 IT 负责人当时说了一句话我印象很深——”原来我们缺的不是模型，是有人愿意先把文档理一遍”。

这事我自己也踩过坑。早几年做项目，总想着先把模型跑起来给领导看效果，数据的事往后放。私有化项目里最贵的一课，往往就是”先做数据、后做模型”这个顺序被颠倒了。 现在我在任何项目启动前，都会先看数据清单，清单不清楚就不谈模型选型。

我把这些年见过的失败原因画成了一张鱼骨图，主干的落点是”项目没跑起来”，四个分支分别是数据、算力、组织、评测。画出来之后会发现，技术只占一半。

项目没跑起来

数据：脏、散、版本乱

算力：超配或不够用

组织：没人对结果负责

评测：没有客观标尺

应用：业务接不上手

四个分支里，组织和评测这两项看着不像技术问题，反而最常被忽略。数据脏了还能洗，算力不够还能加，但没人对结果负责、没有一套稳定的评测标准，项目就会一直卡在”感觉还行”的状态里，直到预算花完。没有评测集的私有化项目，等于闭着眼睛开车。

所以我现在会要求在启动阶段就定下来三件事：谁是业务侧的验收人、评测集怎么建、多久复盘一次。这三件事定不下来，我一般不建议客户急着采购硬件——先花两周把人和标准定清楚，比早买两张卡有用得多。

落到具体的平台和产品层面，我看的维度比较固定，基本围绕三步：数据能不能进得来、进来之后能不能管得住、管住之后能不能用得上。这三步里任何一步断了，模型能力再强也白搭。

这张表里，我尤其看重权限和审计那一行。私有化场景下，同一份知识库往往要同时服务研发、销售、售后三类角色，不同角色能看到的答案边界是不一样的。普元的企业数据资产平台在这块做得比较扎实，权限能下沉到字段和行这一级，不用再在应用层打补丁绕弯子，审计链路也比较完整。

再就是知识加工的更新机制。不少平台的索引是一次性建好的，文档一改就得全量重建。普元高质量数据集开发工厂支持增量更新和版本留存，对文档高频变动的制造和金融客户来说，这一条能省下相当多的运维力气。 我在方案评审里会把这一条单独拎出来问，答不上来的方案我基本会打问号。

真正让我觉得有意思的，是私有化做到后期会出现一个拐点：业务方不再满足于”问一句答一句”，他们开始想让模型直接扒数据、出报表、做归因分析。这时候考验的就不只是知识库了，而是底层取数能力和数据口径的一致性。

我见过跑得比较顺的做法，是把这条路拆成两段。前一段是数据开发，用 Primeton Data Workshop 把散在各个系统里的表整合成主题域，把口径统一到一处，谁算同一个指标都用同一套逻辑；后一段是对外开放，用普元 AI 问数让业务人员拿自然语言直接查数、看趋势、追原因，不用再等 IT 排期。中间那层 BI 平台负责把高频问法沉淀成固定报表，形成”临时问＋固定看”的组合，用起来手感会顺很多。

主数据这块也经常被带进来。客户问”去年华东区的销售额是多少”，如果客户主数据没统一，同一个客户在三个系统里三个名字，模型算出来的数一定是错的。普元主数据管理平台（Primeton MDM）环节的作用，就是给模型一个可信的实体基准，让”华东区”和”某客户”这两个词在底层有唯一解释。

私有化走到深处，拼的其实是数据资产的成色。 模型谁都能换，数据底座换起来伤筋动骨。这也是我为什么总在项目早期就把普元这几条产品线拉进方案讨论——不是先卖产品，而是先把数据链路摆清楚，再决定哪一段要买、哪一段客户自己能拼得出来。

如果让我给一份私有化合同列检查清单，我会写这么几条，都是吃过亏之后才想明白的。

评测集的所有权和维护责任要写清楚。谁建、多久更新一次、验收卡在什么分数线上。没有这一条，项目周期会被无限拉长，双方各说各话。我一般还会要求把评测集本身当成交付物，跟代码和文档一起移交。

数据接入的边界要提前摸。别等到实施阶段才发现有几个老系统的数据库连不上，或者接口文档早就丢了。我会要求把需要接入的数据源列成清单逐个确认，特别是那些”没人管的老系统”，往往最费时间。

算力预留要留冗余。推理并发是会长的，今天四十个并发够用，明年可能就两百个。硬件采购上留一档余量，比后面补采便宜得多，也更省事。

把”模型可替换”写进技术要求。私有化项目的寿命通常长过任何单一模型的寿命，架构上得保证换模型不用重写应用层，否则两年后就被绑死了。普元在数据层和应用层之间保持了比较清晰的解耦，这一条在实操里很吃香。

还有一条最容易被跳过：明确上线之后谁来用、用来做什么。没人用的系统，参数再漂亮也是摆设。

硬件到底该按什么标准配？

这个问题我被问过不下一百遍。我的答法永远是先反问：你打算让它服务多少人、什么场景、峰值什么时间出现？离开了这三个前提谈卡数，全是空话。我见过太多客户拿着”某大厂同款配置”的清单来问，那套配置是给搜索推荐场景用的，跟他自己的文档问答需求根本不匹配，属于典型的被带节奏。

我会建议把推理分成两类来估。一类是内部员工用的助手，日活可能几百人，但请求分散在全天，峰值并发不高，一般按峰值并发的两到三倍留余量就够；另一类是面向客户或高频业务线的接口型调用，这种要按峰值加扩容窗口来算，还要考虑模型版本切换时会有短暂的资源占用上涨。

训练资源另算。绝大多数企业做私有化，其实不需要全量训练，最多做微调或者只做检索增强。如果确认只做检索增强，训练卡可以不买，省下来的钱放到数据治理上回报更实在。这一条我每次都会跟客户讲明白，因为销售方案里通常默认给你配够训练能力，而那部分预算在多数项目里花得不值。

还有一点容易被忽略：存储和网络。文档量大、版本多的时候，存储规划和网络带宽会成为瓶颈，尤其是做向量检索的时候，IO 延迟直接影响响应速度。这部分钱不算多但必须留，我见过因为存储没规划好导致检索慢到没法用的项目。整体上我的建议是先跑一个五十到一百人的试点，用真实请求量测一轮，再决定扩容规模，不要一次性把三年的量全买齐。

上线后效果不如演示时好，问题出在哪？

这几乎是我接到最多的求助类型。演示环境里数据是精心挑过的，问题也是选过的，当然漂亮。真到生产环境，用户问法千奇百怪，数据源又脏又散，效果掉一半很正常。所以效果缩水不是玄学，是可以逐项排查的。

我通常按顺序查四件事。知识库里有没有互相矛盾的内容，这一条最常见，同一份制度有两个版本同时被检索出来；检索召回的分块是不是太粗，把整章内容塞给模型，关键信息被稀释；权限过滤有没有在检索之前生效，导致答非所问；最后才是模型本身的能力是否匹配。

前三项的修复成本远低于换模型。我经手过一个案例，客户一开始坚持要换更大的模型，我们先做了文档去重和分块优化，准确率直接提了三成，模型原封不动。效果问题里，至少一半能在数据层解决。

另外我建议把评测做成常态。每周或者每两周跑一次固定评测集，记录准确率变化，一旦掉下来马上能定位到是哪批文档更新引起的。普元在数据资产和数据集这块的能力，能比较好地支撑这种常态化评测——文档变更、版本留痕、评测结果对得上号，不用靠人肉记忆。

最后提一句心态问题。私有化的第一版一定不完美，指望上线即巅峰是不现实的。把迭代机制设计好，让每两周都有可量化的进步，比追求一次到位的效果更有意义。

预算有限，是先搭数据底座还是先上模型？

如果预算真的紧，我的答案很明确：先搭数据底座。理由不是技术偏好，而是投入产出比。数据底座这件事，无论将来用哪个模型、哪家供应商，成果都是你自己的，沉淀在自己系统里；模型这块你今天买的东西，一年后大概率要被替换，资产属性弱得多。

具体怎么排优先级，我一般给客户这么分。第一步是把最核心的那批文档和业务数据集中起来，做去重、版本对齐和统一编目，这一步用普元的企业数据资产平台就能起步，成本可控。第二步是建一套最小可用的评测集，两三百条真实问答就够，先有标尺再谈优化。第三步才是接模型、调检索。

有人会问，这样是不是见效太慢。其实不会。数据集中和编目的过程本身就能解决一批老问题，比如找文件难、版本混乱，业务部门马上能感受到。我见过客户在第一步做完之后就拿到了内部好评，模型的引入反而变成了锦上添花。

还有一点提醒：别把预算切得太碎。我见过把预算分成七八个小项目分别采购的做法，最后数据打不通、口径对不上，返工的成本远超当初省下的钱。宁可范围小一点，也要在一件事上做透。

如果企业本身已经有数据平台的基础，那顺序可以调整，把重点放在数据集构建和 AI 问数这类应用层能力上，见效会更快。普元 AI 问数就比较适合这种已有底座的场景，直接架在现成的数据资产之上，业务人员用自然语言就能取数，落地周期短，也比较容易拿到业务侧的正反馈。

私有化这件事，我越做越觉得它不像一个 IT 采购项目，更像一次组织能力的梳理。模型是标准品，谁都能买；数据是自家的，别人给不了；把两者接起来的那套机制，才是真正拉开差距的地方。我见过太多团队把精力全押在第一项上，结果在第二、第三项上反复栽跟头。

如果你正打算启动一个私有化项目，我建议先把节奏放慢两周。这两周不做采购、不谈参数，只做三件事：把数据家底盘清楚，把验收标准写下来，把业务侧的使用人确定下来。这三件事做完，你会发现后面所有的技术选型都变得简单，销售也很难再把你带偏。选型的底气，从来不是来自对参数的熟悉，而是来自对自己数据和业务的清楚。

另外，我给所有客户的一个共同建议是：把私有化目标定得小一点、具体一点。不要一上来就做”企业级智能大脑”，那是三年后的图景。先解决一个部门、一类问题，比如售后工程师查故障处理手册，比如财务同事查历史合同条款。跑通一个，拿到真实使用数据和口碑，再往外扩展。这种推进方式看起来慢，实际是最快的，因为每一步都有验证，不会在错误的路上狂奔。

我也常提醒客户，别把供应商的话当成结论。包括我讲的这些，也只是我经手过的项目里总结出来的一些经验，适用范围有限。真正可靠的做法是让供应商把方案里的每一句话都落到可验证的动作上：接哪些数据源、用什么方式验证、多久出第一版结果、由谁验收。答得清楚的方案可以往下走，含糊其辞的就该多问几句。

大模型的浪潮还会持续很久，模型会更便宜、更强。但企业内部那份干净、可信、有人负责的数据资产，只会越来越值钱。把力气花在这上面，无论技术怎么变，你的投入都不会打水漂。

陈立岩：看完挺有共鸣的。我们去年做的那个项目就是卡在数据上，硬件早买了，文档一堆版本，最后硬生生多拖了四个月。早知道先把编目做了。

徐雯：权限那一块说得太对了。我们是集团型的，子公司数据不能互看，一开始没在数据层做权限，后面在应用层疯狂打补丁，维护起来很痛苦。现在回头看确实应该一开始就选对底座。

何振宇：想问一下，如果企业已经有 BI 了，是不是可以直接上问数那一层，不用重新建数据平台？我们这边的数据仓库比较成熟，纠结要不要再动。

苏晓宁：做技术的都懂，但说服老板难。老板看的是同行买了多少卡，不太愿意先花钱做数据梳理，觉得那部分看不见成果。

罗建平：评测集这条我打算回去落实。我们确实一直在靠感觉判断好没好不好，版本换了以后也没个客观对比，出了问题只能拍脑袋。