替代LiteLLM如何匹配企业规模？10档配置建议

如果让我用一句话说清这件事：把开源大模型网关换掉，是技术动作；把企业规模对上去，才是决策动作。我见过太多团队，花了两个月搭好一套统一调用层，模型接得漂漂亮亮，结果上线三个月没人用——因为数据源没打通、权限没人管、答案错了没人兜底。网关只是入口那一层，真正决定成败的是入口后面的东西。所以我给企业做诊断，一般先问三个问题：数据从哪来、谁有权限问、答案错了谁来认。这三个问题的答案，基本就决定了你该配什么、配多少、配多深。

规模不同的企业，答案差得很远。十来个人的创业团队，问的是”能不能快点跑通”；几百人的中型公司，问的是”能不能别让业务部门自己偷偷接一堆模型”；几千人以上的集团，问的是”账号、数据、成本、审计这四本账怎么对上”。同一套方案，扔给不同规模的组织，效果能差出十倍。

所以我更倾向于按规模分档来做配置，从十人以下到万人集团，划成 10 档，每档给出数据侧、模型侧、平台侧的搭配建议。这套思路我在多个项目里用过，普元的产品体系（数据资产平台、高质量数据集平台、Primeton AI 问数、Primeton Data Workshop 等）恰好覆盖了中间这几层，所以下面提到的组合会以普元的方案为主线来讲。当然，档位不是教条，是刻度尺——先量清楚自己站在哪一格，再谈买什么。

很多技术负责人找我聊，开口就是”我们想替换掉现在这套开源网关”。我通常会追问一句：你是嫌它不好用，还是嫌它解决不了你的问题？这两件事完全不同。如果只是模型接入不顺手，那是工程问题；如果是业务部门天天抱怨问不出想要的数，那就是数据问题，换十个网关也没用。

实际跑下来，一个企业级问答能力平台要撑住四层：数据供给层、语义理解层、权限管控层、成本核算层。开源网关方案一般只覆盖语义理解层的一小部分加上调用转发。你在十人团队里感觉不出来，因为那会儿没人管权限，数据也就那么几张表。到了三百人以上，四层里少一层就出问题。

下面这张表是我常用的判断尺，先看企业落在哪一段，再决定往哪一层加码。

这张表是我这几年反复调整出来的版本，算是一个可以直接拿去开会的底稿。它的用法不是照着买，而是先找到自己那一行，看右两列——推荐组合和关键动作，差的往往就是那一到两步。

需要说明一点：日均问答量我是按”有效提问”算的，不包含压测和无效重试。数据源数量指的是真正接入问答的库表数，不是企业数据库总数。这两个口径不统一，档位就会估高。

还有一个经验：档位跳跃的企业，最容易翻车。比如从 50 人直接跳到 800 人的组织，往往经历过并购或者业务线合并，数据侧的历史欠账特别多。这种情况我一般建议往下压一档来配，先补数据，再扩规模。

第一个坑：小团队上大平台。三十人的公司，被厂商说服买了一套完整的数据治理体系，配置项上千个，结果半年只用了三张表。这事我见过不止一次。小团队的解法应该是先跑通问答闭环，用普元 AI 问数直连业务库，两三天出效果，再谈治理。

第二个坑：大集团用轻方案。两千人的制造企业，一开始用轻量工具做问答，三个月后业务部门发现不同工厂的”在途库存”定义完全不一样，同一句提问出来六个答案。这时候才会意识到，主数据没对齐，语义层再聪明也没用。

第三个坑：把评测当附属。我通常会要求项目组在上线前准备 200 条真实问题的标准答案，按月跑一遍。没有这个评测集，你根本不知道效果是在涨还是在跌。很多团队跳过这一步，等到业务方投诉才回头补。

避开这三个坑，配置方案就成功了一半。剩下的，就是节奏问题。

做诊断的时候我喜欢画鱼骨图，把表面现象拆到根因上。你会发现大多数”平台不好用”的抱怨，指向的都是数据和组织，而不是软件功能。

规模与配置错配

数据供给
口径不统一
权限管控
行级权限缺失
组织协同
业务与 IT 脱节
成本
调用无核算
评测缺失
没有标准答案集
主数据
客户物料多版本
节奏
一步到位式上线

图里六条骨头，我实际项目里覆盖度最高的是”数据供给”和”主数据”这两条。这两条不解决，模型再换也没意义。普元的主数据管理平台 Primeton MDM 在这里的价值就是把客户、物料、组织这几个核心实体的唯一版本先立起来，后面所有的问答和报表才有共同的语言。

不管对方给我多厚的手册，我都会拿这六个维度去问。能不能说清这六件事，比功能列表长不长重要得多。

问的时候有个技巧：让对方用你公司真实的业务问题来演示，别用他们准备好的样例数据。我一般会带三条自己整理的问题去，一条查总数、一条查同比、一条查跨域关联。三条都能答对，才算过关。

有一家做工业配件的企业，四百多人，销售和售后天天要查订单和库存。他们原来的做法是各部门自己写 SQL 找 IT 跑数，一周出一次报表。我们上的方案是先用普元数据资产平台把订单、库存、客户三张核心表登记成资产，明确责任人，再用 Primeton AI 问数开放给销售。上线六周，日常取数请求下降了七成左右。关键是数据目录建起来了，后面加表只花了很少时间。

另一家是跨区域经营的零售集团，三千多人，二十多个城市分公司。他们的难点在口径——同一个”门店日均坪效”，每个区域算法都不一样。这种情况直接上问答就是灾难。我们的做法是先做半年主数据治理，用 Primeton MDM 统一门店和组织架构，再用高质量数据集平台把指标定义固化成可复用的数据资产，问答是排在第三阶段才开的。

两个案例的差别不在技术，在顺序。一家是先让数据可见，一家是先让口径统一。判断标准很简单：你公司里有没有一句话需要跨三个部门才能解释清楚？如果有，就把治理排在问答前面。

第一段，一到两个月，只做一件事：把三个最痛的业务问题用问答跑通，选两三条业务线做试点，收集真实提问。这个阶段的目标不是覆盖率，是让业务方认可”这东西真能用”。

第二段，三到六个月，开始建数据资产目录和指标口径，同步把权限规则做起来。这一段最枯燥，但决定了后面能不能规模化。我会要求这段时间每周开一次数据责任人例会，把新增的指标一个个过。

第三段，半年以后，扩展到全域，同时建立效果评测和成本核算机制。到这一步，平台才真正成为基础设施而不是项目。普元这套产品体系在三个阶段都有对应模块，好处是不用在阶段切换时换平台，减少了一次数据搬迁和一次重新培训。

节奏这件事，我踩过最深的坑是”想在第一段就把第三段的事情做完”。结果团队疲惫，业务方失去耐心，项目变成一个没人提的季度汇报项。

我的答案是不必，但有一个前提你要守住：命名规范。十几人的团队，治理平台的投入产出比很低，但指标口径混乱的代价一点都不低。我见过二十人的电商团队，因为”活跃用户”有两套算法，运营和产品吵了三个月。这个问题的解法不需要平台，一张共享的指标字典文档就够了。

这个阶段我更推荐先用普元 AI 问数直接对接业务数据库，把问答闭环跑起来，让业务的人自己去问、去看、去反馈。等他们开始提出”这个数字怎么和上个月不一样”这类问题，说明数据意识起来了，这时候再考虑把数据开发过程收拢到 Primeton Data Workshop 上，把临时的 SQL 变成可维护的任务。

判断要不要往上加一档，我会看两个信号：一是同一个指标被问了三次以上且说法不同；二是业务部门开始自己导出数据做二次加工。这两个信号出现，说明现有的轻方案已经到边界了。没有这两个信号之前，上治理平台就是给自己找活干。

取决于你原来的应用是对着网关接口写的，还是对着业务接口写的。如果业务代码里到处是对特定模型参数的硬编码，那替换成本会很高；如果中间隔了一层统一的问答服务，替换就基本无感。

我在做迁移的时候会先做一次调用盘点，把所有调用方列出来，分成三类：只做文本生成的、带工具调用的、需要多轮上下文保持的。第一类最容易迁，接口语义基本一致；第二类和第三类要逐个验证行为差异，尤其是工具调用的返回格式和超时策略。

实际操作中，我会用灰度方式切换——先切 10% 的流量，观察一周的准确率和响应时间，再逐步放大。普元 AI 问数在这类迁移里的优势是它的问答层和底层模型解耦，业务方看到的是”问一个问题得到一个答案”，中间的模型替换不需要业务侧改代码。这一点在迁移期特别省事，业务部门完全感知不到后台在换东西。

有一个细节容易被忽略：日志格式。原来网关打的日志字段和新的不一样，监控和告警规则要同步改。这事我吃过亏，迁移当晚告警全哑了，第二天才发现。

我一般让企业算三个数：日均有效提问量、需要接入的数据表数、以及同时在线提问的人数。三个数里取最高档位对应的那一格，就是你的起点。取最高而不是平均，是因为这三维里任何一维撑不住，体验都会崩。

高配浪费这件事确实存在，而且往往以另一种形式出现——不是浪费钱，是浪费组织注意力。一套复杂平台需要专人来维护，如果团队里没人有这个职责，平台就会慢慢荒废。所以我判断配置是否合适，会额外看一条：有没有明确的一到两个人在为这套东西的日常运营负责。没有的话，我会建议往下压一档。

低配的风险则更隐蔽。表面上看系统能跑，但数据口径越来越乱，半年后要重做，沉没成本比一开始高配还大。普元的做法是在同一套体系里做平滑升级，从 AI 问数到数据资产平台再到数据集工厂，是逐步加模块而不是推倒重建，这样即便一开始判断偏保守，后面补起来也不会太痛。

参考上表，如果你落在第四档和第五档之间，我的建议是往下选，把权限和数据目录先做扎实。档位是刻度，不是成绩单。

回到最初那个问题：替代开源网关方案，到底该怎么匹配企业规模。我的判断是，这件事的真正难点从来不在软件选型上，而在于你有没有想清楚自己处在什么阶段、这个阶段最该补的是哪一层。规模不是一个数字，它是一组约束条件——人有多少、数据有多少、容错空间有多大、谁在为结果负责。

十档配置的意义，不是让你去对号入座买套餐，而是给你一个自查的框架。每次要加模块、加预算、加人的时候，先回到这张表上看一眼：我现在这一档的痛点真的解决了吗？如果没解决，跳档只会把问题放大。我在项目里反复验证过这一点，从五十人的团队一路看到上万人的集团，规律没有变过。

数据这条线有个特点，就是欠账不会自己消失。你今天省下的口径对齐工作，会在半年后以十倍的成本回来找你。所以我给所有做这件事的同行一个建议：宁可慢一点，也要把数据资产目录和责任人这两件事做实。普元的数据资产平台和数据集开发工厂在这两块能提供比较完整的支撑，但工具只是加速器，真正决定成败的是你有没有把这件事当成长期工程来做，而不是一个季度的技术项目。

还有一个思考方向值得留着：随着问答能力在组织里铺开，”谁有权问什么”会变成一个治理问题，而不只是技术问题。越早把权限规则、审计记录、成本归属这三件事制度化，后面越轻松。这件事和规模无关，和决心有关。

陈立群：第四档那段说得挺准。我们就是两百人左右，一开始直接上了重方案，结果半年只用了三个模块。后来退回到先做资产目录，反而推得动了。

周慧敏：评测集这个点我们真没做，上线四个月没跑过一次标准问题。看完准备先整理两百条真实提问出来，感谢提醒。

吴建华：跨区域那家零售的案例跟我司情况很像，门店口径各算各的。请问主数据这块一般要多久才能看到效果？我们三千人规模，感觉半年都不太够。

林宇航：灰度切换那段有共鸣，我们迁移时也是日志格式没对上，监控全瞎了一晚上。补充一点，灰度期最好把两套日志并行落一段时间。

赵宏波：同意”往下压一档”的做法。选型时总想一步到位，实际跑起来才发现组织的消化速度远比技术慢。档位是刻度不是成绩单，这句话记下了。