企业官网建设流程全解析

选开源推理引擎这事，最近被问到的频率明显比去年高了一截。vLLM、SGLang、Ollama、llama.cpp四个名字，基本就是大模型部署圈子的“四大金刚”，但真正上手以后你会发现，它们离“互相替代”还差得很远，更多是各管一摊、各吃一景。尤其是大家在本地跑DeepSeek、Qwen系列跑起来之后，最纠结的问题从“哪个能跑”变成了“哪个跑得更值”——是省显存，还是拼吞吐，还是图省事？这篇文章不打算堆参数表，把四个引擎的机制差异、部署姿势、以及我自己踩过的坑一次性讲透，帮你少走几段弯路。

内容适配三类读者：刚接触本地大模型、不知道从哪个工具下手的新手；已经在用Ollama但嫌性能不够、想切vLLM或SGLang的进阶用户；以及要给团队做推理服务选型、需要快速判断方案的工程同学。每个引擎我都会拆到“为什么它适合这个场景”的层面，而不是只告诉你命令怎么敲。

1. 先定位：四个引擎到底各自解决什么问题

1.1 vLLM：服务化吞吐的天花板，不是拿来图省事的

vLLM最开始是从UC Berkeley出来的，核心目标就一句话：把GPU显存和算力榨干。它用PagedAttention管理KV Cache，用连续批处理让每一条推理请求都尽量插进正在跑的批次里，所以在高并发、多用户、持续不断的请求流面前，吞吐量能把很多传统方案甩开一个量级。你要是在跑私有化大模型对外开API、或者要给一组业务方提供统一推理服务，vLLM几乎是绕不开的选项。

但它的代价也很直接：学习门槛不低。你要理解scheduler、executor、tensor parallel、prefix caching这些概念，得会配Docker、配显存利用率、处理CUDA版本兼容。很多从Ollama切过来的人第一反应是“怎么这么麻烦”，这不奇怪，vLLM的设计目标就不是给个人玩具准备的，它瞄准的是生产环境。

另外要提醒一句：vLLM对单条请求的首token延迟（TTFT）并不总是最优。它优先保证整体吞吐，在低并发瞬时请求场景下，体感速度反而可能不如本地小工具。所以别一听“吞吐高”就无脑换，得先看你手里是什么流量模型。

1.2 SGLang：从Transformer到结构化生成，一整套答案

SGLang是UC Berkeley、CMU和NVIDIA一起推的项目，作者是LMSYS的核心成员，天然带着浓厚的学术前沿气息。它不止是一个推理引擎，还定义了一套结构化生成语言，核心亮点是RadixAttention——一种基于前缀树的KV Cache复用机制。你去看关于SGLang和vLLM的对比贴，八成都会提到这个。

相比vLLM，SGLang在复杂交互场景的优势更明显：多轮对话、Agent工具调用、带格式约束的JSON输出、few-shot带固定模板的批量请求。这些场景里，请求之间共享大量前缀token，RadixAttention能把公共前缀的计算直接复用到下一条请求，省掉一大票重复计算。如果你做的应用是“大模型当Agent反复调工具”或者“长文档问答”，SGLang的表现经常比vLLM高出一截。

代价是生态还在快速发育，第三方工具链的兼容性不如vLLM成熟，文档没那么多现成坑位可以抄。所以我的建议是：纯跑OpenAI兼容API、请求相对简单，用vLLM；如果你的核心场景是重交互、结构化输出，花时间研究SGLang很值。

1.3 Ollama：本地部署的第一台阶，开箱即用的代价

Ollama本质上是基于llama.cpp做的一套服务化封装，再加一个模型仓库管理功能。它的最大贡献是把“下载模型—格式转换—启动服务—暴露API”全流程做成了几乎零配置的体验。我见过完全不懂CUDA、不懂量化格式的人，装好Ollama以后十分钟把Qwen跑起来，这就是它的价值。

它的取舍也很明确：为了易用性牺牲了对底层的控制力。调度策略、量化粒度、显存分配这些，Ollama都帮你定了默认值，你想精确干预就很难。并发能力也偏弱，扛不住高QPS的在线服务。如果你只是本地研究、写写脚本、跑个小团队内部工具，Ollama足够；但一旦流量起来、要求上生产，它就会成为瓶颈。

热词里有人在问LM Studio和Ollama哪个好。这俩底层都依赖llama.cpp生态，定位极其相似。我的体会是：LM Studio更像一个带图形界面的调试器，适合你反复换模型、对比效果、看日志；Ollama则更适合做服务化，因为它的API简洁，命令行好用，特别是在Docker里一装就能被其他应用对接。日常自用选哪个都不错，要接到LangChain、Dify这种平台里，Ollama明显更省心。

1.4 llama.cpp：硬件兼容的尽头，不止是CPU推理

llama.cpp是伴随第一代Llama火起来的C/C++推理库，今天已经成了全平台推理的代表。GGUF量化格式就是它定义的，目前几乎所有本地推理工具（包括Ollama、LM Studio）都在用这一套格式。它的覆盖范围极夸张：x86、ARM、Apple Silicon、Android、树莓派、NAS，甚至不少开发板的CUDA、Metal、Vulkan后端都能跑。

如果你要把模型塞进移动端、嵌入式设备或者低功耗终端，llama.cpp几乎是唯一靠谱选择。我在Android手机上跑过7B量化的GGUF模型，纯离线状态，速度虽然比不上桌面GPU，但做演示、做隐私离线工具完全够用。反过来讲，你要在数据中心追求极致吞吐，它又不如vLLM那条路线。llama.cpp的定位不是“替代谁”，而是把推理带到所有能放芯片的地方。

2. 机制拆解：高吞吐、高复用背后的工程逻辑

2.1 vLLM的PagedAttention到底解决了什么

要理解vLLM为什么快，得先理解推理时显存最贵的东西——KV Cache。Transformer每生成一个token，都要把之前所有token的Key和Value缓存起来供后续注意力计算使用。问题在于，传统方案给每条请求预分配一整段连续显存，但请求长度长短不一，预分配多的会浪费、少的又放不下，显存碎片率经常高得吓人。

PagedAttention的思路直接抄了操作系统虚拟内存的做法。把KV Cache切成固定大小的块（block），物理上允许离散存放，逻辑上用页表把它们拼成连续的虚拟空间。每条请求按需申请块，序列完了块就回收给下一条用。这个设计把显存浪费率从过去的大几十个百分点压到很低，同样一张20GB的显卡，传统做法可能只能同时撑12条并发，vLLM能轻松翻两三倍以上。这个量级的差距，直接决定了服务能不能上生产。

我在一台A800上对比过同一份7B模型，Ollama默认配置扛不住60路并发，vLLM开连续批处理和prefix caching后，80路并发还能保持平稳输出。这就是为什么只要你的场景是“很多人同时用”，就得往vLLM这条路上走。

2.2 新版vLLM的EngineCore、Scheduler、Executor是怎么协作的

如果你看过旧版vLLM的源码再去看新版本，会觉得它整个骨架都换了。现在的vLLM把进程架构拉得更清晰：EngineCore是常驻的引擎进程，负责请求队列、生命周期管理和内部消息传递；Scheduler负责每一轮迭代的调度决策；Executor真正去执行计算，把指令分发到GPU和注意力后端。

具体交互流程大致是：外部请求先进EngineCore的队列，Scheduler根据策略决定本步要跑哪些序列——默认是先来先服务，也能配优先级。它同时要评估KV Cache够不够分，不够时就得做抢占，把某些序列换出或重算。决定做完以后，Executor拿着指令实际跑kernel，比如卷进Tensor Parallel的多卡场景，Executor还要负责跨卡的AllReduce通信。整个过程是事件循环加消息传递，不是过去那种一层层函数调下去的模式。

这也解释了为什么很多老博客里的自定义代码在新版vLLM里跑不通——你面对的从“一个可以接管的推理类”变成了“一套进程协作系统”。好处是内核更稳定、多卡扩展性更好，坏处是定制改动的学习成本变高了。大家在搜“vllm scheduler逻辑”时，其实想搞明白的就是这一层：谁决定顺序、谁决定抢占、谁干活。

2.3 SGLang的RadixAttention：前缀也是可以复用的资产

RadixAttention把prompt里重复出现的前缀当成一棵树来缓存。举个例子，多轮对话里每一轮只是最后一个问题在变，前面的系统提示、历史记录完全一样。你在vLLM里每轮都要重新算一遍完整前缀，在SGLang里则直接从树里复用上一轮的中间结果，只增量计算新增的部分。

更爽的是批量场景。假设一百条请求共享同一个超长few-shot模板，只有尾部各不相同，RadixAttention会让公共模板只算一遍，各条请求独立跑尾部分支。这种结构化的前缀复用，让你的重复计算成本直接归零。对Agent类的应用来说，系统提示词经常几千个token，一轮里要连续调用好几次工具，省下的就是看得见的延迟和算力。

所以当你纠结“SGLang和vLLM选谁”，本质是在问一个问题：我的场景里是否存在大量共享前缀？如果是长文档问答、多轮复杂对话、批量模板请求，选SGLang；如果是短query、一次性大并发问答，两者差距没有想象中大，反而vLLM的生态更稳。别被基准测试的漂亮数字骗了，得拿自己的真实prompt去压测。

2.4 llama.cpp的量化与CPU/GPU混合调度

llama.cpp这套体系里，GGUF是核心资产。它把FP16权重压缩到INT8、INT4甚至更低比特位，配合不同量化方案（比如常见的Q4_K_M、Q5_K_M），能把7B模型从14GB压到4GB左右，精度损失在小模型上可控。对消费级显卡和无独显的机器来说，这是能跑和不能跑的分界线。

推理时llama.cpp能同时利用CPU和GPU：GPU有算力就把算子丢过去，剩余层数回退到CPU，内存够就一直跑。很多人觉得llama.cpp慢，其实在Apple Silicon上它的Metal后端优化得相当好，我实测M1 Max跑Q4量化的7B模型，生成速度比某些通用容器方案还稳定。嵌入式场景里，用Vulkan后端还能把一部分负载塞给核显或者移动GPU，通用性非常强。

需要留意的是，GGUF量化并不是无损的。层数越多、量化越激进的模型，在复杂推理任务上的表现下降越明显。所以选量化档位别一味求小，建议从Q6、Q5开始试，显存真的不够再降到Q4。

3. 部署实操：四套姿势的落地对比

3.1 vLLM的Docker部署：镜像、模型挂载与显存规划

vLLM部署首选官方Docker镜像。很多人问“vllm docker镜像中带模型吗”，答案是不带，镜像里只有引擎本体，模型权重必须你自己挂进去，别指望拉个镜像就万事大吉。我常用的启动命令长这样：

docker run --gpus all --ipc=host \ -p 8000:8000 \ -v /data/models:/models \ vllm/vllm-openai:latest \ --model /models/qwen2.5-14b-instruct \ --gpu-memory-utilization 0.9 \ --max-model-len 32768 \ --enable-prefix-caching

这里几个参数解释一下：--gpu-memory-utilization控制显存预留比例，设太高会因为KV Cache碎片导致OOM，设太低浪费吞吐，我一般取0.85到0.92；--max-model-len决定了上下文窗口上限，开得越大KV Cache占得越多，别盲目开满；--enable-prefix-caching在多用户共享系统提示词时收益明显，建议直接开。

如果要用vLLM加载qwen3-embedding-0.6b这类向量模型，得在启动参数里指定--task embedding，它会走OpenAI兼容的/v1/embeddings接口，而且这类小模型通常不需要开prefix caching，别照抄对话模型的参数。热词里有问到v0.27.1这个镜像，我的建议是先用latest，因为embedding加载方面新版支持更完整，旧镜像为了稳定可以在生产环境里固定。

DeepSeek系列部署时，尤其是V3、R1这种MoE模型，需要确保vLLM版本不要太旧。MoE的路由和专家并行依赖较新的调度实现，我在0.7.x版本上跑R1出现过显存分配异常，升到0.8.3以后稳定。对接ChatBox这类前端时，Base URL填http://127.0.0.1:8000/v1就行，模型名填启动时设置的模型路径或名称，别填错成文件名。

GLM新模型和Minimax-H3这类新架构，部署前先看官方模型卡，里面通常会写明推荐用哪个vLLM或SGLang的版本。L20这种Ampere架构的卡部署Minimax-H3时，驱动版本和镜像版本要匹配，否则容易出现kernel加载失败。总之在vLLM的世界里，“固定版本跑生产、升级前先看release notes”是必须养成的习惯。

3.2 SGLang部署：与vLLM同构但别搞混端口

SGLang的启动方式和vLLM非常像，本质上都是“挂一个模型路径、开一个兼容API端口”。它默认使用python -m sglang.launch_server，模型路径、张量并行参数、显存比例都能直接指定。不过注意SGLang默认端口是30000，vLLM是8000，很多人两台引擎来回切的时候容易记混，导致应用连不上。

python -m sglang.launch_server \ --model-path /models/qwen2.5-7b-instruct \ --port 30000 \ --mem-fraction-static 0.9 \ --tp-size 1

SGLang对结构化输出的支持是我最喜欢的地方。需要模型严格输出JSON时，可以直接在客户端用结构化生成语法来约束解码，不用自己在prompt里反复强调“不要输出多余内容”。这在做工具调用、表单抽取、代码生成时非常省事。

实际迁移时还要注意：SGLang和vLLM在显存上都要预留KV Cache的空间，你的GPU总容量有限，别在同一张卡上同时跑两个引擎的实例，会出现性能两极分化。多卡场景下SGLang也支持张量并行，但记得--tp-size和物理卡数对上，否则启动时会直接报错。

3.3 Ollama部署：下载慢、离线安装、模型路径迁移与500错误

Ollama的安装本身很无脑，Windows上一个exe、Mac一套安装包、Linux一行curl脚本。但国内用户最痛苦的首先是下载慢。我现在的标准流程是绕过Ollama内置的拉取通道，直接去ModelScope这类国内可访问的模型社区找GGUF文件，下载完以后用ollama create导入。

官方工具链里，导入GGUF的标准做法是写一个Modelfile：

FROM /data/models/qwen2.5-7b-instruct-q4_k_m.gguf

然后执行：

ollama create qwen2.5-7b -f Modelfile

这样出来的模型和ollama pull拉下来的效果一样，但下载速度完全是两个世界。离线环境里这个方案也一样有效，只要你在能联网的机器上把GGUF下好，拷贝到内网机器再导入即可，这也是“ollama离线安装包”这个搜索词背后的典型需求。

模型存放路径，Windows默认在C:\Users\你的用户名\.ollama\models，想装到D盘，就把用户环境变量OLLAMA_MODELS设为D:\ollama\models，然后重启Ollama，再把旧目录的模型文件搬过去。查看已下载模型用ollama list，查看某个模型的参数格式用ollama show 模型名。

很多人遇到的500 internal server error: llama-server process，绝大多数情况下逃不出三个原因：模型文件损坏、显存不足或显卡太旧。排查顺序先看日志——Windows托盘图标右键有“View Logs”入口，Linux直接看ollama serve的输出。日志里如果出现CUDA out of memory，就先设OLLAMA_NUM_GPU=0强制CPU跑，能跑通就说明是显存预算问题，可以换更小量化档位的模型或者减少模型容器数量。如果日志里出现“too old”之类的字样，那就是显卡太老，CUDA capability不够，基本没救，换卡或者纯CPU。

顺便说个Ollama在消费级GPU上跑Qwen3系列的小技巧：Qwen3默认会进入思考模式，输出一堆推理过程，既占显存又拖慢速度。初始化时传"think": false参数可以关闭思考，或者用/no_think指令。这个开关对交互体验影响非常直接，实测关掉以后首token延迟能明显下降。

3.4 llama.cpp：Android部署与跨平台编译

llama.cpp的部署形态最灵活。你可以在GitHub Releases里直接找官方编译好的Windows包，也可以自己从源码编译，关键在后端开关。想要CUDA加速就加-DLLAMA_CUDA=ON，想支持AMD就开HIP或者Vulkan：

cmake -B build -DLLAMA_CUDA=ON cmake --build build --config Release

编译完以后直接用llama-server启动API服务，它的/chat/completions接口也是OpenAI兼容的，这意味着你能用任何标准OpenAI客户端对接llama.cpp。命令行里-ngl 99代表把尽可能多的层放到GPU，--port指定端口，其他记不住就直接不加参数，默认值也能跑。

Android版本我强烈建议试一下。GitHub releases里有一个llama.cpp-android的APK，装好以后把GGUF模型放到手机存储，选好模型文件就能在手机上对话。我在骁龙8 Gen 2上跑7B Q4量化，速度大概10到20 token每秒，用来给朋友演示本地离线大模型效果非常唬人，而且完全断网也能跑，隐私演示场景尤其合适。

手机端跑大模型的关键还是选对量化档位。7B模型Q4档大概不到4GB，16GB内存手机没压力；3B模型则几乎可以随便跑。如果手机是8GB内存，建议选Q4_K_M档次以下，同时关闭系统里的高内存占用应用，不然加载阶段容易直接被杀进程。

4. 选型决策：直接抄作业的场景对照

4.1 一张表解决80%的选型问题

我见过太多人在这四个引擎之间反复横跳，最后发现最耽误时间的是纠结本身。这里给一张我自己的速查表，覆盖大部分常见场景：

这张表不是绝对标准，但它能帮你把问题收敛到“我到底需要什么”而不是“哪个框架听起来更厉害”。真要决定，我的建议是用自己真实的prompt和真实流量镜像做压测，别拿官方的benchmark数据当决策依据。

4.2 知识库与Agent工具链：Ollama不孤单

热词里有一大串和Ollama搭配的实践，比如AnythingLLM、Dify、Goose、LangChain、Chroma。这其实是本地大模型应用最常见的一条技术栈：Ollama当推理后端，LangChain做流程编排，Chroma存向量，AnythingLLM或Dify做交互界面。

这里最关键的一个坑是embedding模型。知识库的文档切分后要转成向量，这个embedding过程必须也在本地完成，否则文档内容会被传到第三方服务，数据安全直接破防。Ollama支持跑专用embedding模型，比如qwen3-embedding-0.6b、bge-m3系列，向量模型体量小、CPU都能跑，建议单独用一个模型实例，别和对话模型混着加载。

Goose这种MCP客户端可以配置成连接Ollama，等于把你的本地大模型接进MCP生态，AI助手可以调用本地模型完成推理同时无缝调用各类工具。Dify也可以直接配置Ollama作为OpenAI兼容的provider，界面选模型时填Ollama服务地址就行。这套链路的好处是每一层都是开箱即用的，从文档上传到对话回答，半小时就能搭出一个能演示的本地知识库。

要注意的是，AnythingLLM和Dify这类应用对Ollama连接速度的体感，很大程度上取决于Ollama所在机器的算力。知识库场景下上下文会变长，建议给对话模型专门分配较大显存，或者直接切到vLLM/SGLang这类能高效复用前缀的引擎，否则回答大文档问题时速度会很难看。

5. 性能调优与常见问题排查实录

5.1 vLLM新版本性能下降是怎么回事

“vLLM新版本性能下降”这个话题在社区里经常出现，根源往往是默认策略变了。比如某些版本调整了调度器策略，从单纯FCFS变成了考虑KV Cache复用，小并发场景下反而增加了额外开销；又比如CUDA graph的捕获方式变了，冷启动时短暂变慢就被放大成“性能回退”。

我的建议是三条：第一，生产环境固定版本，不要追最新；第二，升级前先读release notes，重点看scheduler、prefix caching、CUDA graph相关变更；第三，升级后用vllm bench跑同一批测试请求做前后对比。实测中，把--max-num-seqs调低一些，往往能解决新版在低并发下TTFT变长的体感问题。

还有一个容易被忽略的点：vLLM版本和模型架构的适配窗口是错开的。新模型发布几个月内，旧版本vLLM经常跑不动或者FP混乱，这是正常的。像GLM这种新架构，官方文档标注“需要vLLM X.X以上版本”就照着升，不要问“哪个版本最稳”——先看模型官方的Known Issues比什么都靠谱。

5.2 Ollama系列问题速查表

排查这类问题，最忌讳的是不看日志瞎改配置。Ollama的日志其实非常直白，GPU检测、模型加载、内存分配失败都会写出来。你把它当第一现场，比在社区里盲搜问题快得多。

5.3 量化、显存与并发参数的估算经验

推理显存估算没有玄学，核心公式是：模型权重占用量等于参数量乘以每参数位数再除以8。以7B模型为例，FP16权重约14GB，Int4量化约3.5到4GB。加上KV Cache、CUDA context、激活值，一张24GB显卡跑7B Q4模型，开32K上下文通常能剩一半空间给并发请求。

如果你想跑14B甚至70B模型，量化就是唯一出路。建议从Q5_K_M起步，能接受就继续，不行再往下掉。Q4_K_M对大部分生成任务来说体感损失不大，但涉及代码、数学、长推理链时，质量下降会比想象中明显。拿真实任务各跑十遍再决定，比看量化对比图有意义。

并发参数方面，vLLM的--max-num-seqs决定单次迭代最多处理的序列数，太大了会频繁抢占，太小则喂不满GPU。我的经验是先从32开始，压测时观察GPU利用率，低于80%就往上加，出现OOM或大量重算就往下调。SGLang的--mem-fraction-static则是控制KV Cache预留比例的，设到0.85左右通常能让吞吐和稳定性平衡。

5.4 一套模型多引擎共用：格式兼容的真相

最后说个很多人踩过的大坑：Ollama下载的模型和llama.cpp能直接共用，因为都是GGUF格式；但vLLM、SGLang不认GGUF，它们加载的是HuggingFace格式的权重目录（safetensors加config）。所以你在Ollama里跑得好好的模型，想迁到vLLM上，不是换个启动命令就行，得重新去模型仓库拿原版HF权重。

反过来也一样，很多人在vLLM部署DeepSeek成功后问能不能直接用Ollama加载，答案是可以去搜DeepSeek的GGUF版本，但那是同一个模型的不同格式包，引擎之间并没有神奇的“无缝转换”。理解了这一层，你就能明白为什么社区里会有人反复问“gguf模型下载后如何导入ollama”这类问题——本质是格式转换和目录管理的事。

我目前的工作习惯是：本地折腾、快速验证一律Ollama；要对外开服务、并发或吞吐要求上来以后迁到vLLM；Agent和复杂结构化交互重点研究SGLang；手机或边缘设备演示则固定用llama.cpp。四个引擎各有站位，谈不上谁完全替代谁。

如果只让我留一条经验：遇到任何推理异常，第一件事看日志，第二件事固定版本。大模型推理框架迭代太快，默认配置每个版本都可能变，不要默认“最新版最好用”，也不要靠猜来解决报错。日志和版本锁定这两件事做好，你在部署上省下的时间比任何调优技巧都多。