Gradio 并发请求怎么设置 concurrency_limit

Gradio 里的 concurrency_limit 控制的是“同一个事件监听器同时运行多少个请求”，不是反向代理的副本数量。默认情况下，一个事件通常只有一个运行槽位；多人同时点击时，后来的请求会先排队。最小改法是在事件绑定处直接写 concurrency_limit=4，而 GPU 任务更适合再配合 concurrency_id 共享一个有限队列。

官方地址：https://www.gradio.app/

结论：轻量、无共享资源的事件可以提高整数上限；占用同一张 GPU 的多个事件，应使用同一个 concurrency_id，让它们共同受一个较小的上限约束。

默认并发为什么看起来只有一个

Gradio 会为事件监听器建立队列。没有显式指定时，事件通常按一个请求一个请求地执行，所以单用户测试正常，多人同时请求却会看到等待。这里的“并发”是后端事件执行槽位，不等于浏览器连接数，也不等于机器可以承受的最大用户数。

因此，先区分两件事：如果只是按钮事件本身处理得慢，可以调整监听器的上限；如果所有事件都要争用同一块 GPU，则不能给每个事件都随意加大数值，否则队列虽短了，显存和推理资源却会更快耗尽。

单个事件怎么设置并发上限

把限制直接写在事件绑定方法上即可。下面的例子把生成按钮限制为最多同时处理 4 个请求；第 5 个及之后的请求仍会进入队列。代码中的睡眠只是模拟耗时任务，不代表真实推理结果。

import time
import gradio as gr

def generate(prompt: str) -> str:
    # 用短暂等待模拟模型或文件处理的耗时，实际项目替换为推理函数。
    time.sleep(2)
    return f"已处理：{prompt}"

with gr.Blocks() as demo:
    prompt = gr.Textbox(label="提示词")
    output = gr.Textbox(label="结果")
    button = gr.Button("生成")

    # 这个事件最多同时运行 4 个请求，超出的请求留在事件队列中。
    button.click(generate, inputs=prompt, outputs=output, concurrency_limit=4)

demo.queue(default_concurrency_limit=1)
demo.launch()

这里的关键点是：显式写在 button.click() 上的 4 会优先于全局默认值；demo.queue(default_concurrency_limit=1) 只负责给没有单独设置限制的事件提供默认值。CPU 轻任务可以从较小整数开始，GPU 推理则应结合显存、批大小和单次耗时压测后再调。

多个事件怎么共享 GPU 队列

假设“文生图”和“放大”两个按钮都会调用 GPU。分别给它们设置 concurrency_limit=2，并不等于整台 GPU 最多只跑两个任务，因为两个事件可能各有自己的队列。此时给它们相同的 concurrency_id，就能把它们放到同一个并发边界中。

import gradio as gr

def generate(prompt: str) -> str:
    # 这里代表占用 GPU 的生成函数，真实代码中应复用模型对象。
    return f"生成：{prompt}"

def upscale(image: str) -> str:
    # 放大任务也占用同一资源，因此加入同一个共享队列。
    return f"放大：{image}"

with gr.Blocks() as demo:
    prompt = gr.Textbox(label="提示词")
    image = gr.Textbox(label="图像标识")
    generate_btn = gr.Button("生成")
    upscale_btn = gr.Button("放大")

    # 两个事件共享 gpu_queue，整个共享边界最多保留 2 个并发槽位。
    generate_btn.click(generate, prompt, image, concurrency_limit=2, concurrency_id="gpu_queue")
    upscale_btn.click(upscale, image, image, concurrency_id="gpu_queue")

demo.queue()
demo.launch()

共享组里要把资源相同的事件放在一起。一个事件明确设置了较低的上限时，共享组会受较小限制影响；不要把 CPU 快速格式化任务和 GPU 推理任务无差别地塞进同一组，否则会让本来不需要等待的请求也被 GPU 队列拖慢。

整数、None 和 default 怎么选

concurrency_limit=2 表示最多同时运行 2 个该事件；None 表示不设置并发上限，适合真正由外部服务自行限流、且本地不持有稀缺资源的轻量调用；default 表示使用 Blocks.queue() 提供的默认值。对模型推理不要因为“取消排队”就直接使用 None，无上限并发可能带来显存溢出、上下文切换和更长的总耗时。

可以按下面的速查规则起步：

常见问题

把 concurrency_limit 调大后，为什么显存更容易爆？

因为它允许更多执行同时进入函数；如果每个请求都会加载输入、创建中间张量或保留生成结果，峰值资源会随并发上升。先把同一 GPU 的事件用 concurrency_id 合并，再逐级增加整数。

设置了 concurrency_limit，为什么请求还是等待？

等待可能来自共享队列、函数本身的耗时、max_size 队列容量，或外部模型服务的限流。先确认事件是否使用了相同的 concurrency_id，再看机器资源；不要把所有等待都归因于单个监听器的默认值。

什么时候可以使用 None？

只有当事件不持有本地稀缺资源，并且下游服务有自己的稳定限流策略时才适合。GPU 推理、CPU 密集型转换和会大量占用内存的任务，通常应该保留明确的整数上限。

最终可以记住一句话：先按事件设置最小可用的整数上限；多个事件争抢同一资源时用 concurrency_id 合并；只有真正可安全扩张的轻量任务，才考虑 None。