如何基于Azure无服务器技术实现Azure OpenAI的高效TPM限流有序队列？

核心架构选型 #

采用Azure Service Bus作为消息队列保证请求的FIFO顺序，搭配Azure Functions作为无服务器消费执行单元，自动实现并发扩缩容。核心依赖组件：

• Azure Service Bus 队列：存储OpenAI请求消息，严格保证入队顺序，支持消息调度、延迟重试特性
• Azure Functions：作为消费端，触发执行OpenAI调用逻辑
• Azure Redis Cache：维护分布式令牌计数器，多实例共享当前分钟内已消耗的令牌数

TPM限流调度策略 #

针对TPM（每分钟令牌数）限制，分两种调度方案实现高效利用配额：

基础顺序调度方案 #

严格按入队顺序组合可并发执行的请求，避免超限额：

1. 消费端从Service Bus队列拉取消息，读取每个请求的预计算令牌数
2. 实时查询Redis中的当前分钟令牌消耗值：
   • 组合请求1（2000）+请求2（5000），总令牌7000 < 10000TPM阈值，并发执行，更新Redis计数器为7000
   • 处理请求3时，7000+5000=12000>10000，触发等待逻辑：将请求3重新调度为1分钟后可见的消息，等待Redis计数器自动过期重置
   • 1分钟后，Redis计数器重置，执行请求3+请求4（5000+2000=7000<10000），更新计数器为7000
   • 处理请求5时，7000+7000=14000>10000，再次调度延迟1分钟后执行

智能贪心调度方案 #

最大化利用分钟内剩余令牌，在保证先到请求优先处理的前提下调整并发组合：

1. 拉取一批待处理消息，按入队顺序做贪心组合：
   • 初始计数器为0，选择请求1（2000）、请求2（5000）、请求4（2000），总令牌9000 < 10000，并发执行，更新计数器为9000
   • 剩余请求3（5000）无法加入当前组合，调度延迟1分钟后执行
   • 1分钟后计数器重置，执行请求3；再次等待1分钟后执行请求5
2. 注：贪心组合需保证先入队的请求优先获得执行机会，仅当高优先级请求无法在当前窗口执行时，才利用剩余配额处理后续请求

重试策略的竞争规避 #

直接重试会导致请求乱序（如请求5重试后先于请求3完成），需通过以下方式规避：

1. 消息顺序标识：所有入队消息携带全局唯一的入队序列ID，按递增顺序生成
2. 延迟重试队列：请求调用OpenAI触发限流错误时，不直接重新入队主队列，而是发送到延迟重试队列，并保留原序列ID
3. 顺序校验逻辑：消费重试队列消息前，查询主队列和重试队列中是否存在序列ID更小的未处理消息，仅当所有更早的消息都已处理完成，才执行当前重试消息
4. 会话绑定：使用Azure Service Bus的会话功能，将同一业务流的请求绑定到同一个会话，重试消息回到原会话，保证会话内的严格顺序

关键实现细节 #

• 令牌数预计算：消息入队时，根据prompt长度、预期completion长度提前估算令牌数，避免消费端重复计算
• 分布式计数器：用Redis的过期键实现分钟级令牌计数器，键的过期时间设为1分钟，自动完成重置
• 消息调度：利用Azure Service Bus的ScheduleMessageAsync方法，将需要等待的消息调度到指定时间后可见，避免消费端阻塞等待
• 并发控制：Azure Functions的Service Bus触发器可配置并发度，结合令牌计数器动态调整并发数，避免超限额

内容的提问来源于stack exchange，提问作者Bonen