为什么从「并发」而不是「模型」入手
本地部署最常见的误区是：换更大的模型、换更新的量化，却从不调并发。实际上单机 Token 产出 ≈ 有效并发数 × 单请求解码速度 × 时间。模型定了之后，能动的杠杆几乎全在并发与批处理上。
2026 年的现实是：Ollama 适合「单人/小团队交互」，vLLM 适合「多请求吞吐」，两者不是二选一，而是前后台分工。
操作步骤
第一步：用 Ollama 做前台限流入口
- 安装 Ollama 后，通过环境变量控制并发与排队：
OLLAMA_NUM_PARALLEL：单个模型允许同时处理的请求数。设为 1 时请求串行，适合显存紧张；设为 2~4 时交互更顺，但显存占用上升。OLLAMA_MAX_QUEUE：等待队列长度上限，超出即拒绝，避免请求无限堆积把延迟拖垮。OLLAMA_MAX_LOADED_MODELS：同时驻留显存的不同模型数量。多模型切换会带来加载抖动，建议只保留 1~2 个常用模型。
- 用
ollama serve启动后，通过/api/generate或 OpenAI 兼容的/v1/chat/completions接入。 - 前台只跑交互式任务（对话、补全、代码助手），把长文本批处理全部推到后台。
第二步：用 vLLM 做后台吞吐引擎
- 以 OpenAI 兼容服务方式启动，例如
vllm serve <model> --max-model-len <长度> --gpu-memory-utilization 0.85 --max-num-seqs <N>。 --max-num-seqs决定同时批处理的序列数，是吞吐的核心旋钮；--gpu-memory-utilization决定预留给 KV cache 的显存比例，直接约束可承载并发。- 开启 continuous batching（vLLM 默认行为），让新请求在旧请求解码间隙插入，而不是等整批结束。
- 量化权重（AWQ / GPTQ / FP8 视硬件而定）能显著降低显存占用，从而把
--max-num-seqs调高，但要注意低比特量化对长上下文质量的折损。
第三步：压测出「可计量产能」
- 用固定 prompt 长度 + 固定输出长度做基准，记录：每秒输出 Token 数、首 Token 延迟（TTFT）、P95 延迟。
- 逐步提高并发（1→2→4→8…），画出「并发—吞吐」与「并发—延迟」两条曲线。
- 找到吞吐趋于平缓、延迟开始陡升的拐点，把生产并发设在拐点略下方。这个拐点值就是你这条本地供给线的「额度」。
- 把压测结果写进配置文件或文档，模型或硬件变动后重跑。
第四步：前后台路由与监控
- 用一个轻量网关（如 LiteLLM Proxy 或自写 FastAPI）按任务类型分流：交互请求打 Ollama，批处理请求打 vLLM。
- 记录每次请求的输入/输出 Token 数，按日汇总，得到「本地 Token 产出量」指标。
- 设置队列长度与显存占用告警，避免 OOM 或请求雪崩。
注意事项
- 显存是硬约束：并发调高会线性推高 KV cache 占用，超过
--gpu-memory-utilization上限会直接 OOM 或触发抢占。 - 量化不是免费的：4bit 量化能换更高并发，但在长上下文、数学与代码任务上质量折损明显，建议按任务分级使用。
- Ollama 与 vLLM 不要抢同一张卡：同卡混跑会互相挤占显存，最好分卡或分时段。
- 本地 Token 的「免费」是有边界的：省的是 API 调用费，付出的是电费、硬件折旧与运维时间；小规模高频场景才划算。
- 合规与数据：本地部署的优势是数据不出域，但对外提供服务时仍需遵守模型许可证（如 Llama 系列的自定义许可、Apache 2.0 模型的商用条款）。
适用场景
- 团队内部代码助手、文档摘要、批量翻译等高频低价值任务。
- 对数据隐私敏感、不能调用外部 API 的场景。
- 需要离线或弱网环境下持续产出 Token 的场景。
- 作为外部 API 的降级备份：外部额度用尽或限速时自动切到本地。
不适用场景
- 需要前沿模型能力（复杂推理、多模态）的任务。
- 一次性、低频、对延迟不敏感的长任务——直接买 API 更省心。
- 没有 GPU 或只有消费级小显存显卡、又要求高并发的场景。