自托管大模型不一定省钱：盈亏线先看GPU利用率
新闻 1
Ollama还是vLLM：并发8路快2.3倍，单请求却反过来
在Markaicode的A100测量中，Llama 3 8B单请求生成速度为Ollama约45 token/s、vLLM约38 token/s；8路并发的总吞吐则为vLLM约187 token/s、Ollama约82 token/s，前者约为后者的2.3倍。测试还报告，从重启容器到首个输出token，Ollama用时3.2秒，vLLM用时8.7秒。若主要是间歇性的个人交互，单次等待更重要；若请求经常重叠，就要优先看总吞吐和排队时间。
另一组SitePoint的RTX 4090测量报告，Llama 3.1 8B在50路并发时，vLLM总吞吐约920 token/s，Ollama约155 token/s；其端到端延迟的p99分别为2.8秒和24.7秒。这组测试给Ollama使用Q4_K_M量化版本，给vLLM的主要对照项使用FP16版本。因此，高并发结果提示了服务容量与尾延迟的取舍，却不能与前一组A100数字连成同一条扩容曲线。
三档并发，各回答一个容量问题
生成吞吐的单位是每秒输出的token数，表示一段时间内完成了多少生成工作。单请求速度描述一条输出流；多请求总吞吐则把同时运行的请求合在一起。它们都不能直接换算成可服务人数，因为输入长度、输出长度、到达节奏和排队时间会改变每个人的实际等待。
- 1路：个人交互。关注模型就绪后输出是否跟得上阅读，以及闲置后再次调用要等多久。持续驻留的模型主要体现热态速度；频繁卸载模型的设备，还要承担重新加载的等待。
- 8路：小型共享服务。关注重叠请求的总产出，以及排队是否开始拖慢个别用户。总吞吐领先并不保证每条请求都按同样比例提速；正在生成的请求、等待中的请求和较长上下文会争用同一张卡的资源。
- 50路：持续高负载。关注总吞吐之外的尾延迟。即使平均响应看起来可接受，最慢一批请求仍可能明显变慢。这一档来自另一种GPU、另一版模型和不同精度的权重，适合提示风险，不适合推算A100需要多少实例。
这张容量判断表中的“路”指同时进行的请求，不是注册用户数。一个拥有许多用户、但请求很少重叠的应用，可能长期接近单路负载；一个用户量不大的自动化任务，也可能在短时间内集中提交请求。按用户总数套用并发测试，容易同时误判显存需求和响应时间。
冷启动与单请求速度要分开看
A100测量中的冷启动从容器重启算到首个输出token，覆盖了服务和模型转为可用的过程。单请求token/s则是生成阶段的速率。对于按需启动的本地环境，前一段等待可能比生成速度差距更显眼；对于一直保持热态的服务，它不会在每次调用时重新出现。
Ollama官方FAQ说明，空请求可以预加载模型，keep_alive可以控制模型在内存中保留的时间，OLLAMA_NUM_PARALLEL可以调整单模型同时处理的请求数。并行请求会增加上下文所需内存，所以提高这个设置时，必须同时考虑上下文长度和可用显存。保持模型常驻能减少反复加载，却也会持续占用设备资源。
单请求领先也不意味着Ollama在任何个人任务上都会更快。A100那组报告将两端权重标为FP16，但给出的Ollama拉取命令没有显式指定FP16标签，精度条件因而难以仅凭示例命令复现。把这组结果用于选型时，应将其理解为所报告配置下的表现，而非两套运行时不受模型打包方式影响的固定差距。
多人服务为何更在意尾延迟
并发到来时，运行时必须决定哪些请求先进入GPU、哪些生成步骤可以一起处理，以及新请求要排队多久。vLLM的连续批处理适合把不同请求的生成步骤纳入共享计算；当请求持续进入，这种调度有机会提高设备在单位时间内完成的输出量。Ollama也支持同一模型的并行请求，实际效果取决于并行设置、上下文占用和剩余内存。
p99端到端延迟描述接近最慢一端的完成时间，比平均值更容易暴露拥塞。前述RTX 4090测试使用非流式请求，其“首次响应”指标不能当作流式输出的首token时间。对于让用户边生成边阅读的产品，首token等待、输出过程中的速度和最终完成时间是不同体验；总吞吐高，也不能替代对排队尾部的判断。
模型精度还会影响解释。RTX 4090测量中的Ollama与vLLM主要对照项并未使用相同量化方式，显存占用和生成速度的差异都包含这一配置因素。选择推理服务时，可以先确定自己能接受的输出质量、上下文长度和响应时间，再判断某个吞吐数字是否对应可用的配置。仅按token/s的倍率估算节省多少GPU成本，会漏掉模型驻留、请求波动和尾延迟约束。
扩容时，切分模型与增加副本用途不同
vLLM并行配置说明建议，模型装得进单张GPU时先使用单卡；模型超出单卡容量、但能放入单机多卡时，可考虑张量并行；跨节点容纳更大模型时，可组合张量并行与流水线并行。这些方式主要处理单个模型副本如何占用计算和显存资源，不能单凭开启某个选项就保证请求尾延迟下降。
当单个副本已经能运行、主要问题变成独立请求过多时，vLLM数据并行说明给出的方式是在不同实例或GPU上复制模型权重，分别处理请求批次。副本增加了分担流量的入口，也需要为每份权重预留资源。若请求分配不均，一部分副本仍可能排队，而另一部分空闲。
这两类扩容动作的顺序取决于瓶颈：模型放不下，先解决单副本的容纳问题；模型放得下而请求积压，再考虑每个副本能承受的并发和增加副本。把原本适合单卡的模型直接切到多卡，可能增加设备间通信；只加副本而不考虑流量分配，也未必改善最慢请求的体验。
选Ollama还是vLLM
个人设备、开发调试和低频调用，通常先看启动等待、模型管理是否顺手，以及热态单请求是否足够流畅。Ollama在所引A100测量的单路表现和冷启动表现占先，也提供预加载与驻留设置；如果设备显存紧张，选定的权重精度与上下文长度会比运行时名称更直接地限制体验。
共享服务的判断从请求重叠开始。偶尔出现并发时，Ollama的并行配置仍有使用空间；当持续流量使排队成为主要等待来源，vLLM的批处理和副本扩展更值得优先考虑。最终应按目标模型、量化方式、GPU容量及可接受的尾延迟来确定部署规模：公开测试说明性能排序会随负载改变，却不提供一条适用于所有配置的切换门槛。
相关阅读：
相关文章
订阅我们的新闻通讯
将最新 Web3、AI 和加密货币新闻直接发送到您的邮箱。
0