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 常见问题速查表问题现象可能原因排查方法解决方案请求超时率突然升高模型服务不稳定或网络抖动查看各模型的P95延迟曲线临时切换到备用模型联系供应商确认Token计数对不上适配层计算规则有误对比平台日志和供应商后台数据修正适配层的token计算逻辑某业务方费用异常高请求量突增或存在异常调用查看该业务方的调用明细设置限流或联系业务方确认模型切换后输出质量下降新模型在该场景下效果不佳跑评测集对比得分调整路由策略切回原模型平台响应时间变长数据库连接池或HTTP连接池瓶颈查看连接池使用率优化连接池配置或改为异步写入密钥认证失败密钥过期或轮换未同步检查密钥有效期和轮换日志更新密钥并同步到所有节点6. 成本控制与效果评测的实战经验6.1 成本归集与预算控制的具体做法成本控制是企业级平台绕不开的话题。我们的做法是把成本归集到三个维度业务方、模型、时间段。每个维度都可以设置预算超预算会自动触发告警甚至限流。业务方维度的预算控制最直接。每个业务方在平台上注册的时候会分配一个预算额度可以是月度的也可以是季度的。平台实时统计每个业务方的消耗达到预算的80%发预警达到100%自动限流。限流策略可以配置有的是直接拒绝新请求有的是降级到更便宜的模型。模型维度的成本分析主要用于优化路由策略。我们会定期分析各模型的单位成本效益也就是每块钱能产生多少有效输出。有些模型虽然单价贵但生成质量高需要的重试次数少综合成本反而更低。这些分析结果会反馈到路由策略的调整中。时间段维度的分析主要用于发现异常。比如某个时间段的成本突然飙升可能是业务方做了批量任务也可能是遭到了异常调用。我们设置了同比和环比的告警阈值超过阈值就会通知相关人员确认。6.2 评测集构建与效果对比方法评测集是衡量模型效果的基础。我们的评测集分通用和专用两部分。通用评测集覆盖了文本生成、代码补全、信息抽取、情感分析等常见任务每个任务50到100个样本。专用评测集是针对我们公司具体业务场景构建的比如客服对话、商品描述生成、合同条款抽取等。评测方法上我们用了自动评测加人工评测的组合。自动评测用BLEU、ROUGE、以及基于另一个大模型的打分。人工评测由业务方的同学来做每个样本至少两个人独立打分取平均分。自动评测每周跑一次人工评测每月跑一次。评测结果会生成一个对比矩阵行是模型列是任务单元格是得分。这个矩阵是路由策略调整的主要依据。比如某个业务方要做商品描述生成我们就查这个矩阵看哪个模型在“商品描述生成”这个任务上得分最高然后把该业务方的请求优先路由到那个模型。6.3 模型降级与熔断机制的设计熔断机制是保障平台稳定性的最后一道防线。当某个模型的错误率超过阈值我们设的是20%或者响应时间超过阈值我们设的是10秒熔断器就会打开后续请求不再发往该模型而是直接走降级逻辑。降级逻辑分两种。一种是降级到备用模型比如主模型不可用就切到备用模型虽然效果可能差一点但至少能用。另一种是降级到缓存结果对于重复性高的请求直接返回之前缓存的结果。两种降级策略可以组合使用优先走备用模型备用模型也不可用就走缓存。熔断器的恢复策略我们用的是半开模式。熔断打开后每隔30秒放一个探测请求过去如果探测成功就关闭熔断器恢复正常路由如果探测失败就继续保持熔断状态。这个策略比固定时间恢复更安全避免在模型服务还没完全恢复的时候就把大量流量打过去。实操心得熔断阈值不要设得太敏感否则容易误伤。我们一开始设的错误率阈值是10%结果模型服务偶尔抖动一下就触发熔断业务方投诉了好几次。后来调到20%就稳定多了。7. 平台后续扩展的一些想法这个平台目前已经稳定运行了大半年支撑了公司内部十几个业务线的AI调用需求。回过头看最大的收获不是技术上的而是对“企业级AI能力管理”这件事的理解加深了。聚合平台的价值不在于技术有多复杂而在于它把分散的、不可控的AI调用变成了集中的、可度量、可优化的服务能力。后续我们计划在几个方向上继续扩展。一是增加多模态能力的支持目前主要是文本和代码后面要加上图像生成、语音合成、视频理解等能力。二是做更智能的路由现在还是基于规则的后面想引入强化学习让路由策略能够根据实时的效果反馈自动调整。三是把评测体系做得更完善引入更多的自动化评测指标减少人工评测的工作量。如果你也在做类似的事情我的建议是不要一开始就追求大而全。先把最核心的文本生成能力聚合起来把计量计费和监控告警做扎实然后再逐步扩展其他能力。平台的价值是随着接入的业务方数量增加而增长的所以早期最重要的是让业务方用得放心、用得方便而不是堆砌功能。