1. 从零拆解一个AI大模型聚合平台：企业级落地的真实路径

这两年跟不少做企业数字化的朋友聊天，话题绕来绕去总归会落到同一个点上：大模型到底怎么用起来。不是那种演示级别的“你问它答”，而是真正嵌进业务流程、能扛住并发、能算清楚成本、还能让老板看到投入产出比的那种用法。我所在的团队从去年开始折腾一个内部的大模型聚合平台，踩了无数的坑，也攒了一些实打实的经验。这篇文章就把我们做这个平台的整体思路、技术选型、实操细节和踩坑记录完整地摊开来聊一聊。

所谓“AI大模型聚合平台”，说白了就是一个中间层，把市面上各种大模型的能力统一封装起来，让企业内部的业务系统不用关心底层到底调的是哪家模型、接口长什么样、计费怎么算，只需要面向一个统一的接口编程就行。它解决的问题很具体：当你的企业同时需要文本生成、代码补全、图像理解、语音转写等多种AI能力时，如果每个业务线各自去对接不同的模型供应商，那就会出现密钥管理混乱、成本无法归集、效果无法横向对比、切换模型要改代码等一系列问题。聚合平台就是把这些脏活累活集中处理掉。

这个平台适合谁来参考？如果你是企业内部的架构师、技术负责人，正在考虑怎么把大模型能力系统性地引入公司；或者你是某个业务线的开发，受够了每次换模型都要重写一遍调用逻辑；再或者你是技术管理者，想搞清楚大模型调用的成本到底花在了哪里——那这篇内容应该能给你一些可以直接抄作业的东西。

2. 整体架构设计与核心思路拆解

2.1 为什么需要一个聚合层而不是直连

最开始我们也是直连的。业务A要做一个智能客服，直接对接了一家模型服务商的API；业务B要做代码审查助手，又对接了另一家。前两个月没什么问题，到了第三个月，问题开始集中爆发。首先是密钥管理，每个业务线各自申请密钥，有的写在配置文件里，有的硬编码在代码里，安全审计的时候一查一个准，全是隐患。其次是成本，财务那边问“这个月AI调用花了多少钱”，没人能给出一个准确的数字，因为账单散落在各个服务商的后台。最要命的是效果对比，老板问“到底哪家模型在我们这个场景下效果最好”，我们只能凭感觉回答，因为没有统一的评测数据。

这些问题单独看都不算大，但叠在一起就变成了一个系统性的管理难题。聚合层的价值就在于，它把“调用模型”这件事从一个分散的、不可观测的行为，变成了一个集中的、可度量、可控制的服务。所有的请求都经过同一个入口，密钥统一管理，成本统一归集，效果统一评测，模型切换对业务方透明。这个思路跟当年做微服务网关的逻辑是一模一样的，只不过管的对象从内部服务变成了外部AI能力。

2.2 核心模块划分与职责边界

我们的平台大致分了五个核心模块，每个模块的职责边界划得很清楚，这样后面扩展和维护才不会乱。

统一接入层是整个平台的入口，负责接收业务方的请求，做身份认证、限流、请求格式校验。这一层不关心具体调哪个模型，只负责把请求标准化之后往后传。我们用的是标准的RESTful接口，请求体和响应体都定义了一套内部协议，业务方只需要按这个协议来就行。

路由调度层是核心中的核心。它根据请求的内容、业务方的配置、当前的模型可用状态，决定这个请求到底发给哪个模型。比如同样是文本生成，有的业务要求速度快，那就路由到响应延迟低的模型；有的业务要求质量高，那就路由到生成效果好的模型。路由策略可以按业务方配置，也可以按请求内容动态判断。

模型适配层负责把内部标准协议翻译成各个模型供应商的私有协议。每家模型的接口参数、返回格式、错误码都不一样，这一层就是做适配和转换的。新增一家模型供应商，只需要在这一层加一个适配器，上层完全不用动。

计量与计费层负责记录每一次调用的token消耗、响应时间、模型标识等信息，然后按照预设的单价计算出成本。这些数据会按业务方、按模型、按时间段聚合，生成报表。这一层的数据也是后续做成本优化和预算控制的基础。

监控与评测层负责实时监控各个模型的可用性和响应质量，同时定期跑评测集，对比不同模型在同一任务上的表现。评测结果会反馈给路由调度层，作为路由策略调整的依据。

2.3 技术选型背后的取舍逻辑

技术选型这块我们纠结了很久，最终的选择未必是最优解，但确实是最适合我们团队现状的。

后端语言选了Go，主要考虑的是高并发场景下的性能和资源效率。聚合平台本质上是一个IO密集型的网关服务，Go的goroutine模型在这种场景下优势很明显，单机可以轻松扛住几千的并发请求，而且内存占用比Java小很多。我们实测下来，同样的硬件配置，Go版本的吞吐量大概是Java版本的1.5倍左右。

数据库用了PostgreSQL加Redis的组合。PostgreSQL存配置数据、计费数据、评测结果这些需要持久化和复杂查询的数据；Redis做缓存和限流计数器。选PostgreSQL而不是MySQL，主要是看中了它的JSONB字段类型，存模型配置这种半结构化数据非常方便，不用频繁改表结构。

消息队列用了Kafka，主要是为了异步处理计费和日志数据。每次模型调用的计量信息先写到Kafka，然后由消费者异步写入数据库。这样做的好处是计量逻辑不会阻塞主请求链路，即使计量服务短暂不可用，也不会影响业务方的正常调用。

容器化部署用的是Kubernetes，这个没什么好说的，现在基本上是新项目的标配了。值得一提的是我们把每个模型适配器都做成了独立的Sidecar容器，这样某个适配器出问题不会影响其他模型，而且可以独立扩缩容。

3. 核心细节解析与实操要点

3.1 统一接口协议的设计细节

统一接口协议是整个平台的基石，设计得好不好直接决定了后续的扩展成本。我们的设计原则是“面向能力而不是面向模型”，也就是说接口定义的是“我要做文本生成”这个能力，而不是“我要调某个特定模型”。

请求体的核心字段包括：能力类型（比如text-generation、code-completion、image-captioning）、输入内容、业务方标识、优先级、超时时间、以及一个可选的模型偏好配置。响应体包括：生成结果、实际使用的模型标识、token消耗量、响应时间、以及一个请求追踪ID。

这里有个细节值得展开说。模型偏好配置我们设计成了一个灵活的JSON结构，业务方可以指定“优先使用某家模型”、“排除某家模型”、“在延迟超过X毫秒时自动降级到备用模型”等策略。这个配置不是必须的，不填就走平台的默认路由策略。这样设计的好处是，业务方既有默认的省心选项，也有精细控制的能力。

注意：接口协议一旦定下来，后续修改的成本非常高。建议在设计阶段就充分考虑未来可能的能力扩展，比如多模态输入、流式输出、函数调用等。我们当时没考虑流式输出，后来加的时候改了不少东西。

3.2 路由策略的算法与参数调优

路由策略我们实现了三种模式，业务方可以按需选择。

权重轮询模式是最简单的，按照预设的权重把请求分发到不同的模型。适合那种对模型没有特别偏好、只想分摊成本的场景。权重可以按成本比例设置，比如A模型便宜就权重高一些，B模型贵就权重低一些。

延迟优先模式会实时统计各个模型的P95响应时间，然后把请求路由到当前延迟最低的模型。这个模式适合对响应速度要求高的场景，比如在线客服。实现上我们维护了一个滑动窗口，每10秒更新一次各模型的延迟统计数据。

质量优先模式会参考评测集的得分，把请求路由到当前任务上得分最高的模型。评测集是我们自己构建的，覆盖了常见的业务场景，每个模型每周跑一次评测，得分存入数据库。这个模式适合对生成质量要求高的场景，比如对外发布的内容生成。

参数调优这块，最关键的是滑动窗口的大小和更新频率。窗口太小会导致路由抖动，请求在模型之间来回跳；窗口太大又会导致对模型状态变化反应迟钝。我们试了几轮，最终定在了10秒窗口、5秒更新频率，实测下来比较平衡。

3.3 计量计费的精确性保障

计量计费这块最容易出问题，因为涉及到钱，一点差错都不能有。我们的做法是“双写校验”：每次调用的计量信息同时写入Kafka和本地日志文件，Kafka用于实时计费，本地日志用于对账和故障恢复。

Token的计算方式各家模型不一样，有的按输入输出分开计费，有的按总量计费，有的还有缓存命中折扣。我们在适配层里为每家模型单独实现了token计算逻辑，确保跟官方账单能对上。这里有个坑：有些模型的流式输出模式下，token计数跟非流式模式不一样，我们一开始没注意，导致对账的时候差了百分之几，查了好久才发现。

计费单价我们做成了可配置的，因为模型供应商经常会调价。配置支持按时间段生效，这样调价的时候不用改代码，改配置就行。历史计费数据会保留原始单价，不会因为后续调价而影响已经生成的账单。

实操心得：建议在平台上线初期就建立每日对账机制，把平台统计的token消耗跟模型供应商后台的数据做比对。我们前两个月每周对一次，发现了不少适配层的bug，后来稳定了才改成每月对一次。

4. 实操过程与核心环节实现

4.1 环境准备与基础依赖搭建

先说一下我们的部署环境。生产环境是Kubernetes集群，版本1.28，节点配置是8核16G，一共6个节点。测试环境是3个节点，配置减半。数据库用的是云托管的PostgreSQL 15，开了读写分离。Redis用的是集群模式，3主3从。

基础依赖的安装没什么特别的，主要是Go的编译环境、Docker、以及一些常用的命令行工具。这里重点说一下配置管理。我们用的是ConfigMap加环境变量的方式，敏感信息比如数据库密码、模型API密钥存在Kubernetes Secret里。密钥的轮换通过定时任务自动完成，每90天换一次。

网络这块需要特别注意。因为要调用外部的模型服务，所以集群的出网策略要配好。我们给聚合平台单独分配了一个NAT网关，所有出网请求都走这个网关，方便做流量监控和访问控制。同时设置了请求超时和重试策略，避免因为外部服务不稳定导致平台自身被拖垮。

4.2 模型适配器的开发与接入流程

新增一个模型适配器的流程我们标准化了，大概半天到一天就能完成一个。

第一步是定义适配器的配置结构。每家模型的配置包括：模型标识、API端点、认证方式、支持的输入输出格式、token计算规则、单价信息、以及一些模型特有的参数。这些配置存在数据库里，通过管理后台可以动态修改。

第二步是实现适配器接口。我们定义了一个ModelAdapter接口，包含Init、Generate、StreamGenerate、CountTokens、HealthCheck这几个方法。新增模型只需要实现这个接口就行。Generate方法负责把内部标准请求转换成模型私有请求，调用API，然后把响应转换回内部标准格式。

第三步是编写单元测试和集成测试。单元测试主要验证请求转换和响应转换的正确性，集成测试会真实调用模型API，验证端到端的可用性。集成测试我们放在单独的测试环境跑，避免消耗生产环境的配额。

第四步是灰度上线。新适配器先接入10%的流量，观察一周的稳定性和效果，没问题再逐步放大到全量。灰度期间会重点关注错误率、延迟、以及token计数的准确性。

4.3 高并发场景下的性能调优记录

上线初期我们遇到过一次性能问题。当时有个业务方做了一次大规模的内容生成任务，瞬间打了几千个并发请求过来，平台的响应时间从平均200毫秒飙升到了5秒以上，部分请求直接超时。

排查下来发现瓶颈在数据库连接池。每次模型调用都要写一条计量记录到PostgreSQL，高并发下连接池被打满了，后续请求都在等连接。解决方案是把计量写入改成异步的，先写Kafka，然后由消费者批量写入数据库。改造之后，同样的并发量下，平台响应时间稳定在300毫秒以内。

另一个优化点是HTTP客户端的连接复用。我们一开始每次调用模型API都新建一个HTTP连接，后来改成了连接池，复用TCP连接，减少了握手开销。这个优化对延迟的改善大概在20%左右。

还有一个容易被忽略的点是DNS解析。外部模型API的域名解析在高并发下也会成为瓶颈，我们后来加了本地DNS缓存，把解析结果缓存5分钟，效果很明显。

4.4 监控告警体系的搭建

监控这块我们用了Prometheus加Grafana的组合，告警走Alertmanager。核心监控指标分四类。

可用性指标包括各模型的请求成功率、错误率、以及健康检查通过率。错误率超过5%持续3分钟就触发告警。

性能指标包括P50、P95、P99响应时间，以及QPS。P95超过2秒持续5分钟触发告警。

成本指标包括每小时token消耗量、每小时费用、以及各业务方的费用占比。费用超过预算的80%触发预警，超过100%触发告警。

质量指标包括评测集得分的变化趋势、以及用户反馈的满意度评分。得分下降超过10%触发告警。

告警通知我们分了三个级别：P0是平台不可用，直接打电话；P1是部分功能异常，发即时消息；P2是性能或成本异常，发邮件。告警信息里会带上相关的仪表盘链接和排查手册，方便值班同学快速定位问题。

5. 常见问题与排查技巧实录

5.1 模型调用超时与重试策略

超时是最高频的问题，没有之一。外部模型服务的响应时间波动很大，有时候正常200毫秒，有时候突然飙到好几秒。我们的策略是分级超时：普通请求超时时间设5秒，流式请求设30秒，批量任务设120秒。超时之后会自动重试一次，重试还是超时就返回错误给业务方。

重试有个坑要注意：不是所有请求都适合重试。比如文本生成这种幂等操作，重试没问题；但如果是计费相关的操作，重试可能会导致重复计费。我们在适配层里给每个操作标记了是否可重试，只有标记为可重试的才会走重试逻辑。

还有一个细节是重试的退避策略。我们用的是指数退避，第一次重试等100毫秒，第二次等200毫秒，第三次等400毫秒。这样避免在模型服务刚恢复的时候瞬间又被打满。

5.2 Token计数偏差的排查方法

Token计数偏差是对账时最常发现的问题。排查思路是这样的：先从平台日志里找出偏差的那批请求，然后逐条对比平台记录的token数和模型供应商后台的token数。如果是个别请求偏差，通常是适配层的转换逻辑有问题；如果是批量偏差，可能是token计算规则理解错了。

我们遇到过几种典型的偏差原因。一种是模型供应商在特定情况下会额外计算一些token，比如函数调用的参数也会计入token，我们一开始没算进去。另一种是流式输出模式下，最后一个chunk的token计算方式跟非流式不一样。还有一种是模型供应商调整了token计算规则但没有通知，导致我们的计算逻辑过时了。

避坑技巧：建议在适配器里加一个“token计数校验”的开关，开启后会把平台计算的token数和模型返回的token数都记录下来，方便对比。平时关掉，对账的时候打开。

5.3 模型切换时的兼容性处理

模型切换是聚合平台的核心价值之一，但切换过程中的兼容性问题也不少。最大的问题是不同模型的输出格式和风格差异很大，业务方如果直接依赖了某个模型的特定输出格式，切换之后就会出问题。

我们的解决方案是在适配层做输出标准化。不管底层模型返回什么格式，适配层都会转换成统一的内部格式再返回给业务方。比如有的模型返回Markdown格式的文本，有的返回纯文本，适配层会统一转换成纯文本，同时保留原始格式作为一个可选字段。

另一个问题是模型的能力差异。比如A模型支持函数调用，B模型不支持，那路由到B模型的时候函数调用就会失败。我们在路由层做了能力匹配，请求里如果指定了需要函数调用能力，就只会路由到支持该能力的模型。

5.4 常见问题速查表

6. 成本控制与效果评测的实战经验

6.1 成本归集与预算控制的具体做法

成本控制是企业级平台绕不开的话题。我们的做法是把成本归集到三个维度：业务方、模型、时间段。每个维度都可以设置预算，超预算会自动触发告警甚至限流。

业务方维度的预算控制最直接。每个业务方在平台上注册的时候会分配一个预算额度，可以是月度的也可以是季度的。平台实时统计每个业务方的消耗，达到预算的80%发预警，达到100%自动限流。限流策略可以配置，有的是直接拒绝新请求，有的是降级到更便宜的模型。

模型维度的成本分析主要用于优化路由策略。我们会定期分析各模型的单位成本效益，也就是每块钱能产生多少有效输出。有些模型虽然单价贵，但生成质量高，需要的重试次数少，综合成本反而更低。这些分析结果会反馈到路由策略的调整中。

时间段维度的分析主要用于发现异常。比如某个时间段的成本突然飙升，可能是业务方做了批量任务，也可能是遭到了异常调用。我们设置了同比和环比的告警阈值，超过阈值就会通知相关人员确认。

6.2 评测集构建与效果对比方法

评测集是衡量模型效果的基础。我们的评测集分通用和专用两部分。通用评测集覆盖了文本生成、代码补全、信息抽取、情感分析等常见任务，每个任务50到100个样本。专用评测集是针对我们公司具体业务场景构建的，比如客服对话、商品描述生成、合同条款抽取等。

评测方法上，我们用了自动评测加人工评测的组合。自动评测用BLEU、ROUGE、以及基于另一个大模型的打分。人工评测由业务方的同学来做，每个样本至少两个人独立打分，取平均分。自动评测每周跑一次，人工评测每月跑一次。

评测结果会生成一个对比矩阵，行是模型，列是任务，单元格是得分。这个矩阵是路由策略调整的主要依据。比如某个业务方要做商品描述生成，我们就查这个矩阵，看哪个模型在“商品描述生成”这个任务上得分最高，然后把该业务方的请求优先路由到那个模型。

6.3 模型降级与熔断机制的设计

熔断机制是保障平台稳定性的最后一道防线。当某个模型的错误率超过阈值（我们设的是20%），或者响应时间超过阈值（我们设的是10秒），熔断器就会打开，后续请求不再发往该模型，而是直接走降级逻辑。

降级逻辑分两种。一种是降级到备用模型，比如主模型不可用就切到备用模型，虽然效果可能差一点但至少能用。另一种是降级到缓存结果，对于重复性高的请求，直接返回之前缓存的结果。两种降级策略可以组合使用，优先走备用模型，备用模型也不可用就走缓存。

熔断器的恢复策略我们用的是半开模式。熔断打开后每隔30秒放一个探测请求过去，如果探测成功就关闭熔断器，恢复正常路由；如果探测失败就继续保持熔断状态。这个策略比固定时间恢复更安全，避免在模型服务还没完全恢复的时候就把大量流量打过去。

实操心得：熔断阈值不要设得太敏感，否则容易误伤。我们一开始设的错误率阈值是10%，结果模型服务偶尔抖动一下就触发熔断，业务方投诉了好几次。后来调到20%就稳定多了。

7. 平台后续扩展的一些想法

这个平台目前已经稳定运行了大半年，支撑了公司内部十几个业务线的AI调用需求。回过头看，最大的收获不是技术上的，而是对“企业级AI能力管理”这件事的理解加深了。聚合平台的价值不在于技术有多复杂，而在于它把分散的、不可控的AI调用变成了集中的、可度量、可优化的服务能力。

后续我们计划在几个方向上继续扩展。一是增加多模态能力的支持，目前主要是文本和代码，后面要加上图像生成、语音合成、视频理解等能力。二是做更智能的路由，现在还是基于规则的，后面想引入强化学习，让路由策略能够根据实时的效果反馈自动调整。三是把评测体系做得更完善，引入更多的自动化评测指标，减少人工评测的工作量。

如果你也在做类似的事情，我的建议是不要一开始就追求大而全。先把最核心的文本生成能力聚合起来，把计量计费和监控告警做扎实，然后再逐步扩展其他能力。平台的价值是随着接入的业务方数量增加而增长的，所以早期最重要的是让业务方用得放心、用得方便，而不是堆砌功能。