大语言模型部署实战：从 Ollama、vLLM 到 SGLang，本地服务到底怎么搭？

大语言模型部署实战从 Ollama、vLLM 到 SGLang本地服务到底怎么搭前面这条主线已经把几个关键问题往前推进了一步Transformer 为什么会成为大模型基础架构预训练到底在学什么SFT、RLHF、DPO 这类对齐训练怎么串起来长上下文能力是怎么做出来的temperature、top-k、top-p、repeat penalty 这类生成参数怎么调LoRA、QLoRA、全参微调分别适合什么任务FP16、INT8、4bit 量化到底该怎么选接下来就进入很多团队真正开始落地时绕不开的一步模型有了、权重有了、量化格式也选了本地服务到底该怎么搭很多人第一次做部署时会把“部署”理解成一条命令把模型跑起来。但工程里真正的问题远不止这个开发机本地验证应该优先用 Ollama 还是 llama.cpp做 OpenAI 兼容接口时vLLM 为什么几乎成了默认选项SGLang 适合什么场景它和 vLLM 的分工到底有什么不同max_model_len、tensor_parallel_size、gpu_memory_utilization、max_num_seqs这些参数到底在影响什么为什么同一块卡有时单请求很快但一上并发就开始抖为什么有些模型能离线聊天却不适合拿来做稳定 API 服务这篇文章我想把“本地部署”这件事拆开讲清楚。不是只告诉你某个框架怎么安装而是回答三个更关键的问题你的目标是什么本地体验、研发验证还是服务化供多人调用不同框架分别擅长什么Ollama、vLLM、SGLang、llama.cpp 该怎么选真正影响稳定性和吞吐的参数在哪里该怎么配如果你正准备把 7B、14B、32B 级别模型放到个人开发机单机单卡服务器单机多卡服务节点内网 OpenAI 兼容 API这篇会比“照着 README 跑一遍”更有用。一、先说结论本地部署不是“跑起来”就结束而是要先明确你在解决哪类问题“本地部署”这个词很宽很多讨论混在一起最后就会得出错误结论。比如有人说Ollama 很方便所以应该优先用 OllamavLLM 很快所以部署都该上 vLLM4bit 更省显存所以所有场景都应该量化到 4bit这些说法都只对一半。更准确的判断方式应该是1如果目标是个人本地体验先考虑“能否快速跑通”典型需求本地问答Prompt 调试小范围功能验证让产品、运营、研究同学先感受效果这类场景通常优先考虑Ollamallama.cpp / GGUF 路线少量并发甚至默认单用户核心指标不是极致吞吐而是安装快不快模型拉取和切换是否简单机器配置要求是否友好是否容易暴露一个可调用接口2如果目标是研发验证或内网 API先考虑“服务模型是否稳定”典型需求给应用层统一提供 OpenAI 兼容接口做 A/B 测试和模型对比小团队内部多用户并发调用跑 batch 推理或评测这时候就不能只看“能启动”而要看连续请求是否稳定batch 调度是否高效KV Cache 管理是否合理长上下文下吞吐是否还能接受多卡切分和资源利用率是否好用这类场景里vLLM 往往是优先项。3如果目标是高吞吐、复杂推理编排先考虑“调度能力和执行模型”典型需求高并发在线推理Agent / structured output / tool use 编排speculative decoding、前缀复用、复杂采样控制面向任务工作流而不是单纯聊天接口这类场景下SGLang 的优势就会更明显。所以别再问“哪个框架最好”。应该问的是我现在要解决的是体验问题、服务问题还是吞吐与编排问题二、从部署目标反推框架Ollama、vLLM、SGLang、llama.cpp 的定位差别先把最常见几条路线放到一张脑图里理解。1Ollama最像“开箱即用”的本地大模型运行器Ollama 的核心价值不是让你跑得最快而是让你几分钟内把一个模型在本地跑起来。它适合Mac 开发机个人 PC 本地体验原型验证快速切换多个常见开源模型用最少运维成本提供一个本地接口它的优点很明确安装成本低常见模型拉取方便对个人用户友好接口简单和很多上层工具兼容在 CPU / Apple Silicon / 小显存机器上也比较容易落地但它的边界也要看清更偏本地体验不是高并发服务框架对底层调度、批处理、显存利用的可控性不如专业推理服务框架做严肃线上 API 时灵活性和性能上限一般不如 vLLM / SGLang可以把它理解成本地大模型世界里的“开发者友好入口”。不是不能做服务而是它最擅长的不是“重服务化”。2llama.cpp最强的轻量本地推理生态之一llama.cpp 的定位比 Ollama 更底层。很多本地应用、桌面端 UI、边缘端部署方案本质上都绕不开它。它特别适合CPU 推理Apple Silicon 本地推理小型边缘设备GGUF 模型生态低资源环境里的可用性优先部署它的优势通常在资源门槛低兼容多种硬件后端GGUF 生态成熟做离线本地应用非常合适但它不一定是你做多人高并发 API 的最好选择。它是“让模型在更多设备上可运行”的强项不是“最大化在线服务吞吐”的强项。3vLLM当前最常见的服务化推理基础设施之一如果你的目标是搭 OpenAI 兼容 API跑在线推理服务做多请求调度提高 GPU 利用率控制 TTFT 和吞吐那么 vLLM 通常是最先要看的框架。它为什么流行因为它解决了一个很核心的问题大模型服务不是单次推理快就够了而是要让一块 GPU 同时高效处理很多请求。vLLM 的关键优势一般包括对连续 batching 的支持成熟KV Cache 管理效率高OpenAI 兼容接口生态好Hugging Face 模型接入方便多卡和服务化部署路线成熟简单说vLLM 的强项不是“个人本地玩模型”而是把模型当成一项可被调用的推理服务来运营。4SGLang更强调推理编排与高性能服务控制SGLang 常被和 vLLM 放到一起比较但它的亮点不只是“另一个推理框架”。它更适合下面这类事情复杂 prompt 程序化控制结构化输出与生成流程编排多步推理任务优化对吞吐和调度做更细粒度控制在 Agent、工具调用、复杂生成流水线上做性能优化换句话说vLLM 更像高性能通用推理引擎SGLang 更像高性能推理引擎 程序化生成编排层如果你的系统不只是“给一个 prompt吐一段文本”而是会做多轮控制流多段生成拼接结构化字段输出工具调用前后的模板化推理SGLang 往往更值得投入。三、别先装框架先做容量估算模型、上下文、并发三件事决定了能不能部署很多部署失败不是命令写错而是容量判断从一开始就错了。在服务启动前至少要先估算三件事1模型权重能否装下这是第一层门槛。比如一个 7B 模型FP16 / BF16 大约需要十几 GB 权重显存INT8 会下降到约一半量级4bit 会继续下降但别忘了“装得下模型权重”不等于“能稳定服务”。因为真正吃显存的不只有权重。2上下文长度会不会把 KV Cache 撑爆很多人部署时只算模型大小不算上下文长度。这是非常常见的误判。因为在推理阶段只要请求开始生成KV Cache 就会持续占用显存。影响它的主要因素有上下文长度batch size并发请求数模型层数和隐藏维度注意力头设置所以当你把max_model_len从 4096 提到 32768 时问题不是“数字更大了”而是每个请求可能都在拿更多显存换更长上下文能力。3你到底想支持多少并发单请求可跑和多人稳定调用是两回事。比如单用户聊天时7B 模型在 24GB 卡上可能体验还不错但如果你要支持 10 个同时在线请求调度压力和 KV Cache 占用会立刻变成另一个量级所以工程上一定要先定目标是单用户开发机是 520 QPS 的内网服务还是高并发公共 API不同目标部署参数和框架选择会完全不同。四、Ollama 适合怎么搭把“个人体验”做到顺手而不是把它硬拽成大规模服务如果你现在的目标是今天就想把模型跑起来快速做原型给自己或小团队本地用在 Mac 或个人工作站上长期保留几个常用模型那 Ollama 是很合理的起点。1适合的典型部署姿势最常见做法是本地安装 Ollama拉取 13 个常用模型暴露本地 HTTP 接口上层应用直接调这个接口这类架构的优点是简单几乎没有复杂运维模型切换快配置门槛低非研发同学也比较容易上手2什么时候 Ollama 特别合适下面这些情况优先选它往往没错你在 Apple Silicon 上做本地验证你主要关注是否可用而不是峰值吞吐你需要经常切换模型做效果对比你想先把上层产品逻辑跑通3什么时候别硬用 Ollama如果你开始遇到这些需求就要考虑切换到服务框架需要严格控制并发吞吐需要多卡部署需要更精细的显存调度需要做稳定的 OpenAI 兼容网关需要高负载下可观测性和性能调优Ollama 最大的问题不是“不好用”而是它太容易让人误以为“我已经完成部署了”。实际上它更像“部署前半段的快速落地工具”。五、vLLM 适合怎么搭面向 API 服务的默认解法重点看 5 个关键参数如果你的目标是内网服务化vLLM 往往是性价比最高的起点。它常见的部署思路是准备好 Hugging Face 或本地模型权重用 vLLM 启一个服务进程暴露 OpenAI 兼容接口上层应用、Agent、评测脚本统一走 HTTP API真正关键的不只是能启动而是下面这些参数。1max_model_len控制最大上下文窗口也是显存预算开关很多人第一反应是把它尽量开大。这往往不对。因为它直接影响KV Cache 预留可承载请求数显存余量长输入时的稳定性如果你的业务大多数请求都在 2k4k token 内没必要默认把服务开到 32k 甚至 128k。更稳妥的思路是先按真实请求分布设定窗口把长上下文能力留给特定实例或特定路由别让所有请求都承担长窗口成本2gpu_memory_utilization不是越接近 1.0 越好这个参数决定你愿意让框架占用多少 GPU 显存。很多人为了“榨干显卡”会配得非常激进。问题在于框架自身有 buffer 开销模型和量化格式有差异请求峰值时会出现额外波动过于贴边容易导致 OOM 或抖动工程上更建议先保守起步通过压测逐步上调给波峰流量留一点余量比起极限利用率稳定服务通常更重要。3tensor_parallel_size多卡不是“自动更快”先看模型切分是否值得很多人一有两张卡就想开 tensor parallel。但它不是免费午餐。多卡切分意味着通信开销增加拓扑结构会影响收益小模型可能收益有限某些负载下反而不如单卡紧凑部署经验上大模型装不下单卡时多卡切分是必要方案小模型若单卡能稳定承载单卡往往更省事真要多卡一定要结合压测看 TTFT、tokens/s 和尾延迟4max_num_seqs决定调度上限不是越高越好这个参数通常控制系统希望同时处理多少条序列。它会影响并发承载能力显存占用batch 调度行为长短请求混跑时的公平性配太低吞吐上不去。配太高显存和延迟可能同时失控。所以它本质上是一个吞吐与稳定性的平衡参数。5采样参数和服务参数要分开看很多团队会把 temperature、top-p、max_tokens 跟服务参数混在一起调。其实这是两个层面服务参数决定资源利用与稳定性采样参数决定输出风格与生成长度但两者又会相互影响。例如max_tokens开得很大就会拉长 decode 阶段占用更久的 KV Cache降低整体系统吞吐增大尾部请求延迟所以线上服务里生成长度通常也要做限流和模板化约束。六、SGLang 适合怎么搭当你不只是在“提供一个聊天接口”时它的优势才会真正出来如果你的目标已经不是简单聊天而是让模型严格输出结构化 JSON在一个请求里做多步生成与控制让工具调用、规划、执行形成稳定流水线对前缀复用和复杂生成逻辑做优化那 SGLang 会比纯聊天接口框架更有吸引力。1它的价值不只是快而是“生成流程可编程”很多业务不是一次性出完整答案而是先分类再抽取字段再补全解释最后再形成最终回复如果这些流程全写在应用层一方面很绕另一方面会损失很多推理优化空间。而 SGLang 的一个优势就是更适合把这些流程显式表达出来。2在哪些业务里更值得上 SGLang比如Agent 框架中的多步推理工具调用前后的模板化生成大量结构化信息抽取多提示模板共享长前缀的场景强调吞吐和程序控制的推理任务3什么时候没必要一上来就选它如果你现在只是单模型聊天 API一般问答服务标准 OpenAI 兼容接口小团队内部调用那先上 vLLM 往往更务实。SGLang 的收益通常建立在你已经明确需要“更复杂推理控制”的前提下。七、本地部署最常见的 6 个坑基本都不是“不会安装”而是目标设错了坑 1只看模型参数量不看上下文长度7B 不等于一定轻松。如果你把上下文窗口、并发数、输出长度一起拉高7B 一样会把显存打满。坑 2只看首 token 延迟不看持续吞吐很多 Demo 看起来“回得很快”但一上多人请求就不行。因为线上服务看的不只是 TTFT还包括decode tokens/s并发下平均延迟P95 / P99 尾延迟长短请求混跑时的稳定性坑 3把长上下文当默认配置长上下文不是免费的卖点而是高成本能力。如果业务不是强依赖长文本就别让所有服务实例默认承担这个成本。坑 4把量化当万能药4bit 确实能明显降低显存占用但它不总是代表更高速度也不总是最稳。有些场景更适合BF16 保精度INT8 平衡兼容性4bit 做本地可运行或资源受限部署坑 5混淆“验证环境”和“生产环境”本地开发机能跑不代表生产就该这么跑。研发验证时你可以接受偶发重启单实例瓶颈手动换模型但生产环境需要监控日志限流灰度故障恢复这是两套思维。坑 6没有基于真实请求做压测只跑一句“你好请介绍自己”测出来的数据几乎没有参考价值。更好的压测样本应该覆盖短输入短输出长输入短输出长输入长输出多用户同时请求带结构化输出约束的任务只有这样参数调优才有意义。八、三类典型部署方案个人开发机、单机服务节点、内网多用户 API下面给三个非常常见的部署模板。方案一个人开发机 / 本地研究验证目标快速跑通低运维成本方便切模型推荐思路优先 Ollama 或 llama.cpp模型优先 7B / 14B 量级优先量化版本控制上下文长度不追求大窗口重点关注首次加载时间本地交互速度CPU / GPU / 统一内存占用是否方便接到自己的脚本或前端方案二单机单卡或单机多卡服务节点目标给应用或小团队稳定供 API有一定并发能力统一模型接口推荐思路优先 vLLM配 OpenAI 兼容接口先做保守参数配置基于压测再调max_model_len、max_num_seqs、显存利用率重点关注GPU 利用率并发吞吐长请求是否拖慢整体系统日志和监控是否齐全方案三复杂任务流 / Agent / 结构化生成服务目标提高复杂任务吞吐优化多步生成流程让推理逻辑更可控推荐思路考虑 SGLang结合结构化输出、前缀复用、任务模板设计把 prompt 程序逻辑前移到推理层思考重点关注复杂流程下的总耗时共享前缀带来的收益工具调用前后生成链路是否稳定结构化输出失败率九、几个最重要的参数到底应该怎么理解最后把部署时最常见的一批参数做个工程化解释。1max_model_len含义服务允许处理的最大上下文长度影响KV Cache 预算单请求能力上限显存占用并发能力建议按真实业务分布来设不要盲目拉满2max_tokens含义单次生成最大输出长度影响请求耗时decode 阶段资源占用系统吞吐尾延迟建议按任务类型分类限制不同接口用不同默认值3temperature/top-p含义控制输出随机性与采样范围影响内容稳定性创造性一致性建议问答、抽取、代码、结构化任务尽量保守创作类任务再适当提高4tensor_parallel_size含义模型在多少张 GPU 上切分影响能否装下大模型多卡通信成本推理延迟建议先解决“装不装得下”再讨论“是不是更快”5gpu_memory_utilization含义允许推理框架占用的 GPU 显存比例影响系统稳定性OOM 风险可承载并发建议留余量不要一开始就贴极限6batch / 并发相关参数含义控制同时处理请求的规模影响吞吐平均延迟尾延迟显存压力建议用真实流量模型压测而不是靠主观感觉设值十、部署选型的实用决策表别再纠结“哪个最好”先看你在哪个阶段如果你今天就要选方案可以直接按这个思路判断情况一我只是想让模型先在本地稳定跑起来优先Ollamallama.cpp原因快简单门槛低适合本地原型和个人使用情况二我想给应用层提供统一 API优先vLLM原因服务化成熟OpenAI 兼容接口友好并发和调度能力更强情况三我做的是 Agent、结构化生成或复杂任务流优先SGLang原因推理流程更可编程更适合复杂生成逻辑优化在前缀复用和任务编排上更有发挥空间情况四我硬件资源非常有限但又必须本地离线可用优先llama.cpp / GGUF 路线必要时配合 Ollama 生态原因对低资源环境更友好更容易落地到 CPU、Mac、本地边缘设备十一、最后总结本地部署真正要解决的不是“把模型启动”而是“让资源和业务目标匹配”大模型部署最容易踩的坑就是把“运行成功”误认为“部署完成”。但工程视角里真正的问题始终是这几个模型多大应该用什么精度目标是本地体验、研发验证还是稳定服务上下文长度、并发、生成长度如何约束是选更轻的入口工具还是直接上服务框架是否需要把复杂推理流程前移到推理层来优化所以这篇的核心结论其实很简单本地部署没有唯一正确答案只有是否适合当前阶段。你如果是个人开发者先用 Ollama 或 llama.cpp 把体验跑顺是对的。你如果要做团队 API 服务优先上 vLLM通常也是对的。你如果在做复杂 Agent 流水线、结构化生成或高性能任务编排认真评估 SGLang往往更对。部署这件事从来不是“谁最先进就用谁”而是谁最符合你的硬件边界、业务形态和稳定性目标。