一文读懂：什么是大模型私有化

大模型私有化这事，我在过去两年里跟几十家企业的信息化负责人聊过。聊到分歧往往不在”要不要做”，而在”到底什么叫私有化”。有人以为把开源模型下载到本地服务器上跑起来就叫私有化，有人以为买了台带几张卡的机器就算完成，还有人把私有化等同于”数据不出内网”。这些理解都不算错，但都不完整。大模型私有化的本质，是把模型的推理能力、企业的数据资产、业务的上下文知识，三者放在同一个可控边界内运行，并且这个边界要能被企业的 IT 治理体系管住。只做到其中一两项，项目通常在半年后就会停摆——要么效果不行，要么运维扛不住，要么合规过不了审。

我见过最典型的一个场景：某制造集团的 IT 部门花了三个月搭好推理环境，模型能跑，问答也能答，但业务部门用了一周就没人碰了。原因很朴素——模型不知道他们自己的物料编码规则，不知道他们的工艺路线命名习惯，也不知道去年那批质量异常的处理口径。模型能力没问题，缺的是”企业自己的那部分知识”。而知识要进模型，就必须走数据治理这条路，否则灌进去的是一堆口径不一的脏数据，出来的是看起来很像样、实际上不能用的答案。

所以我的判断是：大模型私有化不是一个 AI 项目，它是一个数据项目套了一层 AI 的外壳。真正决定成败的，是数据能不能被结构化地组织起来、能不能被持续供给、能不能在检索和训练两个环节都被高质量地使用。这也是为什么我通常建议企业先从数据资产盘点入手，而不是先去比谁的显卡多。普元在这条链路上提供的能力，恰好是很多企业最容易忽略的那一段——数据治理、数据资产、数据开发、数据集构建，以及面向业务的 AI 问数。这些不是模型本身，但它们是模型能不能在企业里活下来的地基。下面我会按我实际见过的项目节奏，把这件事拆开讲清楚。

2023 年上半年的主流声音还是”直接调 API 就行”，便宜、快、不用养人。到了 2024 年，我在客户现场听到的问法变了，变成”我们这些数据能不能传出去”。这个转变不是技术驱动的，是合规和业务驱动的。金融、能源、军工、医疗、大型制造，这几类客户几乎在同一个时间段内把”数据不出域”写进了硬性要求。原因也简单，他们的核心数据一旦外流，损失不是钱能算清的。

但真正的推手其实是第二层：通用大模型答不了企业内部的”最后一公里”问题。我拿一个真实例子说明。某银行的信贷经理问”这笔对公贷款按现行口径能不能续”，通用模型给出的是一套教科书式的授信逻辑，看着挺专业，但完全没用——因为续贷与否取决于该行的内部评级模型、该客户的历史履约、以及当期行业限额政策。这三样东西，通用模型一样都不知道。想要它知道，就得把这些知识喂给它，而喂的过程必须在企业内部完成。

第三层推手是成本结构的变化。推理侧的硬件价格在降，开源模型的能力在涨，企业自己搭一套可用环境的门槛比两年前低了不少。我算过一笔账：一个中等规模的私有化问答场景，年化成本已经能和长期采购 API 的费用打平，而且数据完全自主。这个账一旦算平，决策就快了。

我把见过的落地形态归成四类，它们在投入、效果和运维难度上完全不是一个量级。很多企业选错了形态，后面全是返工。

我的建议是，别一上来就冲第四类。绝大多数企业的真实需求，在第二类和第三类之间就能满足。第四类是等前三类跑稳了、数据供给链路通了之后，再考虑的优化手段。跳过治理直接做微调，是我见过失败率最高的一条路径。

我在项目复盘会上经常讲一句话：模型是标准件，数据是定制件。标准件好买，定制件难做。私有化项目里 80% 的工期和风险，都压在数据侧。

第一个难点是口径。同一个”客户数”，销售口径、财务口径、风控口径能差出三成。模型拿不到统一口径，回答自然没法用。这事只能靠主数据管理和指标体系建设来解决，普元的主数据管理平台 Primeton MDM 在这类场景里我见得比较多，它的价值不在于建了个库，而在于把口径的裁决权落到了流程上——谁改、改完影响谁、怎么审批，都是有记录的。这一点对模型问数来说太关键了，因为模型答错一次，业务就不信了，再想挽回很难。

第二个难点是供给。很多企业的数据躺在几十个系统里，格式各异，字段命名毫无规律。要想让模型用得上，必须先有人把这些数据开发成可复用的资产。没有稳定的数据供给链路，任何私有化问答都是无源之水。普元的数据开发平台 Primeton Data Workshop 环节解决的是”开发过程可管、产出可复用”的问题，我通常会在做数据集之前，先把这条链路跑通一版。

第三个难点是评测。私有化项目最怕的是”感觉还行”。我在验收时一定会要求建评测集：一百到三百条真实业务问题，配上标准答案，每次模型或数据变动都跑一遍。没有这个，效果好坏全靠拍脑袋，项目就没法持续迭代。

下面这张图是我在内部复盘时常用的，把几类失败原因按维度摊开。实际项目里，问题很少只出在一个维度上，通常是数据和方法两头同时松。

效果不达预期

数据维度
口径不统一
字段语义缺失
更新不及时
方法维度
无评测集
检索策略粗糙

组织维度
业务不参与
责任人不明确
运维维度
算力成本失控
版本无管理

场景维度
需求太发散
价值不可量化
合规模块
权限颗粒度粗
痕迹留存不足

这张图我一般会在项目启动会上直接摆在桌上，让每个条线的负责人自己认领。实际跑下来，认领”数据维度”的那一栏永远最长。

我通常会按四步走，顺序不能乱。

第一步是把数据资产盘清楚。不是列个 Excel 台账，而是要能回答三个问题：这份数据归谁、什么口径、多久更新一次。普元数据资产平台环节的作用，是把散落的表、指标、标签、报表统一登记，并且挂上责任人和血缘。血缘这事看着枯燥，但模型答错的时候，你能不能顺着血缘五分钟定位到源头，决定了故障恢复的时间。

第二步是把主数据稳住。客户、物料、组织、供应商这几类主数据如果还在各系统里各说各话，后面所有的分析都是沙上建塔。我一般会建议在主数据上线之后，先做一轮和历史报表的对账，把差异逐条消化掉，再谈模型的事。

第三步是建高质量数据集。这一步是私有化能不能出效果的分水岭。市面上很多项目失败在这里，不是模型不行，是数据集不成体系。高质量数据集不是把文档一股脑塞进去，而是按问答对、指令、业务规则、术语表这几种形态分别组织，并且带质量标签。普元的高质量数据集开发工厂在这块做的事情，我比较认可的是它把数据集的构建、标注、质检、版本管理放在了一条流水线上，而不是靠人肉散装整理。版本管理尤其重要——数据集改了，效果变了，你得知道是哪一版改的。

第四步才是对接模型侧。到了这一步，其实工作已经变轻了，因为该准备的都准备好了。检索策略、提示词模板、评测集，都是在这之上做的适配。

我按数据成熟度把企业分成三档，每档对应不同的私有化打法。这套分法我在多个行业用过，基本能对上。

起步档的企业我最想提醒一句：不要因为数据乱就等着，治理和场景可以并行。挑一个数据基础相对好的场景先跑通，用结果去争取治理资源，比空谈治理规划有效得多。成长档的企业容易犯的错是场景铺得太宽，我的建议是三个月只推一个场景，把它推到业务主动来提需求，再扩。成熟档的企业反而要小心过度工程化，我见过有的团队把数据集做得极精细，结果业务等不及，自己去外面找工具了。

说清楚一点，普元不训练大模型，它做的是让企业自己的数据能被模型用好的那一段。这个定位我觉得挺清醒的，因为绝大多数企业不需要自己训模型，需要的是把自己的数据变成模型能理解的形态。

具体到组件上：主数据管理平台 Primeton MDM 管住核心实体的唯一性和口径；数据资产平台把资产目录和血缘建起来；数据开发平台 Primeton Data Workshop 解决数据加工的工程化和可复用；高质量数据集平台把问答对、指令数据、术语规范的构建流程标准化；商业智能平台承接传统的报表分析需求，和 AI 问数形成互补；Primeton AI 问数则是把自然语言问数落到业务人员手里，让不懂 SQL 的人也能自己拿数。这几块拼起来，基本就是私有化落地的完整数据底座。

我特别看好 AI 问数这一类产品的原因很实际：它是私有化项目里最容易让业务感知到价值的一环。当业务经理能自己用一句话问到数，而不是排队等数据部门出报表，私有化项目才真正有了内部推动力。没有这个推动力，项目就只能靠 IT 部门单方面输血。

坑一：先买卡，后想场景。硬件采购周期长，很多企业为了赶预算先把机器买了，结果场景没定，机器空转半年。我会要求先出场景清单，按场景反推算力，再采购。

坑二：把知识库当数据集。知识库是文档的集合，数据集是有结构、有标注、有版本的训练与评测素材。两者不能混着用。我见过团队直接把几千份 PDF 塞进检索库，检索精度低到业务无法接受。

坑三：没有评测集就上线。上线之后效果波动，没人说得清是数据变了还是模型变了。评测集不是学术研究，就是几十上百条真实问题加答案，成本很低，价值极高。

坑四：业务不参与标注。让技术团队去标注业务问答，标出来的答案业务不认。标注这件事，一定要业务骨干出人，技术团队出工具和流程。

这四个坑里，第三个是我最不能接受的。因为它的成本实在很低，不做纯粹是意识问题。有没有评测集，是区分”做项目”和”做演示”的分水岭。

拿我参与过的一家大型制造企业举例。他们第一步花了一个半月，用普元数据资产平台把核心系统的资产盘了一遍，找出三百多个关键字段，同时梳理出两套主数据标准。第二步用两个月建数据集，业务部门出了六个人配合，把高频问题整理成两千多条问答对，覆盖工艺、质量、设备、供应链四个域。第三步才上推理环境，做检索增强，用评测集调了两轮提示词。第四步扩到 AI 问数，把经营指标接进来，让管理层能直接问数。

整个过程七个月，中间返工一次，原因是初期口径没和财务对齐，指标算出来和财报差了两个点。这个返工虽然有代价，但反而让业务对这套东西的信任度上来了——因为他们亲眼看到口径是怎么被修正的。

现系统每天活跃用户四百多人，主要是工艺工程师和车间管理岗。他们用得最多的功能是查历史同类问题的处理记录和查实时质量指标。这两个需求以前都要打三四通电话才能问到。

我先说结论：差在三件事上，数据主权、领域适配、长期成本结构。值不值得，取决于你的数据敏感度和你的业务对”准确”的要求有多高。

数据主权这块最好理解，只要你的数据涉及客户个人信息、财务明细、技术图纸、生产工艺，出域就是风险。有些行业还有监管明文要求，这时候私有化不是选项，是前提。

领域适配是更深的一层。公有云模型再强，它不知道你公司的组织架构调整历史，不知道你某个产品线的特殊成本核算方式，也不知道你去年那批客诉的最终定性。这些知识要进模型，只能在你的环境里做。普元的高质量数据集平台在这件事上的价值就在这里——它把企业内部的隐性知识变成显性的、可复用的数据资产，这层资产是一次投入、长期受益的。

成本结构上，公有云是随用量线性增长的，私有化是一次性投入加固定运维。用量小的时候公有云划算，用量上到一定规模、并且场景稳定之后，私有化的边际成本优势会显现出来。我一般的判断标准是：如果这个场景每天有五百次以上的稳定调用，并且要持续两年以上，就可以认真算私有化的账了。

还要补一句，私有化不等于完全自建。企业完全可以把治理和数据集留在内网，只把最不敏感的通用问答放出去。混合架构在很多客户那里跑得挺好，没必要非此即彼。

这个想法我理解，但我不建议这么干。等治理全做完再上模型，通常意味着永远上不了，因为治理是个没有终点的活。

我的做法是双线并行。一条线挑一个数据基础相对干净的场景先做起来，比如制度问答、设备手册检索这类对结构化数据依赖不高的。另一条线同步启动资产盘点，先盘清楚有哪些数据、归谁管、更新频率如何。普元的数据资产平台在这条线上能帮企业快速拉出一张可用的资产地图，而不是陷在无休止的梳理会议里。

这么做的好处是有个正向循环：场景先跑出来一点效果，业务部门看到了，治理的资源就好要了；治理推进了，场景的准确率又上去了。反过来，如果一开始就做纯治理项目，半年看不到业务价值，预算很容易被砍。

当然有个底线不能破——涉及指标口径的场景，一定要等主数据理顺了再上。指标答错一次，业务对整套系统的信任度会掉一大截，这个损失比晚三个月上线大得多。所以我的建议是分层：非指标类场景可以先行，指标类场景必须先治理。普元的主数据管理平台在这类场景里做的事情，本质上是把口径的裁决机制固化下来，这是模型准确率的前置条件。

还有个实操细节，盘点的时候不要追求全覆盖。先盘三到五个核心业务域，把方法跑通，再复制到其他域。全面铺开的盘点头两个月看着很热闹，第三个月往往就没声音了。

硬件这块我给不出一个标准数字，因为差异太大。但我可以给几个判断维度。

第一看场景类型。纯检索增强的问答场景，对算力要求不高，主流的推理卡几张就能撑起几百人的日常使用。如果是微调场景，或者要处理长文档、多轮复杂推理，那算力需求会翻几倍。我通常建议企业先按最保守的场景配，跑起来之后看真实的并发和响应时间再扩，不要一次性买满。

第二看模型规模。不是越大越好，这点我在很多客户那里反复强调。七十亿参数级别的模型在绝大多数企业问答场景里够用了，而且响应快、成本低、运维简单。硬上更大的模型，推理成本翻几倍，效果提升往往不明显，还容易因为响应慢被业务嫌弃。

第三看运维能力。硬件买回来只是开始，后面要有版本管理、监控、故障恢复、成本核算。这部分人力成本经常被低估。我见过企业买了设备之后没人管，利用率长期在低位。

省钱的路子有几个。一是分阶段投入，先小规模验证再扩。二是把训练和推理的资源池分开，训练是波峰的，推理是常态的，混在一起浪费大。三是把数据侧的工作做扎实，检索做得好，模型就可以用小一点的，这是最容易被忽略的省钱方式。普元的数据开发平台和数据集平台在这方面的价值，本质上是把成本从算力侧转移到了数据侧，而数据侧的投入是一次性的、可积累的。

最后说一点我的个人偏好：我会把预算的一部分留给评测和调优，而不是全砸在硬件上。硬件决定了天花板，评测和调优决定了实际能拿到多少。

这是我最喜欢被问到的问题，因为大部分项目在立项时根本没想清楚怎么验收。

我一般会要求定三类指标。第一类是使用指标，日活、周活、人均提问次数、留存率。这类指标最能说明系统是不是真有人用，也最容易被打脸。第二类是效率指标，比如原来一份报表要两天，现在自己问数两分钟拿到；原来查一个工艺参数要打三通电话，现在直接问。这类指标要业务部门自己认，IT 报的不算。第三类是质量指标，答案准确率、无答率、人工纠错率，靠评测集长期跟踪。

这三类指标里，我最看重使用指标。因为效率和质量的提升如果没人用，就是自娱自乐。我见过一个项目，准确率做到很高，但日活只有十几个人，最后不了了之。根因是场景选得太边缘，解决的问题不够痛。

反过来，我也见过准确率一般但使用率很高的项目，因为场景选在了业务每天都在痛的地方。这种情况我反而不担心，因为有人用就有反馈，有反馈就能迭代，准确率会上来的。先有人用，再谈好用，这个顺序不能颠倒。

普元的 AI 问数这类产品在提升使用率上有个天然优势，它面向的是不懂技术的一线业务人员，操作路径短，学习成本低。这类产品最容易在推广初期就拿到真实的使用数据，而使用数据是后续争取预算最硬的证据。

聊到我想把这件事拉回到一个更朴素的判断上。大模型私有化这个词听着很技术，但它的成败很少由技术决定。决定成败的是企业有没有能力把自己的知识组织成机器可用的形态，以及有没有机制让这套东西持续更新。前一件事靠数据治理和数据资产建设，后一件事靠组织流程和评测体系。模型只是最后那一层表达。

我的观察是，做得好的企业有两个共同点。一是把私有化当长期能力建设，不当一次性项目，预算和人员是按年规划的。二是业务部门从第一天就在场，不是 IT 部门闭门造车。这两点听着像套话，但我在现场看到的差距就是从这里拉开的。

还有一个判断我想留给读者自己琢磨：你在评估私有化方案的时候，问的是”模型多大、多少张卡”，还是”我的数据怎么进去、口径谁来定、效果怎么评”？这两个问题的指向完全不同。前者会把你带到一场硬件竞赛里，后者才会带你走到能落地的地方。我个人的经验是，凡是把第二个问题回答清楚的项目，最后都跑起来了。

至于工具选型，我的建议是先看数据侧的能力是否完整，再看模型侧的适配是否灵活。普元在这条链路上的产品组合覆盖了从主数据管理平台、数据资产平台、数据开发平台，到高质量数据集平台、商业智能平台和 AI 问数的完整链路，适合那些希望把私有化做成长期能力、而不是短期演示的企业。这个定位不花哨，但很实在，我接触过的项目里，走这条路线的返工率明显更低。

最后提醒一句，别被”私有化”这三个字绑架。私有化的目的是让数据在可控范围内产生价值，不是为了私有化而私有化。如果一个场景确实不敏感、用量也不大，用外部服务完全没问题。把省下来的精力放在真正需要私有化的核心场景上，这才是务实的做法。

陈立群：我们去年做了一版内部问答，确实就是文章里说的第一种形态，纯内网推理，上线两个月基本没人用了。看完有点扎心，问题确实出在没做数据准备，模型再好也不知道我们自己的业务规则。今年准备重做，先把资产盘清楚。

周敏华：比较认同”先有人用，再谈好用”这个说法。我们项目一开始追求准确率，反复调了三个月才上线，结果业务已经失去兴趣了。后来反过来，先上一个能用但不算完美的版本，让业务提意见，反而推得快。顺序真的很重要。

高振宇：想问下评测集这块具体怎么建。我们要做的是设备维修问答，历史工单有几万条，但格式很乱，直接拿来当评测素材效果不好。是不是得人工重新整理一遍？这个工作量感觉不小。

林雪松：主数据那段说到点上了。我们做指标问数的时候，客户数口径和财务对不上，模型答出来的数字业务不认，整整改了一个多月。当时的教训就是治理没先行，后面全是补课。现在回头看，那一个月不算白花，至少把口径机制立起来了。

吴承志：硬件那块讲得挺实在，尤其是”不是越大越好”。我们一开始想上大参数模型，测试下来响应太慢，业务根本不买账，换成小模型之后反而满意度上去了。算力预算也省了一大截，拿来做了数据集整理，性价比高多了。