mumong's blog
Go back

本地大模型部署与调优：从 Ollama 到 vLLM

梳理本地大模型推理的核心瓶颈、量化格式选择、Ollama 的定位与限制，以及 vLLM、PagedAttention、连续批处理带来的吞吐优化。

本文由《本地大模型部署与调优》PDF 整理而来；原 PDF 无嵌入图片，正文按博客阅读方式重新排版，并补充自制架构图帮助理解。
系列导航：本地推理与 vLLM 优化 · 分布式部署与生产化

本地大模型推理优化栈
本地大模型推理优化栈

大语言模型部署架构师手册：从本地原型到分布式生产

执行摘要

大语言模型（LLM）的部署已成为将人工智能从研究领域推向实际应用的关键环节。本报告旨在为技术领导者提供一份全面的架构指南，系统性地阐述了LLM部署从简单本地实验到复杂分布式生产系统的完整演进路径。报告的核心脉络遵循一条明确的技术进阶路线：始于使用Ollama进行快速本地开发与原型验证，随后过渡到采用vLLM高性能推理框架以满足生产环境对吞吐量和延迟的严苛要求，并最终探讨了通过Docker容器化、Kubernetes编排以及与Ray结合实现分布式计算的先进架构。 报告首先深入剖析了支撑高性能推理的底层技术基石，特别是GPU架构的并行计算能力和PagedAttention内存管理技术在解决Transformer模型KV缓存瓶颈中的决定性作用。在此基础上，报告详细评估了Ollama在开发阶段的价值及其在并发场景下的性能天花板，从而论证了向vLLM迁移的必要性。通过量化基准测试，报告清晰地展示了vLLM在吞吐量和延迟方面的数量级优势。 为了实现可移植、可扩展的生产部署，报告进一步探讨了将vLLM服务容器化和集群化的关键技术。内容涵盖了使用Docker构建标准化的部署单元，利用Kubernetes进行服务编排、弹性和负载均衡，以及集成Ray框架以支持超越单节点能力的大规模模型并行计算。此外，报告还系统性地梳理了生产环境中不可或缺的运维最佳实践，包括可观测性体系的构建、API网关的设计原则以及一个全面的安全框架。 最后，本报告将自托管部署方案与主流云厂商提供的托管服务（包括AWS SageMaker、 Google Vertex AI和Azure Machine Learning）进行了战略性对比分析。通过对总拥有成本（TCO）、控制力与便利性、以及各平台独特优势的深入探讨，报告为企业在“自建”与“购买”之间进行决策提供了清晰的框架。最终，本手册旨在通过提供一个从战术实施到战略决策的完整视角，帮助企业根据其业务规模、性能需求、团队技能和安全合规性要求，选择最合适的LLM部署路径。

第一部分：大模型推理优化的全景图

第一章 引言

大语言模型（LLM）的崛起，标志着人工智能领域的一次范式转移。然而，其卓越能力的背后，是模型规模的急剧膨胀。这种规模化带来了严峻的计算与内存瓶颈，使得高效部署LLM 成为一个核心挑战。LLM推理的本质，是在有限的硬件资源与用户对低延迟、高吞吐的需求之间寻求一个动态平衡。本报告旨在深入剖析当前LLM推理的技术前沿，从底层框架、核心算法到硬件选型与优化策略，为AI工程师和MLOps专家提供一份全面、深入的技术指南。

第二章 LLM推理的三大瓶颈

要理解推理优化，首先必须认识到其面临的三大根本性瓶颈。这些瓶颈共同构成了推理优化的核心问题域。

2.1 内存带宽瓶颈（KV缓存问题）

与传统观念不同，LLM推理的主要瓶颈通常并非原始计算能力（FLOPs），而是内存带宽。 在自回归解码（Autoregressive Decoding）过程中，模型每生成一个新词元（token），都必须访问并处理先前所有词元的键（Key）和值（Value）向量，这些向量被存储在所谓的KV 缓存（KV Cache）中。这一机制是Transformer架构保持上下文记忆的关键，但也带来了巨大的内存挑战。 KV缓存具有以下特点：

高达1.7GB的GPU显存。对于70B级别的模型和长上下文，其体积更是惊人。

可预测的。

的最大序列长度所对应的内存。这种策略导致了严重的内存浪费，包括内部碎片化（已分配但未使用的内存）和外部碎片化（分配块之间的未使用间隙），浪费率可高达60%至80%。每次解码步骤中，从GPU的高带宽显存（HBM）中读取庞大的KV缓存，成为限制整体性能的关键瓶颈。

2.2 计算密集瓶颈（提示词处理问题）

LLM的推理过程可分为两个截然不同的阶段：提示词处理（Prefill/Prompt Processing）和词元生成（Decoding）。提示词处理阶段负责计算输入提示（Prompt）中所有词元的KV缓存，这是一个高度并行的、计算密集型（Compute-Bound）的过程。当输入提示非常长时， 这个初始计算阶段会消耗大量时间，直接导致“首词元生成时间”（Time-to-First-Token, TTFT）过长，影响交互式应用的响应速度。

2.3 顺序生成瓶颈（自回归问题）

解码器（Decoder-only）Transformer架构的自回归特性是其固有的延迟来源。模型必须逐个生成词元，每个新词元的生成都依赖于前一个词元。这种严格的顺序依赖性，从根本上限制了生成过程本身的并行性，使得提高“每秒生成词元数”（Tokens per Second, TPS）变得极具挑战性。

2.4 推理优化的四大支柱

为了克服上述三大瓶颈，业界发展出了四大优化支柱。本报告的后续章节将围绕这些支柱展开详细论述，它们共同构成了现代LLM推理优化的技术栈。 1. 模型压缩（Model Compression）：这是减小模型部署成本的第一道防线。通过技术手段降低模型的体积和计算需求，使其能够在资源受限的硬件上运行。主要方法包括量化（Quantization）、剪枝（Pruning）和知识蒸馏（Knowledge Distillation）。 2. 优化的运行时与核函数（Optimized Runtimes & Kernels）：构建高效的软件层，以最优方式在硬件上执行模型。这包括将多个计算操作合并为单一核函数的核函数融合（Kernel Fusion），以及针对KV缓存管理设计的PagedAttention等关键技术。 3. 智能批处理与调度（Strategic Batching & Scheduling）：通过智能地组织和处理并发请求，最大化GPU的利用率。连续批处理（Continuous Batching）是其中的代表性技术。 4. 解码算法增强（Algorithmic Enhancements）：从算法层面改进解码过程本身，以降低延迟。推测解码（Speculative Decoding）是这一方向的突破性进展。 5. 并行化计算（Parallelism）：当单个GPU无法承载模型时，通过将模型或数据分布到多个GPU或节点上，实现规模化部署。主要包括张量并行（Tensor Parallelism）和流水线并行（Pipeline Parallelism）。 对这些优化支柱的深入分析揭示了一个核心趋势：整个LLM推理优化领域，在很大程度上是一场对抗内存带宽限制和低效内存管理的战争，而不仅仅是追求更快的矩阵运算。最成功的创新，如PagedAttention、FlashAttention和核函数融合，其核心价值都在于直接或间接地缓解了内存瓶颈。PagedAttention通过精细的内存管理将吞吐量提升高达24倍，而核函数融合的主要目的正是减少GPU核心与全局内存之间的数据传输。甚至新兴的非Transformer架构（如Mamba/RWKV），其线性时间复杂度的优势也直接体现在对内存和计算随上下文长度增长的有效控制上。这预示着，未来推理优化的前沿将继续围绕内存高效的算法和数据结构展开，而非单纯依赖于更快的计算硬件。

第三章 模型压缩技术：减小模型体积

3.1 引言

模型压缩是使LLM在资源有限的硬件上变得可行的首要步骤。尽管剪枝和知识蒸馏等技术亦有应用，但对于推理优化而言，量化（Quantization）无疑是当前应用最广泛、影响最深远的技术。

3.2 什么是量化？

从根本上说，量化是将模型中的权重（有时也包括激活值）从高精度浮点数格式（如32位浮点数FP32或16位浮点数FP16）转换为低精度整数格式（如8位整数INT8或4位整数INT4）的过程。这一过程能带来三大核心优势： 1. 减小内存占用：低精度数据类型需要更少的存储空间，显著减小模型的体积。 2. 降低内存带宽需求：由于数据量减小，在推理过程中从显存加载权重到计算核心所需的时间和带宽也相应减少。 3. 加速计算：许多现代GPU和CPU都包含针对低精度整数运算的专用硬件单元，执行这些运算比高精度浮点运算更快。 当前，社区中形成了多种主流的量化格式，它们针对不同的硬件和目标进行了优化。其中， GGUF、GPTQ和AWQ是最具代表性的三种。

3.2.1 GGUF (GPT-Generated Unified Format)

移植性和易用性 。它将模型权重、量化信息以及元数据（如模型架构、词汇表、提示词

模板等）打包成一个单一的、自包含的文件 。这极大地简化了模型的分享和使用。 3

（Metal） 。其标志性特性是支持混合CPU/GPU推理，用户可以通过设置 n-gpu-layers

参数，将模型的一部分计算层卸载到NVIDIA或AMD的GPU上，以加速推理，而其余部分则由CPU处理 。 1

人电脑上运行大模型 。然而，这种灵活性是以牺牲部分性能为代价的。当模型可以完全

加载到GPU显存中时，GGUF的运行速度通常会慢于专为GPU设计的量化格式（如AWQ/GPTQ） 。尽管如此，其K-quants（如 q4_K_M ）量化方法在保持较高模型质量的

同时实现了显著的压缩，被广泛认为是一个优秀的平衡点 。 6

3.2.2 GPTQ (Post-Training Quantization for Generative Pre-trained

Transformers)

法。它逐层对模型权重进行量化，并使用一个小的校准数据集来指导量化过程，以最小化量化误差 。其技术核心是利用近似的二阶信息（Hessian矩阵）来确定权重的量化方

式，从而在压缩后保持较高的模型精度 。 6

正逐渐被更先进的方法（如AWQ和EXL2）所超越，后者通常能提供更快的速度 。此 5

外，有用户报告指出，在高负载情况下，GPTQ的性能可能会下降，因为动态解量化的计算开销会成为新的瓶颈。

3.2.3 AWQ (Activation-Aware Weight Quantization)

要。AWQ通过分析模型在处理校准数据时的激活值分布，来识别出对模型性能至关重要的“显著权重” 。在量化过程中，它会通过应用一个缩放因子来“保护”这些显著权重，减小

它们的量化误差，同时对其他次要权重进行更大力度的压缩 。 1

理框架中得到了广泛支持 。 1

准确率），尤其是在指令微调模型上表现出色 。它被认为是当前GPU量化部署的领先技

术之一。与GPTQ一样，它需要一个以GPU为中心的部署流程，缺乏GGUF的便携性。其性能优势在高负载下尤为明显。

2.3 量化方法选择的战略考量

对这三种主流方法的比较揭示了一个更深层次的结论：量化方法的选择不仅是一个技术细节，更是一种战略宣言，它反映了部署者的核心目标。

GPU的设备）运行起来，那么GGUF是必然之选。它代表了一种“先跑起来再说”的哲学， 优先考虑的是普适性和易用性 。用户选择GGUF，通常是因为他们希望在自己的本地消

费级硬件上进行实验和使用。

那么AWQ（或其同类GPU原生格式）是最佳选择。它代表了一种“跑得尽可能快”的哲学，优先考虑的是在特定硬件上的速度和吞吐量 。 1

因此，开发者在选择量化格式时，实际上是在为自己的项目选择一个部署理念。这个选择将直接决定后续的硬件需求、工作流程和生态系统。下表总结了这三种量化方法的关键特性， 为战略决策提供参考。 量化方法 核心技术原理 主要目标硬件 关键优势 主要局限性GGUF 便携式单一文件格式，支 CPU, Apple 极高的可访问性、跨 在纯GPU环持CPU与GPU混合卸载。 Silicon, 混合 平台能力和易用性 。 于原生GPU

元数据自包含，易于分发 CPU/GPU 1 和使用 。

GPTQ 基于近似二阶信息的逐层 NVIDIA/AMD 曾是GPU量化的主 性能常被AW 训练后量化，使用校准数 GPUs 1 流，在压缩率和速度 越，高负载据最小化误差 。 6 之间取得良好平衡 。 销可能成为

AWQ 激活感知量化，通过分析 NVIDIA/AMD 当前GPU推理的SOTA 需要以GPU 激活值来保护关键权重， GPUs 1 性能和精度，尤其适 署流程，可从而保持高精度 。 1 用于指令微调模型 。 差。

第二部分：高性能推理引擎与框架

第一章 vLLM：以PagedAttention革新吞吐量

1.1 引言

vLLM是一个源自加州大学伯克利分校的开源推理与服务引擎，它已迅速成为高吞吐量LLM服务的行业标杆 。其核心贡献在于，通过一项名为PagedAttention的革命性技术，直接攻克

了KV缓存管理中的内存碎片化和低效问题，从而实现了性能的巨大飞跃 。基准测试显示， 11

vLLM的吞吐量最高可达原生HuggingFace Transformers的24倍 。 11

1.2 PagedAttention 机制：为GPU引入虚拟内存

要理解vLLM的强大之处，必须深入其核心机制——PagedAttention。

度的庞大内存块。这导致了两个致命问题：当实际序列远短于最大长度时，产生大量未使用的内部碎片；同时，这些巨大的、不规则的内存块之间会形成无法被新请求利用的外部碎片 。最终，高达60%-80%的宝贵显存被白白浪费 。 11 12

应用于GPU显存管理 。 10

a. KV块（KV Blocks）：它将每个序列的KV缓存分割成许多个固定大小的小块（Blocks），这些块就像操作系统中的内存页（Pages） b. 非连续分配（Non-Contiguous Allocation）：这些KV块可以存储在GPU物理显存的任意非连续位置 。这彻底消除了外部碎片问题，因为任何一个空闲的块都可以被

分配给任何一个请求 。 14

c. 块表（Block Tables）：vLLM为每个序列维护一个“块表”，这个表记录了序列的逻辑块（在序列看来是连续的）到物理块（在显存中的实际位置）的映射关系 。这与 12

操作系统中用于地址转换的页表（Page Table）功能完全相同 。 14

d. 按需分配（On-Demand Allocation）：只有在生成新词元需要更多空间时，系统才会动态地分配新的物理块 。这使得内部碎片被限制在每个序列的最后一个块内，从

而将整体内存浪费率降低到惊人的4%以下 。 11

1.3 连续批处理：最大化GPU利用率

高效的内存管理，为另一项关键优化——连续批处理（Continuous PagedAttention ） 奠定了基础 。 Batching —— 15

求全部处理完成后，才能开始下一批。这意味着，即使批次中的某个请求已经生成完毕， 它也必须等待同批次中最慢的那个请求结束，这期间GPU资源被闲置，造成了严重的利用率低下 。 16

。其调度器不再以整个请求为单位，而是以单次模型前向传播（即一个词元的生成步

骤）为单位进行操作 。 15

在每一步生成后，调度器会检查当前批次中是否有序列已经完成。 ○

完成的序列会立即被移出批次，释放其占用的资源。 ○

如果此时有资源空出，调度器会立刻从等待队列中选择新的请求加入到当前批次 ○

中 。 17

这个过程确保了GPU始终处于高负载工作状态，从而极大地提升了系统总吞吐量 。 ○ 15

1.4 写时复制（Copy-on-Write）实现高效内存共享

的块状管理机制还带来了一个巨大的附加优势：几乎零成本的内存共享。在PagedAttention 并行采样（Parallel Sampling，即从一个提示生成多个不同回复）或束搜索（Beam Search）等场景中，多个输出序列共享相同的输入提示部分 。 12

分的逻辑块，指向相同的物理块即可 。 12

（Copy-on-Write）**机制被触发：系统会为这个分叉的序列分配一个新的物理块，并将共享块的内容复制过去 。此后，这个序列就可以独立地在新块上进行写入，而不影响其

他共享该旧块的序列。

vLLM的成功并非源于一种全新的AI算法或底层的CUDA核函数，而是一套源自经典操作系统理论的系统级解决方案。它雄辩地证明，将计算机科学其他领域中经过时间考验的成熟思想（如内存管理）应用于AI系统，能够解锁巨大的性能潜力。PagedAttention的实现细节—— 块表、非连续分配、按需分配——都与操作系统的虚拟内存管理如出一辙 。这揭示了一个 12

深刻的趋势：未来AI系统工程的突破，可能更多地来自于对数据库、分布式系统、编译器等经典计算机科学领域智慧的巧妙借鉴与应用。所谓的“秘密武器”，有时并非一个全新的算法，而是一个被重新发现和巧妙应用的旧智慧。

第二章 Ollama：民主化本地LLM部署

与追求极致性能的vLLM不同，Ollama的诞生有着一个根本上不同的目标：可访问性（Accessibility）与易用性（Ease of Use） 。它致力于将本地运行LLM的门槛降至最低，

让广大开发者、研究者乃至技术爱好者都能在自己的个人电脑上轻松体验和使用大模型 。 34

2.1 Ollama的架构：一个用户友好的封装层

Ollama 的架构设计完美地体现了其易用性的哲学。

端）与一个在后台运行的Go语言编写的服务器 ollama serve 进行交互 。两者之间的通

信基于本地HTTP REST API 。 35

引擎llama.cpp之间并非通过直接的函数库集成（如FFI）进行通信。相反，Ollama的Go 服务器为每个需要运行的模型启动一个独立的llama.cpp服务器进程，并为其分配一个动态的空闲端口 。随后，Go服务器扮演一个代理的角色，将来自客户端的API请求（如 /a

pi/chat ）转发给对应的llama.cpp进程的 /completion 等API端点，两者之间通过HTTP协议进行数据交换 。 35

式的模型，将其统一存储在本地（通常是 ~/.ollama 目录），并根据使用情况和闲置超时（默认为5分钟）自动加载和卸载模型到内存中，有效管理了系统资源 。 36

优势与应用场景

像 ollama run llama3 一样简单 。这为初学者和快速原型开发提供了无与伦比的便利。

Apple Silicon）、Windows和Linux上，并能自动利用可用的GPU硬件（通过CUDA、 Metal或ROCm）进行加速 。

现有的AI工具、库（如LangChain、LlamaIndex）和前端应用可以几乎不做修改地与本地运行的Ollama模型进行集成，极大地扩展了其应用范围 。 33

2.2 局限性与升级路径

不可避免的性能开销（如进程间通信、HTTP协议解析、数据序列化等） 。因此， 37

Ollama不适用于需要高吞吐量、低延迟的生产级多用户服务场景，其性能远低于vLLM或TensorRT-LLM等专用引擎。

框架，Ollama提供的高级性能调优选项非常有限 。例如，有用户反馈在多GPU系统上难

以精确控制使用哪块GPU 。 37

Ollama的架构选择——采用进程间HTTP通信而非直接库绑定——是一个深思熟虑的权衡。 这种设计牺牲了部分原始性能，换来了模块化、稳定性和未来的可扩展性 。它将核心的Go 37

应用与C++推理后端完全解耦，这意味着任何一个组件的崩溃或升级都不会影响到另一个。 正如社区讨论所指出的，这种架构也使得未来支持除llama.cpp之外的其他推理后端变得更加容易 。这一架构决策清晰地揭示了Ollama的产品哲学：它定位自己为一个健壮、易于管理

的“模型调度器”，而非一个追求极致性能的单体推理引擎。这使其成为本地开发、实验和学习的绝佳工具，但对于那些对每毫秒延迟都斤斤计较的生产环境，则并非最佳选择。

第三章 llama.cpp：可访问本地推理的基石

在探讨Ollama、vLLM等高级框架之前，必须先了解它们许多所依赖的基石：llama.cpp。这是一个用纯C/C++编写的高效推理引擎，其核心使命是让LLM能够在消费级硬件上以最小的设置和最高的效率运行 。它代表了一种“回归本源”的工程哲学，通过精简的实现和对硬件的

底层优化，实现了无与伦比的可移植性和性能。

3.1 核心理念与架构

GPU 的普通计算机上运行 。它通过利用现代CPU的SIMD指令集（如AVX、AVX2、

NEON ）来实现高效的计算 。这一特性使其具有极强的可移植性，能够无缝运行在

Windows、macOS（包括Apple Silicon）和Linux上 。 4

种自包含的二进制文件格式，它将模型权重、词汇表、量化信息和元数据打包在一起，极大地简化了模型的分发和使用 。 3

其标志性特性是混合推理（Hybrid Inference），允许用户通过 --n-gpu-layers （或 -ng l ）参数，将模型的一部分计算密集型层卸载到GPU（支持NVIDIA CUDA、AMD ROCm、Apple Metal）上，而其余部分则由CPU处理 。这种灵活的卸载机制使得在

VRAM有限的消费级显卡上运行大型模型成为可能，因为它能有效平衡VRAM占用和系统RAM的使用 。 46

度，特别是其独有的“K-quants”系列（如Q4_K_M、Q6_K等），被广泛认为在压缩率和模型保真度之间取得了极佳的平衡 。 4

3.2 性能画像与战略定位

Apple Silicon上。其启动速度极快，通常只需几秒钟就能加载模型，远快于vLLM等需要复杂初始化的框架 。 47

吞吐量 。在需要同时处理大量请求的服务器场景中，其性能通常不及vLLM或TensorRT-

LLM，后两者拥有PagedAttention和连续批处理等专为高吞吐量设计的复杂调度系统 。 47

可以精细调整线程数、GPU层数、张量分割等，以榨干特定硬件的性能 。然而，这种控 45

制力也意味着更高的使用门槛。相比之下，Ollama等工具通过封装 llama.cpp ，牺牲了部分控制力以换取极致的易用性 。 33

3.3 结论：基础引擎 vs. 集成解决方案

llama.cpp在推理生态中的定位是一个高性能、可移植的基础引擎。它不是一个像vLLM或Ollama那样的“开箱即用”的服务框架，而是一个强大的、可被集成的核心组件。

限设备（尤其是CPU和Apple Silicon）上的最佳单用户性能。它是DIY爱好者、嵌入式开发者和需要在非主流硬件上部署LLM的工程师的首选。

意接受一定的性能开销来换取便捷的模型管理和API接口。 因此， llama.cpp 与vLLM/TensorRT-LLM并非直接的竞争对手，它们服务于不同的目标。 ll ama.cpp 致力于让LLM在任何地方都能运行起来，而vLLM和TensorRT-LLM则致力于让LLM在专用服务器上运行得尽可能快。

第四章 框架哲学与战略定位：综合对比

在深入探讨了四个关键的推理框架——vLLM、TensorRT-LLM、Ollama和llama.cpp之后，我们可以清晰地看到它们各自代表了不同的设计哲学和战略定位。选择哪个框架，不仅是一个技术决策，更是一个与项目目标、团队技能和硬件资源相匹配的战略选择。 下表从高层次视角对这四个框架进行了综合对比： 框架 核心哲学 主要目标 关键技术 目标硬件 性能画像

vLLM        系统优化   最大化多用户吞吐 PagedAttention, 高端NVIDIA/AMD          极高的吞

量 连续批处理 GPU 10 的通用性TensorRT- 软硬协同 在NVIDIA GPU上 编译器优化, 核函 NVIDIA数据中心 极致的单LLM 实现最低延迟和最 数融合, FP8 24 GPU (H100, A100) 能，尤其高性能 下29

Ollama 可访问性 简化本地部署，提 Go语言封装, 消费级硬件 (CPU, 性能有开供无缝的用户体验 HTTP代理, 自动模 GPU, Apple Silicon) 生产级高型管理 35

llama.cpp 可移植性 在最广泛的硬件上 C++原生实现, CPU, Apple Silicon, 最佳的CP 实现高效的单用户 GGUF, 混合 消费级GPU 理性能， 推理 CPU/GPU卸载 4 低47

战略象限分析我们可以将这四个框架放置在一个二维的战略象限中，横轴代表**“易用性与可访问性”，纵轴代表“峰值性能与吞吐量”**。

（PagedAttention）在不牺牲过多易用性的前提下，提供了接近理论极限的高吞吐量，成为大多数生产级云端部署的“甜点”选择 。 51

过与NVIDIA硬件的深度绑定，换取了无与伦比的性能。这是追求极致速度和效率、且不惜投入工程资源的团队的终极选择 。 30

妙的封装，让非专业用户也能轻松运行LLM。它的成功证明了“让技术变得简单”本身就是一种强大的价值 。 34

个用户友好的应用，而是成为一个可以在任何地方运行的、高度可控的引擎。它赋予了开发者在各种硬件上进行底层优化的能力，是整个本地LLM生态的“发动机” 。 4

结论：这个生态系统展现了健康和成熟的迹象。从追求极致性能的TensorRT-LLM，到平衡性能与易用性的vLLM，再到专注于用户体验的Ollama，以及提供底层动力和最大灵活性的llama.cpp，它们共同构成了一个分层、互补的工具链。开发者可以根据自身在“性能-易用性- 硬件平台”这个三维空间中的具体位置，选择最适合自己的工具，而无需被迫接受一个“一刀切”的解决方案。

第三部分：Ollama架构

第一章：引言

近年来，大语言模型（LLM）的发展浪潮正从云端API服务向本地化部署延伸。驱动这一趋势的因素是多方面的，包括对数据隐私和安全性的严格要求、对低延迟实时交互的需求、对云服务成本的控制，以及对模型进行深度定制和微调的灵活性 。本地化部署赋予了开发者和企

业前所未有的控制权，但也带来了新的技术挑战，其中最核心的便是如何高效地在有限的硬件资源上运行这些庞大的模型。在LLM部署旅程的起点，开发团队需要一个简单、快速且易于管理的工具来进行本地实验和应用集成。Ollama正为此而生，它将复杂的LLM运行环境打包，极大地降低了开发人员的入门门槛。 本章节选取阿里巴巴集团开源的Qwen2.5系列模型作为研究对象，特别是其14B和32B参数版本。Qwen2.5系列是当前业界领先的开源模型之一，以其在多语言理解、代码生成、长文本处理和指令遵循等方面的卓越表现而备受关注 12。其强大的综合能力使其成为检验和对比不同部署框架性能的理想基准。Ollama: 被誉为“LLM领域的Docker”，Ollama致力于将LLM的部署和管理过程极度简化，通过一个统一的命令行工具和API，让开发者能够轻松下载、运行和切换不同的模型 。其设计哲学是“民主化AI”，降低技术门槛。

第二章：Ollama架构：通过抽象实现简洁与可及性

的架构设计精髓在于“封装”与“抽象”。它为用户提供了一个极其简洁的交互界面，将Ollama 底层复杂的 llama.cpp 引擎的细节完全隐藏起来，从而实现了其“一键运行”的用户体验 。 1

2.1 核心架构：双组件模型

Ollama 的系统由两个主要部分构成：一个用Go语言编写的服务器端和一个C++实现的推理后端。 1. Go服务器: 这是用户直接交互的层面。它提供了一个RESTful API，负责处理用户的命令（如 ollama run , ollama pull ），管理模型文件，解析Modelfile，并协调后端的推理任务。 2. llama.cpp 后端: Ollama本身不直接执行模型推理。当需要进行推理时，Go服务器会启动一个名为 ollama_llama_server 的独立进程。这个进程是 llama.cpp 官方服务器的一个轻微修改版，专门用于执行实际的计算任务 。Go服务器通过本地HTTP请求与这个C++服

务器进程进行通信，发送推理请求并接收生成结果。

2.2 llama.cpp的集成方式

Ollama与llama.cpp的集成是其架构的关键。这种集成并非深度融合，而是一种“管理器-执行者”模式。

数。例如，当用户使用 ollama create 命令创建自定义模型并指定量化时，Ollama会调用llama.cpp 中的 llama_model_quantize 函数来完成量化工作 。

成的。这种设计虽然实现了语言和模块的解耦，但也引入了不可避免的性能开销。

2.3 GGUF 模型格式的角色

GGUF （GPT-Generated Unified Format）是Ollama生态系统的基石，由llama.cpp团队开发，是GGML格式的继任者。

包在一个文件中：模型权重、分词器配置、提示词模板、量化信息以及其他元数据 。这 20

极大地简化了模型的分享和分发。

并允许将模型的某些层“卸载”到GPU上进行加速 。这种混合执行的能力使得GGUF模型

能够在从苹果M系列芯片的MacBook到没有高端GPU的Linux服务器等各种设备上运行， 这是Ollama能够跨平台普及的关键。 Ollama的“封装”架构带来了双重影响：

每一次推理请求都涉及到一次本地网络调用、数据序列化和反序列化，这引入了额外的延迟，尤其是在处理大量小请求时，这种开销会变得非常显著 。相比之下，一个单体式 17

的、在同一进程内完成所有操作的框架则没有这部分开销。

能子集。许多 llama.cpp 的高级参数和精细控制选项在Ollama中并未提供，这使得高级用户在进行深度优化时感到受限 。 17

参数、模型格式转换等问题。Ollama将所有复杂性都隐藏在了一个统一且简洁的接口之后，用户只需执行 ollama run qwen2.5 即可开始使用，极大地降低了进入门槛 。 1

这种架构选择清晰地表明，Ollama的设计优先序是易用性 > 兼容性 > 性能。它通过牺牲一部分原生性能和控制力，换取了无与伦比的便捷性和跨平台能力，这一定位使其在开发者社区中广受欢迎。

第三章：Ollama多GPU部署策略与实现

支持多GPU运行，其多GPU支持主要是为了解决“模型放不下”的问题，而非“让模型Ollama 跑得更快”。 的自动多GPU行为

3.1 Ollama

将模型的各层（layers）分割，并依次加载到不同的GPU上 。例如，一个30GB的模型

在两张24GB的GPU上运行时，Ollama可能会将前一半的层加载到GPU 0，后一半的层加载到GPU 1。

过程是串行的：数据必须先在GPU 0上完成其对应层的计算，然后通过相对较慢的PCIe 总线传输到GPU 1，再由GPU 1完成剩余层的计算 。在这个过程中，当一张GPU在工作

时，另一张GPU很可能在等待。这不仅没有实现计算的并行加速，反而因为跨卡数据传输引入了额外的延迟。许多用户和专家的分析都证实，这并非张量并行，对于追求性能的场景是次优选择 。10

3.2 手动控制与社区变通方案

由于Ollama原生的多GPU机制无法满足性能需求，社区发展出了一套“变通”方案。

用程序能够“看到”和使用的GPU。例如，设置 CUDA_VISIBLE_DEVICES=0 将使程序只能使用第一张GPU。

E_DEVICES 将每个实例“钉”在不同的GPU上 。例如，在一个4卡系统上，可以启动4个

Ollama服务，分别监听在不同的端口上，并分别配置 CUDA_VISIBLE_DEVICES=0 , CUDA_VISI BLE_DEVICES=1 , CUDA_VISIBLE_DEVICES=2 , CUDA_VISIBLE_DEVICES=3 。

Nginx），将传入的API请求分发到不同的实例上。

个Ollama实例都需要在它所绑定的GPU上完整地加载一份模型副本。这意味着巨大的显存冗余。对于一个需要18GB显存的32B量化模型，在4x 4090系统上使用此方案，将总共消耗 18GB * 4 = 72GB 的显存，仅仅用于存储模型权重。这不仅极大地浪费了宝贵的显存资源，限制了可用于KV缓存的空间，而且对于那些单卡无法容纳的模型（例如未量化的32B模型），此方案根本不可行。

Ollama提供了一个实验性参数OLLAMA_SCHED_SPREAD=1，该参数会强制Ollama将模型分散到所有可用的GPU上，即使模型可以装入单卡 10。但这需要明确，其分散方式仍然是基于层的顺序分割，并不能加速单个请求的处理速度，其性能模型与自动分割时一致。

第四章：特定硬件性能与部署分析

本章节将Ollama架构理论应用于用户指定的具体硬件平台——NVIDIA A800和多卡NVIDIA RTX 4090，并结合Qwen2.5模型的特性，提供具体的性能预测和部署策略。

4.1 目标硬件规格与考量

为了进行精确分析，首先需要明确两款目标GPU在LLM推理任务中的关键特性。具体分析如下： 1. NVIDIA A800 (80GB)

带宽高达约1.94 TB/s。它拥有432个第三代Tensor Core，最大功耗（TDP）为250W 。

显存可以轻松容纳像Qwen2.5-32B这样的模型以FP16（半精度，约64GB）甚至BF16格式运行，无需进行有损的低比特量化，从而最大程度地保留模型原始性能。 其超高的内存带宽是LLM推理的另一个关键优势，因为推理过程是内存密集型（memory-bound）的，需要快速地将模型权重从显存加载到计算单元。vLLM的PagedAttention和连续批处理等技术能够充分利用这一高带宽特性，实现极高的请求吞吐量。

2. NVIDIA RTX 4090 (24GB) 关键规格: RTX 4090采用更先进的AD102 Ada Lovelace架构，配备24GB的GDDR6X

显存，内存带宽约为1.01 TB/s。它拥有512个第四代Tensor Core，但TDP也更高， 达到了450W 。 34

LLM推理分析: RTX 4090的优势在于其更高的核心频率和更现代的架构，其第四代

Tensor Core对FP8等新数据格式的支持更佳。然而，其24GB的显存容量和约1TB/s 的内存带宽与A800相比有明显差距。对于多卡配置（如4x 4090），总显存容量可观（96GB），但性能瓶颈转移到了卡间互联的速度上。消费级的RTX 4090通常不具备企业级GPU的NVLink高速互联，卡间通信依赖于PCIe 4.0总线，这对需要频繁进行跨卡数据交换的张量并行等技术提出了更高的要求。框架能否高效利用这种互联方式，成为决定最终性能的关键。 表2：NVIDIA A800与RTX 4090在LLM推理中的关键规格对比规格 NVIDIA A800 (80GB) NVIDIA RTX 4090 (24GB)

架构 Ampere (GA100) Ada Lovelace (AD102)

显存容量 80 GB 33 24 GB 34

显存类型 HBM2e 33 GDDR6X 34

内存带宽 ~1.94 TB/s 33 ~1.01 TB/s 35

Tensor Cores 第三代) 432 ( 33 512 ( 第四代) 37

支持NVLink 是 (400 GB/s) 38 否 36

最大功耗 (TDP) 250 W 33 450 W 35

互联接口 PCIe 4.0 x16 PCIe 4.0 x16

4.2 模型部署场景与建议

基于上述硬件分析，我们可以对具体的模型部署场景进行评估。 1. 场景一：在单张NVIDIA A800上部署Qwen2.5-32B 模型大小: Qwen2.5-32B的FP16权重约为64GB，完全可以装入A800的80GB显存

中。

使用Ollama: 部署过程极为简单。性能对于单个用户的交互式会话是足够的。但由于

其批处理机制效率不高，在处理并发请求时，吞吐量将很快达到瓶颈，无法充分发挥A800的硬件潜力 。 3

2. 场景二：在4x RTX 4090上部署Qwen2.5-32B 模型大小: FP16权重（~64GB）必须被分割。即使是4-bit量化模型（~18GB） ，虽

然可以装入单卡，但目标是利用全部四张卡来获得更高性能。 使用Ollama: Ollama会自动将64GB的FP16模型进行层分割，每张卡大约承载16GB

的权重。模型可以运行，但性能会非常低下。因为推理过程是串行的，数据需要在四张卡之间通过PCIe总线依次传递，跨卡通信的延迟将成为主要瓶颈 。 10

强烈不推荐此方案用于任何对性能有要求的应用。 3. 场景三：在4x RTX 4090上部署Qwen2.5-14B 模型大小: 4-bit量化后的Qwen2.5-14B模型大小约为9GB 。

使用Ollama: 可以采用社区的“多实例”变通方案。在每张4090上都运行一个独立的

Ollama实例，并加载一份9GB的模型副本，前端用负载均衡器分发请求。这会消耗 9 GB * 4 = 36GB 的总显存来存储权重，但可以实现4个请求的并行处理。

4.3 量化影响分析

量化是在资源受限的硬件上运行大模型的关键技术。GGUF (Ollama生态): GGUF本身是一个容器格式，它支持多种量化策略，通常以 Q4_K_M 、 Q5_K_S 等标签表示，这些是采用混合精度技术的复杂量化方案 。GGUF的核心优势在于其为CPU和GPU混合执行设计的灵活性，

但这对于纯GPU的高性能服务器来说并非优点，反而可能带来一些不必要的开销 。 3

表3：Qwen2.5模型部署性能综合预估 (单位：tokens/秒) 框架 硬件配置 模型 量化 使用场景 预估吞吐量 ( Ollama 1x A800 Qwen2.5-32B GGUF Q4_K_M 单用户交互 ~40-60

Ollama 4x RTX 4090 Qwen2.5-32B GGUF Q4_K_M 层分割 受 < 20 ( PCIe

Ollama 4x RTX 4090 Qwen2.5-14B GGUF Q4_K_M 多实例 独 ~60-70 * 4 (

注意：以上数据是基于所提供的研究材料中的基准测试数据 进行的综合预估，实际性能可 40

能因具体工作负载、输入/输出长度和软件版本而异。

第五章：实践部署指南与代码示例

本节提供具体、可操作的部署步骤和命令，旨在帮助技术人员在目标硬件上快速部署Qwen2.5模型。

5.1 Ollama 部署

以其简便性著称。以下介绍几种不同的部署方法。 Ollama 1. 环境准备在Linux系统上，使用官方提供的一行命令即可完成Ollama的安装： 复制代码

curl -fsSL https://ollama.com/install.sh | sh

安装程序会自动配置好服务 。 12

2. 标准模型拉取与运行 (以单卡A800为例)

复制代码ollama pull qwen2.5:32b

Ollama 会自动从其官方模型库下载预先转换为GGUF格式的Qwen2.5-32B模型 。21

复制代码ollama run qwen2.5:32b

此命令会启动一个交互式的命令行会话，可以直接与模型对话。同时，Ollama的后台服务也会启动，可以通过其API进行访问。 3. 使用自定义GGUF和Modelfile

当用户拥有一个特定的GGUF文件（例如，由社区提供的特殊量化版本）时，可以使用Modelfile来创建自定义的Ollama模型。

在你的GGUF文件所在的目录，创建一个名为 Modelfile (无扩展名) 的文件。文件内容应包含模型来源、参数和提示模板。以Qwen2.5为例，内容如下 21：

复制代码FROM./qwen2.5-32b-instruct-q4_k_m.gguf PARAMETER temperature 0.7 PARAMETER top_p 0.8 TEMPLATE """<|im_start|>system {{.System }}<|im_end|> <|im_start|>user {{.Prompt }}<|im_end|> <|im_start|>assistant """ SYSTEM """You are a helpful assistant."""

复制代码ollama create my-qwen2.5-32b -f Modelfile

复制代码ollama run my-qwen2.5-32b

多GPU变通方案 (用于在4x 4090上并行处理小模型) 4. 此方法仅适用于模型可以完全装入单张RTX 4090的情况（例如Qwen2.5-14B），并且需要手动配置，效率较低。

同端口。

复制代码 #!/bin/bash # 启动4个Ollama实例

# 实例 0 on GPU 0 CUDA_VISIBLE_DEVICES=0 OLLAMA_HOST=0.0.0.0:11434 ollama serve &

# 实例 1 on GPU 1 CUDA_VISIBLE_DEVICES=1 OLLAMA_HOST=0.0.0.0:11435 ollama serve &

# 实例 2 on GPU 2 CUDA_VISIBLE_DEVICES=2 OLLAMA_HOST=0.0.0.0:11436 ollama serve &

# 实例 3 on GPU 3 CUDA_VISIBLE_DEVICES=3 OLLAMA_HOST=0.0.0.0:11437 ollama serve &

wait

此脚本展示了如何使用 CUDA_VISIBLE_DEVICES 环境变量来隔离GPU 。在生产环境中，这通

常通过systemd服务文件或Docker Compose来管理。 负载均衡: 用户需要在这些实例（ localhost:11434 到 localhost:11437 ）之前部署 ○

一个反向代理（如Nginx）来统一入口并将请求轮询分发。 注意: 此方案会导致模型权重被复制4次，造成巨大的显存浪费，因此仅作为特定场景 ○

下的备选方案。

第六章：结论

的架构与生态系统

6.1 Ollama

统一的工具，用户只需一条命令即可在本地运行一个功能完备的LLM服务 。它提供了一 15

个简洁的命令行界面（CLI）用于模型管理和交互，并默认在本地11434端口暴露一个兼容OpenAI的API服务，方便应用程序集成 。 19

○ 数据隐私与离线能力：所有数据和计算都保留在本地硬件上，完全消除了数据隐私泄露的风险，并支持在无网络连接的环境下工作 。 19

○ 快速原型验证：开发人员无需申请API密钥或配置云服务，即可快速地在本地测试不同的开源模型，迭代和优化提示词（Prompt），从而加速AI功能的开发周期 。 20

○ 环境一致性：Ollama为团队提供了一个可复现的模型运行环境。通过共享 Modelfil e 或容器化的Ollama环境，可以确保所有团队成员使用相同的模型和配置，有效避免了“在我机器上能跑”的问题 。 20

○ 嵌入式部署：将Ollama服务与应用程序部署在同一台服务器上，应用通过本地回环地址调用API。这种方式结构简单，移动部件最少 。 20

○ 边车（Sidecar）容器：在Kubernetes等容器编排环境中，可以将Ollama作为一个边车容器与主应用容器部署在同一个Pod中。这实现了关注点分离，同时保持了逻辑上的紧密耦合 。

○ 专用的本地服务：为内部工具或多个小型应用提供一个集中的本地LLM服务 。 20

6.2 Ollama局限性分析

尽管Ollama在开发阶段表现出色，但其架构上的选择也决定了它在生产级别的高并发场景下存在明显的性能瓶颈。

于加速）和CPU 。运行大型模型需要大量的内存，例如，一个7B参数的模型通常需要

至少8GB的RAM，而一个70B的模型则可能需要高端GPU和数十GB的显存 。 19

求，一旦超出此限制，后续的请求就会进入队列等待 。这导致在高并发负载下，请求的

“首字返回时间”（Time to First Token, TTFT）会急剧增加，而整体的吞吐量（TPS/RPS）则会迅速达到平台期，无法随用户数增加而扩展 。 21

即使请求的是同一个模型，它也可能会卸载当前加载的模型并重新加载一个新配置的版本。这个“模型切换”（Model Swapping）过程会引入显著的延迟，使其不适合同时为多个不同需求的应用场景提供服务 。 25

Ollama的架构设计体现了一种权衡：它通过牺牲极致的性能和扩展性，换取了无与伦比的易用性和便捷性。那些使其易于上手的特性，如自动化的模型管理和简单的请求队列，正是导致其在生产环境中性能受限的直接原因。Ollama是为单用户、交互式的开发工作流而优化的，而非为多租户、高并发的服务端工作流设计。因此，将Ollama定位为应用开发和提示工程的“第0阶段”工具是恰当的，但企业必须清醒地认识到，当一个AI功能走向成熟并面临生产流量时，从Ollama平滑过渡到vLLM这样的生产级推理服务器，是一个必要且关键的架构决策

第四部分：vLLM框架

第一章：引言

尽管 Ollama 为本地部署提供了无与伦比的易用性，但在追求极致性能、高吞吐量和低延迟的生产级应用场景下，其背后的通用化设计哲学便显现出局限性。在这些严苛的性能需求面前，开发者们需要一个专门为大规模 LLM 推理而优化的框架。

vLLM 应运而生，它是一个专门为最大化 LLM 推理吞吐量而设计的开源库。其工程设计的每

一个环节都围绕着提升效率、支持高并发用户和实现生产级服务展开。vLLM 的核心优势源于其底层创新的算法，尤其是其革命性的 PagedAttention 技术，该技术通过借鉴操作系统分页机制，从根本上解决了 LLM 推存中的 KV 缓存内存碎片化问题，极大地提升了显存利用率和吞吐量。 本报告将深入剖析其核心技术，并详细阐述如何在上述两种高性能 NVIDIA GPU 平台上（NVIDIA A800 和 NVIDIA RTX 4090）进行部署和性能调优。通过与 Ollama 的对比，我们将清晰地展示 vLLM 在处理复杂、高负载场景时的架构优势和性能表现，为企业级和专业级应用提供明确的技术选型指南。 在深入vLLM技术细节之前，下表提供了一个对两个框架关键特性的高层次概览，以帮助读者建立初步的认知框架。 特性 Ollama vLLM

主要目标 简化本地部署，提升易用性 1 最大化推理吞吐量与效率 4

目标用户 个人开发者、研究人员、快速原型验证 生产环境、性能敏感型应用、高并发服务核心引擎 llama.cpp 6 自研Python/CUDA引擎

关键技术 模型格式，CPU/GPU混合执行GGUF 7 PagedAttention，连续批处理 5

多GPU策略 自动层分割（容量扩展） 10 张量并行/流水线并行（性能扩展） 9

支持的量化 GGUF (Q2-Q8, K-quants) 7 AWQ, GPTQ, FP8等GPU原生格式 4

API兼容性 自有REST API，兼容OpenAI部分接口 1 完全兼容OpenAI API服务器 4

第二章：vLLM架构：以内存为中心的性能优化革命

与Ollama的“自顶向下”设计不同，vLLM采用了“自底向上”的工程哲学。它首先识别出LLM服务中最核心、最致命的性能瓶颈，然后围绕解决这个瓶颈构建了整个系统。

2.1 核心瓶颈：KV缓存管理

vLLM的诞生源于对LLM自回归解码过程中一个关键组件——KV缓存（Key-Value Cache）的深刻洞察。在生成每个新词元时，模型都需要利用先前所有词元的注意力键（Key）和值（Value）张量，这些张量被存储在GPU显存中，即KV缓存。KV缓存具有两大棘手的特性： 1. 体积庞大: 对于一个长序列，KV缓存可能占用数GB的显存，例如LLaMA-13B处理单个序列就需要高达1.7GB 。 5

2. 动态变化: 其大小与序列长度成正比，而输入和输出序列的长度是高度可变且不可预测的。 传统的推理系统在管理KV缓存时效率低下。它们通常为每个请求预先分配一块能够容纳最大可能序列长度的连续显存块。这种“过度预留”导致了严重的内存浪费。vLLM的研究发现，现有系统因内存碎片化和过度预留，浪费了高达60%至80%的显存 。这极大地限制了系统能5

够同时处理的请求数量（即批处理大小），从而限制了GPU的利用率和整体吞吐量。

2.2 核心技术一：PagedAttention

为了解决KV缓存的管理难题，vLLM引入了其核心创新——PagedAttention算法 5。该算法的设计灵感源自操作系统中经典的虚拟内存和分页机制 8。

它将KV缓存分割成许多个固定大小的小块（Block），这些块在物理显存中可以是不连续的。系统通过一个“块表”（Block Table）来维护每个序列的逻辑词元顺序与这些物理块之间的映射关系。当生成新词元需要更多KV缓存空间时，内存管理器会按需分配新的物理块，并更新块表 。 5

a. 消除内存碎片: 通过以小块为单位进行内存管理，PagedAttention几乎完全消除了内部碎片化。内存浪费仅存在于每个序列的最后一个块中，实际浪费率低于4% 。这使 5

得显存利用率达到近乎最优，从而可以容纳更大规模的批处理。 b. 实现高效内存共享: 在并行采样（parallel sampling）或束搜索（beam search）等复杂解码场景中，多个候选输出序列共享相同的前缀（prompt）。利用PagedAttention，这些序列可以共享存储prompt的KV缓存物理块，而无需为每个候选序列都复制一份。这极大地节省了显存和计算量，显著提升了这类任务的效率 。 5

尽管PagedAttention带来了巨大的性能提升，但也有其技术代价。正如后续研究（如vAttention）所指出的，实现PagedAttention需要重写底层的CUDA注意力核函数以支持非连续内存访问，并需要在框架内实现一个复杂的用户态内存管理器 。这体现了vLLM为追求极

致性能所付出的巨大工程努力。

2.3 核心技术二：连续批处理 (Continuous Batching)

PagedAttention 高效的内存管理为另一项关键优化——连续批处理——铺平了道路。

一个批次，然后必须等待这个批次中所有请求都完成生成后，才能开始处理下一个批次。 由于不同请求的输出长度不同，这会导致GPU在等待最长的请求完成时处于空闲状态。

骤（iteration）后都会检查批次中是否有请求已经完成。一旦某个请求完成，调度器会立即从等待队列中选择一个新的请求加入到当前批次中，而无需等待整个批次结束 。 4

率和系统总吞吐量。基准测试显示，vLLM凭借这一技术，相比标准的HuggingFace Transformers实现，吞吐量提升可高达24倍 。 5

2.4 以GPU为中心的设计

vLLM的整个设计理念都是以GPU为中心，为高性能服务而生。它深度集成了业界最优化的CUDA 核函数（如FlashAttention），并原生支持为GPU推理设计的量化格式，如AWQ （Activation-aware Weight Quantization）4。这与Ollama所依赖的GGUF格式的CPU优先、 追求普适性的设计哲学形成了鲜明对比。 vLLM的架构选择体现了其对性能的极致追求。它没有在易用性上做任何妥协，而是直面LLM 服务中最根本的系统瓶颈，并通过世界级的算法创新和工程实现来解决它。这种“第一性原理”的解决问题方式，是其能够在高性能LLM服务领域树立标杆的根本原因。

第三章：vLLM多GPU部署策略与实现

为多GPU部署提供了两种成熟的模型并行策略：张量并行（Tensor Parallelism）和流vLLM 水线并行（Pipeline Parallelism），两者均旨在通过分布式计算来突破单卡限制。

3.1 张量并行 (Tensor Parallelism, TP)

分，如Transformer层中的权重矩阵（例如，自注意力机制的查询、键、值投影矩阵和前馈网络的线性层矩阵），沿着某个维度进行切分，并将切分后的子矩阵分布到不同的GPU上 。在进行前向传播时，每张GPU仅负责其持有的那部分矩阵的乘法运算。计算完

成后，各GPU通过高速互联（如NVLink或PCIe）交换部分结果（All-Reduce或All-Gather 等集合通信操作），并将结果合并，以获得与在单卡上计算等效的完整输出，然后进入模型的下一步计算。

重要的是，它并行化了计算密集型任务。这意味着多张GPU可以同时为一个请求（或一个批次）进行计算，从而直接降低了单次推理的延迟，并显著提升了系统的整体吞吐量。

arallel-size <N> ，其中 N 是希望用于张量并行的GPU数量，vLLM便会自动处理模型的切分、分发和通信 。例如，在4卡系统上，设置为 --tensor-parallel-size 4 即可。

3.2 流水线并行 (Pipeline Parallelism, PP)

块）顺序地放置在不同的GPU上。例如，GPU 0负责计算第1到10层，GPU 1负责第11到20层，以此类推 。数据流像流水线一样，在前向传播时，一个微批次（micro-batch）的

数据在GPU 0上完成计算后，其输出激活值被传递给GPU 1进行下一阶段的计算，同时GPU 0可以开始处理下一个微批次。

纳的模型，或者在多节点（multi-node）分布式推理中使用。然而，由于流水线的启动和排空阶段会存在部分GPU空闲的“气泡”（bubble）问题，其效率通常低于张量并行。 vLLM的文档也指出，在单节点内，这是一种用于处理GPU数量无法被模型层数整除等边缘情况的策略 。 9

vLLM的分布式优势：vLLM利用Ray作为其分布式执行后端，这使得配置和管理上述复杂的并行策略变得相对容易。整个框架从设计之初就考虑了跨多GPU和多节点的性能扩展，为生产级的大规模部署提供了坚实的基础。 尽管Ollama和vLLM都支持多 GPU，但其底层实现和达到的效果截然不同。vLLM 提供的是通过张量并行实现的真实性能扩展，能够将单个大模型的高效推理任务分布到多张卡上，从而显著提升吞吐量和降低延迟。相比之下，Ollama 提供的是通过层分割实现的容量扩展，即将模型的不同层分配到不同的 GPU 上以容纳更大的模型，而非并行加速推理过程。综上所述，对于希望利用多卡系统（如4x RTX 4090）来运行大模型并获得高性能的用户而言，

vLLM 的架构是唯一合理且高效的选择。而 Ollama 的方案则暴露了其在高性能、多卡并行计

算场景下的架构局限性。对于期望利用多卡系统（如4x 4090）来运行大模型并获得高性能的用户来说，vLLM的架构是唯一合理且高效的选择。Ollama的方案则暴露了其在高性能、多卡并行计算场景下的架构局限性。

第四章：特定硬件性能与部署分析

本章节将前述的架构理论应用于用户指定的具体硬件平台——NVIDIA A800和多卡NVIDIA RTX 4090，并结合Qwen2.5模型的特性，提供具体的性能预测和部署策略。目标硬件平台的具体规格与考量在前文 Ollama 章节中已进行了详细介绍，本章节将不再重复赘述。我们将直接聚焦于模型部署场景与建议以及量化影响分析，通过将 Ollama 的方案与 vLLM 进行对比，提供具体的性能预测和部署策略。

4.1 模型部署场景与建议

基于上述硬件分析，我们可以对具体的模型部署场景进行评估。 场景一：在单张NVIDIA A800上部署Qwen2.5-32B

处理机制效率不高，在处理并发请求时，吞吐量将很快达到瓶颈，无法充分发挥A800的硬件潜力 。 3

6GB ）作为KV缓存空间，并通过PagedAttention和连续批处理技术，将多个并发请求高效地打包处理，从而将A800的高内存带宽和计算能力压榨到极限，获得极高的服务吞吐量。 5

场景二：在4x RTX 4090上部署Qwen2.5-32B

以装入单卡，但目标是利用全部四张卡来获得更高性能。

重。模型可以运行，但性能会非常低下。因为推理过程是串行的，数据需要在四张卡之间通过PCIe总线依次传递，跨卡通信的延迟将成为主要瓶颈 。 10

强烈不推荐此方案用于任何对性能有要求的应用。

vLLM会将模型的张量权重均匀分布到四张卡上（每卡约16GB）。计算将在四张卡上并行进行，并通过vLLM优化的通信原语（如Ring-Attention）聚合结果。这种方式能够有效聚合四张卡的算力，提供高吞吐量的服务 。 9

场景三：在4x RTX 4090上部署Qwen2.5-14B

实例，并加载一份9GB的模型副本，前端用负载均衡器分发请求。这会消耗 9GB * 4 = 36 GB 的总显存来存储权重，但可以实现4个请求的并行处理。

被加载一次，分散在四张卡上（每卡约2.25GB）。这样，总系统显存（96GB）中将有超过85GB的巨大空间可用于KV缓存。这使得vLLM能够支持极大的批处理大小和极高的并发请求数，其总吞吐量将远超Ollama的多实例方案。

4.2 量化影响分析

4.2.1 AWQ vs. GGUF

Ollama 和vLLM生态系统分别倾向于不同的量化方案。

GGUF (Ollama M 、 Q5_K_S 等标签表示，这些是采用混合精度技术的复杂量化方案 。GGUF的核心优 43

势在于其为CPU和GPU混合执行设计的灵活性，但这对于纯GPU的高性能服务器来说并非优点，反而可能带来一些不必要的开销 。 3

量化（PTQ）方法。它的核心思想是，并非所有模型权重都同等重要。通过在一个校准数据集上观察模型的激活值，AWQ能够识别出那些对模型性能影响最大的“显著权重” （salient weights），并在量化过程中给予它们保护（即用更高的精度或更小的缩放因子），而对其他不那么重要的权重进行更大幅度的压缩 。AWQ是专门为GPU推理设计 23

的，vLLM对其提供了原生支持 。在纯GPU推理场景下，AWQ通常被认为比其前辈

GPTQ以及通用格式GGUF具有更好的性能和速度表现 。部分社区测试甚至表明，4-bit 23

的AWQ模型性能可以媲美甚至超过更高比特数的GGUF模型 。 45

表3：Qwen2.5模型部署性能综合预估 (单位：tokens/秒) 框架 硬件配置 模型 量化 使用场景 预估吞吐量Ollama 1x A800 Qwen2.5-32B GGUF Q4_K_M 单用户交互 ~40-60

vLLM        1x A800       Qwen2.5-32B       AWQ 4-bit                  高并发服务      > 130 42

Ollama 4x RTX 4090 Qwen2.5-32B GGUF Q4_K_M 层分割 受 < 20 ( PCI

vLLM        4x RTX 4090   Qwen2.5-32B       AWQ 4-bit                  张量并行       > 100 (聚合性

Ollama 4x RTX 4090 Qwen2.5-14B GGUF Q4_K_M 多实例 ~60-70 * 4 (

vLLM        4x RTX 4090   Qwen2.5-14B       AWQ 4-bit                  张量并行       > 250 (高并发

注意：以上数据是基于所提供的研究材料中的基准测试数据 进行的综合预估，实际性能可 40

能因具体工作负载、输入/输出长度和软件版本而异。

4.2.2 性能基准测试：量化分析

vLLM与Ollama之间的性能差距是巨大的，这一点在量化基准测试中得到了清晰的体现。通过对比两者在相同硬件（如NVIDIA A100 GPU）和模型（如Llama-3.1 8B）下的表现，可以观察到以下关键差异 ： 23

秒生成token数（TPS）几乎呈线性增长，直至硬件饱和。相比之下，Ollama的吞吐量在很低的并发水平（如4个并发请求）下就迅速达到瓶颈并保持平坦 。在峰值负载下， 23

的 可以达到

vLLM TPS       Ollama  的近20倍（例如，一项基准测试中vLLM达到793 TPS，而

仅为Ollama ）。 41 TPS 23

○ 首字返回时间（TTFT）：vLLM在各种负载下都能保持极低且稳定的TTFT，确保用户能够快速得到响应。而Ollama由于采用请求排队机制，其TTFT会随着并发数的增加而急剧恶化 。 23

○ 字间延迟（ITL）：Ollama通过限制并行处理，其ITL保持稳定，但这牺牲了大量用户的等待时间。vLLM为了最大化整体吞吐量，会处理更大的批次，这可能导致在高并发下ITL有轻微上升，但其绝对值仍然处于极低的水平，保证了流畅的文本生成体验 。

这种性能上的鸿沟并非偶然，而是源于两者根本不同的架构哲学。vLLM的架构设计以系统吞吐量为首要目标，其核心的PagedAttention机制直接解决了内存管理这一根本性瓶颈，从而释放了GPU的全部潜力。而Ollama的设计则优先考虑了开发者的易用性。基准测试数据为这一架构选择的差异提供了无可辩驳的量化证据。

4.2.3 通过模型量化优化vLLM

为了在有限的硬件资源上运行更大的模型，或进一步提升现有模型的推理速度，模型量化是一种至关重要的优化技术。量化通过将模型权重和激活值从高精度浮点数（如FP16）转换为低精度整数（如INT8, INT4）或浮点数（如FP8），来减小模型的内存占用和计算量 。 26

度、性能和硬件的权衡来选择最合适的方案 ： 28

○ AWQ (Activation-aware Weight Quantization)：一种流行的权重量化方法，通过分析激活值的分布来保留对模型性能至关重要的权重，从而在低比特量化（如4-bit） 下保持较高的模型精度 。 29

○ GPTQ (General-purpose Post-Training Quantization)：另一种先进的训练后权重量化算法，它逐层对权重进行量化，并通过校准数据来最小化量化误差 。 29

○ FP8：一种8位浮点数格式，能够在保持较高精度的同时提供显著的性能提升，但通常需要较新的GPU架构（如NVIDIA Ada Lovelace和Hopper系列）才能获得硬件加速支持 。 30

○ W8A8：权重和激活值均为8位整数的量化方案，可以大幅降低内存占用和计算需求 。

○ GGUF：一种广泛用于本地LLM社区的文件格式，它将模型权重和元数据打包在一起，并支持多种量化等级。vLLM对GGUF格式的支持增强了其与社区生态的兼容性 。

采用vLLM标志着团队职责和所需技能的重大转变。关注点从应用层逻辑（如提示工程）转移到了系统层优化（如量化方案选择、GPU内存调优）。这要求团队必须具备或培养更强的

和系统工程能力。如何选择最合适的量化方案，以在性能、精度和硬件兼容性之间找MLOps 到最佳平衡点，本身就构成了一个新的、复杂的优化挑战。 表2：性能基准摘要：Ollama vs. vLLM 性能指标 Ollama ( 调优后) vLLM 性能差异峰值吞吐量 (TPS) 41 793 vLLM高19.3倍

峰值吞吐量 (RPS) 4.8 36.5 vLLM高7.6倍

P99首字返回时间 673 ms 80 ms vLLM快8.4倍(TTFT) @ 峰值

数据来源:. 测试环境为单张NVIDIA A100-40GB GPU，模型为Llama-3.1-8B。Ollama已调

优至在此硬件上的最佳并行设置。 表3：vLLM支持的主流模型量化方案量化方案 描述 主要优势 适用AWQ 激活感知权重量化。保留对模 在4-bit等低比特下保持高精度。 内存型性能重要的权重。 景。 GPTQ 通用训练后量化。逐层量化以 良好的精度和性能平衡。 广泛最小化误差。 FP8 8位浮点数量化。 显著的速度提升和内存节省。 需要Ho 件加W8A8 权重和激活值均为8位整数。 大幅减少内存占用和计算量。 对模感型GGUF 社区流行的模型文件格式，支 良好的生态兼容性，易于使用。 快速持多种量化等级。

4.3 vllm启动以及设备类型确认

本章节开始梳理一下vllm在使用GPU运行LLM时的启动路径，其中很多内容在前面有所涉及，温故而知新。 启动使用debug模式，查看更多的启动信息。 源码在

vllm/platforms/init.py 这里会验证资源类型，我的环境是GPU环境。 当这个模块

（vllm/platforms/init.py）被import时（比如from vllm.platforms import current_platform），Python 会执行模块中的顶级代码。这包括定义函数、类和变量。具体执行内容如下，在__init__.py中，触发__getattr__这是一个特殊的 Python 函数，当访问一个不存在的属性时会被调用。在这个文件中，它用于延迟初始化 current_platform。 这里为什么需要延迟初始化current_platform呢？ 模块导入时不初始化：在模块导入时不立即初始化current_platform，而是等到第一次访问 current_platform 时才进行初始化。这种方式称为 “延迟初始化”或“惰性初始化”。 插件加载顺序：延迟初始化允许在模块导入后，确保所有可能影响平台检测的插件都已加载，从而避免在插件加载之前就确定平台。 通过这种方式， current_platform 的初始化被推迟到实际需要时才进行，确保了平台检测的准确性和灵活性。

源码

vllm                                                 复制代码

def cuda_platform_plugin() -> Optional[str]: is_cuda = False try: from vllm.utils import import_pynvml # 这里使用了pynvml（另外pynvml有两个，一个是nvidia官方的nvdia-ml- py，另外一个是pynvml， # 并且pynvml在系统中的优先级更高，因为vllm会将nvidia-ml-py一起安装， # 所以用户可以将之前安装的pynvml卸载掉避免调用错误） pynvml = import_pynvml() # 进行nvml初始化，但是不调用cuda，可以避免cuda context的创建,缩短初始化时间， # 这里只需要通过nvml确认GPU存在即可。 pynvml.nvmlInit() try: if pynvml.nvmlDeviceGetCount() > 0: is_cuda = True finally: pynvml.nvmlShutdown() except Exception as e: if "nvml" not in e.__class__.__name__.lower(): # If the error is not related to NVML, re-raise it. raise e

# CUDA is supported on Jetson, but NVML may not be. import os

def cuda_is_jetson() -> bool: return os.path.isfile("/etc/nv_tegra_release") \ or os.path.exists("/sys/class/tegra-firmware")

if cuda_is_jetson(): is_cuda = True

return "vllm.platforms.cuda.CudaPlatform" if is_cuda else None

builtin_platform_plugins = { 'tpu': tpu_platform_plugin, 'cuda': cuda_platform_plugin, 'rocm': rocm_platform_plugin, 'hpu': hpu_platform_plugin, 'xpu': xpu_platform_plugin, 'cpu': cpu_platform_plugin, 'neuron': neuron_platform_plugin, 'openvino': openvino_platform_plugin, }

def resolve_current_platform_cls_qualname() -> str: platform_plugins = load_plugins_by_group('vllm.platform_plugins')

activated_plugins = []

for name, func in chain(builtin_platform_plugins.items(), platform_plugins.items()): try: assert callable(func) platform_cls_qualname = func() if platform_cls_qualname is not None: activated_plugins.append(name) except Exception: pass

activated_builtin_plugins = list( set(activated_plugins) & set(builtin_platform_plugins.keys()))

activated_oot_plugins = list( set(activated_plugins) & set(platform_plugins.keys()))

if len(activated_oot_plugins) >= 2: raise RuntimeError( "Only one platform plugin can be activated, but got: " f"{activated_oot_plugins}") elif len(activated_oot_plugins) == 1: platform_cls_qualname = platform_plugins[activated_oot_plugins[0]]() logger.info("Platform plugin %s is activated", activated_oot_plugins[0]) elif len(activated_builtin_plugins) >= 2: raise RuntimeError( "Only one platform plugin can be activated, but got: " f"{activated_builtin_plugins}") elif len(activated_builtin_plugins) == 1: # 当当前环境对应的设备类型及plugin的设备类型取交集，得到activated_builtin_plugins， # 如果结果=1，则将调用plugin的函数，并赋值给platform_cls_qualname。 # 以cuda为例，返回的结果是vllm.platforms.cuda.CudaPlatform platform_cls_qualname = builtin_platform_plugins[ activated_builtin_plugins[0]]() logger.info("Automatically detected platform %s.", activated_builtin_plugins[0]) else: platform_cls_qualname = "vllm.platforms.interface.UnspecifiedPlatform" logger.info( "No platform detected, vLLM is running on UnspecifiedPlatform") return platform_cls_qualname

_current_platform = None _init_trace: str = ''

if TYPE_CHECKING: current_platform: Platform

def __getattr__(name: str): if name == 'current_platform': # lazy init current_platform. # 1. out-of-tree platform plugins need `from vllm.platforms import # Platform` so that they can inherit `Platform` class. Therefore, # we cannot resolve `current_platform` during the import of # `vllm.platforms`. # 2. when users use out-of-tree platform plugins, they might run # `import vllm`, some vllm internal code might access # `current_platform` during the import, and we need to make sure # `current_platform` is only resolved after the plugins are loaded # (we have tests for this, if any developer violate this, they will # see the test failures). global _current_platform if _current_platform is None: # 调用 resolve_current_platform_cls_qualname，这个函数会遍历builtin_platform_plugins， # 获得对应函数的返回platform_cls_qualname，并赋值给activated_plugins， # 进而生成activated_oot_plugins，如果activated_oot_plugins大于等于2，则报错。 platform_cls_qualname = resolve_current_platform_cls_qualname() _current_platform = resolve_obj_by_qualname( platform_cls_qualname)() global _init_trace _init_trace = "".join(traceback.format_stack()) return _current_platform elif name in globals(): return globals()[name] else: raise AttributeError( f"No attribute named '{name}' exists in {__name__}.")

__all__ = [

'Platform', 'PlatformEnum', 'current_platform', 'CpuArchEnum',

第五章：实践部署指南与代码示例

本节提供具体、可操作的部署步骤和命令，旨在帮助技术人员在目标硬件上快速部署Qwen2.5模型。

5.1 vLLM 部署工作流 (以4x RTX 4090为例)

vLLM是高性能多卡部署的首选。以下步骤将指导如何在4卡RTX 4090服务器上以张量并行模式部署Qwen2.5-32B的AWQ量化模型。 1. 环境准备确保服务器已安装NVIDIA驱动、CUDA Toolkit (推荐12.1或更高版本)，并已配置好Python环境。 2. 安装vLLM 推荐从PyPI直接安装最新版本的vLLM： 复制代码

pip install vllm

对于特定硬件或需要最新功能，也可以从源码编译安装。 3. 启动vLLM OpenAI兼容服务器使用以下命令启动服务。该命令集成了张量并行、AWQ量化、内存管理等多项关键参数： 复制代码

vllm serve Qwen/Qwen2.5-32B-Instruct-AWQ \
--model-name qwen2.5-32b-instruct \
--tensor-parallel-size 4 \
--quantization awq \
--gpu-memory-utilization 0.90 \
--max-model-len 8192 \
--trust-remote-code \

--port 8000

命令参数详解:

动处理下载和缓存 。 50

缓存，预留10%以防意外 。 25

数为必须 。 25

4. 客户端交互服务启动后，vLLM会提供一个与OpenAI API完全兼容的端点。可以使用任何OpenAI兼容的客户端或curl进行测试： 复制代码

curl http://localhost:8000/v1/chat/completions \
-H "Content-Type: application/json" \
-d '{

"model": "qwen2.5-32b-instruct", "messages": [ {"role": "system", "content": "You are a helpful assistant."}, {"role": "user", "content": "请介绍一下vLLM的PagedAttention技术。"} ], "temperature": 0.7, "max_tokens": 512 }'

5.2 vLLM 参数

的参数在高效部署和调优中扮演着至关重要的角色，它们直接影响着模型的性能、资vLLM 源利用率和稳定性。理解这些参数的作用，是进行生产级 LLM 推理优化的关键。通过对这些参数的精细化配置，开发者可以根据具体的硬件环境、模型大小以及业务需求进行灵活调整，从而充分利用 vLLM 的优化能力，实现大模型推理服务的性能最大化和成本最优化。 表4：vLLM部分参数参数 功能 默认值 说明 --block_size 设置块大小 16 在 CUDA 设备上，仅支持最大

--enable-prefix-caching 是否启用前缀缓存 None V0 默认禁用。V1 默认启用。 效果最佳。 --gpu-memory-utilization 模型执行器的 GPU 内存 0.9 仅适用于当前的 vLLM 实例。 比例 高的值会提高 KV 缓存的大小存不足（OOM）错误。

--swap-space               每个 GPU 的 CPU 交换    4      允许将不活跃的 KV 缓存块迁

空间大小 增加延迟。 --enable-chunked-prefill 对预填充请求进行分块 None 如果为 True，则可以根据 ma 启用分块预填充后，调度策略之前，批处理所有待处理的解可用 token 时，它会调度待处max_num_batched_tokens， 此策略有两个优点：（1）由于Token 延迟）和生成解码。（ （解码）请求放在同一个批次 --max-num-batched-tokens 每次迭代的最大批处理 None 此配置没有静态默认值。如果token 数 EngineArgs.create_engine_c 小的值（例如 2048）可以实现少，不会减慢解码速度。较大（TTFT），因为您可以在一个吐量，官方建议将 max_num 上的小型模型。

--max-num-seqs 每次迭代的最大序列数 None 控制并发处理的序列数量上限max_num_batched_tokens会KV 缓存空间。此配置没有静态在 EngineArgs.create_engine --scheduler-delay-factor 在调度下一个提示之前应 0 延迟因子乘以先前提示延迟。 用延迟 时间，提高可增加批处理效率

--data-parallel-size       数据并行副本数     1                数据并行在多个 GPU 集上复

足够的 GPU 来复制整个模型环境中，请求批次之间的隔离用，并通过 data_parallel_siz 大小的乘积进行分片。

--pipeline-parallel-size   管道并行阶段数             1        将模型层分布到不同的 GPU

留下更多内存用于 KV 缓存。

--tensor-parallel-size     张量并行副本数             1        控制模型跨 GPU 并行程度，

权重分片到不同的 GPU 上， 而，增加此值可能会导致过多 --dtype 模型权重和激活的数据类 auto 可选值：auto, half, float16, b 型 --max-model-len 单个请求的最大处理长度 None 输入prompt + 生成内容的tok 大会占用更多显存，设置过小 --model 要使用的 Hugging Face Qwen/Qwe 当未指定 served_model_nam 模型的名称或路径 n3-0.6B 容。 --quantization 用于量化权重的方法 None 如果为 None，首先检查模型None，假设模型权重未量化，

--served-model-name API 中使用的模型名称 与 -- 如果提供了多个名称，则服务model 参数 型名称将是列表中的第一个名相同 model_name 标签内容中，如

--trust-remote-code 下载模型和分词器时，信 FALSE 任远程代码（例如，来自HuggingFace）

5.3 使用Docker容器化vLLM

在生产环境中，确保部署的一致性和可移植性至关重要。将vLLM服务打包成Docker容器， 是实现这一目标并简化运维管理的标准做法。容器化将应用程序及其所有依赖项封装成一个轻量级、独立的单元，确保其在任何环境中都能以相同的方式运行。

5.3.1 vLLM 服务器的Docker化蓝图

构建一个健壮的vLLM Docker镜像是容器化部署的第一步。这个过程涉及选择合适的基础镜像、安装依赖、以及管理模型文件。

点，例如 nvidia/cuda:12.4.0-base-ubuntu22.04 。这确保了容器内包含与GPU驱动兼容

的CUDA运行时库。随后，通过

pip 安装vLLM及其所需的Python依赖 。     33

Dockerfile

复制代码 # 使用NVIDIA官方CUDA基础镜像FROM nvidia/cuda:12.4.0-base-ubuntu22.04

# 设置工作目录WORKDIR /app

# 安装Python和pip RUN apt-get update && apt-get install -y python3-pip

# 安装vLLM # 为了构建效率，可以指定torch_cuda_arch_list来仅为目标GPU架构编译RUN pip install vllm

# 暴露vLLM默认的服务端口EXPOSE 8000

# 启动vLLM OpenAI兼容服务器的命令 # 模型ID作为参数传入，使其更具灵活性ENTRYPOINT ["python3", "-m", "vllm.entrypoints.openai.api_server"] CMD

在实践中，为了减小最终镜像的大小，可以采用多阶段构建。对于模型文件的处理，可以选择将其直接构建到镜像中以实现不可变的基础设施，或者在容器运行时通过卷挂载的方式提供，后者在模型更新和管理上更为灵活 。 34

脚本，如 run_vllm_docker.sh 。该脚本封装了所有必要的 docker run 命令和参数，使得部署过程可重复且不易出错 。 36

部署的最佳实践

5.3.2. vLLM Docker

成功运行vLLM容器需要正确配置几个关键的运行时参数，这些参数直接关系到GPU的访问和多GPU并行计算的性能。

并在运行容器时添加 --runtime nvidia --gpus all 标志。这使得Docker能够将宿主机的GPU设备和驱动程序映射到容器内部，从而让vLLM应用能够利用GPU进行计算 。 32

（Tensor Parallelism）推理时 。PyTorch的分布式通信库（如NCCL）依赖于进程间共

享内存（IPC）来进行高效的数据交换。将容器的IPC命名空间设置为主机模式，可以确保vLLM的多个工作进程能够无缝地共享数据，从而实现高性能的并行计算 。 34

文件，强烈建议将本地的Hugging Face缓存目录挂载到容器内部，例如使用 -v ~/.cach e/huggingface:/root/.cache/huggingface 。这样，模型文件可以被持久化存储在宿主机

上，在容器重启或更新后依然可用，极大地节省了时间和网络带宽。

确的做法是通过环境变量（ --env ）在容器启动时安全地传入 。 36

GPU软件栈的复杂性——包括对特定NVIDIA驱动版本、CUDA工具包、cuDNN库和相应PyTorch编译版本的严格依赖 ——使得容器化部署从一种“最佳实践”上升为一种“必要手

段”。这个脆弱的依赖链条中任何一个环节的微小差异都可能导致应用崩溃。Docker通过创建一个包含完整且正确依赖链的不可变制品，从根本上解决了这个问题，确保了部署的可靠性和一致性。然而，这也引入了新的挑战：包含大模型文件的容器镜像会变得异常臃肿，给镜像仓库带来存储压力并拖慢部署速度。因此，成熟的部署模式会趋向于将运行时环境（vLLM基础镜像）与模型制品（权重文件）分离，在运行时从一个共享的持久化存储（如Kubernetes的PVC）动态加载模型。

第六章：结论与战略建议

经过对Ollama和vLLM在架构、多GPU策略、硬件适应性及部署实践等方面的深入剖析，本报告得出以下结论，并为用户在特定场景下选择合适的框架提供战略性建议。 核心发现回顾

装，成功地将复杂的LLM部署流程大众化 。vLLM的设计则以

性能为唯一圭臬，通过对底层内存瓶颈的革命性创新（PagedAttention），实现了业界顶尖的推理吞吐量 。 5

台能力，但其“封装-通信”的架构也带来了固有的性能开销和控制局限性 。vLLM的6

PagedAttention与连续批处理技术，是其在高并发场景下取得压倒性性能优势的根本原因，这是一种算法层面的系统性优势 。 4

和显存以加速单个大模型的处理 。Ollama的默认多GPU机制是基于层分割的

容量扩展策略，主要解决模型装不下的问题，无法有效提升性能，甚至可能因通信开销而降低性能 。

性能与实用性的权衡最终的选择归结于一个经典的工程权衡：性能与实用性。vLLM提供了无与伦比的性能，尤其是在高并发和多GPU环境中，其吞吐量可以数倍于Ollama 40。但它也要求一个更受控的、 以GPU为中心的部署环境。Ollama则提供了极致的实用性和便捷性，能够在几分钟内让任何用户在几乎任何设备上运行起一个LLM，但这是以牺牲高负载下的性能为代价的 1。 针对用户场景的最终裁决

或追求最高吞吐量和最低延迟的应用，vLLM是明确且唯一的最佳选择。 其架构优势在此类场景中将得到充分体现，带来数量级的性能提升。

是简化流程和减少设置时间的场景，Ollama仍然是一个极其出色和值得推荐的选项。 特别是在单张A800上进行探索性工作时，Ollama的便捷性优势巨大。

用Ollama。 其层分割机制无法有效利用多卡的并行计算能力。在此场景下，vLLM的张量并行是唯一能够发挥硬件集群优势的正确技术路径。 为了将上述结论转化为一个清晰的决策工具，下表提供了一个推荐矩阵，将不同的使用场景和优先级映射到最合适的框架。 表4：Ollama vs. vLLM 推荐决策矩阵

使用场景 / 优先级 推荐框架 理由与关键考量生产级服务 / 高并发吞吐量 vLLM PagedAttention和连续批处理技术专计，性能优势巨大 。 5

多GPU性能扩展 (如4x 4090) vLLM 原生支持张量并行，可有效聚合多现性能加速 。 9

单用户开发 / 快速实验 Ollama 安装和使用极其简单， ollama ru 极大缩短了从想法到实践的距离 。 1

在A800上运行尽可能大的模型 两者皆可，vLLM更优 A800的80GB显存可容纳大模型。O vLLM能更好地利用显存和带宽，提

跨平台兼容性 (含CPU/Mac) Ollama 基于 llama.cpp 和GGUF，拥有无容性，可在无NVIDIA GPU的环境中追求最低设置门槛 / 易用性 Ollama 设计哲学的核心。无需关心底层细求效率的开发者的首选 。 3

与OpenAI API的兼容性 vLLM 提供完全兼容的API服务器，便于现缝迁移 。Ollama的API为自有格式

Share this post on:
Share this post via WhatsApp Share this post on Facebook Share this post on X Share this post via Telegram Share this post on Pinterest Share this post via email
Previous Post
本地大模型生产化部署：vLLM、Ray、Kubernetes 与显存策略
Next Post
AIOps 智能运维 Agent 部署、评估与小模型测试