企业官网建设流程全解析

上周有个老朋友发消息问我：“你们一台GPU服务器上跑七八个模型，图什么？直接上一个大模型不就完事了？”他截图给我看，一台机器上挂着对话模型、向量模型、视觉模型，甚至还有一个文生图模型，第一眼确实像“模型收藏家”。但做AI应用落地的人应该都有同感：这不是在集邮，而是在给不同的业务问题找最合适的工具。

大模型部署这件事，很多人一开始以为“部署一个大模型”就是终点，真正踩进去才发现，生产环境里的大模型部署，准确说是“部署一批大模型”。为什么？因为没有任何一个模型能在效果、速度、成本、安全这四个维度上同时做到最优。你需要一个大而全的模型当主力，需要几个小而快的模型处理简单任务，还需要专门的向量模型给RAG做召回，可能还得有OCR模型、语音模型、绘图模型。这一整套组合下来，自然就变成了“部署这么多大模型”。

这篇文章不聊概念，直接聊实战。我会从需求侧把“为什么要部署这么多”这件事掰开揉碎，再给出三条主流部署路线，最后用一台16G显存机器做示例，完整跑通多模型部署、API暴露、业务接入和问题排查。无论你是个人开发者、小团队，还是企业里负责AI基础设施的人，这套思路应该都能直接用得上。

1. 先算清楚账：为什么业务里需要同时部署多个大模型

1.1 不存在一个模型通吃所有任务

我们经常听到“大模型是通才”这种说法，但通才指的是知识面广，不代表每项任务都是顶尖水平。实际业务里，任务类型差异非常大：代码补全要精准、RAG召回要语义匹配准确、客服对话要稳、多轮问答要不跑偏，这些任务如果都用同一个7B模型去扛，表现只能是“都能干、都不精”。

我自己的经验是，不同任务应该让不同模型去分工。比如代码生成任务，用专门的代码模型（Qwen2.5-Coder系列或者DeepSeek-Coder系）效果比通用对话模型好一截；文本向量化任务，用专门的embedding模型（如BGE系列），召回率明显高于用大模型硬做；OCR类任务，甚至不需要上LLM，直接上PaddleOCR或者视觉大模型反而更轻量。就算你只做纯粹的文本生成，也可以用“一个强模型负责复杂推理 + 一个小模型负责简单抽取”的组合，强模型不加班、小模型不拖后腿。

1.2 模型不是越大越好，成本和延迟都要算账

很多团队一上来就想部署70B甚至更大参数的模型，理由是“效果最好”。但效果只是维度之一。一台A100或者H100的租金、电费、维护成本摆在那里，而且70B模型的推理延迟通常不可接受，企业级接口要求P95延迟在几秒内，你拿一个大模型扛所有请求，并发一上来就直接打爆。

我的经验是建一个“模型阶梯”：简单任务（打标、抽取、改写、路由）用7B级别模型，中等任务（总结、翻译、单轮问答）用13B~14B，复杂任务（代码生成、多跳推理、长文档分析）才用32B以上。这样既不牺牲关键场景的效果，又保住了成本和响应速度。举个直观例子：同样生成一段代码，7B模型的输出速度可能是70B模型的3到5倍，而效果差距在简单场景下几乎感知不到。

1.3 数据不出内网：私有化部署是绕不开的硬约束

为什么不用大厂API？因为很多业务场景的数据是不能出内网的。企业内部的合同、客服记录、代码仓库、财务数据，直接发给外部API等于裸奔。就算有合规协议，法务和合规部门也很难批准。所以“企业大模型私有化部署”这些年特别热，本质上是在安全和效果之间找一个折中点。

私有化部署不等于非得买A100集群。一台16G显存的GPU工作站，部署一个7B量化模型加一个embedding模型，再套一层RAG，已经能解决很多内部知识库问答的需求。要是不同业务线的数据需要隔离，可以给每条业务线单独部署一个小模型，互不干扰，这又会多出来好几个模型实例。安全边界划分得越细，模型实例就越多。

1.4 线上同一时间往往跑着同一模型的好几个版本

还有一个容易被忽略的点：你以为线上只有“一个对话模型”，实际上往往跑着主版本、灰度版本、不同prompt模板的定制版本、不同量化精度的版本。模型更新不能直接全量替换，要灰度放量、A/B对比，旧版本还要保留一段时间兜底。算力充足的公司干脆把不同版本都常驻内存，用路由层动态分发流量。

所以“部署这么多大模型”不是谁在炫技，而是由业务复杂度决定的。需求侧的问题想清楚了，下面才轮到技术选型。

2. 三条部署路线：从Ollama到vLLM再到GPU集群

2.1 先看清三条路线的定位

部署工具有很多，Ollama、vLLM、Text Generation Inference、TensorRT-LLM、GPUStack、KServe……新手容易选花眼。我的建议是不要按工具选，而是按你的场景选：

Ollama负责让你“跑起来”，vLLM负责让你“跑得稳、跑得快”，GPUStack这类平台负责让你“跑得多、跑得省”。现实中很多团队这三层都会用：开发环境用Ollama，生产环境用vLLM，规模大到需要多台机器后上调度平台。

2.2 本地部署派代表：Ollama为什么受欢迎

Ollama火起来不是没道理的，它把“下载模型到本地跑”这件事简化到了极致。它内置了GGUF格式的模型管理，你只需要一条命令就能拉取模型，一条命令就能启动服务。它把量化、权重加载、上下文管理都封装好了，对新手极其友好。

但Ollama也不是万能的。它的并发能力和吞吐优化比起vLLM有差距，适合单机、小并发、内部使用。如果要做正式的线上服务，我建议把它定位成“开发调试工具”或“内网轻量服务”，而不是高性能推理引擎。

2.3 服务化部署派：vLLM为什么吞吐高

vLLM是目前开源社区用得最广的高性能推理框架之一，核心优势是两个：PagedAttention和continuous batching。PagedAttention解决了KV Cache显存碎片问题，让你能把显存利用率拉高；连续批处理让一个请求生成完一个token后可以立刻离开批次，新请求马上补位，而不是像传统批处理那样必须等整个批次全跑完。

用大白话解释就是：传统批处理像核载十人的电梯，必须等十个人都到达各自楼层，电梯才继续接人；连续批处理像地铁，有人到站就下车，新乘客随时上车，所以运载效率高得多。生产环境并发大，vLLM这类框架几乎是必选项，它暴露的是OpenAI兼容API，业务代码可以直接用openai库调用，迁移成本极低。

2.4 统一调度派：GPUStack这类平台解决什么问题

模型一多，另一个问题就出现了：GPU怎么分配？A机器显存不够，B机器闲着，人工搬模型太痛苦。GPUStack这类开源GPU管理平台做的事情就是“把一堆零散的GPU变成一个大资源池”，你在管理页面上点几下就能把模型部署到指定节点，自动调度显存，还能监控每个模型的GPU占用。

我看热词里有人在搜“gpustack部署模型windows”，确实对Windows节点支持是很多人关心的。这类平台适合模型数量多、机器多、希望有个可视化管控界面的团队，初期只有一两台机器的时候可以先不上，等到机器超过三台、模型超过五个，再上调度平台你会真香。

3. 实战：16G显存机器同时跑多个模型的完整过程

3.1 为什么拿16G显存举例

网上大量讨论“16G显存本地部署AI”，是因为这个配置恰好是个人开发者和中小企业最常接触的档位：RTX 3080/4070/4080、A4000，或者云厂商的16G GPU实例。16G显存说多不多，说少也不少——跑一个70B模型肯定没戏，但精打细算，同时跑两三个7B级别模型是现实的。

我们要在16G显存上实现的目标很朴素：同时常驻一个对话/生成模型、一个embedding向量模型，最好再塞一个低成本小模型，对外提供统一API。下面我把流程完整走一遍。

3.2 模型选型与显存估算：量化规格怎么选

先搞明白一个概念：FP16格式下，模型权重占用的显存大约等于“参数量 × 2字节”。7B模型FP16大约14GB，16G显存勉强能放但加载完基本没剩余空间，推理慢还容易OOM。所以本地部署的通用做法是量化。

量化就是用更少的bit表示一个参数，把占用压下来。GGUF格式有好几档，常见的有Q2_K、Q3_K_M、Q4_0、Q4_K_M、Q5_K_M、Q6_K、Q8_0。其中Q4_K_M是口碑最好的“性价比之王”，质量损失小、体积适中。直观参考一下：

注意这里的“推荐最低显存”考虑了权重之外的开销：KV Cache、CUDA context、激活值。KV Cache是重头戏，后面第4小节细说。在16G显存上，比较稳的组合是“一个7B Q4对话模型（约5GB）+ 一个embedding模型（几百MB）+ 预留KV Cache和系统开销”。如果你胆子大，也可以上14B Q4，但上下文长度要压短，并发调低。

3.3 Ollama部署多个模型的具体步骤

我用Ollama跑通这个过程。安装环节不啰嗦，官网下载对应系统的安装包，装完服务会自动启动，命令行里敲ollama --version能看到版本就说明成功。

第一步，拉取模型。对话模型我用Qwen2.5 7B的指令版，向量模型用BGE-M3（Ollama里叫bge-m3），再顺手拉一个用于简单抽取的小模型：

ollama pull qwen2.5:7b-instruct-q4_K_M ollama pull bge-m3 ollama pull qwen2.5:0.5b-instruct-q4_K_M

第二步，确认模型都到位：

ollama list

你会看到类似这样的输出，说明三个模型已经在本地：

NAME ID SIZE MODIFIED qwen2.5:7b-instruct-q4_K_M xxxxxxxx 4.7 GB ... bge-m3 yyyyyyyy 1.2 GB ... qwen2.5:0.5b-instruct-q4_K_M zzzzzzzz 382 MB ...

第三步，启动服务。Ollama默认会常驻服务，如果想手动启动，用：

ollama serve

默认端口是11434，通过http://localhost:11434访问。测试一下API：

curl http://localhost:11434/api/generate -d '{ "model": "qwen2.5:7b-instruct-q4_K_M", "prompt": "用一句话介绍什么是量化", "stream": false }'

返回JSON里会有response字段，这就是模型生成的结果。这里有个细节：Ollama同时提供了OpenAI兼容接口http://localhost:11434/v1，这意味着你不需要额外适配，直接用OpenAI SDK改一下base_url就能调它。下面这段Python代码可以验证：

from openai import OpenAI client = OpenAI( base_url="http://localhost:11434/v1", api_key="ollama" # 本地服务，key随便填 ) resp = client.chat.completions.create( model="qwen2.5:7b-instruct-q4_K_M", messages=[{"role": "user", "content": "部署多个大模型的理由有哪些？"}] ) print(resp.choices[0].message.content)

第四步，如果你需要调整模型默认行为，可以写Modelfile。Ollama允许你用Modelfile定制模型参数，比如设置上下文长度、温度、system prompt：

FROM qwen2.5:7b-instruct-q4_K_M PARAMETER temperature 0.3 PARAMETER num_ctx 8192 SYSTEM "你是一个严谨的技术助手，回答要精简直接。"

保存为Modelfile后执行：

ollama create my-tech-assistant -f Modelfile

之后就能直接用my-tech-assistant这个名字运行自己的定制模型了。这一步很实用，因为生产环境下不同业务需要不同人设，你不需要重新下载模型，只需要从同一个基础模型派生出多个定制变体。

3.4 用Docker跑vLLM，把模型服务化

Ollama适合单机，但如果你的模型需要承受生产级并发，建议在同一台机器上再用Docker跑vLLM。vLLM的Docker镜像已经打包好CUDA环境，省掉配环境这个最痛苦的环节。

以部署Qwen2.5 7B的AWQ量化版为例：

docker run --runtime nvidia --gpus all \ -v ~/.cache/huggingface:/root/.cache/huggingface \ -p 8000:8000 \ --ipc=host \ vllm/vllm-openai:latest \ --model Qwen/Qwen2.5-7B-Instruct-AWQ \ --quantization awq \ --max-model-len 32768 \ --gpu-memory-utilization 0.85

几个参数说明一下：

• --max-model-len 32768：模型支持的最大上下文长度，设得越大KV Cache占用越高。
• --gpu-memory-utilization 0.85：允许vLLM最多使用85%的显存，留一点给CUDA和其它模型。
• --quantization awq：因为拉的是AWQ量化版，必须声明量化方式，否则加载会报错。

启动后，访问http://localhost:8000/v1就是OpenAI兼容接口，业务代码里只需要把base_url指过去即可。vLLM的优势在并发场景下非常明显，同一台16G机器，Ollama可能只能扛两三个并发，vLLM配合continuous batching可以轻松扛几十个Requests Per Second级别（具体取决于请求长度和模型大小）。

实际上，我把Ollama和vLLM两者配合使用：Ollama跑embedding和小模型，vLLM跑7B主力对话模型，两个服务端口不同，但都暴露OpenAI兼容API，上层应用接入起来完全无感。

4. 模型一多必然遇到路由：API编排与业务接入

4.1 统一API入口：别让业务代码到处搬

模型多了以后，第一个坑就是业务代码里写死了各个模型的地址。今天你换一台服务器、加一个模型副本，所有调用方都得跟着改。正确做法是加一个路由层，对外只暴露一个稳定入口，内部根据请求参数把流量分到对应模型。

轻量方案是直接用Nginx做反向代理，把/v1/chat/completions转发到vLLM，把/v1/embeddings转发到Ollama的embedding模型。重型方案可以上开源API网关项目，支持模型分组、负载均衡、密钥管理、配额限制。生产环境我建议至少要做到“应用层不感知模型地址”，否则后期每次扩容都像在拆弹。

4.2 工作流平台接入：Dify接本地模型的配置要点

现在很多团队用Dify这类开源LLMOps平台编排Agent工作流，Dify本身不跑模型，它需要对接外部模型服务。把本地模型接入Dify的关键一步是：在“设置-模型供应商”里选“OpenAI-API-compatible”，然后填三个东西——API Endpoint、API Key（本地服务随便填）、模型名称。

这里有个容易踩的坑：Dify如果用Docker Compose启动，容器内的localhost指向的是Dify容器本身，不是你的宿主机。你需要填写局域网IP或者host.docker.internal，例如http://host.docker.internal:8000/v1，否则怎么配都连不上。另外，同一个模型要在Dify里同时用于对话、Embedding、Agent推理等不同场景，就要在每种类型下分别注册一次，这也是很多新手抱怨“为什么模型加载不出来”的常见原因。

4.3 Agent应用与内网部署：离线环境下的特殊考虑

Agent类应用（热词里有人在搜DeepSeek harness这类项目）对多模型的需求尤其明显：一个Agent任务里，规划器用大模型、工具调用解析用小模型、记忆检索用向量模型，有时候还要配一个代码解释器模型。可以说Agent是“为什么需要部署这么多大模型”的最佳范例。

在内网部署这类应用，关键不是模型本身，而是“没有外网依赖”。我建议提前做三件事：一是把依赖包离线导出（pip download、npm pack或Docker镜像save）；二是模型文件提前下载好，用移动硬盘或内网共享存储拷贝进去；三是在内网搭一个Harbor镜像仓库，把需要用到的镜像全部push进内网。这样就算部署环境完全断网，也能在半小时内把整套Agent服务拉起来。

4.4 上下文长度这个参数别乱调

热词里“大模型上下文长度”搜索量很高，说明很多人栽过跟头。直接说结论：上下文长度不是设得越大越好，它跟显存强相关。KV Cache会随着上下文长度线性增长，公式可以简化成：

KV Cache占用 ≈ 每token的KV大小 × 上下文长度

拿7B模型举例，Llama架构大约每个token的KV Cache需要128KB左右。算一笔账：1K个token大约128MB，8K上下文大约1GB，32K上下文大约4GB。如果模型权重已经吃掉5GB，再把上下文拉到128K，16G显存直接OOM给你看。这也是为什么很多16G用户发现“模型明明能跑，一开长文档就崩”。

我的建议是：日常对话场景设置8K或16K就足够，只有做长文档分析时才临时切到大上下文版本。与其硬撑超长上下文，不如用RAG把文档切片召回，效果更好还省显存。

5. 多模型部署翻车实录：常见问题与排查技巧

5.1 显存OOM：最经典的事故现场

症状很统一：日志出现CUDA out of memory，或者推理到一半直接崩。排查方向按优先级排序：第一，看模型权重大小，Q4_K_M的7B不该占10G；第二，看上下文长度，把num_ctx或max-model-len调小；第三，看并发数量，Ollama默认并行就会吃KV Cache显存。我自己常用的命令是nvidia-smi实时盯着显存曲线，确认到底是谁在吃显存。

一个很实用的习惯是给模型预留显存余量。Ollama可以设置OLLAMA_MAX_LOADED_MODELS，限制同时加载的模型数量；vLLM可以用--gpu-memory-utilization 0.8避免占满。切记不要让某个模型把显存吃到100%，否则其它常驻模型会被强行换出，你还会看到“模型重新加载”的诡异延迟。

5.2 并发上不去：批处理策略的锅

如果你用Ollama，请求一多就排队，多半是默认并行度不够。可以设置环境变量OLLAMA_NUM_PARALLEL=4或更高，让它同时处理多个请求。但并行加高会挤占KV Cache，属于拆东墙补西墙。

如果并发压力真的很大，直接换vLLM是正道。vLLM的continuous batching能把GPU利用率拉到很高，实测同样一张卡，吞吐量经常是Ollama的好几倍。这里还有个隐藏技巧：vLLM启动时预留一小块显存给embedding模型用，vLLM和Ollama可以同时跑在一台机器上，各占一部分显存不冲突。

5.3 响应慢：分清单词还是句子的锅

响应慢要分情况看。如果是“第一个请求特别慢，后续恢复正常”，这是冷启动加载模型；如果是每个请求都慢，说明模型太大、量化精度太高或者并发排队长。冷启动问题的最优解是让模型常驻显存，别让它被换出。Ollama的模型默认在一定时间不调用后会释放显存，可以设置OLLAMA_KEEP_ALIVE=-1让模型永久驻留。生产环境还可以用vLLM配合--enforce-eager减少启动时间（牺牲一点首token速度换启动稳定）。

5.4 模型下载慢与离线分发

本地部署绕不开模型下载。国内网络环境下从Hugging Face直接拉模型经常慢到怀疑人生，我的做法是优先从ModelScope（魔搭社区）下载，它的服务器在国内，速度稳定。下载完成后把模型目录保存好，内网传输用U盘或内网共享盘都行；如果用的是Docker镜像，就docker save成tar包拷进内网再docker load。整个流程不需要任何特殊网络手段，纯粹靠离线拷贝解决问题。

汇总一个速查表，方便遇到问题直接对号入座：

最后分享一点个人体会：多模型部署不是终点，它只是手段。真正要花心思的是“哪些场景用哪个模型”这套路由策略，以及“模型更新时怎么灰度替换”这套运维机制。如果你刚开始接触，不必一步到位，先用Ollama在本地把两三个模型跑起来，VLLM容器化服务化也试一遍，等模型数量和流量上去了，再引入GPUStack这类调度平台也不迟。这个方向后续值得延伸的内容还有很多，比如多模型之间的自动路由、基于流量的模型自动伸缩、以及把不同模型的KV Cache配额管理做成可视化报表，都是可以让这套东西真正“生产化”的关键动作。