本地大模型API并发控制，防止算力过载

知识分享

2026-09-27 10:00

18 阅读

本地大模型API并发控制的核心目标是限制同一时间进入模型的请求数量，避免GPU显存溢出或CPU满载导致服务崩溃。
本文面向零基础用户，以Ollama为例，通过Nginx反向代理和限流模块，配合Ollama自身参数，给出可直接执行的配置步骤，最终验证并发被限制、服务稳定响应。

判断你的场景是否真的需要限流

如果出现以下情况，就需要做并发控制：

多个客户端同时调用API，GPU显存瞬间占满，返回CUDA out of memory。
CPU推理服务响应时间从几百毫秒飙升到数秒，甚至无响应。
日志中频繁出现连接超时或502错误。

限流不是提高性能，而是保证服务不崩溃。 对于单卡或低配CPU环境，建议最大并发数控制在1~2；
多卡或高性能CPU可适当放宽，但需实测。

前置准备：环境与工具确认

假设你已经在Linux服务器上安装了Ollama，并且API默认监听127.0.0.1:11434。
如果尚未安装，可参考Ollama官方文档完成安装。

检查Ollama服务状态：

systemctl status ollama
curl http://127.0.0.1:11434/api/tags

第二条命令应返回模型列表。
若返回连接拒绝，说明Ollama未运行或端口不对。

下一步安装Nginx，用于反向代理和限流：

# Ubuntu/Debian
sudo apt update && sudo apt install -y nginx
# CentOS/RHEL
sudo yum install -y nginx

启动并设置开机自启：

sudo systemctl enable --now nginx

配置Ollama自身并发参数

Ollama默认允许一定并发，但可以通过环境变量调整。
编辑Ollama服务配置：

sudo systemctl edit ollama

在编辑器中添加以下内容（注意不要删除原有配置）：

[Service]
Environment="OLLAMA_NUM_PARALLEL=1"
Environment="OLLAMA_MAX_LOADED_MODELS=1"

OLLAMA_NUM_PARALLEL：每个模型允许的并行请求数，设为1表示串行处理。
OLLAMA_MAX_LOADED_MODELS：同时加载的模型数，设为1避免多个模型争抢显存。

保存后重载并重启Ollama：

sudo systemctl daemon-reload
sudo systemctl restart ollama

验证环境变量已生效：

systemctl show ollama | grep Environment

应看到OLLAMA_NUM_PARALLEL=1和OLLAMA_MAX_LOADED_MODELS=1。

用Nginx实现请求队列与限流

仅靠Ollama参数还不够，因为大量请求仍会堆积在Ollama内部。
Nginx可以作为前置队列，限制同时转发到Ollama的请求数。

创建Nginx配置文件/etc/nginx/conf.d/ollama-proxy.conf：

upstream ollama_backend {
    server 127.0.0.1:11434;
    keepalive 32;
}

# 定义限流区域，以客户端IP为键，每秒最多2个请求，突发不超过5个
limit_req_zone $binary_remote_addr zone=ollama_limit:10m rate=2r/s;

server {
    listen 8080;
    server_name _;

    location / {
        limit_req zone=ollama_limit burst=5 nodelay;
        limit_req_status 429;

        proxy_pass http://ollama_backend;
        proxy_http_version 1.1;
        proxy_set_header Connection "";
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_read_timeout 300s;
        proxy_send_timeout 300s;
    }
}

关键参数说明：

rate=2r/s：每个IP每秒允许2个请求，可根据实际算力调整。
burst=5：允许突发5个请求排队，超出直接返回429。
nodelay：突发请求立即处理，不延迟。
limit_req_status 429：被限流时返回429状态码，便于客户端识别。

测试Nginx配置并重载：

sudo nginx -t
sudo systemctl reload nginx

现在API地址变为http://服务器IP:8080，原来的11434端口建议只监听本地，避免绕过限流。

避坑与调优要点

限流阈值不是越高越好。 需要根据模型大小和硬件实测。
例如7B模型在单张消费级显卡上，并发2可能就会显存不足。
建议从rate=1r/s、burst=2开始测试。

不要忽略超时设置。 大模型生成文本耗时较长，proxy_read_timeout建议设为300秒以上，否则长回答会被Nginx切断。

注意Nginx的limit_req_zone键选择。 使用$binary_remote_addr按IP限流，如果所有请求来自同一台内网机器，则所有请求共享同一个限流桶。
此时可以改用$http_x_api_key或$server_name等，但需要客户端传递对应头。

Ollama的并行参数与Nginx限流叠加时，以更严格的为准。 例如Nginx允许2并发，Ollama允许1并发，实际同时处理的请求数为1，其余在Ollama内部排队。

验证并发控制是否生效

使用curl模拟并发请求。
先准备一个简单的请求文件：

cat > /tmp/request.json <<'EOF'
{
  "model": "llama3",
  "prompt": "你好",
  "stream": false
}
EOF

然后使用xargs发起5个并发请求：

seq 5 | xargs -P 5 -I {} curl -s -o /dev/null -w "%{http_code}\n" -X POST http://127.0.0.1:8080/api/generate -H "Content-Type: application/json" -d @/tmp/request.json

观察返回的状态码。
如果限流生效，部分请求会返回429，其余返回200。
同时查看Ollama日志：

journalctl -u ollama -f

日志中不应出现显存溢出或崩溃信息。
GPU使用率可通过nvidia-smi观察，应保持在合理范围，不会瞬间冲顶。

最终验证标准： 并发请求下服务不崩溃，超出限流的请求快速失败并返回429，正常请求能完整生成回答。

常见疑问

限流后客户端收到429怎么办？ 客户端应实现重试机制，等待1~2秒后重新发送。
也可以在Nginx中配置limit_req_status 503并配合error_page返回友好提示。

能否针对不同API路径设置不同限流？ 可以。
在location块中单独定义limit_req，例如对/api/generate限制更严，对/api/tags放宽。

Ollama重启后配置丢失？ 使用systemctl edit ollama写入的配置会保存在/etc/systemd/system/ollama.service.d/override.conf，不会丢失。
修改后需daemon-reload和restart。

本地大模型API并发控制的关键是组合使用Ollama并行参数和Nginx限流，先从小阈值开始压测，再逐步调整到硬件能承受的极限。
完成配置后，建议持续观察GPU显存和请求延迟，确保长期稳定运行。

AI辅助写CMS采集正则，快速提取网页内容

大模型微调算力需求测算，训练最低显存