“这台机器能服务多少人？”不能只看内存大小或模型参数量。要先说清“服务”是能启动、能同时回答几条请求，还是在高峰时仍满足目标延迟。用户数还取决于每个人多久问一次、每次输入和输出多长，以及能接受多长等待。本文用一台 M1 Max Mac 跑两种本地模型，比较短批次并发表现，并给出如何为真实业务重新压测的方法。
先把“多少人”拆成三个问题
| 问题 | 要测什么 | 单看它能否得到用户数 |
|---|---|---|
| 模型能否启动 | 权重、运行时和上下文是否能放入可用内存/显存 | 不能 |
| 同时几条请求 | 请求并发、等待队列和超时情况 | 不能 |
| 高峰能服务多少人 | 真实请求节奏、长短输入输出和目标延迟下的持续表现 | 这是容量评估要回答的事 |
在线用户不等于同时生成的请求。一个有 100 位注册用户的内部助手，可能大多数时间只有少量人提问；反过来，活动开始时几十个人同时发长文，也可能一下把队列堆满。先记录高峰到达率、输入与输出长度、可接受的首字和完整回答时间，再选测试负载。
本机测试环境
| 项目 | 本次配置 | 说明 |
|---|---|---|
| 设备 | Apple M1 Max、64GB 统一内存、macOS 27.0.1 | 不是 NVIDIA 云 GPU |
| 服务 | Ollama 0.35.1，127.0.0.1:11434 |
只调用本机回环 API |
| 小模型 | Qwen3 0.6B Q8_0，磁盘模型约 639MB，运行时约 910MB | 本机已有标签 boxai-basics-qwen3-06b-q8:latest |
| 大模型 | Gemma4 12B Q4_K_M，磁盘模型约 7.1GB，运行时约 7.7GB | 本机已有标签 gemma4-12b:latest |
| 请求 | 上下文 2048、最多生成 128 token、每批 4 条 | 使用固定虚构提示，禁用思考输出 |
这些数字是本机当时的观察值，不是购买建议。运行时占用还受上下文长度、并发、模型实现和其他进程影响；权重文件能下载下来，也不代表高峰时一定有足够内存。Ollama 官方说明，并行请求可能为每个并发序列占用额外上下文内存，队列和并发设置需要结合可用内存调整。查看 Ollama 并发与内存说明
本文没有使用付费云 GPU；vLLM 官方资料用于说明怎样压测 NVIDIA 服务，不代表本文已在 vLLM 或云机器上复现。Gemma4 的模型标签和说明以官方模型页为准。
跑一轮本机短批次
练习包里有标准库脚本、环境快照和原始结果：下载私有模型服务容量练习包。下载并解压后，在包含 README.md 和 benchmark.py 的文件夹打开终端。测试只发固定的合成提示，不包含客户或个人资料。脚本默认访问回环地址，不修改 Ollama 配置：
python3 benchmark.py --self-check
python3 benchmark.py --model gemma4-12b:latest --requests 4 --output results.json--model 要换成 ollama list 中的实际标签。脚本先预热一次，再分别以并发 1、2、4 各发一批 4 个请求。每个请求的输入长度相近，输出上限为 128 token。它适合初步观察，不是长时间压力测试。
脚本会把本次模型保持加载 10 分钟，减少连续几批测试的重复加载时间。测试结束后用 ollama ps 查看当前进程；不再测试时，只停止本次指定的模型标签：
ollama stop gemma4-12b:latest如果你用的是其他标签，把命令里的名称换成 --model 对应的值。
一次实测看到的差异
| 模型 | 并发 | 4 条请求总耗时 | 每条请求中位耗时 | 本批输出速度合计 |
|---|---|---|---|---|
| Qwen3 0.6B Q8_0 | 1 | 4.943 秒 | 1.417 秒 | 83.36 token/秒 |
| Qwen3 0.6B Q8_0 | 2 | 1.984 秒 | 0.992 秒 | 207.63 token/秒 |
| Qwen3 0.6B Q8_0 | 4 | 2.053 秒 | 1.276 秒 | 200.67 token/秒 |
| Gemma4 12B Q4_K_M | 1 | 18.444 秒 | 3.867 秒 | 19.09 token/秒 |
| Gemma4 12B Q4_K_M | 2 | 28.768 秒 | 14.270 秒 | 12.24 token/秒 |
| Gemma4 12B Q4_K_M | 4 | 28.727 秒 | 17.966 秒 | 12.25 token/秒 |
每档并发只有一批 4 个请求，且实测回答为 88–103 个输出 token。这个样本里，小模型并发 2 的批次比并发 1 快；并发升到 4 没有继续变快。12B 模型并发增加时，每条请求等待变长。本次结果只能说明这台机器、这两个模型和这组短请求的单次表现。
**不要把表格中的“每分钟请求数”外推成持续吞吐或在线人数。**没有重复批次、峰值流量、长上下文、混合输出长度、稳定运行时段、错误率或 p95 延迟；模型刚加载和已预热的表现也不同。完整请求参数与原始计时在练习包的 evidence/ 目录。
估算用户容量时要补哪些数据
先定义服务目标，再压测。建议至少准备：
- 硬件和模型：CPU、GPU、显存或统一内存、模型精确版本与量化方式、上下文长度，以及机器上其他进程占用。
- 真实请求形状：高峰每秒/每分钟到达多少请求、输入长度分布、输出长度分布、是否有工具调用和多轮上下文。
- 延迟和可靠性目标：首 token 延迟、整段回答延迟的 p50/p95、允许的排队时间、超时和错误上限。
- 持续负载：逐步提高到达率并维持一段时间，记录吞吐、队列长度、内存/显存、温度、错误和尾延迟；重复几轮并检查冷启动与预热差异。
得到满足目标的持续请求率后，再结合每位活跃用户的平均提问频率估一个范围。比如“高峰 1.5 个请求/秒”要除以“每位同时活跃用户每秒发出多少请求”，并为突发、长回答和波动留余量。这个换算只用于初步容量规划，最终仍需把目标负载压到真实部署机器上；不要用一次短批次算出一个看似精确的“可服务 500 人”。
内存也要按并发重新核算。模型权重只是底数；上下文越长、同时处理的序列越多，KV cache 等运行时内存通常也越多。Ollama 提供并发和队列相关设置，但调大并发并不会凭空增加算力或内存；先用小步负载实测，避免请求积压或服务拒绝新请求。查看 Ollama FAQ · 查看 Chat API 参数
若目标机器是 NVIDIA GPU，可以用 vLLM 的 bench serve 按请求速率、最大并发、提示长度和输出长度构造负载，再看吞吐和延迟变化。官方的并行/扩展文档也说明了模型切分和 KV cache 容量等因素。仍要在目标硬件、目标模型和真实请求分布上重新测试，不能从理论显存容量直接推导在线用户数。vLLM 压测 CLI · vLLM 并行与扩展
给客户报价前的检查清单
- 确认“多少人”指注册人数、日活人数、峰值同时提问人数，还是有延迟承诺的请求容量。
- 让客户提供经过授权、去标识化的代表性请求；没有业务数据时先用合成数据并标清假设。
- 在计划交付的硬件、模型、量化、上下文和服务版本上测冷启动、预热、逐级并发和持续负载。
- 报告通过的负载、p50/p95、错误与队列变化，以及尚未覆盖的长文或峰值场景。
- 按实测结果留资源余量，写清超出负载时排队、限流、扩容或降级的处理方式。
Ollama 的本机 API 仅用于本地试验。对外提供服务前，还要配置鉴权、访问控制、TLS、网络隔离、日志和资源限额；不要把未经保护的推理端口直接暴露到公网。生产部署还要按服务框架的当前安全文档核对具体配置。
本文验证边界
本机真实测试覆盖 Ollama 0.35.1、两个已有本地模型、一次预热和并发 1/2/4 的短批次；两种测试模型在该轮结束后已停止。复测前先用 ollama ps 查看当时服务进程和资源占用。没有安装或测试 vLLM，没有连接云 GPU，没有测目标客户机器、长时间稳定性、真实业务提示、峰值并发或 p95 SLA。因此本文不承诺任何固定在线用户数，也不把本机吞吐当作生产容量。
如果你还没在本机运行 Ollama，可以先看安装和运行 Ollama；想先了解企业知识库试点的需求与交付，可看中小企业 AI 知识库项目流程。