一、 硬件就位，模型如何高效“跑起来”？
上一篇我们详细讨论了 LLM 私有化部署的硬件选型，搞定了算力基础。但光有硬件还不够，我们需要一个“引擎”——也就是 LLM 服务框架——来负责加载模型、管理资源、接收用户请求，并高效地把模型的计算能力转化成实际的服务。
市面上这类框架有不少，选择哪个直接关系到你的 LLM 应用的性能、成本和部署维护的复杂度。本篇将重点对比几个我们实践中接触较多或社区热门的框架：Ollama、Xinference 和 VLLM，分析它们的特点、适用场景以及运维中需要注意的地方，帮助你根据自己的实际情况做出判断。
注意： 不存在哪个框架“最好”，只有哪个“最适合”你当前的具体需求（性能要求？易用性要求？模型种类要求？）和实际限制（硬件资源？运维能力？）。我们在项目中最终选择了 VLLM 用于 RAGFlow 问答系统（追求高吞吐和长上下文处理能力），并选择了 Ollama 用于代码审查（考虑到部署便捷性以及特定模型的支持），这正是基于具体场景权衡的结果。
二、 Ollama：快速上手，本地开发的友好伙伴
如果你刚开始接触本地 LLM，或者需要在开发环境快速验证想法，Ollama 是一个非常不错的起点。
最大优点：简单易用。
安装和启动非常方便，通常一条命令搞定 (curl ... | sh）。
命令行交互友好：ollama pull <模型名> 下载模型，ollama run <模型名> 直接启动并交互。
自带模型库管理，不需要你手动下载和组织模型文件（虽然底层也需要存储空间）。
提供了 OpenAI 兼容的 API 接口 (/v1/chat/completions)，方便与其他应用（如 LlamaIndex, LangChain）集成。
量化模型支持： 最初以支持 GGUF 等预量化模型格式为主，现在也在扩展支持。加载量化模型可以显著降低对硬件（尤其是显存）的要求。
性能和并发： 相较于后面要介绍的框架，Ollama 在高并发、高吞吐量场景下的性能优化通常不是其强项。它的多 GPU 利用可能相对简单（例如，倾向于填满一个再用下一个）。
在 Ubuntu 上部署和运行 Ollama (示例)：
安装 Ollama: 打开终端，执行官方安装脚本：
curl -fsSL <https://ollama.com/install.sh> | sh
这个脚本会自动下载并安装 Ollama 服务。
验证安装与服务状态:
ollama --version # 查看版本systemctl status ollama # 检查服务是否正在运行# 如果未运行，使用 sudo systemctl start ollama 启动
拉取模型: 选择一个你想运行的模型，例如 mistral 或 qwen:7b：
ollama pull mistral
Ollama 会自动从它的模型库下载模型文件。你可以在 ollama list 命令中看到可用的模型。
运行模型并交互:
ollama run mistral
这会加载 mistral 模型，然后你就可以在终端里直接和它对话了。输入你的问题，按回车发送。输入 /bye 退出交互。
启动 API 服务: Ollama 服务默认会在本地 11434 端口监听 API 请求。你通常不需要额外启动 API 服务，安装完成后它就在后台运行了。你可以通过其他程序（如 Python 脚本、Curl）向 http://localhost:11434/api/... 发送请求。
适用场景：
本地开发、模型试用、快速原型验证。
个人使用或低并发量的内部应用。
对部署便捷性要求远高于极致性能的场景（例如我们选择用它支持 Code Review，可能正是看中了这一点）。
核心优势 1：更优的多 GPU 资源利用 (理论上)。
Ollama 在利用多 GPU 时可能相对简单，有时更像是“接力式”使用（填满一个再用下一个）。
Xinference 的设计明确支持分布式部署，允许将模型的不同部分或副本分布在多个 GPU 或多个机器上。这意味着理论上它能更智能地调度任务，让多块 GPU 协同工作，从而更充分地利用整体算力资源，这对于运行那些单卡显存装不下的大模型至关重要。
核心优势 2：启动时动态量化——在有限显存上运行更大模型成为可能。
Ollama 主要依赖加载预先量化好的模型文件（如 GGUF）。如果某个模型的某个量化版本（如 4-bit）所需的显存依然超过你的硬件限制，Ollama 就无能为力了。
Xinference 则提供了一个“杀手锏”：启动时动态量化。你可以先下载模型的原始高精度版本（例如 FP16，可能需要 60GB 显存）。然后，在通过 Xinference 启动这个模型服务时，你可以指定使用较低的精度加载（例如 quantization: '4bit' 或 '8bit'）。Xinference 会在加载过程中（利用 bitsandbytes 等库）动态地将模型量化到你指定的精度。
这意味着什么？ 即使你的 GPU 只有 40GB 显存，装不下原始的 60GB FP16 模型，但你仍然有可能通过 Xinference 的动态 4-bit 量化功能，将这个原本跑不起来的 60GB 模型成功加载并运行起来（因为 4-bit 量化后实际占用的显存会远小于 60GB）。这极大地扩展了在显存受限硬件上选用更大、能力更强模型的可能性。
其他特点：
支持多种模型： 不仅支持 LLM，还能部署 Embedding 模型、Reranker 模型，甚至多模态模型。这对于构建复杂的 RAG 系统很有帮助。
Web UI 管理： 提供图形化界面来管理部署的模型、查看状态等。
提供 RESTful API 和客户端 SDK。
性能和并发： 其架构设计考虑了并发处理，通常优于 Ollama，但对于 LLM 推理的极致吞吐量优化可能不如 VLLM。
复杂度： 比 Ollama 复杂。你需要自己准备模型文件，配置也相对更多。
在 Ubuntu 上通过 Docker 部署和运行 Xinference (示例)：
前提： 确保你的 Ubuntu 上已经安装了 Docker，并且当前用户有权限运行 Docker 命令（或者使用 sudo）。
创建数据和模型挂载目录 (推荐):
mkdir -p ~/.xinference # 存储 Xinference 配置和数据库mkdir -p /path/to/your/llm_models # 你存放 LLM 模型文件的目录
将 /path/to/your/llm_models 替换成你实际的模型存储路径。
运行 Xinference Docker 容器: (这里使用了官方推荐的镜像，注意替换模型挂载路径)
docker run -d --gpus all \ -p 9997:9997 \ -v ~/.xinference:/root/.xinference \ -v /path/to/your/llm_models:/models \ --name xinference-service \ xprobe/xinference:latest \ xinference-local -H 0.0.0.0
d: 后台运行。
-gpus all: 允许容器使用所有可用的 GPU。如果你想指定 GPU，可以使用 -gpus '"device=0,1"'。
p 9997:9997: 将容器的 9997 端口映射到宿主机的 9997 端口（Xinference 默认 API 和 Web UI 端口）。
v ~/.xinference:/root/.xinference: 挂载配置目录，持久化数据。
v /path/to/your/llm_models:/models: 关键！ 将你存放模型文件的宿主机目录挂载到容器内的 /models 路径。
-name xinference-service: 给容器命名，方便管理。
xprobe/xinference:latest: Xinference 的官方 Docker 镜像。
xinference-local -H 0.0.0.0: 启动 Xinference 服务并监听所有网络接口。
访问 Web UI: 在浏览器中打开 http://<你的服务器IP>:9997。你应该能看到 Xinference 的管理界面。
通过 Web UI 或 API 启动模型:
Web UI: 在 "Launch Model" -> "Language Models (LLM)" 中，选择模型类型（如 auto 或具体格式），在 "Model Path" 中输入容器内的模型路径（例如 /models/Qwen1.5-7B-Chat），选择量化方式（如 none, 4-bit），配置其他参数（如副本数），然后启动。
API/Client: 你也可以通过 Xinference 的 Python 客户端或 REST API 来启动模型。
检查状态: 在 Web UI 查看模型状态，或使用 docker logs xinference-service 查看容器日志。
适用场景：
需要统一部署多种 AI 模型（LLM, Embedding 等）的环境。
显存有限，希望通过动态量化运行更大模型的场景。
需要较好并发处理能力，且看重部署灵活性的企业级应用。
核心优势：性能优化。
PagedAttention 技术： 这是 VLLM 的“杀手锏”。它极大优化了 KV Cache 的显存管理方式，相比传统方法能在同等显存下支持更长的上下文、更高的并发量，并显著提升 GPU 利用率和吞吐量。这对于需要处理长文本或高并发的 RAG 问答系统（我们选择用它支撑 RAGFlow）至关重要。
连续批处理 (Continuous Batching)： 不同于静态批处理，它可以动态地将请求组合起来处理，进一步提高 GPU 效率。
针对热门模型进行 Kernel 优化。
同样提供 OpenAI 兼容的 API 接口。
量化支持： 支持加载常见的预量化模型格式（如 AWQ, GPTQ 等）。
性能和并发： 在支持的模型上，通常能达到非常领先的吞吐量和较低的延迟。
复杂度： 部署和调优相对复杂。
通常通过 Docker 部署。
需要仔细调整启动参数以获得最佳性能，例如：-tensor-parallel-size (张量并行度，用于多 GPU)、-gpu-memory-utilization (GPU 显存使用率，需要留余量)、-max-model-len (最大模型长度)、-max-num-seqs (最大并发请求数) 等。
对模型的兼容性有一定要求（虽然支持越来越广，但不是所有模型都能即插即用获得最佳性能）。
在 Ubuntu 上通过 Docker 部署和运行 VLLM (示例)：
前提： 确保 Docker、NVIDIA 驱动、CUDA 环境都已正确安装，并且安装了 nvidia-docker2 (或确保 Docker 配置支持 -gpus 参数)。
准备模型文件: 将你需要部署的模型文件（可能包含多个文件和子目录）放在宿主机的一个目录下，例如 /path/to/your/vllm_models/Qwen1.5-14B-Chat。
运行 VLLM Docker 容器: (这是一个参考命令，你需要根据你的模型、硬件和需求调整参数）
# 基础示例命令，需要替换 <占位符> 并添加更多参数docker run -d --gpus all --restart unless-stopped \--name my_vllm_server \-p 8000:8000 \-v /path/to/your/vllm_models/<your_model_folder>:/model \ vllm/vllm-openai:latest \--model /model \--trust-remote-code \--served-model-name <your_model_service_name> \--dtype auto \--tensor-parallel-size 1 # 如果是单 GPU # --tensor-parallel-size 2 # 如果是双 GPU # --max-model-len 8192 # 根据模型和需求设置 # --gpu-memory-utilization 0.9 # 调整 GPU 显存使用率 # --max-num-seqs 256 # 调整最大并发请求数 # --quantization <awq|gptq> # 如果加载量化模型
关键参数解释 (参考)： -gpus all: 使用所有 GPU。
-restart unless-stopped: 容器异常退出时自动重启。
-name vllm_qwen3014: 容器名称。
-ipc=host: 使用宿主机的 IPC 命名空间，有时对多 GPU 通信有帮助。
p 8018:8000: 将容器的 8000 端口（VLLM 默认 API 端口）映射到宿主机的 8018 端口。
v /home/dell/models/Qwen/Qwen3-14B:/model: 挂载模型目录。
vllm/vllm-openai:latest: VLLM 官方提供的兼容 OpenAI API 的镜像。
-model /model: 指定容器内模型的路径。
-trust-remote-code: 如果模型代码托管在 Hugging Face Hub 上需要。
-served-model-name Qwen3-14B: 指定服务暴露的模型名称。
-dtype half: 使用半精度 (float16)，通常比 auto 更明确，比 bfloat16 兼容性稍好)。
-tensor-parallel-size 2: 使用 2 个 GPU 进行张量并行。
-max-model-len 16384: 最大支持的模型上下文长度。
-gpu-memory-utilization 0.7: GPU 显存使用率限制为 70%，留出余量。
-max-num-seqs 16: 最大并发序列数。
检查容器状态和日志:
docker ps # 查看容器是否运行docker logs my_vllm_server # 或者你的容器名，如 vllm_qwen3014# 持续监控日志： docker logs -f my_vllm_server
观察日志确保模型加载成功，没有 OOM (Out Of Memory) 错误，并且 API 服务在 8000 端口启动。
测试 API: VLLM 启动后，会在容器的 8000 端口（映射到宿主机的指定端口，如 8018）提供 OpenAI 兼容的 API 服务。你可以使用 Curl 或 Python 的 requests 库来测试 /v1/chat/completions 或 /v1/completions 端点。
适用场景：
对 LLM 推理吞吐量、延迟有极高要求的生产环境。
高并发的 API 服务、实时问答系统。
需要充分压榨 GPU 性能以降低单位请求成本的场景。
确定优先需求：首先明确您最关键的需求是什么 - 易用性、性能还是灵活性？
评估资源现状：
如果您的团队技术资源有限，优先考虑 Ollama
如果显存资源受限但需要运行较大模型，优先考虑 Xinference
如果追求极致性能且有运维能力，选择 VLLM
考虑应用场景：
内部开发测试环境 → Ollama
多种模型统一管理平台 → Xinference
生产环境高并发服务 → VLLM
资源监控是常态： 密切关注 GPU 显存使用率（尤其小心 OOM）、显存带宽、GPU 利用率、CPU 和内存负载。不同框架对资源的消耗模式不同。
日志是排错关键： 学会看懂框架的运行日志，是快速定位问题的基础。关注错误信息（Error）、警告信息（Warning）。
模型管理（对 Xinference/VLLM）： 如何安全存放、版本控制、加载更新模型文件。
依赖与兼容： 确保框架版本、Python 库、CUDA 版本、NVIDIA 驱动之间相互兼容。升级任何一个组件都可能带来兼容性风险。
性能调优（尤其 VLLM）： 根据实际负载情况，可能需要反复调整框架的启动参数，以达到最佳的性能和资源利用平衡。
首先评估团队技术能力和时间限制
技术团队精简且项目周期紧张？→ Ollama (快速部署、简单运维)
有专门的 MLOps 或 AI 基础设施团队？→ 可以考虑 VLLM (性能最优但需调优)
然后考虑硬件资源限制
只有有限显存但需运行较大模型？→ Xinference (动态量化优势明显)
有充足高端GPU资源？→ VLLM (能最大化利用硬件性能)
最后结合应用场景
内部开发测试、概念验证？→ Ollama
需要同时运行多种类型模型(LLM、Embedding等)？→ Xinference
面向用户的生产环境、高并发API服务？→ VLLM
三、 Xinference：功能全面，灵活的企业级选择——尤其擅长“榨干”显存潜力
如果你的需求超出了简单的本地运行，需要更强的灵活性、支持更多类型的模型或更精细的控制，Xinference 值得关注。
四、 VLLM：性能标杆，高吞吐推理的利器
如果你追求的是极致的 LLM 推理性能（高 TPS、低延迟、高并发），尤其是在提供 API 服务或实时问答系统时，VLLM 是目前业界的标杆之一。
五、 如何选择？—— 需求驱动，权衡利弊
再次强调，没有绝对的优劣。回顾我自己的选择：用 VLLM 支持 RAGFlow 问答，主要是因为它需要处理大量用户的并发请求，且 RAG 需要较好的长上下文处理能力和低延迟响应，VLLM 的 PagedAttention 在这方面优势明显。而之所以选用 Ollama 支持 Code Review，则是因为 Code Review 场景并发量不高，且 Ollama 上下载的量化模型在同量级下刚好该模型比魔搭社区下载的量化模型要好，且显存占用不算太高，故而进行选择。
帮你梳理一下决策的关键点：
| 易用性 | |||
| 性能/吞吐量 | |||
| 并发处理 | |||
| 模型支持广度 | |||
| 动态量化 | |||
| 多 GPU/分布式 | |||
| 部署复杂度 | |||
| 社区/生态 | |||
| 最佳场景 |
基于以上对比，我们建议按照以下简化决策流程选择适合的框架：
实际上，很多企业会采用混合策略：在开发环境使用 Ollama 快速验证，在测试环境用 Xinference 探索不同模型，在生产环境部署 VLLM 提供稳定高效服务。这种渐进式采用策略能够平衡学习成本和部署效率。
六、 运维不轻松：选择框架后需要关注什么？
选定并部署好框架只是第一步，长期的稳定运行还需要关注运维：
总结
选择 LLM 服务框架是一个需要结合自身场景、需求、资源和运维能力进行综合权衡的过程。Ollama 胜在易用，Xinference 强在灵活和动态量化，VLLM 则专注于极致的推理性能。理解它们的差异，才能为你后续的应用打下坚实的基础。
实际选型决策路径
根据我们的实践经验，以下是一个简化但实用的框架选型决策流程：
实际上，很多成熟的企业 LLM 实践会在不同阶段采用不同框架，形成互补优势。例如，我们的做法是在开发探索阶段使用 Ollama，在正式 RAG 系统中部署 VLLM，在特定场景如代码审查中仍保留 Ollama 的灵活性。技术选型没有绝对的对错，关键在于找到最适合自身需求与约束的平衡点。
