1. 概述与测试背景在端侧大模型落地和数字人一体机等应用场景中大模型推理引擎的选择直接关系到系统的首字延迟、高并发吞吐量率以及硬件资源的有效利用率。近期我们在新搭建的NVIDIA GeForce RTX 5090 (32GB 显存)硬件平台上针对Qwen3-7B模型对业界主流的两个开源推理框架 ——Ollama基于 llama.cpp 后端与vLLM部署在 Windows WSL2 Ubuntu 环境下进行了横向对比测试。本次测试的目的在于理清两者在不同并发压力、不同上下文长度下的真实性能表现并剖析其底层的计算调度机制。本文将客观记录实验过程中的关键数据、遇到的技术问题如长文本窗口截断以及对应的调优解决方案。2. 测试环境与配置为了保证对比结果的客观性测试统一在同一台物理机上进行硬件环境GeForce RTX 5090 (32GB 显存) / 宿主机 Windows 11运行环境Ollama 组Ollama for Windows 官方原生版本vLLM 组Windows WSL2 (Ubuntu 22.04 LTS) CUDA 12.x测试模型Qwen3-7B测试工具Postman接口基本功能验证、基于 Pythonasyncio与aiohttp自研的流式 API 并发压测脚本。3. 实验过程与结果分析测试共分为两个主要阶段单请求/低并发测试、长文本高并发极限压力测试。3.1 阶段一单请求场景性能分析首先通过 Postman 发起单路并发数为 1的常规对话请求观察推理框架的基本开销与静态资源分配。显存分配策略与部署成本Ollama在 Windows 下支持一键安装启动显存分配策略温和。在未接收到请求或空闲状态下对 GPU 显存的静态占用较低。vLLM由于原生支持主要面向 Linux在 WSL2 下部署需要配置 GPU 挂载与网络映射。启动时为了最大化缓存空间vLLM 默认会激进地预分配大部分显存作为 KV Cache 资源池静态显存占用较高。首字延迟TTFTTime to First Token测试表现在单用户单次请求场景下Ollama 的响应速度明显快于 vLLM。机制剖析vLLM 底层设计包含了复杂的 Continuous Batching持续批处理调度机制和 PagedAttention 虚拟内存映射这些机制在低并发下会引入额外的“时钟调度损耗”而 Ollama 依赖的 llama.cpp 后端对单次会话进行了极致的静态内存映射优化。在没有多路请求交织时Ollama 能够更直接地利用硬件算力。3.2 阶段二长文本高并发压力测试在实际的多 Agent 编排或多用户 SaaS 应用中并发吞吐量是核心指标。我们通过 Python 自研脚本模拟多路用户并发请求。高并发下的吞吐量逆转随着并发数的提升Ollama 内部请求由于缺乏流式动态批处理机制开始产生明显的排队阻塞现象整体吞吐量受限。而 vLLM 的Continuous Batching持续批处理机制开始发挥优势能够把不同时序到达的 Token 请求动态拼入同一个计算批次中配合 5090 强大的算力vLLM 在高并发状态下的吞吐量Throughput达到了 Ollama 的数倍以上。万字长文本“针尖对麦芒”质量评测与踩坑为了模拟长上下文业务我们设计了一项测试准备一段约 10000 字的上下文语料由技术文档与影评组合而成将核心提示词指令Prompt分别随机插入到这篇长文本的 5%、15%、50%、95% 等不同位置组合成 20 个测试样例并同时发起并发请求。发现问题在首轮压测中Ollama 的回答正确率发生塌方表现为模型开始胡言乱语、答非所问而 vLLM 虽耗时拉长但依然能正确从长文本中检索并回答问题。原因排查分析日志后发现问题出在上下文窗口限制Context Length。Ollama 默认的模型加载参数中上下文窗口num_ctx通常被限制在 2048 或 4096 Token。当 10000 字的长文本涌入时超出的核心 Prompt 在框架前端被直接截断导致模型根本没读到完整的核心指令。3.3 Ollama 调优方案Modelfile 参数重构为了解决 Ollama 在长文本下的截断故障需要利用自定义Modelfile强行覆盖默认上下文深度编写名为Modelfile的配置文件DockerfileFROM qwen3-7b # 将上下文窗口扩大至 10240 Token 以容纳长文本 PARAMETER num_ctx 10240在终端重新编译生成扩展了上下文深度的新模型拓扑Bashollama create qwen3-7b-long -f ./Modelfile调优后对比调整num_ctx后Ollama 能够正常输出答案。但在“万字长文本 高并发”的双重高负载状态下vLLM 的稳定性与处理速度依然占优。这得益于 vLLM 核心的PagedAttention技术。它模仿了操作系统的虚拟内存管理方式将 KV Cache 离散地存储在不连续的物理显存块Page中避免了 Ollama 在扩展大上下文时为了寻找连续显存而带来的内存碎片开销与 Prefill预填充阶段时延。4. 框架深度对比总结通过在 RTX 5090 上对 Qwen3-7B 的多轮测试我们将两者的关键指标总结如下表评估维度Ollama (基于 llama.cpp)vLLM (WSL2 环境)部署与运维成本原生交付安装与调用极其简便相对复杂涉及 Linux 环境与网络桥接显存分配机制动态按需分配空闲时静态占用低激进预分配启动即锁定大量 KV Cache 空间首字延迟 (TTFT)低单请求下具备绝对优势较高受制于框架内核调度开销高并发极限吞吐较弱高负载下易发生排队阻塞极强利用动态批处理大幅提升吞吐长文本并发适应度需手动调优num_ctx长文下变慢原生 PagedAttention 支持长文并发性能稳健5. 工程选型结论与建议基于上述朴实的实验数据团队在数字人一体机及大模型工程落地中得出了清晰的选型导向端侧/边缘侧单用户场景选择 Ollama如果应用场景定位在单设备离线部署、单用户独占交互如数字人一体机系统核心瓶颈在于降低用户的等待感知追求极致的“首字秒吐”交互体感。在此场景下应选择Ollama。它能规避复杂的底层运维并完美利用单路推理下的低时延优势。中后台/多 Agent 编排场景选择 vLLM如果应用场景属于多用户在线的 SaaS 平台、或者后台涉及到多个 Agent 并发调用工具、处理万字以上超长上下文。在此场景下必须选择vLLM。虽然它的前期部署和静态显存开销较大但它在高并发和长文本下的 PagedAttention 管理机制是保证系统在高负载下不崩溃、高吞吐运行的核心底座。
1. 概述与测试背景在端侧大模型落地和数字人一体机等应用场景中大模型推理引擎的选择直接关系到系统的首字延迟、高并发吞吐量率以及硬件资源的有效利用率。近期我们在新搭建的NVIDIA GeForce RTX 5090 (32GB 显存)硬件平台上针对Qwen3-7B模型对业界主流的两个开源推理框架 ——Ollama基于 llama.cpp 后端与vLLM部署在 Windows WSL2 Ubuntu 环境下进行了横向对比测试。本次测试的目的在于理清两者在不同并发压力、不同上下文长度下的真实性能表现并剖析其底层的计算调度机制。本文将客观记录实验过程中的关键数据、遇到的技术问题如长文本窗口截断以及对应的调优解决方案。2. 测试环境与配置为了保证对比结果的客观性测试统一在同一台物理机上进行硬件环境GeForce RTX 5090 (32GB 显存) / 宿主机 Windows 11运行环境Ollama 组Ollama for Windows 官方原生版本vLLM 组Windows WSL2 (Ubuntu 22.04 LTS) CUDA 12.x测试模型Qwen3-7B测试工具Postman接口基本功能验证、基于 Pythonasyncio与aiohttp自研的流式 API 并发压测脚本。3. 实验过程与结果分析测试共分为两个主要阶段单请求/低并发测试、长文本高并发极限压力测试。3.1 阶段一单请求场景性能分析首先通过 Postman 发起单路并发数为 1的常规对话请求观察推理框架的基本开销与静态资源分配。显存分配策略与部署成本Ollama在 Windows 下支持一键安装启动显存分配策略温和。在未接收到请求或空闲状态下对 GPU 显存的静态占用较低。vLLM由于原生支持主要面向 Linux在 WSL2 下部署需要配置 GPU 挂载与网络映射。启动时为了最大化缓存空间vLLM 默认会激进地预分配大部分显存作为 KV Cache 资源池静态显存占用较高。首字延迟TTFTTime to First Token测试表现在单用户单次请求场景下Ollama 的响应速度明显快于 vLLM。机制剖析vLLM 底层设计包含了复杂的 Continuous Batching持续批处理调度机制和 PagedAttention 虚拟内存映射这些机制在低并发下会引入额外的“时钟调度损耗”而 Ollama 依赖的 llama.cpp 后端对单次会话进行了极致的静态内存映射优化。在没有多路请求交织时Ollama 能够更直接地利用硬件算力。3.2 阶段二长文本高并发压力测试在实际的多 Agent 编排或多用户 SaaS 应用中并发吞吐量是核心指标。我们通过 Python 自研脚本模拟多路用户并发请求。高并发下的吞吐量逆转随着并发数的提升Ollama 内部请求由于缺乏流式动态批处理机制开始产生明显的排队阻塞现象整体吞吐量受限。而 vLLM 的Continuous Batching持续批处理机制开始发挥优势能够把不同时序到达的 Token 请求动态拼入同一个计算批次中配合 5090 强大的算力vLLM 在高并发状态下的吞吐量Throughput达到了 Ollama 的数倍以上。万字长文本“针尖对麦芒”质量评测与踩坑为了模拟长上下文业务我们设计了一项测试准备一段约 10000 字的上下文语料由技术文档与影评组合而成将核心提示词指令Prompt分别随机插入到这篇长文本的 5%、15%、50%、95% 等不同位置组合成 20 个测试样例并同时发起并发请求。发现问题在首轮压测中Ollama 的回答正确率发生塌方表现为模型开始胡言乱语、答非所问而 vLLM 虽耗时拉长但依然能正确从长文本中检索并回答问题。原因排查分析日志后发现问题出在上下文窗口限制Context Length。Ollama 默认的模型加载参数中上下文窗口num_ctx通常被限制在 2048 或 4096 Token。当 10000 字的长文本涌入时超出的核心 Prompt 在框架前端被直接截断导致模型根本没读到完整的核心指令。3.3 Ollama 调优方案Modelfile 参数重构为了解决 Ollama 在长文本下的截断故障需要利用自定义Modelfile强行覆盖默认上下文深度编写名为Modelfile的配置文件DockerfileFROM qwen3-7b # 将上下文窗口扩大至 10240 Token 以容纳长文本 PARAMETER num_ctx 10240在终端重新编译生成扩展了上下文深度的新模型拓扑Bashollama create qwen3-7b-long -f ./Modelfile调优后对比调整num_ctx后Ollama 能够正常输出答案。但在“万字长文本 高并发”的双重高负载状态下vLLM 的稳定性与处理速度依然占优。这得益于 vLLM 核心的PagedAttention技术。它模仿了操作系统的虚拟内存管理方式将 KV Cache 离散地存储在不连续的物理显存块Page中避免了 Ollama 在扩展大上下文时为了寻找连续显存而带来的内存碎片开销与 Prefill预填充阶段时延。4. 框架深度对比总结通过在 RTX 5090 上对 Qwen3-7B 的多轮测试我们将两者的关键指标总结如下表评估维度Ollama (基于 llama.cpp)vLLM (WSL2 环境)部署与运维成本原生交付安装与调用极其简便相对复杂涉及 Linux 环境与网络桥接显存分配机制动态按需分配空闲时静态占用低激进预分配启动即锁定大量 KV Cache 空间首字延迟 (TTFT)低单请求下具备绝对优势较高受制于框架内核调度开销高并发极限吞吐较弱高负载下易发生排队阻塞极强利用动态批处理大幅提升吞吐长文本并发适应度需手动调优num_ctx长文下变慢原生 PagedAttention 支持长文并发性能稳健5. 工程选型结论与建议基于上述朴实的实验数据团队在数字人一体机及大模型工程落地中得出了清晰的选型导向端侧/边缘侧单用户场景选择 Ollama如果应用场景定位在单设备离线部署、单用户独占交互如数字人一体机系统核心瓶颈在于降低用户的等待感知追求极致的“首字秒吐”交互体感。在此场景下应选择Ollama。它能规避复杂的底层运维并完美利用单路推理下的低时延优势。中后台/多 Agent 编排场景选择 vLLM如果应用场景属于多用户在线的 SaaS 平台、或者后台涉及到多个 Agent 并发调用工具、处理万字以上超长上下文。在此场景下必须选择vLLM。虽然它的前期部署和静态显存开销较大但它在高并发和长文本下的 PagedAttention 管理机制是保证系统在高负载下不崩溃、高吞吐运行的核心底座。
：枚举和指针)
平方复杂度无法被常规优化消除｜TaoToken 统一 Key 通道实测)
