企业官网建设流程全解析

大模型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 选型决策表：按场景对号入座

为了方便你快速定位，我把三条路线放在一起对比：

这张表不是绝对的，但能帮你快速定位。自己玩、做原型验证，无脑选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精度存储，权重约占14GB，13B约26GB，70B约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_url="http://localhost:11434/v1", api_key="ollama" ) resp = client.chat.completions.create( model="qwen2.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-utilization：GPU显存利用率上限，默认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默认占11434，vLLM默认占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。一步到位的心态在大模型部署里往往是最大的坑。