DeepSeek V4 Pro 中转站：8 并发队列怎么排
01 · 先认清 Quanta 的在途上限：8 个请求同时在跑
做批量任务时，很多团队把「并发」理解成一个模糊的性能目标：越多越好，直到系统开始超时。Quanta 把这件事写成了明确数字：每个账户同时在途的请求为 8 个，每个密钥每分钟 120 个请求，单次请求体上限 25 MB，每个账户最多 20 个有效密钥。也就是说，队列的放行速度不该由「机器还有多少空闲线程」决定，而应由「账户此刻允许多少请求在途」决定。
这个区别很关键。假设你的团队每天要处理大量文档摘要任务，示例场景下，如果 8 个在途请求都平均耗时较长，那么把放行并发直接调到 32，得到的不是更快完成，而是请求在客户端一侧堆积、超时增加、失败重试互相踩踏。围绕在途上限设计队列，本质上是让上游保持可预期的节奏，让下游的等待时间可估算。
Quanta 的设计目标很明确：它面向有持续重负载的团队，并把并发、速率限制与账单规则直接公开，而不是留给使用者去猜。你可以在 https://quantarelay.com 查看说明，在控制台看到每一次调用的 token 用量与对应费用。
02 · 把队列拆成三层：入队、排队、放行
围绕在途上限，最实用的队列结构是三层。第一层是入队层，接收来自业务侧的请求并立即返回受理结果，不让调用方一直挂着连接。第二层是排队层，把任务放进队列，按优先级与到达时间等待。第三层是放行层，只负责在账户许可的窗口内把请求送出去。
- › 放行并发设为 8。这直接对应 Quanta 的在途上限，不必自行试探更高数值。
- › 出队后立刻占用一个在途名额。名额在收到完整响应后才释放，这样计数才与真实状态一致。
- › 把每分钟 120 次的速率限制放进放行层。即使并发没有跑满，也不能让短时间内的请求数越界。
- › 为长任务单独准备队列。流式请求没有总时长上限，只在上游静默 300 秒后结束，因此长输出任务可以占用在途名额更久，需要单独规划。
这一结构的好处是，队列参数与 Quanta 的限制一一对应。以后需要调整节奏，改的是队列配置，而不是去改业务代码。
03 · 用每分钟 120 次推算队列容量与等待时间
队列容量可以从两个数字反推：每分钟 120 次请求，以及同时在途 8 个请求。举例说明（仅为示例，不代表任何真实客户数据）：假设你的团队每天需要完成 50,000 次调用，折算到每个工作日 8 小时，就是平均每分钟约 104 次，已经接近 Quanta 每密钥 120 次的速率上限。此时若只使用一把密钥，队列会持续积压；可行思路是评估是否需要更多密钥，或者把非实时任务分散到时间更宽裕的时段。
等待时间也可以估算。示例场景下，假设平均单次请求耗时 4 秒，8 个在途名额每分钟大约能完成 120 次，与速率上限基本重合。如果平均耗时降到 2 秒，8 个名额每分钟可完成约 240 次，那么速率限制会先成为瓶颈；如果平均耗时升到 8 秒，每分钟只能完成约 60 次，并发则先成为瓶颈。先判断哪一种约束先到，再决定是优化请求耗时还是扩展队列宽度，比盲目加并发有效得多。
Quanta 在这一点上给出的信息是完整且可核对的：并发数、速率限制、请求体大小、有效密钥数量，全部是公开且强制执行的规则。团队据此做容量规划，不需要依赖经验值。
04 · 让重试与退避不破坏在途上限
队列系统最容易出问题的环节不是放行，而是重试。示例场景：上游短暂失败后立刻重试，如果重试请求也占用在途名额，就可能形成自我放大的拥塞。稳妥的做法是让重试回到排队层的队尾，按退避策略重新排队，而不是在放行层内部直接循环。
- › 失败请求先释放名额，再进入退避队列。避免失败任务空占在途资源。
- › 退避时长要大于平均耗时。否则重试会与新请求争抢同一批名额。
- › 对 429 与超时分开计数。速率触顶与上游无响应，对队列的影响并不相同。
- › 设置最大重试次数。超过上限就转入人工排查队列，而不是无限占用资源。
采用这种设计后，Quanta 的 8 个在途上限仍然是硬边界，重试只是让队列的节奏变慢，不会让它失控。
05 · 按量付费让队列优化的收益直接可见
队列做得更稳，下一步自然要问成本。Quanta 采用预付余额、按量付费，没有月费，也没有最低消费；每次调用按真实 token 计费，输入、输出、缓存写入与缓存读取分别定价，控制台会列出每次调用的 token 数与费用。
以 DeepSeek V4 Pro 为例，输入价格为每 100 万 token ¥10.40，输出为每 100 万 token ¥31.10，缓存读取为每 100 万 token ¥0.35，缓存写入暂无对应价格。示例说明：若某个队列场景每月消耗 1000 万 token，按输入与输出 3:1、无缓存命中的口径估算，费用约为 ¥518.33。同一场景换成 GPT-6.1 Sol，示例口径下每月 1000 万 token 约为 ¥295.00；换成 Qwen3.7 Plus，则约为 ¥82.50。这说明模型选择本身也是队列设计的一部分：把高吞吐、可容忍延迟的任务分流到不同模型，往往比单纯加并发更划算。
缓存读取的价格差异同样值得纳入队列规划。Claude Sonnet 5.5 的缓存读取为每 100 万 token ¥0.66，Claude Fable 5 为 ¥2.40，DeepSeek V4 Pro 为 ¥0.35。对于重复前缀较多的批处理任务，队列可以先按内容哈希归并，再决定是否触发缓存写入与缓存读取，让费用结构更清楚。
充值门槛同样明确：可选 ¥10.00、¥50.00、¥100.00、¥200.00、¥500.00 与 ¥1,000.00；注册即有 ¥2.80 试用额度。余额未使用部分可在充值后 15 天内退款，公司账户可通过银行转账付款，预报价与发票在控制台的 Contact 页面或 Messages 页面办理。
06 · 把不同协议与客户端接入同一套队列
队列设计完成之后，剩下的是接入。Quanta 提供 OpenAI 兼容接口（/v1）、Anthropic 原生接口与 Gemini 原生接口，一把密钥、一个余额即可横跨三类协议，API 基础地址为 https://api.quantarelay.com。对于批量任务团队来说，这意味着不同来源的工作负载可以共用同一个队列与同一套限流逻辑。
客户端配对需要严格对齐。Claude 模型只能通过官方 Claude Code 与 Claude Desktop 使用，且 Claude Code 需为 2.1.285 或更新版本；Gemini 模型走原生协议，通过 Gemini CLI 使用；Codex、Cursor、Cherry Studio、Cline、OpenCode、OpenAI SDK 与 cURL 则对应 GPT、DeepSeek 以及其他非 Claude、非 Gemini 的模型。DeepSeek V4 Pro 正属于可直接用于上述客户端与 SDK 的那一类，因此它适合承担通用队列的主力吞吐。
最后还有一条与合规直接相关的规则值得写进队列文档：用户发送的文本会保留 30 天，用于滥用处理与账单争议，之后删除；模型回答不予存储。如果队列任务涉及敏感内容，应当在入队前就完成脱敏，而不是依赖事后处理。
回到最初的问题：队列不是把并发开大，而是让每一个在途请求都有明确的位置。Quanta 把 8 个在途请求、每密钥每分钟 120 次请求、25 MB 请求体与 20 把有效密钥都写在明处，团队据此排出可解释的队列；再配合按量计费、公开的 token 单价与可办理的公司发票，容量规划与预算核对就能落在同一张表上。注册 Quanta，从 ¥2.80 试用额度开始，把第一个队列跑起来，再按实际账单校准节奏。