2025年，大模型价格战打得如火如荼。

各家厂商轮番降价，调用量呈指数级增长。我们公司的AI服务，日调用量从年初的几百万次，涨到了现在的几千万次。价格降了，量上来了，但系统的压力也大了。如何在低成本的前提下，保证高可用和高并发，成了我们架构团队的核心挑战。

这篇文章，我想分享一下我们在大模型价格战背景下的架构设计经验。从流量调度、模型管理、缓存策略、成本控制到容灾备份，聊聊如何构建一个高可用高并发的AI服务架构。

背景：价格战带来的挑战

大模型价格战，对我们的架构带来了几个直接的挑战。

第一个挑战是，调用量暴增。价格降了，用户用得起了，调用量自然就上来了。我们的几个核心API，调用量在半年内涨了10倍。原来的架构是按百万级日调用设计的，突然面对千万级，很多地方都扛不住了。

第二个挑战是，成本压力。价格战意味着收入下降，但调用量增加意味着成本上升（GPU服务器、带宽、运维成本都在涨）。如果架构不优化，成本可能会超过收入，那就亏大了。所以，架构设计必须把成本控制放在重要位置。

第三个挑战是，多模型管理。为了应对价格战，我们接入了多家厂商的大模型，有贵的、有便宜的、有快的、有慢的。如何根据用户需求和成本，智能地选择模型，是一个复杂的问题。

第四个挑战是，稳定性要求高。AI服务已经成为很多产品的核心功能，一旦出问题，影响很大。用户对AI服务的稳定性要求越来越高， downtime 是不可接受的。

面对这些挑战，我们对架构进行了一次全面的重构。下面分享一下我们的设计思路和实践经验。

整体架构设计

我们的整体架构，可以分为几层：

第一层是接入层。负责接收用户请求，做鉴权、限流、路由。用的是API网关（基于Kong二次开发），加上负载均衡（Nginx）。接入层是整个系统的入口，必须保证高可用，我们做了多可用区部署，任何一个可用区挂了，流量自动切换到其他可用区。

第二层是调度层。这是我们的核心层，负责智能路由和模型选择。调度层根据请求的类型、用户等级、当前各模型的负载和价格，动态选择最合适的模型和厂商。比如，简单的问答用便宜的模型，复杂的推理用贵的模型；某个厂商负载高了，就把流量切到其他厂商。

第三层是模型服务层。这是实际调用大模型的层。我们接入了多家厂商的API，同时也有自部署的开源模型。模型服务层负责和厂商API通信，做协议转换、超时控制、重试熔断。

第四层是缓存层。对于重复的请求，直接从缓存返回结果，不用调用大模型。这是降低成本和提升响应速度的关键。我们用了多级缓存：本地缓存（Redis）+ 分布式缓存（Memcached）+ 语义缓存（基于向量相似度的缓存）。

第五层是数据和监控层。记录所有的请求和响应，用于分析、优化和计费。监控系统实时监控各个环节的性能、错误率、成本，发现异常及时告警。

下面详细说说每一层的关键设计。

接入层：限流和防护

接入层是系统的第一道防线，主要做几件事。

第一是鉴权。每个请求都要验证API Key或者用户Token，确保是合法用户。我们用了JWT + Redis的方案，Token存在Redis里，验证很快。同时，记录每个用户的调用量，用于计费和限流。

第二是限流。这是保护系统的重要手段。我们做了多级限流：全局限流（整个系统的QPS上限）、用户级限流（每个用户的QPS上限）、API级限流（每个接口的QPS上限）。限流算法用的是令牌桶，比较平滑，不会突然拒绝请求。

限流的阈值不是固定的，而是动态调整的。根据系统当前的负载和各模型的可用容量，自动调整限流阈值。系统负载高的时候，收紧限流；负载低的时候，放宽限流。这样既能保护系统，又能充分利用资源。

第三是WAF（Web应用防火墙）。防止恶意攻击，比如SQL注入、XSS、DDoS。我们用了云厂商的WAF，加上自己的规则，拦截恶意请求。大模型服务很容易被爬虫和恶意调用攻击，WAF是必须的。

第四是请求校验。对请求参数做校验，比如内容长度、格式、敏感词。不合规的请求直接在接入层拒绝，不用传到后面的服务，节省资源。

接入层的所有组件都是无状态的，可以水平扩展。流量大的时候，加机器就行。我们用了Kubernetes来管理接入层的Pod，根据负载自动扩缩容。

调度层：智能路由

调度层是我们架构的核心，也是最复杂的部分。它的核心任务是：对于每个请求，选择最合适的模型和厂商来处理。

选择的依据有几个维度：

第一，能力匹配。不同的模型能力不一样，有的擅长推理，有的擅长代码，有的擅长多模态。调度层会根据请求的类型和复杂度，选择能力匹配的模型。比如，简单的聊天用小模型，复杂的数学推理用大模型。

第二，成本。价格战期间，各厂商的价格差异很大，同一个能力的模型，价格可能差好几倍。调度层会优先选便宜的模型，降低成本。但也不是只看价格，还要考虑质量和稳定性。

第三，延迟。不同的模型和厂商，响应时间不一样。对于对延迟敏感的请求（比如实时对话），选响应快的模型；对于不敏感的请求（比如批量处理），可以选慢一点但便宜的模型。

第四，负载和可用性。某个厂商的服务可能正在降级或者维护，这时候调度层会把流量切到其他厂商。我们实时监控各厂商的可用性和延迟，动态调整流量分配。

调度的算法，我们一开始用的是简单的规则引擎，后来换成了基于强化学习的智能调度。系统会根据历史数据，学习什么样的请求用什么样的模型效果最好、成本最低，不断优化调度策略。

调度层还有一个重要功能：故障转移。如果某个厂商的API超时或者报错，调度层会自动重试，或者切换到备用厂商。对用户来说，完全感知不到后端的故障。

为了保证调度层本身的高可用，我们做了多副本部署，加上分布式一致性协议（用的是Raft），保证调度策略的一致性。调度层是无状态的（状态存在Redis里），任何一个副本挂了，其他副本可以接管。

模型服务层：多模型管理

模型服务层负责实际调用大模型，主要做几件事。

第一是多厂商接入。我们接入了OpenAI、Anthropic、Google、国内的几家大模型厂商，还有自部署的开源模型。每个厂商的API格式不一样，我们做了一个统一的适配层，把不同厂商的API转换成统一的内部格式。这样，上层不用关心具体是哪个厂商，调度层选了哪个，模型服务层就调用哪个。

第二是超时和重试。大模型API的响应时间不稳定，有时候快有时候慢，有时候还会超时。我们设置了合理的超时时间（根据模型类型和请求复杂度动态调整），超时后自动重试。重试有次数限制，而且会切换到备用厂商，避免在一个厂商上反复重试。

第三是熔断机制。如果某个厂商的错误率超过阈值（比如连续10次请求有5次失败），就熔断这个厂商，暂时不往它那里发流量，过一段时间再试探性恢复。熔断机制能防止故障扩散，保护整个系统。

第四是流式处理。大模型的生成是流式的（一个字一个字吐出来），我们支持流式响应，让用户能实时看到生成的内容，不用等全部生成完。流式处理对网络和服务器的要求更高，但用户体验好很多。

第五是自部署模型。对于一些简单的、调用量大的任务，我们用自部署的开源模型（比如Llama、Qwen），成本比调用厂商API低很多。自部署模型用的是GPU服务器，基于vLLM或者TensorRT-LLM做推理优化，能充分利用GPU的算力。

模型服务层也是无状态的，可以水平扩展。我们用Kubernetes管理模型服务的Pod，根据队列长度自动扩缩容。GPU资源比较贵，我们做了分时复用，不同的模型共享GPU，提高利用率。

缓存层：降低成本的关键

缓存是降低大模型调用成本的最有效手段。我们做了多级缓存。

第一级是精确缓存。对于完全相同的请求（同样的prompt、同样的参数），直接返回之前的结果。用Redis做缓存，key是请求的哈希值，value是响应结果。缓存时间根据内容类型设置，比如事实性问题可以缓存久一点，时效性问题缓存短一点。

精确缓存的命中率取决于业务场景。对于问答、客服这类重复请求多的场景，命中率能到30%-50%，意味着有三分之一到一半的请求不用调用大模型，成本大大降低。

第二级是语义缓存。对于不完全相同但语义相似的请求，也可以复用之前的结果。比如，"北京的天气怎么样"和"北京今天天气如何"，语义是一样的，不用重复调用。语义缓存用向量数据库，把请求向量化，找相似度高的历史请求，返回对应的结果。

语义缓存的实现要注意精度和召回率的平衡。相似度阈值设得太高，命中率低；设得太低，可能返回不相关的结果。我们用了一个折中方案，高相似度的直接返回，中等相似度的让大模型做一次轻量判断，低相似度的重新生成。

第三级是提示词缓存。很多请求的系统提示词（system prompt）是一样的，只是用户输入不同。大模型厂商支持提示词缓存（比如OpenAI的prompt caching），缓存的部分计费更低。我们把常用的系统提示词做了缓存，降低了token成本。

缓存的更新和失效也很重要。我们设置了合理的过期时间，同时支持手动刷新。对于时效性内容（比如新闻、天气），缓存时间很短，或者不缓存。

成本控制：精细化运营

在价格战的背景下，成本控制是架构设计的核心目标之一。我们从几个方面做成本控制。

第一是模型分级。把模型分成不同的等级：入门级（便宜、能力一般）、进阶级（中等价格、能力不错）、旗舰级（贵、能力强）。根据请求的复杂度，自动选择合适的等级。简单的请求用入门级，复杂的用旗舰级，避免"杀鸡用牛刀"。

第二是Token优化。大模型是按token计费的，减少token的使用量就是省钱。我们做了几件事：优化提示词，去掉不必要的内容；对长文本做摘要，只把关键部分传给模型；设置合理的max_tokens，避免生成过长的内容；用更高效的分词方式。

第三是批处理。对于不要求实时响应的请求（比如批量生成、数据分析），攒成一批一起处理，提高GPU的利用率，降低单位成本。批处理在自部署模型上效果尤其明显，一次推理处理多个请求，吞吐量能提升好几倍。

第四是资源弹性。GPU资源很贵，不能一直开着。我们根据流量的波峰波谷，自动调整GPU的数量。白天流量大，多开一些；晚上和凌晨流量小，关掉一些。用的是云厂商的按量付费GPU，按需使用，不用不花钱。

第五是成本监控和告警。我们有一个实时的成本监控面板，能看到每个模型、每个用户、每个接口的成本。成本异常的时候自动告警，比如某个用户的调用量突然暴增，或者某个模型的单位成本上升了。及时发现问题，及时处理。

通过这些手段，我们的单位调用成本在半年内降了60%，虽然调用量涨了10倍，但总成本只涨了3倍。这在价格战的背景下，是非常关键的。

高可用设计

高可用是AI服务的基本要求。我们从几个层面做了高可用设计。

第一是多可用区部署。所有服务都部署在至少两个可用区，流量通过负载均衡分发。一个可用区出问题，流量自动切到另一个可用区，用户无感知。数据库和缓存也做了跨可用区的主从复制。

第二是多厂商冗余。大模型服务不能只依赖一家厂商，否则厂商出问题，我们的服务就挂了。我们接入了至少三家厂商，任何一家出问题，流量可以切到其他家。虽然成本高一些，但保证了可用性。

第三是降级策略。当系统负载过高或者出现故障时，有分级降级策略。一级降级：关闭非核心功能（比如流式输出、详细日志），保证核心功能可用。二级降级：用缓存或者简化模型响应，保证服务不中断。三级降级：返回友好的错误提示，告诉用户稍后再试。

第四是熔断和限流。前面说过，熔断防止故障扩散，限流保护系统不被压垮。这两个机制配合，能在突发流量或者后端故障时，保证系统的核心功能可用。

第五是灾备演练。定期做灾备演练，模拟各种故障场景（可用区宕机、厂商API不可用、数据库故障、网络中断），验证系统的容错能力。演练中发现的问题，及时修复。

通过这些设计，我们的系统可用性达到了99.95%以上，全年 downtime 控制在几个小时以内。

监控和可观测性

高可用离不开完善的监控。我们建立了全链路的监控体系。

第一是指标监控。用Prometheus + Grafana，监控各个服务的QPS、延迟、错误率、资源使用率（CPU、内存、GPU）。设置了合理的告警阈值，异常时通过短信、电话、飞书通知值班人员。

第二是日志管理。所有请求都有详细的日志，包括请求参数、响应结果、耗时、调用的模型、费用。用ELK（Elasticsearch + Logstash + Kibana）做日志收集和分析，方便排查问题和做数据分析。

第三是链路追踪。用OpenTelemetry做分布式链路追踪，每个请求从接入层到调度层到模型服务层，完整记录下来。出问题的时候，能快速定位是哪个环节出了问题。

第四是成本监控。前面说过，实时监控各维度的成本，成本异常及时告警。这在价格战期间尤其重要，成本失控可能直接导致亏损。

第五是用户体验监控。监控用户的实际体验，比如首字延迟（从请求到第一个字返回的时间）、完整响应时间、用户满意度。这些指标比技术指标更能反映服务的质量。

踩过的坑

分享几个我们踩过的坑。

第一个坑是，缓存污染。语义缓存如果相似度阈值设得不好，会把不相关的结果返回给用户，导致回答错误。我们一开始阈值设得太低，出现了几次答非所问的情况，后来调整了阈值，加了人工审核机制，才解决。

第二个坑是，厂商API的隐性限制。有些厂商的API，文档里说支持多少QPS，但实际用的时候，超过一定量就会被限流或者降级。我们一开始没注意，流量上来之后频繁被限流，后来和厂商沟通，购买了更高的配额，同时做了多厂商分流。

第三个坑是，GPU资源的调度。自部署模型用GPU，GPU的调度很复杂，不同的模型需要不同的GPU型号，显存占用也不一样。我们一开始用Kubernetes的默认调度，经常出现GPU碎片（有GPU但凑不够一个模型需要的），后来用了专门的GPU调度器（比如Volcano），才解决。

第四个坑是，成本核算的复杂性。多模型、多厂商、多种计费方式（按token、按次、按时间），成本核算很复杂。我们一开始算不清楚每个请求的真实成本，后来做了一个统一的成本核算模块，实时计算每个请求的成本，才搞清楚。

第五个坑是，数据安全和合规。大模型处理的数据可能包含敏感信息，数据安全和合规很重要。我们踩过一次坑，有用户把敏感数据传给了大模型，导致数据泄露风险。后来加了敏感信息检测和过滤，和厂商签了数据保密协议，才解决。

写在最后

大模型价格战还在继续，调用量还在增长，架构也需要持续演进。

这篇文章分享的是我们目前的架构设计和实践经验，不一定是最优的，但都是在实战中踩坑踩出来的。每个团队的业务场景和资源条件不一样，架构设计也应该因地制宜。

但有几个原则是通用的：

第一，成本和性能要平衡。不能只追求性能不考虑成本，也不能只省钱牺牲体验。在价格战的背景下，找到最佳的性价比点，是架构设计的核心。

第二，高可用是底线。不管价格怎么降，服务不能挂。多冗余、多备份、多演练，保证系统的稳定性。

第三，可观测性是基础。没有完善的监控，就不知道系统在发生什么，出了问题也没法快速定位。监控要覆盖技术指标、业务指标、成本指标。

第四，持续优化。架构不是一成不变的，业务在变，技术在变，成本在变。要持续监控、持续分析、持续优化。

希望我们的经验能给做类似系统的朋友一些参考。如果你也在做大模型相关的架构，有什么经验或者问题，欢迎在评论区交流。