事情本身不复杂，线索都在日志里。用 8 个线程请求同一个 Ollama 服务，实际变成串行执行，总耗时是单条的八倍，日志里请求依次进入队列。
第一反应是「显存不足时服务端主动降为串行」，验证下来不成立。
真正麻烦的地方在于，几个原因的现象几乎一样。默认并发数是按显存自动推算的，可能只有 1。还有一种是同一模型的多请求共用一份上下文缓冲。
少数情况下是客户端连接池太小，请求在本地就排上了。
第一件事是看服务端当前的并发与上下文配置
ollama ps然后设置并发数后重启服务
$env:OLLAMA_NUM_PARALLEL='4'; ollama serve同时压测观察吞吐变化
python bench.py --concurrency 4 --requests 40显存不够时降低单请求上下文长度
$env:OLLAMA_CONTEXT_LENGTH='2048'; ollama serve怎么算真的好了，看的是同一批现象。四条并发请求的完成时间接近单条，吞吐提升到原来的三倍以上，显存占用仍在安全范围。
容易忽略的是，并发数乘以单请求上下文就是总显存需求，盲目调大并发会直接触发加载失败，先算清楚再改。同一份配置在测试环境跑通，不代表线上没事，两边的默认值经常不一样。