多业务模块共用同一个 DeepSeek API 额度时，常见问题是低优先级任务（如批量摘要、离线标注）把并发打满，高优先级任务（如在线问答、实时客服）只能排队或直接触发限流。本文从工程角度讨论如何把并发限制配置与业务优先级映射到调用层，给出可落地的配置结构和控制方法。需要说明的是，以下方案属于工程分析，具体并发上限、限流阈值和错误码应以 DeepSeek 官方文档和实际账号配额为准。

一、先明确控制目标

并发控制要解决三件事：第一，限制同一时刻真正在途的请求数，避免瞬时打满配额；第二，按业务优先级分配并发份额，保证高优先级任务始终有可用通道；第三，限流发生后按优先级决定重试、排队还是降级，而不是所有调用统一报错。

这三件事分别对应三个层次：配置层定义每个业务组的并发上限和优先级；调用层用信号量或队列控制实际并发数；错误处理层对限流错误做分级重试与降级。

二、配置结构：按业务分组声明并发份额

建议用一份结构化配置描述业务组，而不是把并发数散落在代码里。核心字段包括：业务组名、优先级、最大并发数、队列容量、超时时间、限流后的重试策略。示例（YAML 伪代码）：

api_groups:
  realtime_qa:
    priority: 1
    max_concurrency: 8
    queue_capacity: 32
    timeout_ms: 3000
    on_rate_limit: retry_then_fallback
  batch_summary:
    priority: 3
    max_concurrency: 2
    queue_capacity: 100
    timeout_ms: 30000
    on_rate_limit: queue_and_delay

配置层只声明意图，不直接发请求。调用层读取配置后，为每个业务组创建独立的并发控制器。这样调整配额时只改配置，不需要改业务代码。

三、调用层：信号量控制实际并发数

信号量是控制实际并发数最直接的手段。每个业务组持有一个信号量，初始值等于该组的 max_concurrency。请求进入时先尝试获取许可，获取成功才真正调用 API，调用结束后释放。伪代码：

sem = Semaphore(group.max_concurrency)

def call_group(group, payload):
    if not sem.acquire(timeout=group.queue_wait_ms):
        raise QueueTimeout(group.name)
    try:
        return api_call(payload)
    finally:
        sem.release()

这里有两个边界条件需要注意。第一，信号量只限制在途请求数，不限制请求速率；如果上游要求的是每秒请求数限制，还需要叠加令牌桶或滑动窗口。第二，队列等待时间要有上限，否则低优先级任务会长期占用线程或协程资源，拖垮整个服务。

对于高优先级业务组，建议预留一部分并发份额，不参与全局共享。例如总并发为 20 时，实时问答固定占 8，其余业务共享 12。这样即使批量任务排队，实时任务也不会被挤占。

四、优先级映射：队列调度与降级策略

当多个业务组竞争同一额度时，优先级应体现在两个位置：排队顺序和限流后的处理方式。

排队顺序上，可以为不同优先级设置不同的队列容量和等待上限。高优先级队列容量小但等待时间短，低优先级队列容量大但允许更长的延迟。调度器按优先级从高到低取任务，同级任务按先进先出。

限流后的处理上，建议按优先级分级：高优先级任务在限流后做有限次短间隔重试，重试仍失败则降级到备用模型或返回兜底结果；低优先级任务不立即重试，而是延迟后重新入队，避免重试风暴进一步加剧限流。

需要强调的是，重试必须带退避和抖动，且重试次数要有上限。对限流错误做无差别重试，只会让所有业务一起恶化。

五、可观测性与配置校验

并发控制上线后，至少需要观测三类指标：每个业务组的在途请求数、队列等待时长、限流错误次数。这些指标能回答“高优先级任务是否被挤占”这个核心问题。

配置校验也不可省略。启动时应检查各业务组 max_concurrency 之和是否超过账号允许的总并发，超过则拒绝启动或告警。同时校验优先级字段是否重复、队列容量是否为正数，避免配置错误在运行期才暴露。

六、工程取舍

按业务分组隔离并发，代价是额度利用率下降：高优先级组预留的份额在空闲时不能被低优先级任务使用。如果业务波动大，可以考虑在低优先级任务排队严重时临时借用预留份额，但借用必须有上限和回收机制，否则隔离就失去意义。

另一个取舍是复杂度。单进程内用信号量足够简单；多实例部署时，进程内信号量只能控制单实例并发，总量控制需要依赖外部协调或按实例数均分配额。选择哪种方案，取决于部署形态和对超额调用的容忍度。

总结来说，把并发限制配置化、把优先级映射到队列和降级策略、把限流错误分级处理，是多个业务共用 DeepSeek API 额度时较为稳妥的工程方法。具体阈值和错误处理细节，仍需以官方文档和实际配额为准。