大模型烧穿预算？企业级 Token 限流与计费实战指南

大模型烧穿预算？企业级 Token 限流与计费实战指南

前言

兄弟们，说实话，搞技术这条路真是各种坑。咱们做开发的，说白了就是要不断踩坑、不断成长，这才是技术人的常态。

上个月，老张的项目刚上线。第二天财务直接找我。说账单爆了，服务器差点被烧穿。原因很简单，没人管大模型的 Token 消耗。客户随便调接口，模型随便跑。Token 像流水一样花出去，老板心在滴血。

这种“裸奔”状态，绝对不能忍。今天咱们就聊聊，怎么给大模型服务穿上“防弹衣”。既要管住流量，又要算清账目。这是企业级 AI 服务的必经之路。

一、 底层原理

1.1 核心机制

大模型调用的本质，就是买“智力”。Token 就是这种智力的计量单位。限流和计费，其实是一回事。就是控制每个租户能买多少“智力”。

核心逻辑在于“预扣减”和“实时校验”。你不能等请求跑完了再算钱。那样万一扣费失败，你就亏大了。必须在请求进来的一瞬间，锁定额度。这就好比去超市结账，得先扫码再拿走。

这里我们采用 Redis + Lua 脚本的方案。Redis 速度够快，能抗住高并发。Lua 脚本保证了操作的原子性。不会出现两个请求同时扣钱，结果扣重了的情况。架构流程长这样：

sequenceDiagram participant Client as 租户客户端 participant Gateway as API 网关 participant Redis as Redis 计数器 participant Model as 大模型服务 participant DB as 计费数据库 Client->>Gateway: 发起 AI 请求 Gateway->>Redis: 执行 Lua 脚本(预扣减) alt 额度充足 Redis-->>Gateway: 返回成功 Gateway->>Model: 转发请求 Model-->>Gateway: 返回结果 Gateway->>DB: 异步记录账单 else 额度不足 Redis-->>Gateway: 返回失败 Gateway-->>Client: 返回 429 限流错误 end

这种设计的优势很明显。响应速度在毫秒级，用户无感知。数据一致性高，不会少算钱。而且 Redis 天然支持过期时间，适合做周期重置。

1.2 与同类方案的对比

市面上方案不少，咱们挑两个主流的比划比划。

别为了省那一点 Redis 成本，去挑战数据库的并发极限。那是给 DBA 找麻烦，也是给自己挖坑。

二、 快速上手

别整那些虚的，直接上代码。咱们用 Java 写一个最小可运行的 Demo。3 分钟让你看到效果。你需要准备一个 Redis 实例。然后引入 Spring Data Redis 依赖。

import org.springframework.data.redis.core.StringRedisTemplate; import org.springframework.stereotype.Service; import java.util.Collections; @Service public class TokenLimitService { // 注入 Redis 模板，这是操作 Redis 的标准姿势 private final StringRedisTemplate redisTemplate; public TokenLimitService(StringRedisTemplate redisTemplate) { this.redisTemplate = redisTemplate; } /** * 尝试扣减 Token 额度 * @param tenantId 租户 ID，比如 "company_a" * @param cost 需要消耗的 Token 数量 * @param limit 租户的总限额 * @return 是否扣减成功 */ public boolean tryConsume(String tenantId, int cost, int limit) { // 定义 Redis Key，加上前缀防止冲突 String key = "ai:quota:" + tenantId; // 编写 Lua 脚本，保证原子性 // 脚本逻辑：先判断剩余值，再决定扣不扣 String luaScript = "local current = tonumber(redis.call('get', KEYS[1]) or '0')" + "if current >= tonumber(ARGV[1]) then" + " redis.call('decrby', KEYS[1], ARGV[1])" + " return 1" + "else" + " return 0" + "end"; // 执行脚本，传入 Key 和参数 // cost 是消耗量，limit 在这里其实用于初始化，实际逻辑可更复杂 Object result = redisTemplate.execute( new DefaultRedisScript<>(luaScript, Long.class), Collections.singletonList(key), String.valueOf(cost) ); // 判断返回值，1 代表成功，0 代表失败 return Long.valueOf(1).equals(result); } }

这段代码看着简单，其实门道不少。Lua 脚本里用了decrby，这是原子递减。避免了先get再set的竞态条件。如果两个线程同时进来，Redis 会排队处理。绝对不会出现超卖的情况。

三、 核心 API / 深水区

3.1 核心方法速查

除了基础的扣减，生产环境还需要更多功能。比如查询剩余额度，或者重置额度。我把常用的几个方法整理了一下。

这些方法最好封装成一个接口。别让业务代码直接操作 Redis Key。万一哪天你换了存储方案，改起来不心累。

3.2 生产级配置

光有扣减逻辑还不够，异常处理必须跟上。Redis 挂了怎么办？网络超时怎么办？这些情况在生产环境天天发生。一定要加超时控制和降级策略。

// 生产级配置示例 @Bean public RedisTemplate<String, String> redisTemplate() { RedisTemplate<String, String> template = new RedisTemplate<>(); // 设置连接超时，别让客户无限等待 template.setTimeout(Duration.ofMillis(500)); // 设置序列化方式，防止乱码 template.setStringSerializer(new StringRedisSerializer()); return template; }

如果 Redis 连不上，请求是直接拒绝还是放行？这取决于你的业务容忍度。通常建议“故障开放”，即 Redis 挂了先让请求过。但要记录日志，事后对账。千万别因为限流组件挂了，把整个业务搞瘫痪。

3.3 高级定制

有些租户是 VIP，需要特殊待遇。比如他们不受限流限制，或者单价不同。这时候需要引入“租户等级”概念。在 Lua 脚本里增加判断逻辑。

-- 伪代码示例 local tier = redis.call('get', KEYS[2]) -- 获取租户等级 if tier == 'VIP' then return 1 -- 直接放行 end -- 普通逻辑继续执行...

这样就能实现细粒度的控制。不同等级，不同策略。这才是企业级服务该有的样子。

四、 实战演练

光说不练假把式。咱们模拟一个真实场景。某公司买了 1000 万 Token 的包年套餐。现在他们发起一个聊天请求。系统需要判断额度，扣费，然后调用模型。

@Service public class AiChatService { private final TokenLimitService limitService; private final LlmClient llmClient; // 假设这是调用大模型的客户端 private final BillingService billingService; // 计费服务 public AiChatService(TokenLimitService limitService, LlmClient llmClient, BillingService billingService) { this.limitService = limitService; this.llmClient = llmClient; this.billingService = billingService; } public String chat(String tenantId, String prompt) { // 1. 预估消耗，这里简单设为 1000 Token // 实际生产中应根据 prompt 长度估算 int estimatedCost = 1000; // 2. 预扣减额度 // 如果返回 false，说明没钱了，直接报错 boolean consumed = limitService.tryConsume(tenantId, estimatedCost); if (!consumed) { throw new BusinessException("额度不足，请充值后再试"); } try { // 3. 调用大模型 // 注意：这里要捕获模型调用异常 String response = llmClient.generate(prompt); // 4. 实际扣费 // 大模型返回的 usage 才是真实消耗 // 这里需要回滚多扣的部分，或者记录差额 billingService.recordBill(tenantId, estimatedCost); return response; } catch (Exception e) { // 5. 异常回滚逻辑 // 如果模型调用失败，要把预扣的额度退回去 limitService.refund(tenantId, estimatedCost); throw new BusinessException("模型服务暂时不可用"); } } }

这段代码展示了完整的闭环。先锁钱，再办事，最后结账。如果有意外，还得退钱。逻辑看着简单，写起来全是细节。特别是回滚逻辑，很多人容易忘。一旦忘了，用户额度就凭空消失了，投诉会炸锅。

五、 避坑指南与最佳实践

做了这么多年的架构，坑踩了不少。总结几条血泪经验，你们拿去用。

💡技巧：使用 Lua 脚本减少网络 RTT
不要在一个业务逻辑里多次请求 Redis。把判断、扣减、记录日志封装在一个脚本里。网络往返次数越少，延迟越低。

⚠️警告：注意 Token 的精度问题
大模型的 Token 计算有时会有误差。预扣减和实际消耗往往对不上。建议设置一个“误差容忍池”，比如 5%。不要为了几分钱的差额跟用户较劲。

✅推荐：异步记录账单
扣减额度是同步的，必须快。但写数据库账单可以异步。用消息队列把计费信息发出去，慢慢处理。别让用户等着数据库写入完成。

⚠️警告：防止 Lua 脚本死锁
虽然 Redis 是单线程的，但 Lua 脚本执行期间会阻塞。脚本里千万别写死循环，也别调用耗时操作。脚本执行时间最好控制在 10 毫秒以内。

💡技巧：监控告警要跟上
额度扣减速率、Redis 命中率、扣费失败率。这些指标必须上 Grafana 看板。一旦异常波动，立刻报警。别等财务来找你，你得比财务先知道。

六、 综合实战演示

最后，咱们把上面的点串起来。写一个完整的配置类，直接能抄到项目里用。包含 Redis 配置、Lua 脚本定义、Service 封装。

@Configuration public class AiBillingConfig { // 定义 Lua 脚本的 Bean，方便复用 @Bean public RedisScript<Long> tokenConsumeScript() { DefaultRedisScript<Long> script = new DefaultRedisScript<>(); // 脚本内容，注意转义 script.setScriptText( "local current = tonumber(redis.call('get', KEYS[1]) or '0')" + "if current >= tonumber(ARGV[1]) then" + " redis.call('decrby', KEYS[1], ARGV[1])" + " return 1" + "else" + " return 0" + "end" ); script.setResultType(Long.class); return script; } // 生产环境建议用 Lettuce 客户端，性能更好 @Bean public RedisTemplate<String, String> productionRedisTemplate() { RedisTemplate<String, String> template = new RedisTemplate<>(); // 配置连接池，防止连接耗尽 GenericObjectPoolConfig poolConfig = new GenericObjectPoolConfig(); poolConfig.setMaxTotal(50); poolConfig.setMaxIdle(20); LettuceConnectionFactory factory = new LettuceConnectionFactory(); factory.setPoolConfig(poolConfig); // 设置超时，避免雪崩 factory.setTimeout(Duration.ofMillis(300)); template.setConnectionFactory(factory); template.setStringSerializer(new StringRedisSerializer()); return template; } }

这套配置加上前面的 Service。基本就能应付 90% 的企业级场景。剩下的就是根据业务微调。比如增加黑名单机制，或者按 IP 限流。核心思想不变：原子性、高性能、可观测。

总结

大模型服务，算力是成本，Token 是货币。管不住 Token，就是管不住成本。

Redis Lua 方案，是目前性价比最高的选择。它兼顾了速度和一致性。

但记住，技术只是手段，业务才是目的。