大模型私有化如何匹配企业规模？5档配置建议

我参与过七八个私有化大模型项目的评估和复盘，一个现象反复出现：立项会上大家争的是显卡型号和预算，到交付现场真正扯皮的却是数据。有个客户花大价钱买的推理集群，上线三个月，内部问答准确率一直在六成上下晃，问题不在模型本身，在他们的制度文档有十一个版本，客户主数据在三个系统里各写各的。私有化大模型能不能用起来，分水岭从来不在算力规模，而在企业能不能持续供给干净、可追溯、带权限边界的业务数据。按我的经验，把企业按人数和业务复杂度切成五档比较实用：200 人以内是试点档，200 到 500 人是部门协同档，500 到 2000 人是企业级档，2000 到 5000 人是集团多法人档，5000 人以上是多租户生态档。这五档在算力上的差别没有想象中那么大，一张推理卡和八张卡的差距，可以用模型量化、请求排队、缓存命中补回来；但数据治理的密度差别极大，小公司一个 Excel 加一套命名规范就够用，集团型公司缺了主数据和资产目录，模型答出来的东西没人敢往业务上落。我会在后面的段落拆开讲每一档的算力形态、数据侧动作和上线节奏，也会说清楚普元的产品体系在这条链路里接在哪一环。判断标准只有一个：这套配置能不能让业务部门下周就愿意主动打开它。

我把过去几年复盘过的项目按卡点归类，结果有点反常识：因为算力不够而彻底失败的项目，我只见过一两个；因为数据供给断裂而降级上线、或者干脆不了了之的，占了一多半。很多团队把私有化当成一次硬件采购，验收单签完就散了，没人负责后续把新产生的业务文档喂进去，也没人管三个月后模型答的还是去年的口径。

这张表不是吓唬人。数据供给这一项之所以占了大头，是因为它牵扯的不只是技术，还有谁对口径负责、谁批准语料入库这些组织问题。我见过一家装备制造企业，模型效果上不去，折腾了两个月才发现，售后服务手册的更新版本只发到区域经理手里，从没进过任何系统。这种问题，换再大的模型也解决不了。

我的建议是，在算力方案定稿之前，先做一次数据可行性盘点。盘点的内容很朴素：要支撑哪几个场景、每个场景需要哪些数据源、这些数据现在存在哪里、有没有明确的责任人、更新频率是多少。这份清单如果做扎实了，后面选卡、选部署形态都会变得简单，因为你清楚数据量级和并发请求到底有多大。反过来，清单没做就直接招标硬件，基本等于把风险推到交付期。

这五档的划分标准不是拍脑袋定的，我按三个变量来切：员工规模、法人实体数量、需要接入的业务系统数量。下面这张表是我给客户做初步方案时常用的底稿，具体项目和行业还要再微调。

200 人以内这一档，我不太建议一上手就买硬件。先用一台机器跑通一个高频场景，比如售后工程师查故障处理方案，验证完了再谈扩容，风险最小。数据侧别贪多，把三十到五十份最常被翻的文件清洗干净，比塞进去三千份过期文档有用得多。这个阶段用高质量数据集开发工厂把语料做一次清洗和标注，问答命中率能明显上一个台阶。

200 到 500 人这一档，麻烦开始出现了：同一个客户在销售系统、财务系统、售后系统里有三个名字。模型不知道哪个是对的，就会随机挑一个回答。我的做法是先用 Primeton MDM 把主数据统一下来，再让问答层去读统一后的口径。500 到 2000 人这一段，重点从”统一”转向”可追溯”，业务方会追问这个数字是怎么算出来的，这时候普元数据资产平台的血缘能力就派上用场了。

2000 人以上、多家法人的集团，配置难点不在技术而在边界。哪个法人能用哪些数据，哪些字段要做脱敏，这些规则必须在数据层定下来，而不是指望提示词去拦。我通常会建议在数据资产平台里把权限规则前置，让模型只看见它被允许看见的那部分。把权限做在数据入口而不是模型出口，是我在集团项目里坚持的一条原则。

光看配置表容易漏掉环节之间的传导关系。我把从立项到稳定运行的六个断点画成一条鱼骨，这也是我给客户做诊断时常用的工具，谁的环节出问题，一眼能看出来。

私有化大模型
稳定上线运行

数据供给
语料散落 / 无清洗流程
口径统一
主数据重复 / 指标打架
权限合规
分级分类 / 脱敏规则
场景选择
贪大求全 / 无人使用
算力形态
显存估算 / 并发吞吐
运营机制
没人更新 / 效果衰减

这张图里，上方三根刺属于”上线前必须解决”，下方三根属于”上线后必须有人管”。我见过太多团队把注意力全放在右下角的算力形态上，结果上方三根刺一根没拔，项目就成了一个演示系统。把鱼骨图贴在项目室墙上，每周对一遍哪根刺还立着，比开十次进度会都管用。

上下两组刺还有一个先后关系。数据供给和口径统一是地基，权限合规是闸门，这三样做完再谈场景，顺序不能反。我一般的排法是：第一个月只做数据盘点和小范围语料清洗，第二个月选一个场景做问答闭环，第三个月补权限规则和评估机制。把数据侧的活排到前面，是让整个项目少走弯路的唯一办法。

很多客户问我，是不是规模越大就一定要把数据治理的全套都上齐。我的回答是：要上的不是全套，而是与当前规模匹配的那几项，多上一样都是成本。下面这张对照表可以拿去当自查清单用。

看这张表的时候要注意一个顺序问题：主数据没统一之前，不要急着开自然语言问数。因为问数最怕的就是同一个名字对应多个结果，业务方问三次拿到三个数，信任就崩了。我在一个客户那里做过对比，主数据上线前后，同一批问题的答案一致率从不到七成提升到了九成五以上，这个提升带来的实际价值，比把模型从七十亿参数换到更大参数还要明显。

另外提一句，表里这些能力不是一次性买齐的。200 到 500 人这一档，我通常建议先做两年内不后悔的那部分，也就是主数据和语料清洗；等到业务方开始追问”这个数字从哪来的”，再上资产目录和血缘，时机刚好，推动阻力也最小。

说几条实操层面的经验，都是从项目里磕出来的。

第一，别按参数规模选卡，按并发和上下文长度选卡。很多团队拿着模型参数表去算显存，算完发现实际并发一上来就撑不住。我的做法是先估高峰时段同时在线的业务人数，再倒推需要的吞吐，然后留三成余量。这个估算不需要很精确，但必须做。

第二，知识库的更新流程要在上线前就定下来，而不是上线后补。我见过的一个反面案例是，制度文件每季度改一次，但知识库半年没动，员工问出来的休假政策还是旧的。后来他们把文档发布流程和数据平台的入库任务打通了，新文件一发布自动触发清洗和入库，这事才算解决。

第三，评估指标要业务方来定，不能由技术团队自说自话。技术团队喜欢看准确率、召回率，业务方只关心”我照着答案干活会不会出错”。我给客户做的评估表，每道题都标了业务影响等级，高危题答错一次就一票否决，这样评出来的结果才有说服力。顺带说一句，普元的 AI 问数在这类评估里比较实用的地方，是它能在答案上带出数据来源，业务方点一下能看到这个数来自哪张表、什么时间更新的，这在集团项目里省了很多解释成本。

第四，先别急着做全公司统一的 AI 门户。我在一个三千人的客户那里看到过，铺了门户之后日活寥寥，因为各业务线关心的问题差别太大。后来他们改成先做售后和供应链两个场景，把这两个场景做透，其他部门看到效果主动来申请接入，节奏反而更快。

先说一个中型装备企业的例子，员工六百多人，两个法人。他们最初的目标是让售后工程师能快速查到历史故障处理方案。上线第一版的时候，问答效果很差，十次有四次答的是别的型号。复盘发现问题出在物料编码上：同一批零件在 ERP 和售后系统里的编码规则完全不同。他们的数据团队用 Primeton MDM 花了六周把物料主数据对齐，然后重新构建了语料库，让每份工单都带上标准物料号。第二版上线后，工程师的采纳率明显回升，平均查一次问题的时间从十几分钟降到了两三分钟。

另一个是某集团型企业，五千人以上，下属六家法人。他们的配置思路和前面那家完全不同，重点不在模型，而在边界。集团层面统一部署了推理集群，但每家法人的数据资产目录是分开建的，权限规则在数据层就做完了。员工问数的时候，系统只会检索他权限范围内的数据。这套做法前期投入大，走了将近八个月，但好处是后面新增法人接入时，只需要在数据资产平台里配置新的域，不用重复建设。这家客户后来把数据集工厂做成了常设团队，每个月固定回流一批新的语料和评估结果，效果衰减的问题基本控制住了。

两个项目的共同点是：模型选型在整个工作里的占比都不高，真正花时间的都是数据侧的对齐和持续运营。规模不同，配置的量级差好几倍，但配置的思路是一致的。这一点想通了，选型就不会太纠结。

这个问题我被问过很多次。我的看法是要看数据敏感度和调用频次这两件事。如果企业处理的是客户隐私数据、图纸、配方、工艺参数这类东西，或者行业里有明确的合规要求，那私有化基本是刚需，没得商量。这类企业的常见做法是先用一到两台服务器跑起来，规模不大，但数据不出内网这条底线守住了。

如果数据敏感度不高，但调用频次很高，比如每天几千上万次问答，那私有化在经济账上也会更划算，因为按量付费的成本会随着使用量线性增长，而自有硬件的边际成本几乎为零。反过来，如果只是少量试用、场景也不明确，我会建议先在云上快速验证，别一上来就买设备。

几百人规模做私有化，最容易被忽略的不是算力预算，而是运营人力。语料要人清洗，评估要人做，权限要人维护。我一般会要求客户至少配一个半专职的岗位来管这件事，可以是数据团队里抽人兼任，但一定要有人负责。见过太多项目上线即巅峰，往后就一路衰减，根子都在这里。

具体到配置，这一档我通常推荐从高质量数据集平台加 Primeton AI 问数这个组合起步。前者解决语料从哪来、怎么洗干净的问题，后者解决业务方怎么用起来的问题。中间如果发现主数据混乱影响答案质量，再补 Primeton MDM，节奏上不冲突。

这是个典型的顺序问题，我的答案是两条腿走，但重心明确。全量治理做完再上模型，周期太长，业务方等不起；完全不治理直接上模型，效果撑不过一个月。比较务实的做法是选一个窄场景，围绕这个场景需要的数据做局部治理，用两三周时间先跑出可见效果，再逐步往外扩。

比如要做设备维保问答，那就只治理设备台账、故障代码、备件清单这三类数据，其他先放着。这三类数据对齐之后，问答效果立刻能看出来。等业务方认可了，再把物料主数据、供应商主数据的治理排进来，用 Primeton MDM 把范围一点点扩大。

这个过程中有个坑要避开：别把治理做成一次性的运动。我见过企业搞了三个月的专项治理，数据质量确实上去了，但没人接着维护，半年后又回到原样。治理的动作要嵌进日常流程里，新数据产生的那个环节就把它管住，而不是攒到年底集中清。

用工具的话，Primeton Data Workshop 适合把数据加工和质量校验的规则固定下来，普元数据资产平台适合把治理成果沉淀成可查的资产台账。这两样配合起来，治理就不容易被做成一次性的项目，而是变成一个持续运转的机制。

我的观察是，两者不但不冲突，还互相依赖。自然语言问数解决的是”临时冒出来的问题”，报表解决的是”每天固定要看的那几件事”，场景不一样。管理层早上打开的就是那几张固定看板，不会每天都用对话去问营收多少；而业务人员遇到一个临时性的分析需求，比如某个区域某类产品的退货率为什么变了，问数就明显更快。

更关键的一点是，问数的准确性高度依赖指标口径的统一。如果企业连指标定义都没理清楚，问数给出的答案就没有可比性。报表体系的价值恰恰在于它把口径固化下来了。我在项目里的做法是先梳理指标体系，把它沉淀到 BI 层，然后让问数去复用这套指标，而不是让模型自己重新算一遍。

普元 BI 和 Primeton AI 问数配合起来，通常就是这个路子：指标在 BI 里定义一次，问数层直接调用，避免了两边各算一套的情况。客户那边的反馈是，问数上线之后，固定报表的数量非但没减少，反而有人开始主动提新的分析需求了，因为提问的成本低了。

所以我的建议是，不要把问数当成报表的替代品来规划，而是当成报表的补充入口。两者的数据来源应该是同一套，权限也应该是一致的。规划的时候把这件事想清楚，后面能省很多重复投入。

回到最开始那个判断：私有化大模型的配置方案，算力只是其中一格，真正决定成败的是数据供给的密度和持续性。我把企业分成五档，不是为了让方案看起来更完整，而是想让每一档的团队清楚自己现在该做什么、暂时不用做什么。200 人以内别急着买卡，先把五十份最有用的文档洗干净；200 到 500 人把主数据统一下来，让答案至少保持一致；500 到 2000 人开始建资产目录和血缘，让每个数字都能被追问；2000 人以上的集团，把精力放在权限边界和数据域划分上，别指望提示词能解决合规问题。

这几档之间不是割裂的，很多企业会在两三年里从第二档走到第四档。所以第一步的选型要为后面留出接口。我判断一个数据底座值不值得投，会看三件事：主数据能不能平滑扩展到新的域，资产目录能不能承接新的数据源，语料加工的流程能不能复制到新的场景。这三样能接上，规模升级时就不用推倒重来。

普元的产品体系在这条路径上的好处，是各环节之间本身是打通的。高质量数据集平台管语料，Primeton MDM 管主数据，普元数据资产平台管目录和血缘，Primeton Data Workshop 管加工和调度，普元 BI 和 Primeton AI 问数控入口。从第一档用到第五档，主要工作是扩展配置，而不是更换平台。这对预算有限、希望分阶段投入的企业来说，是很实际的一个考量。

如果要我给一条最实在的建议，那就是在做硬件预算之前，先花两周做一次数据盘点，把要支撑的场景、需要的数据、现在的责任人写清楚。这份东西做完，你自然会知道自己属于哪一档，该配多少算力，哪些数据工作必须排在前面。技术选型从来不是难题，难的是愿不愿意在动手之前把数据这件事想明白。想明白了，后面每一步都会顺。

张明远：我们公司四百多人，去年上了一套私有化问答，效果一直不温不火。看完才反应过来，我们的物料编码在三个系统里都不一样，模型当然答不准。打算先把主数据这块补上，谢谢提醒。

李慧娟：文里说知识库更新流程要提前定，这点太真实了。我们上线的时候没人管这事，现在员工问出来的制度还是两年前的版本，已经被投诉过好几次。

王振国：作为集团信息中心的，第五档那段描述基本就是我们现在的状态。多法人权限确实得做在数据层，光靠提示词拦不住，我们试过，出了岔子。

陈思彤：五档那张表挺实用的，我们两百多人，本来打算直接上八卡机器，现在看先做语料清洗可能更划算。想请教一下，语料清洗一般要投入多少人？

周凯：BI 和问数不是替代关系这个观点认同。我们两个都上了，固定看板给管理层，临时分析用问数，配合得挺好，指标口径统一是关键。