前言：为什么需要专门的推理引擎？

随着大语言模型（LLM）的快速发展，越来越多开发者希望在自己的机器上本地运行这些模型。你可能已经尝试过用几行Python脚本（比如HuggingFace Transformers）就能让Llama 3或Qwen跑起来，并产生一些有趣的回答。既然如此，为什么市面上还会出现像Ollama、vLLM、TGI等一大批专门的“推理引擎”呢？

本文将从“是什么、为什么、怎么选”三个层面，系统梳理大模型推理引擎的核心价值、主流工具对比以及选型建议。无论你是刚入门的AI爱好者，还是负责生产环境部署的工程师，都能从中找到有用的信息。

---

第一部分：推理引擎的本质

1.1 一个简单的Python脚本就能运行模型，为什么还需要引擎？

一个基础的PyTorch + HuggingFace推理脚本非常简单：

from transformers import AutoModelForCausalLM, AutoTokenizer

model = AutoModelForCausalLM.from_pretrained("llama3-8b").cuda()
tokenizer = AutoTokenizer.from_pretrained("llama3-8b")

def generate(prompt):
    inputs = tokenizer(prompt, return_tensors="pt").to("cuda")
    outputs = model.generate(**inputs)
    return tokenizer.decode(outputs[0])

这段代码确实能让模型“运行起来”，但它就像手工打造的一把椅子——能用，却远远无法满足生产环境的需求。当面对真实场景时，脚本会暴露大量问题：

维度	Python脚本	专业推理引擎
单次请求性能	可以工作	更快（算子融合、CUDA优化）
连续多轮对话	每次重新计算全部历史	KV Cache增量计算
并发请求处理	串行执行	Continuous Batching动态调度
内存管理	碎片化严重	PagedAttention按页分配
长文本处理	易OOM	滑动窗口、Streaming
服务化	需要手写API、监控	内置HTTP服务、OpenAI兼容接口
模型量化	可用bitsandbytes但无推理优化	内置GPTQ/AWQ/FP8等专用优化
资源调度	单模型占满显存	多模型复用、按需加载

1.2 推理引擎的核心技术作用

1.2.1 高效的内存与显存管理

原始PyTorch在自回归生成时，每个请求的中间状态（KV Cache）长度会动态变化，导致显存中产生大量碎片。推理引擎（如vLLM的PagedAttention）像操作系统管理内存页一样管理KV Cache，将显存利用率从50%提升到90%以上。

1.2.2 动态批处理

传统静态批处理需要凑齐一批请求才能开始，会引入排队延迟。Continuous Batching（也称In-flight Batching）在每个生成步骤后都检查是否可以插入新请求或结束已完成请求，使GPU始终保持满载。vLLM、TGI、TensorRT-LLM均支持此技术。

1.2.3 计算图优化与算子融合

简单脚本中的model.generate()内部包含成百上千个小算子（kernel），每个小算子都会引发GPU启动开销和数据搬运。推理引擎会将多个连续操作（如LayerNorm + 激活函数 + 矩阵乘）融合成一个大的算子，大幅减少GPU内核启动次数和中间内存读写。

1.2.4 服务化与可扩展性

生产环境需要处理成千上万个并发请求，需要请求队列、超时控制、流式输出（Server-Sent Events）、多卡/多机分布式推理。推理引擎内置这些能力，而手写脚本则需要用FastAPI + asyncio + NCCL去实现，工程量和出错概率都极大增加。

---

第二部分：主流推理引擎全景对比

2.1 引擎概览表

推理引擎	定位	性能特点	易用性	核心技术	适用场景
Ollama	轻量级本地部署工具	低并发尚可，高并发明显不足	极高，一条命令运行	基于llama.cpp，内置量化	个人学习、本地测试、边缘设备
vLLM	高性能推理框架	高吞吐、低延迟，高并发优势明显	较高，需Python环境	PagedAttention、Continuous Batching	企业生产、高并发API服务
llama.cpp	C++底层框架	CPU/混合推理出色，单请求延迟低	入门门槛高	纯C++实现，多量化支持	资源受限设备、纯CPU环境
SGLang	复杂逻辑编排	长文本场景极佳，吞吐与vLLM相当	中等	RadixAttention、前端DSL	复杂控制流、多轮对话
TGI	HuggingFace官方	性能均衡稳定	中等，依赖Docker	HF生态原生支持	快速部署标准HF模型
TensorRT-LLM	NVIDIA极致优化	NVIDIA GPU峰值性能无敌	困难	算子融合、In-flight Batching	追求N卡极致性能
LM Studio	图形化工具箱	依赖底层引擎	极高，图形界面	内置llama.cpp/MLX	非技术用户、Mac用户
MLX	Apple专属框架	Apple Silicon性能卓越	中等	统一内存架构设计	Mac开发与部署
DeepSpeed	超大规模模型	吞吐超vLLM 2.2倍	中等	ZeRO推理、FastGen	超大模型、多GPU集群
CTranslate2	CPU高效库	CPU推理性能优越	一般	权重量化、层融合	CPU环境、资源受限
OpenLLM	云原生调度层	取决于后端引擎	高	集成vLLM等多引擎	模型服务管理、A/B测试
Ray Serve	分布式服务框架	取决于后端引擎	较高	路由、扩缩容、监控	大规模分布式部署

2.2 选型速查表

你的首要追求	首选推荐	备选方案
极致性能（吞吐/延迟）	vLLM, SGLang	TensorRT-LLM, DeepSpeed
部署简便性	Ollama, LM Studio	TGI, OpenLLM
NVIDIA GPU最佳	TensorRT-LLM	vLLM, SGLang
Apple Silicon	MLX, LM Studio	Ollama（新版集成MLX）
CPU/边缘设备	llama.cpp	CTranslate2
HuggingFace生态集成	TGI	vLLM, SGLang
超大规模模型（多机多卡）	DeepSpeed	TensorRT-LLM, Ray Serve+vLLM
复杂生成逻辑（如Agent）	SGLang	LangChain+vLLM

---

第三部分：案例深入——Ollama vs vLLM

3.1 设计哲学对比

Ollama：轻便的跑车，追求启动快、上手简单
vLLM：高速列车，追求高吞吐、低延迟、大规模

3.2 Ollama的并发能力

Ollama从v0.2.0版本开始支持真正的并发，通过环境变量控制：

export OLLAMA_NUM_PARALLEL=4      # 最大并行请求数
export OLLAMA_MAX_LOADED_MODELS=2  # 最多同时加载的模型数
export OLLAMA_MAX_QUEUE=512        # 请求队列长度

3.3 性能实测数据

以下数据基于Llama 3 70B INT4 / Llama 3.1 8B模型测试：

吞吐量对比（tok/s）：

并发数	Ollama	vLLM	vLLM优势
1	42	48	1.14x
10	195	420	2.15x
50	380	1650	4.34x
100	410	2800	6.83x

延迟对比（中位数，秒）：

并发数	Ollama	vLLM
1	6.1s	5.3s
10	13.1s	6.1s
50	33.7s	7.8s
100	62.4s	9.1s

在50人并发时，Ollama用户的平均等待时间已超过半分钟——对于实时交互应用，超过10秒的延迟通常不可接受。

3.4 使用建议

适合Ollama并发的场景：

• 少于10人同时使用的内部工具
• 开发和测试环境
• 个人或小团队的知识库

不适合Ollama并发的场景：

• 面向公众的高并发服务
• 对响应速度有严格要求的实时系统

---

第四部分：选型的底层逻辑

4.1 理解生态位

• 底层引擎：如llama.cpp、MLX，提供基础优化能力
• 上层框架：如vLLM、TGI，封装为服务化接口
• 调度平台：如OpenLLM、Ray Serve，管理多个模型和实例

你的选择决定了是在哪个层次进行优化。

4.2 硬件依赖性

• NVIDIA GPU：TensorRT-LLM（极致）、vLLM（平衡）、TGI（稳健）
• Apple Silicon：MLX（原生）、Ollama（新版集成MLX）
• CPU/边缘设备：llama.cpp、CTranslate2

4.3 核心技术关键词

• vLLM → PagedAttention
• SGLang → RadixAttention（前缀缓存）
• DeepSpeed → ZeRO、FastGen
• TensorRT-LLM → 算子融合、In-flight Batching

理解这些技术，就知道哪个引擎更适合你的“长文本”、“多轮对话”或“超大模型”场景。

---

结语：什么时候该用什么？

你的状态	推荐选择
刚开始学习，想在个人电脑上跑模型	Ollama 或 LM Studio
正在开发聊天机器人原型	FastChat 或 OpenLLM
需要部署高并发API服务（企业级）	vLLM
追求NVIDIA硬件极限性能	TensorRT-LLM
只有CPU，或设备资源受限	llama.cpp 或 CTranslate2
使用Mac，想榨干M芯片性能	MLX
需要处理超大模型（>70B）多卡推理	DeepSpeed
想无缝使用HuggingFace生态	TGI

没有完美的引擎，只有最合适的引擎。 希望这份梳理能帮助你在AI应用落地的道路上少走弯路。当你的场景从“能跑起来”进化到“要跑得又快又稳”时，不妨给这些推理引擎一个机会——它们会证明自己的价值。