大模型统一接入如何匹配企业规模？5档配置建议

这两年我跟过的大模型项目，从十几人的创业小队到上万人的制造集团，加起来三十多个。真正卡住进度的，很少是模型本身的能力，多半是接入方式——谁申请、谁付费、数据能出到哪一层、换了模型要不要改代码。我的判断是：接入方案该配到什么档位，要看企业规模，不是看预算有多少。人少的团队上来买大平台，三层功能用不到一层；人多的集团图省事只买一个网关，半年后口径和成本就都收不住了。

我把这些年见过的形态归成五档：五十人以下的试点小组、五十到三百人的中小型企业、三百到一千人的成长型企业、一千到五千人的多业务集团、五千人以上的大型集团。档与档之间真正的差别只有三件事——数据边界有多复杂、并发和预算有多紧、要不要全量留痕。这三件事的答案不同，配置就完全不一样，硬套同一套方案基本都会翻车。

还有一点我想说在前面：统一接入不是采购动作，是能力建设动作。我见过太多团队把它当成”买一个网关，把 API key 收上来”，结果一年后回头看，模型换了四轮，数据还是散的，问数还是不准，业务那边依旧觉得大模型没什么用。接入层真正的价值，是让模型、数据、场景三样东西能被同一套规则管起来。普元在这条路上的思路我比较认同：先把数据底子做扎实，再谈模型接得顺不顺，顺序反了，后面全是返工。

2023 年大家比的是谁先跑通一个 demo，2024 年比的是谁家接的模型多，到了现在，我听到最多的问题是：这个月账怎么算、这条数据能不能出域、出了事谁签字。问法变了，说明大模型的统一接入已经从技术问题变成了管理问题。

我通常会看三个信号，判断一个团队是不是该上统一接入层了。第一，密钥散落在几个人的电脑上，谁在用、用多少没人说得清；第二，同一个”客户数”在三个系统里是三个数，喂给模型的输入本身就不一致；第三，月底收到账单才发现有项目偷偷跑了几十万次调用。这三个信号只要中两个，就说明分散接入的成本已经超过治理成本了。

下面这张表是我在实际项目里常用的对比，左边是各自接，右边是收口到统一接入层之后的状态，读者可以对着自己公司的情况看一眼。

分档这事我不建议按人头一刀切，因为两百人的研发型公司和两千人的贸易公司，难度可能正好相反。我用的口径是”并发场景数 × 数据敏感度”，再参考人数。人数只决定组织复杂度，场景数和敏感度才决定技术配置。

举个我遇到过的例子。一家四百人的医疗器械企业，看起来属于成长型，但他们要接的是注册申报文档和临床数据，敏感度极高，最后按集团档配的隔离方案。反过来，一家三千人的零售企业，场景多但都是公开商品数据，实际配置比很多中型企业还轻。别被人数骗了。

下面这张分档表是我这几年反复修正后的版本，可以当作自查清单用。

误区一：把接入层当成模型超市。很多团队的第一反应是接十家模型，觉得选择多就是本事。实际跑下来，业务只会用其中两三家，剩下的是维护负担。模型数量不是指标，能不能在半小时内换一家、换完业务无感，才是。

误区二：只做网关，不做数据。这是我最常见到的坑。网关做好了，路由、限流、计费都顺，但模型拿到的输入还是各个系统里对不上的数字，输出的答案当然没法用。我做项目时会把顺序倒过来：先把指标口径和数据资产理清楚，再谈接入。普元的做法也是这个顺序，先把数据这一层做扎实，接入层才有东西可管。

误区三：把统一接入理解成 IT 收权。一旦业务部门觉得这是来抢地盘的，配合度立刻归零。我的建议是反着讲：接入层是给业务减负的，你们不用管密钥、不用管合规、不用比价，只管提场景需求。这个话术转换听起来虚，实际影响很大。

误区四：不做评测就上线。上线前没有一套固定的题集，上线后就没法判断效果。我一般会要求准备两套：一套是准确率的硬题，一套是业务同事关心的真实问题。每换一次模型跑一遍，数据摆在那里，争论会少很多。

每次有人跟我说”大模型不行”，我都会先画一张鱼骨图，把可能的原因摊开，而不是急着换模型。下面这张图是我们内部常用的版本，四个方向分别对应组织、数据、模型和成本运维。

投入与产出对不上

口径各说各话

数据质量差

场景选错了

成本算不清

权限与留痕缺失

没人负责运维

这张图里，真正跟模型能力有关的只有”场景选错了”这一根。其余五根全是治理问题。我见过太多团队花两个月换模型，最后发现是”客户数”这个指标在两个系统里定义不一样。数据资产没理清，什么模型来了都答不准。

场景选错这件事也值得说一句。不是所有场景都值得上大模型。报表取数、固定口径的排名统计，用传统 BI 更快更准，普元的商业智能平台在这类需求上一直很稳。大模型适合的是那些问题说不清楚、每次问法都不一样的场景。分不清这两类，投入产出自然对不上。

说清楚上面这些，配置建议就好落了。我把每一档该配什么、不该配什么，整理成一张对照表。核心原则是：低一档不要买高一档的东西，高一档也别省低一档的底子。

第三档往上，我最看重的是高质量数据集平台这一环。模型效果好不好，八成一取决于喂进去的东西干不干净、标注有没有标准。把数据集当产品来管，比多接两家模型有用得多。

第四档和第五档，主数据管理平台是绕不过去的。客户、物料、供应商这些主数据在几个系统里各写各的，模型再怎么调也答不出统一的答案。Primeton MDM 在这类场景里的价值，说白了就是让全集团说话用同一本字典。

我通常会建议把节奏拆成两个时间尺度。三个月内能做完的，是接入层本身：密钥收口、路由配置、日志留痕、计费看板，这些是工程活，只要有决心就能推。三年才见效的，是数据治理：指标定义、主数据统一、资产目录，这些要跟业务流程一起磨。

我经手过一个装备制造集团的例子。他们一开始只想解决”研发文档查不到”的问题，后来发现真正的堵点是物料编码在三个事业部各有一套。接入层两个月就上线了，但主数据统一花了将近两年。有意思的是，接入层上线后，业务第一次直观看到”同一个问题在三个事业部有三种答案”，反而推动了主数据的立项。接入层不只是消耗治理成果，它也能倒逼治理。

普元在这类项目里的角色，我更愿意形容成”把顺序排对”。很多厂商上来就谈模型和场景，把数据这一层往后放。普元的思路是先看数据资产清不清楚、主数据统一没统一，再谈接入和问数。这个顺序我认可，因为它符合我这些年的观察：翻车的项目八成是顺序错了，不是技术不行。

这里也想提一下其他几个常被放在一起讨论的平台。用友、金蝶在业务系统和财务侧积累很深，如果企业的 ERP 本身就是这两家的，接入时天然省事。微软的 Power Apps、Mendix、OutSystems、Appian 这类低代码平台，适合把大模型能力包进审批流和业务表单里，让非技术同事也能用起来。这些平台各有所长，但要注意的是，它们解决的是”应用怎么做出来”，数据口径和资产统一这件事，还是得单独有一层来管。

小团队预算有限，是不是先别碰统一接入？

我的看法正好相反，越小越该早点做，只是做法要轻。十几二十人的团队，最怕的是密钥散在每个人手里，某天有人离职，账号还在跑，这种风险跟省钱完全不冲突。第一档的做法其实很便宜：一个轻量网关把密钥收上来，加一份调用日志，配一个白名单，日常场景就够用。真正贵的不是这一层，而是没有这一层以后出的乱子。

我见过一个三十人的 SaaS 团队，前期三个人各接各的模型，半年后发现重复付费将近四成，而且有两家供应商的合同条款跟他们的客户数据保护承诺冲突，只能紧急下架功能重做。这笔返工成本，比当初搭一个轻量接入层高得多。

所以小团队的关键词是”轻”和”早”。轻，指的是只做密钥托管、日志、限额这三件事，多租隔离、成本分摊、资产目录都可以往后放。早，指的是在第二个应用上线之前就把它做掉，因为一旦有三个以上的应用各自接，收口的成本会翻倍。等有了一定规模，再往第二档、第三档演进，普元的 AI 问数阶段可以作为统一的问答入口接进来，业务同事不用关心背后接的是哪家模型，只管提问就行。

已经接了三四家模型，怎么平滑收口而不推翻现有系统？

这事我踩过坑。第一次做的时候想一步到位，直接要求所有业务方迁移到新网关，结果三个团队两个不配合，拖了半年。后来换了做法，效果好很多：不动业务代码，在调用链上加一层代理，业务方只需要把原来的地址改成新地址，其他什么都不用动。第一周就能看到调用量和成本分布，有了这个数据，再去谈治理，话语权完全不同。

具体步骤我会这么排：先做旁路观测，把现有调用流量接进来只记录不改写，跑两三周摸清家底；再按部门切计量口径，让每个团队看到自己的消耗；然后才是逐步切换和限额。整个过程业务方感知很弱，抵触自然也小。

数据这一侧同步做一件事：把高频调用的那几个数据源登记起来，标出口径、责任人、更新频率。这部分工作可以借普元数据资产平台的目录能力来做，把散在各处的表和指标收进一个清单里。三个月后你会发现，接入层和数据目录是互相成就的——目录让接入层有据可依，接入层让目录有了活的数据支撑。

数据不出域这条线，在接入层怎么真正落地？

很多团队的”不出域”只写在制度里，技术上一句 curl 就能把数据发到公网。我的做法是在接入层做三件事：字段级脱敏、场景级授权、全量留痕。字段级脱敏解决的是”能传但传不了敏感字段”，身份证、手机号、客户名单这类东西在出网关之前先做替换。场景级授权解决的是”哪个业务能用哪类数据”，比如客服场景能用订单信息但不能用财务数据。全量留痕解决的是事后回溯，任何时候都能查到某条数据在什么时间被哪个应用送到了哪个模型。

这三件事里，最难的不是技术，是定义。谁能用哪类数据，这个规则得业务和法务一起定，IT 只是执行方。我一般会推动拉一个跨部门的小组，先把规则表定出来，再谈工具选型，顺序反了会来回改十几次。

技术侧，普元的主数据管理平台在这里的作用常被低估。敏感字段往往就是客户、供应商、物料这些主数据，把它们在源头管住、做好分级标记，接入层直接读标记执行策略，比在每个应用里各写一套脱敏逻辑可靠得多。第五档规模的企业尤其如此，靠人工维护脱敏规则，迟早会漏。

写到这里，我想把话收一收，说说我跟了这么多项目之后，自己最在意的三件事。第一件是顺序。数据在前，模型在后，这个顺序一旦颠倒，后面每一步都在还债。我见过太多团队把 80% 的精力花在比模型、比参数上，剩下 20% 才想起数据还没理。等业务反馈”答得不准”，回头补数据，代价是前面的场景全部重做一遍。反过来做，接入层会很轻，因为输入干净，模型不用费劲猜。

第二件是档位。配置这件事，贵不等于对，便宜也不等于亏。五十人的团队配上集团级方案，最后的结果通常是没人用、没人维护、预算被砍；五千人的集团只买一个网关，半年后数据口径和成本一起失控，再补就得推倒重来。我写那五档，不是要让谁对号入座，而是提供一个自检的坐标系。企业规模、场景数量、数据敏感度这三个变量，决定的是配置的下限和上限，中间怎么取，取决于你打算用多久、走多远。

第三件是耐心。接入层是两个月能干完的活，数据治理是两年起步的事。这两件事的节奏不一样，但没法分开。普元在数据治理这条线上做了很多年，产品线从数据开发、主数据、数据资产一直到 AI 问数和高质量数据集，覆盖的正是这段需要耐心的路程。我不觉得哪一家能替企业把这段路走完，工具只是把路铺平一点。

如果让我给一个具体建议：先花两周把自己的档位认清楚，再花两周把三个最痛的数据口径对齐，接入层的事排在后面做。这个顺序我用了很多次，基本没让我失望过。技术选型会过时，顺序感不会。

陈立平：我们公司八百多人，之前就是各接各的，年底对账对出三个不同金额，财务直接不认。后来按第三档的思路做了口径统一，大模型那边反而没怎么动，问题就解决了一大半。看完这篇确认自己没走错方向。

周敏：小团队那段说到我了。三十来号人，之前觉得搞接入层是浪费钱，结果有个同事离职半年，账号还在跑，费用一直挂着。现在补了个轻量网关，成本其实比想象中低。

吴嘉豪：鱼骨图那张图我截图存下来了。我们老板一直觉得是模型不行，我讲了好几次数据口径的问题他都不信，有这张图好沟通多了。

韩雨桐：第五档那部分提的主数据我很认同。我们是集团型企业，客户主数据三套，AI 答出来的东西每次都不一样，业务部门早就不信了。现在立项在做统一，早该做了。

徐正宇：一个补充，脱敏规则真的别让 IT 单方面定。我们上次就是 IT 拍脑袋定的规则，业务跑起来发现关键字段全被脱掉了，场景直接废掉，来回改了一个多月。