大模型LLM部署方式如果你最近也在折腾大模型大概率会遇到这样的一幕模型文件下好了官方文档也翻过了但手指停在终端前不知道第一行命令到底该敲什么。是直接跑transformers还是装个Ollama又或者干脆上vLLM有时候连一些写业务后端的老手也会在这种地方卡壳因为大模型部署跟传统应用部署完全是两套思路。这篇文章我想把自己这段时间部署LLM的经验从头捋一遍重点聊聊Ollama和vLLM这两条主流路线加上云端API的取舍、部署前的硬件核算还有部署之后真正会遇到的坑。正在做技术选型或者准备动手部署的朋友可以直接把这篇当参考按图索骥。1. 先把概念摆正你部署的是推理服务不是训练环境1.1 部署和微调为什么总被混为一谈很多人一聊到大模型部署第一反应是“我要不要先微调一下”。我能理解这种想法毕竟网上铺天盖地的教程都在讲微调实战好像不微调就不是真做大模型。但在实际的业务落地里大多数团队压根走不到微调那一步。部署解决的是“怎么把已经训练好的模型跑起来对外提供能力”微调解决的是“怎么让一个基础模型更懂你的领域”。这两个问题完全不同硬件需求也完全不同。做训练的时候一张企业级显卡跑7B模型的完整微调显存经常不够需要梯度累积、混合精度甚至多卡并行但部署一个7B模型做纯推理24GB显存的消费级显卡就能比较从容地跑起来。这也是我把文章重点放在推理部署上的原因——对绝大多数人和绝大多数业务来说把现成的开源模型部署成一个稳定可调用的服务才是性价比最高的事情。1.2 推理服务的本质把权重变成响应部署大模型本质上跑的是一个“推理服务”。你给它一段文本它返回一段文本就像你在网页上和对话机器人聊天一样。只不过这个服务跑在你自己的机器上数据不出本地同时你能自己控制它的响应速度、并发能力和可用的模型版本。整个链路可以拆成三步把模型权重加载进显存把输入文本切分成模型能理解的token序列最后通过模型的前向计算逐字生成输出。前两步都很快瓶颈几乎全在生成阶段——每生成一个字整张模型卡都要做一轮前向计算。这也是为什么大模型部署特别吃显存、吃算力也是后面所有性能优化手段要解决的核心矛盾。有人用CPU跑大模型确实能跑但速度慢得感人一个6B、7B级别的模型生成一句话等几十秒很正常。所以如果你准备长期做部署GPU几乎是必需品偶尔试一次用CPU跑跑小模型看看效果倒也无妨。1.3 影响部署方案的第一因素谁来用选部署方案之前先把一个问题想清楚这个服务是给谁用的如果只是自己在本地电脑上折腾试模型、写Demo、做毕业设计那最合适的就是Ollama这类一体化工具体系如果服务要上线面对多个用户同时请求那就得考虑vLLM这类生产级推理引擎如果只是想快速验证业务逻辑不想管服务器、买显卡那直接用云端大模型API是最省心的。这个“谁来用”的问题直接决定后面所有选型。方向错了后面会走很多弯路。比如在个人电脑上硬跑vLLM环境装了半天结果发现显存不够那就是白忙一场。先分清场景再选工具。2. 主流部署路线横向对比Ollama、vLLM、云端API怎么选2.1 Ollama单机私有部署的最短路径Ollama是近几年本地部署工具里最火的一个。它把模型下载、环境配置、权重加载、API服务全部打包一条命令拉下模型再一条命令把模型跑成服务然后你能像调用OpenAI接口一样用HTTP请求来调用。Ollama对新手极其友好因为它把底层细节都黑盒化了。你不用手动配置Python环境不用处理CUDA版本冲突也不用关心transformers怎么加载权重。它就像一个“一键安装包”把大模型部署从命令行级门槛降到了普通开发者也能轻易上手的程度。Llama、Qwen、Mistral、Gemma这些主流开源模型都支持还可以通过Modelfile自定义温度、上下文长度、系统提示词等参数。很多开发者的本地开发环境、企业内部试点项目其实用Ollama已经足够了。2.2 vLLM生产环境高并发的标准答案如果你的服务要面向大量并发请求Ollama往往就不太够用了。它的默认推理模式对并发的支持有限面对几十上百的请求吞吐量和延迟都会很难看。这时候业界通常会上vLLM。vLLM是加州大学伯克利分校开源的高性能推理引擎核心亮点是PagedAttention。打个比方传统推理引擎生成文本时显存里要为每个请求预留一整块连续区域但很多请求实际生成的长度没那么长多出来的显存就白占了PagedAttention把显存划分成“页”像操作系统管理内存一样按需分配大幅提升显存利用率也就意味着同一块GPU上能同时处理更多请求。vLLM还支持连续批处理模型不用等一个请求全部生成完再处理下一个而是边生成边接收新请求整体吞吐量比朴素实现高出数倍到十几倍。生产环境选它不是因为它花哨而是它真能扛住流量。2.3 云端API与本地私有化的取舍除了本地部署直接用云端API也可以理解为一种“部署”方式。OpenAI、Anthropic、通义千问、文心一言这些平台都提供推理接口你不用买GPU不用管推理引擎按调用量付费。云端API最大的优势是零运维注册拿Key就能用体验非常顺滑。但它有几个让团队犹豫的点一是数据隐私企业内部文档、对话内容要送到第三方平台很多公司接受不了二是长期成本API按token计费用量一大费用往往比买卡自建还贵三是定制化受限你只能用平台规定的模型和参数不能完全掌控推理行为。现在比较主流的姿势其实是“混合”核心业务、私有知识库相关的场景走本地私有化部署通用能力、非敏感场景走云端API。两条腿走路成本和效率才能兼顾。2.4 选型决策表按场景对号入座为了方便你快速定位我把三条路线放在一起对比维度OllamavLLM云端API适合场景个人开发、小团队内部试用、低并发试点生产环境、高并发、对外API服务产品原型验证、无GPU资源、非敏感数据硬件要求单张消费级GPU即可CPU也能凑合单卡或多卡GPU显存越大越好无需硬件上手难度极低一条命令启动中等需配置Python环境和推理参数最低注册拿Key即可并发能力弱适合少量请求强PagedAttention加连续批处理由平台保障数据私密性完全本地完全本地数据经过第三方平台典型成本一次性硬件成本一次性硬件成本按用量持续付费这张表不是绝对的但能帮你快速定位。自己玩、做原型验证无脑选Ollama要上线、要扛并发优先vLLM完全不想碰服务器就用云API。2.5 其他部署工具也要提一嘴除了Ollama和vLLM市面上还有不少工具。Text Generation Inference是Hugging Face出品的生产级推理服务器和vLLM的定位有些重叠llama.cpp则是在CPU上跑大模型的重要方案依赖GGUF量化格式还有LMDeploy、FastChat这些项目各有各的侧重点。它们的核心思路都一样把权重加载、调度和生成过程优化到极致差别在于生态、性能和易用性。对大多数人来说掌握Ollama和vLLM已经能覆盖绝大多数场景。其他工具在遇到特定需求时再去研究就行没必要一开始全部接触否则容易信息过载。3. 部署前必做的三笔账显存、量化、并发3.1 模型规模与显存估算方法部署之前第一件事是估算显存。很多人不看显存就开始下载几十B的大模型下载完一跑就显存溢出然后到处问为什么。一个常用的换算逻辑是模型的权重文件多大显存至少就要多大。7B模型用FP16精度存储权重约占14GB13B约26GB70B约140GB。这还没算运行时需要的KV Cache、中间激活值和推理引擎本身的额外开销。所以实践经验是7B模型用16GB或24GB显存的卡跑着舒服13B建议24GB以上70B基本得上多卡或者A100、H100级别的专业卡。怎么知道某个具体模型需要多少显存最稳的办法是看模型卡片上的说明或者用Hugging Face上的Model Memory Calculator这类工具估算。不要只拿“别人说8GB能跑7B”这种话当真理那通常意味着对方用了量化而且很可能牺牲了速度或精度。3.2 量化级别如何影响部署效果量化是大模型部署绕不开的话题。简单说就是用更低精度的数值表示模型权重把FP32或FP16压成INT8、INT4显存占用和计算量都能降下来代价是可能的精度损失。量化格式里最常见的三种GGUF主要用于Ollama和llama.cpp这类工具AWQ和GPTQ则更适合GPU推理场景。实操中我给一个参考7B模型跑Q4_K_M量化版显存只需要6GB左右很多4GB显存的笔记本都能跑如果追求更高精度可以上Q8或者直接FP16。但量化后效果到底差多少必须拿你自己的测试集验证不要迷信网上“量化无损”的说法。还有一个容易踩的坑量化并不总能提升性能。用CPU跑推理INT4的收益很大但在GPU上如果显存本来够用FP16往往比INT4量化生成速度更快因为GPU对高精度矩阵运算的并行优化更好。量化是一种取舍不是免费午餐。3.3 并发量与推理延迟的平衡并发和延迟是一对互相拉扯的指标。并发是同一时间能处理多少请求延迟是一个请求从发出到拿到结果需要等多久。在大模型推理中同一块GPU上同时处理的请求越多单个请求的等待时间就越长。所以做生产部署前要想清楚你的场景是聊天式应用还是批量离线任务聊天应用对单次延迟敏感需要把并发控制得低一点保证请求能快速开始输出批量任务不关心延迟只关心每小时能处理多少条这种情况下可以把并发拉满让吞吐量最大化。vLLM有个设计很有意思它不会像传统服务一样固定并发数而是基于显存动态决定同时跑多少请求。你设置的max-num-seqs只是一个上限实际跑多少由显存和请求大小决定。这个机制很灵活但也意味着你必须结合真实流量压测而不是看着参数猜性能。4. Ollama实操从下载到对外提供API的完整链路4.1 安装与环境准备Ollama的安装确实是“一条命令”的事情。Linux下执行官方安装脚本macOS下载dmg直接拖入应用程序Windows用安装包双击就行。装好之后终端输入ollama -v能看到版本号就说明成功了。但有一个细节特别容易被忽略Ollama默认把模型存放在用户主目录下Linux通常是~/.ollama/models这个目录会随着模型增加变得非常大。想改位置的话需要设置OLLAMA_MODELS环境变量指向你希望存放的磁盘路径。我的建议是装完第一时间就改好否则模型下多了系统盘被塞满那真是灾难。如果你的机器有多张GPU或者想限制Ollama只使用某张卡可以通过CUDA_VISIBLE_DEVICES环境变量来控制。默认情况下Ollama会占用所有可见GPU做调度这在你同时跑其他模型时容易出现显存竞争。这里不需要过度配置但知道自己机器上有几张卡、Ollama在用哪张是排查问题的基础。4.2 模型拉取与运行Ollama拉取模型只需要一条命令ollama run qwen2.5:7b这条命令会从Ollama官方模型库下载Qwen2.5的7B版本下载完成后自动进入交互式聊天界面你可以在里面直接和模型对话退出交互模式用/bye。如果想脱离交互界面让它作为服务常驻运行用ollama serve服务默认监听11434端口。服务跑起来之后用RESTful API来调用模型curl http://localhost:11434/api/generate -d { model: qwen2.5:7b, prompt: 用一句话介绍大模型部署, stream: false }返回的JSON里就有模型生成的文本。注意ollama run命令本身会自动启动服务所以不需要同时手动跑ollama serve不然会出现端口冲突。4.3 把Ollama接入应用代码Ollama对开发者最友好的一点是它提供了OpenAI兼容接口。在/v1/chat/completions路径上你可以直接用OpenAI的SDK调用本地模型只需要改base_url。我拿Python示例一下from openai import OpenAI client OpenAI( base_urlhttp://localhost:11434/v1, api_keyollama ) resp client.chat.completions.create( modelqwen2.5:7b, messages[{role: user, content: 什么是RAG}] ) print(resp.choices[0].message.content)这里有个容易踩的坑本地Ollama不校验API Key但openai库要求这个参数不能为空所以随便填一个字符串就行。接入老项目时只需要把环境变量里的OPENAI_BASE_URL改成http://localhost:11434/v1业务代码几乎不用动这是很省事的一点。4.4 用Modelfile定制模型行为Ollama的Modelfile相当于一个轻量级“配方”文件可以修改模型的采样参数、上下文长度、系统提示词等让默认行为更贴合你的场景。下面是示例FROM qwen2.5:7b PARAMETER temperature 0.3 PARAMETER num_ctx 8192 SYSTEM 你是公司的技术客服回答要简洁、专业不要废话。构建并运行这个定制模型ollama create my-tech-assistant -f Modelfile ollama run my-tech-assistant这样你就得到了一个人设和参数都定制好的私有助手。Modelfile方式比每次调用API时单独传参数更优雅适合团队内部统一模型行为也方便用Git管理配置版本。5. vLLM实操生产环境里的并发与性能调优5.1 vLLM安装与模型启动如果Ollama是个人笔记本上的“整合套餐”vLLM就是生产线上的“专业设备”。它需要一个干净的Python环境对CUDA版本有要求。我个人强烈建议用官方提供的Docker镜像来跑能省掉大把环境配置的时间。启动一个模型实例的命令大概是python -m vllm.entrypoints.openai.api_server \ --model Qwen/Qwen2.5-7B-Instruct \ --download-dir /data/models \ --host 0.0.0.0 \ --port 8000 \ --tensor-parallel-size 1 \ --max-model-len 32768启动之后vLLM会在8000端口提供OpenAI风格的API地址是http://你的服务器:8000/v1/chat/completions。接入方式和Ollama类似base_url改成这个地址即可。几个启动参数的坑需要提前说--download-dir指定模型下载目录避免模型默认存到系统盘--tensor-parallel-size指定用几张GPU做张量并行只有一张卡的时候必须保持为1乱调数值反而会启动失败。5.2 核心参数你需要调的只有几个vLLM的参数非常多但真正需要关心的其实就几个max-model-len允许的最大上下文长度越大越吃显存。gpu-memory-utilizationGPU显存利用率上限默认0.9显存紧张时可以调低但会影响并发能力。max-num-seqs同时处理的最大序列数直接影响并发上限。enable-prefix-caching开启前缀缓存对多轮对话和RAG场景有帮助能降低重复前缀的计算开销。这些参数之间互相制约。比如把max-model-len从4096调到32768模型很可能因为显存不足直接启动失败。你需要同时降低并发或换个更小的模型反复尝试找到稳定运行的组合。注意vLLM启动时如果报CUDA out of memory优先调低max-model-len而不是急着改max-num-seqs。上下文长度对显存的影响往往比并发数更大。5.3 用观测和压测判断是否达标部署完并不意味着结束你得压测得看指标。我个人习惯用wrk或locust模拟并发请求重点看两个指标TTFT首token延迟和TPS每秒处理请求数。TTFT是用户发出请求到模型吐出第一个字的时间。对话场景下TTFT超过3秒用户就会开始烦躁。TPS则决定系统单位时间能支撑多少请求。压测时发现TTFT过高优先降低并发上限或增加GPU算力TPS上不去先看显存是否打满再看是否需要增加卡数或换更高效的量化方式。vLLM启动时加--verbose参数会打印详细的调度日志能看到每个请求的排队和生成情况。刚开始调试时候建议开着方便定位问题稳定之后再关掉。5.4 vLLM和Ollama同时装会不会起冲突很多人的实际状态是本地调试用Ollama顺手但项目又要上vLLM。两个都装完全没问题但有三个点要提前留意。第一端口冲突。Ollama默认占11434vLLM默认占8000如果你改了端口确保不和现有服务撞上。第二显存分配。Ollama如果常驻并占了大量显存vLLM启动时可能因为显存不足而报错。建议不要让Ollama常驻只在需要时启动或者用环境变量限制它的资源占用。第三模型文件不互通。Ollama的模型和vLLM从Hugging Face拉取的模型存放在不同目录会占两份磁盘空间。如果团队同时用两套方案磁盘成本不容小觑。6. 部署中真正坑人的几个问题显存溢出、下载慢、启动失败6.1 显存溢出OOM的排查链路这是部署大模型时最常碰到的问题。很多人一遇到OOM就慌到处找“优化大招”其实排查链路是有固定套路的。第一步确认模型权重文件是否大于显存容量。权重15GB、显卡只有8GB怎么调都跑不动。第二步确认是否使用量化。权重超了用INT4量化把15GB压到5GB左右再试。第三步确认上下文长度设置。同一个模型把上下文从32768降到8192显存占用能降好几个GB。第四步用nvidia-smi查看当前显存占用情况有时候后台残留的进程才是罪魁祸首。按这条链路走一遍大部分OOM都能解决。如果还不行那大概率是选型问题——当前GPU根本不适合跑这个规模的模型别硬扛换卡或者换更小的模型。6.2 模型下载慢的解决方案开源模型动辄十几GB下载慢是家常便饭。我在这上面吃过不少亏总结出几条经验。第一设置HF_ENDPOINT环境变量指向可用的镜像源在同一个shell里设置后再执行下载命令。第二用huggingface-cli或wget提前把模型下载到本地目录检查文件完整后再启动推理服务避免下载过程中断导致权重文件损坏。第三如果走Ollama路线直接利用它的官方模型库分发加速速度通常比手动下载要稳。下载慢这件事本质上要靠“换源”和“断点续传”来缓解。现在主流下载工具都支持断点续传所以即使中途断了也别怕只要不是从头再来问题就不大。6.3 启动失败时先看日志别急着重装很多人部署时遇到启动失败条件反射地重装环境。这是非常大的误区。大模型部署涉及依赖多重装往往浪费时间而且不一定能解决问题。正确做法是先把完整日志读一遍。Ollama和vLLM启动失败时都会打印具体报错信息比如“CUDA out of memory”“model weights not found”“port already in use”等这些信息已经非常直接地指出了问题方向。大多数启动失败都逃不出几个原因端口被占用、模型权重不完整、CUDA版本不匹配、显存不足。搞清楚是哪一类对症下药。先看日志再动手。排查启动失败的第一原则就是不要拍脑袋重装。我见过最典型的案例是有个人vLLM启动一直失败重装了三遍最后发现是8000端口被别的服务占了。“先看日志再动手”这个习惯真的能省下大半天时间。7. 部署之后还要继续走的路RAG、微调与多模态扩展7.1 用RAG把私有知识库接进来模型部署好只是第一步。要让大模型真正适配业务大多数人的第一站是RAG。RAG的流程大致是把企业文档切块、向量化之后存进向量数据库用户提问时先从库里检索出最相关的几段文本拼进提示词一起发给模型模型再基于资料生成答案。这样做的好处非常明显不需要微调模型就能让模型回答私有知识库里的问题答案有出处幻觉率也低得多。常见工具链有LangChain、LlamaIndex还有AnythingLLM、Dify、FastGPT这类带界面的方案。搭建RAG的挑战集中在文本切块和检索召回质量上单纯部署本身反而不是难点。需要说明的是RAG和微调不是非此即彼的关系。RAG适合知识更新频繁、需要追踪来源的场景微调适合统一语气、格式或领域术语的场景。很多成熟项目是“基础模型RAG轻度微调”的组合这也是大模型落地的常规姿势。7.2 什么时候才需要微调这个问题几乎每个做部署的人都会问。我的判断标准很简单如果通过提示词、RAG能解决就不微调如果尝试了各种提示词写法都没效果而且你有稳定的训练数据和足够的硬件预算才考虑微调。微调的主流工具包括LLaMA Factory这类低门槛方案它可以通过配置文件或界面完成数据准备、训练和评测。但微调和部署是两套体系微调完成之后要重新导出模型、转换格式、重新部署整个链路里的坑比单纯部署多得多。所以我的建议是大多数人先把RAG用娴熟把微调当作最后手段而不是默认手段。7.3 多模态模型的部署差异再往深一点说多模态大模型比如能理解图片、音频的模型的部署和纯文本LLM有相似之处也有不少差异。输入侧多了一个视觉或音频编码器调用时需要处理非结构化数据的预处理输出侧如果涉及多模态生成推理链路更复杂显存占用通常比同参数量级的文本模型更高。如果你要部署这类模型我建议一开始就选择vLLM这类已经兼容多模态输入的推理框架不要自己从头搭。它们对Qwen-VL等主流多模态模型的支持已经比较成熟。等你想把这些能力集成进业务时走OpenAI兼容接口的方式和文本模型一致只是输入格式会有所区别。多模态部署的坑比纯文本多但整体思路仍然是选对框架算好显存跑通闭环再逐步扩展。最后分享一个我自己的体会部署大模型这件事真正难的不是敲命令而是搞清楚自己的边界——硬件边界、场景边界、数据安全边界。你只要把“谁来用、多少人用、数据能不能出内网”这三个问题回答清楚选型十有八九不会错。工具本身都成熟得很真不必焦虑。如果你正准备上手我强烈建议先从Ollama跑一个7B量化模型开始把整个闭环跑通之后再考虑上不上vLLM、接不接RAG。一步到位的心态在大模型部署里往往是最大的坑。