企业官网建设流程全解析

模型部署这件事，这几年变化得实在太快。几年前我还在为一个训练好的分类模型写 Flask 接口，纠结要不要上 uWSGI 还是 Gunicorn，现在手里已经要同时管着几十个大模型服务、几个不同的推理引擎、还有一套带网关和观测的 LLM 推理平台。如果你也正处在“单模型服务能跑，但一上正式环境就各种翻车”的阶段，或者已经在评估 vLLM、TensorRT-LLM、SGLang 这些推理框架，那么这篇从单模型服务讲到 LLM 推理平台的文章，应该能帮你在选型和架构上少走不少弯路。

模型部署不是把模型文件往服务器上一丢就完事。正式环境里有并发、有延迟、有显存、有监控，还有数不清的兼容性问题。本文不聊训练，只聊部署：我会把单模型服务、LLM 推理引擎、量化选型、GPU 适配、推理平台架构、边缘部署、自动化测试和排错经验，按生产落地的主线一路拆开讲，适合做后端的老手、算法工程师转型模型部署的同行，也适合刚准备把模型推到线上的团队参考。

1. 从单模型服务到推理平台：部署架构演进的核心逻辑

1.1 单模型服务为什么扛不住正式环境

先说个很典型的场景。你训练了一个文本分类模型，导出成 ONNX 或者 TorchScript，然后用 FastAPI 写个/predict接口，Uvicorn 一拉，单机部署，模型加载进内存，推理一次几十毫秒。本地压测没问题，接口响应也稳定，看起来挺美。

可一旦上了正式环境，事情就开始变味。第一波并发上来，Uvicorn 的异步模型和 CUDA 推理的同步调用之间的协调就开始出问题，GPU 利用率忽高忽低，显存时不时涨一点，请求稍微多一点，延迟就飙到几秒。更麻烦的是，你要部署的不止一个模型。公司业务一扩张，分类模型、实体识别、相似度匹配、摘要生成，各个团队各自为战，每人一套 FastAPI 服务，端口乱成一锅粥，监控指标没有人统一看，模型版本没人统一管，出了问题谁也说不清是哪儿挂了。

这就是单模型服务架构的天花板：它适合“跑起来”，不适合“运营”。正式环境要的是可观测、可治理、可扩展、可容错。单个服务本身再轻快，也没法回答“你今天为什么 GPU 显存又满了”“昨天上线的模型为什么回流准确率掉了 3 个点”这种平台层面的问题。

1.2 推理平台的核心诉求与分层设计思路

当我们谈模型推理平台，不是简单地做一个“把模型打包部署的工具”，而是要给模型服务提供一个标准化、平台化的运行环境。我拆过很多需求，总结下来，正式环境的推理平台基本要覆盖四层：

第一层是模型服务层，解决“模型怎么跑”的问题。例如用 vLLM 跑 LLM、用 Triton 跑多模型、用 ONNX Runtime 跑中小模型，这一层要管理推理引擎、模型版本、量化精度和显存占用。

第二层是网关接入层，解决“流量怎么进”的问题。统一入口、路由分发、限流熔断、鉴权审计，这些不是业务方各自能搞定的。我们做平台时要让业务方尽量少感知模型背后的部署细节，他们只需要调用一个统一的 API。

第三层是调度资源层，解决“算力怎么分”的问题。多模型共享 GPU、自动扩缩容、队列管理、多副本负载均衡，本质上和微服务架构里的服务编排是一个套路，只不过把 CPU 换成了 GPU + 显存。

第四层是观测治理层，解决“出了事怎么查”的问题。指标、日志、链路追踪、模型质量回放，这四样一样都不能少。模型推理和普通服务不一样，光看 P99 延迟不够，还得看 token 级吞吐、显存水位、量化损失和上下文长度这些模型专属指标。

把架构拆成这四层，你会发现很多技术选型的争论其实是在不同层面打架。你拿 FastAPI 和 vLLM 比，这不对等，FastAPI 是应用框架，vLLM 是服务化推理引擎，它们在平台里的位置截然不同。先有分层思维，再去选型，才不会越选越乱。

2. 单模型服务层的框架选型对比与实操要点

2.1 FastAPI + ONNX Runtime：轻量推理服务的最小可行方案

先补充一段我很常用的底线方案。正式环境里，中小模型的部署量非常大，不可能每个模型都上重型推理平台。一个干净、可控、可基准测试的 FastAPI 服务，配上 ONNX Runtime，依然是目前最稳妥的组合。

FastAPI 的优势在于原生异步、Pydantic 校验、OpenAPI 文档自动生成，这对后端团队接手非常友好。ONNX Runtime 的优势在于跨框架、跨硬件，训练时用 PyTorch，导出 ONNX 后不管是 CPU 还是 GPU 都能用同一套推理代码。

实操上我建议，模型加载必须放到应用启动事件里做，不要放在请求处理函数里。否则第一个请求要做十几秒的模型加载，接口直接超时。更细一点的技巧是，ONNX Runtime 的 session 要按 GPU 设备建，不要每个请求都建，同时设置 intra_op_num_threads 和 inter_op_num_threads，否则多线程并发时 CPU 资源会被白白浪费。

再加两个生产上的细节：第一，请求输入要做长度截断和预检查，尤其文本模型，你不可能让用户一传几 MB 的文本直接进模型。第二，输出要做后处理和结构化包装，我习惯统一返回{"code": 0, "data": ..., "trace_id": ...}的格式，这样后续接网关时做字段映射会非常省事。

2.2 Docker + Ollama：本地大模型部署的最快路径

大模型流行起来以后，本地化部署的诉求也突然多了。很多团队没精力自己搭 vLLM 集群，只需要在局域网里跑一个开源模型，支持 API 调用，比如 Qwen、Llama 的 7B、14B 版本。这种情况下 Docker + Ollama 是我见过效率最高的路径。

Ollama 把模型下载、量化、服务化、API 暴露全部封装好了。你用ollama pull qwen2.5:7b拉模型，docker run -d -v /data/ollama:/root/.ollama -p 11434:11434 ollama/ollama起服务，然后curl http://localhost:11434/v1/chat/completions就能拿到 OpenAI 风格的响应。整个过程十几分钟，几乎没有任何学习成本。

但这里我要强调几点。Ollama 默认加载模型是有内存和显存控制的，如果你的机器是 24G 显存，跑 7B 量化模型没有问题，但想同时加载两个模型，就可能会出现 OOM 或者反复换入换出。操作上可以用OLLAMA_MAX_LOADED_MODELS=1控制并发加载模型数，用OLLAMA_NUM_PARALLEL控制单模型并行请求数，这两个参数在生产环境必须提前调好。

Docker 部署还有一个容易被忽略的点：容器里的 CUDA 运行时版本要和宿主机驱动兼容。常见坑是宿主机驱动太老，容器里拉的新版 PyTorch 镜像跑不起来。先执行nvidia-smi确认驱动版本，再选合适的基础镜像，这是最省心的顺序。

2.3 模型服务封装：预加载、批处理、超时与并发控制

不管用什么框架部署单模型，有几个通用点我建议形成自己的模板，别每次都临时写。

一是预加载。模型、分词器、专用处理器，全部在进程启动时加载，启动完成后等待一个 ready 信号，再对外提供服务。配合 K8s 的 readinessProbe 就很好用。

二是批处理。对于小模型，动态 batching 可以把吞吐提升好几倍。实现思路不复杂：请求进来先不立刻推理，放进队列，积累一定请求数或等待一小段窗口时间，再统一拼成 batch 送入 GPU。vLLM 的 continuous batching 是在引擎层做了类似的事，我们自己写小模型服务时也可以借鉴这套思想。

三是超时与并发控制。推理服务最怕慢查询拖死进程。我通常在服务里用信号量控制并发上限，超过上限直接返回 429 或排队，同时给每个推理请求设一个硬超时时间，GPU 推理线程没有在规定时间返回就直接丢弃。

说到底，单模型服务的核心目标是“跑得稳”，不是“功能多”。把有限的功能做成可复用模板，你才有精力去做真正的平台。

3. LLM推理引擎、量化方案与GPU适配实战

3.1 GGUF、GPTQ、AWQ 几种量化该怎么选

到了 LLM 这里，模型部署的技术栈和传统模型完全不一样。最典型的差异就是量化方案。现在开源模型动辄 70B，不做量化基本没法在单卡上跑。你一定会遇到 GGUF、GPTQ、AWQ 这些词，我一个个说。

GGUF 是 llama.cpp 生态的格式，它把模型权重和超参数打包进一个文件，可以配合 CPU 和 GPU 混合推理。对我来说 GGUF 最大的价值是通用性极强，支持 llama.cpp、Ollama、LM Studio 这类工具，你不用装 PyTorch 就能跑模型。适合个人工作站、边缘设备、以及 CPU 推理场景。

GPTQ 是面向 GPU 的量化格式，主要在 AutoGPTQ 生态里使用。它通过二阶信息做逐层量化补偿，量化到 4bit 后，显存占用能压到原来的四分之一左右，但保留较好的生成质量。如果你确定模型只跑 GPU，GPTQ 是我比较推荐的。

AWQ 的思路不同，它不是单纯量化权重，而是根据激活值分布保护重要权重通道，量化后质量通常比 GPTQ 更稳一点，推理时还有激活感知特性，和 TensorRT-LLM、vLLM 配合都不错。

我的建议很简单：跑在 Ollama、llama.cpp 场景选 GGUF；跑在 GPU 集群、要极致吞吐选 AWQ；要兼容旧生态、用 transformers 直接加载，选 GPTQ。没有绝对优劣，关键是看推理引擎支持和团队熟悉度。

3.2 vLLM / TensorRT-LLM / SGLang 的取舍

在正式环境部署 LLM API 服务，vLLM 是我见过出场率最高的推理框架。它的核心技术是 PagedAttention，把 KV Cache 分成物理块管理，大幅降低了显存碎片浪费，吞吐和并发能力很突出。安装简单，pip install vllm之后一行命令就能启动 OpenAI 兼容服务，部署体验非常顺滑。

TensorRT-LLM 的定位不一样，它是基于 TensorRT 深度优化的推理引擎，适合把模型编译成高度优化的引擎文件，配合 NVIDIA 显卡能压出更强的单卡性能。代价是构建流程相对复杂，模型格式需要通过 trtllm-build 编译，和 Hugging Face 生态的适配没有 vLLM 顺手。它更偏生产级调优，适合已经确定要长期运行同一批模型的场景。

SGLang 是后起之秀，主打的亮点是更高效的前后端处理，在长文本、多轮对话和高并发场景下表现很猛，RadixAttention 可以复用公共前缀的 KV Cache，多轮对话场景优势明显。

我的取舍经验是这样的：想快速上线且团队资源有限，直接上 vLLM，成熟稳定，踩坑资料多；跑在 NVIDIA 系列卡上、追求极限性能和低延迟、且能投入人力的团队，考虑 TensorRT-LLM；如果你的应用场景有大量多轮对话和长文档，试试 SGLang，它的前缀缓存优化会让你惊喜。值得提醒的是，框架版本迭代非常快，别盲目追新，先跑通一版，再评估升级。

3.3 GPU显存估算方法：以L20为例

选卡和选模型永远分不开。热词里频繁出现的 L20 显卡，很多人在问它适合部署什么模型。L20 是 48G 显存的 NVIDIA 数据中心级显卡，显存大、功耗适中、支持 BF16 和 Tensor Core，对于主流开源 LLM 的部署相对友好。

我通常按这个公式估算模型需要的显存：

参数量(GB) = 模型参数量(B) × 每个参数的字节数。FP16/BF16 下每参数约 2 字节，所以 7B 模型全精度权重约 14GB。INT8 量化约 7GB，INT4 量化约 3.5GB。再额外加上 KV Cache 和推理过程中的激活值，一般预留 30%-50% 的余量。

举例来说，在 L20 48G 显存上部署一个 14B 模型，BF16 权重约 28GB，还剩 20GB 给 KV Cache 和激活值，足以应付比较长的上下文。如果想同时部署两个 7B 模型，走 INT8 量化后每个约 7-8GB，两个加上 KV Cache，48G 也能装下，但就要用前面的 Ollama 参数限制并发加载数，避免显存抖动。

这套估算方法不复杂，但能帮你在采购之前快速判断能不能跑。我的建议是至少留 40% 余量，别把显存算到 95% 再去跑，一旦上下文长度升高或并发请求增多，OOM 会来得非常突然。

4. 从单机走向推理平台：网关、调度与观测

4.1 网关层设计：路由、限流和模型多版本管理

当你手里有多个模型服务后，第一件事不是写调度器，而是先把网关立起来。网关要解决的三个问题是：请求往哪走、流量怎么控、模型版本怎么切。

模型路由的维度很多。可以按模型名路由，也可以按业务类型路由，还可以按输入规模路由。例如短文本走小模型，超长文本走大模型；或者同一个线上请求，默认走加速版小模型，检测到置信度低再转发大模型。这块我建议直接用一层独立的网关服务做，不要塞进每个模型服务里。Spring Boot 生态里很多人会直接把网关和业务管理后台合并，其实逻辑可以放一起，但边界要清晰。

限流和熔断也不能省。LLM 推理是典型的高成本慢请求，如果上游业务方写了个 bug 疯狂刷接口，几秒钟就能把 GPU 打满。我习惯在网关层做两层限流：第一层按调用方 AppKey 做 QPS 配额限制，第二层按模型维度做全局并发限制。超出的请求直接返回 429，返回体里带重试时间和排队建议。

多版本管理同样重要。线上模型 A/B 测试和灰度发布，本质就是网关层流量切分。你在网关里配置model_version: v1 → v2的权重比例，然后观察回流数据和推理质量，再逐步切到 v2。这个能力如果没有，每个模型版本更新都意味着业务方改代码，这是不可接受的。

4.2 弹性扩缩容与真正的健康检查

正式环境里，GPU 服务扩缩容和普通 Web 服务不太一样。难点在于：模型加载本身就有几秒到几十秒的时间，副本扩容不能指望秒级完成；GPU 资源是稀缺资源，不能像 CPU 服务那样随便铺一堆副本。

我在生产里推荐的方案是：结合请求队列长度和 GPU 显存使用率做指标。例如当某模型的排队请求数持续超过某个阈值、且 GPU 利用率已超过 85% 时，触发扩容。扩容时不要直接拉新副本，先把模型镜像准备好，再用预热接口加载模型，等 readiness 探针通过后再接入流量。

健康检查也有讲究。LLM 服务如果只是返回 200，不代表推理功能正常。我见过最典型的例子是某个 vLLM 进程已经卡死，但 HTTP 端口还在响应，K8s 认为副本健康，流量继续打进来，直到客户端大量超时才暴露。正确的健康检查要做两件事：一是检查模型推理是否真的在正常响应，例如每 30 秒往服务发一个极短的请求；二是检查推理引擎内部的 state 是否健康，比如 vLLM 的is_server_ready接口。好的探针才能让扩缩容有意义。

4.3 统一接入：OpenAI兼容接口与观测体系

推理平台做到后面，你会发现统一的 API 协议是重中之重。为什么大家都要做 OpenAI 兼容接口？因为它既是事实标准，又方便团队内外部直接复用生态。vLLM、Ollama、LM Studio、TGI 都支持 OpenAI 风格接口，这让平台接入成本大幅降低。

技能方面，模型服务可以暴露原生/v1/chat/completions，但平台层一定要在更上面的地方做协议统一。我们通常在网关层做鉴权、用量计量和审计，业务方拿到的每一个api_key都能对应到具体的配额和账单。这样做还有个额外好处：以后底层换引擎，业务方代码一行都不用改。

观测体系建设是模型平台最重要的投入之一。指标上至少要有：QPS、延迟（TTFT 首 token 延迟和 TBT 每 token 延迟要分开看）、GPU 利用率、显存占用、KV Cache 使用率、排队长度。日志上要带 trace_id、model_id、prompt_tokens、completion_tokens。模型层级还有一个特殊的观测维度是生成质量，定期把线上请求抽样保存，做评估和回归，这就是 LLM as Judge 或离线评测要做的事。没有这套体系，平台离“能运营”还有很远的距离。

5. 边缘部署与全链路质检验收

5.1 树莓派5跑YOLOv5的真实体验

不只是数据中心需要部署模型，边缘设备同样是模型部署的重头戏。热词里有一条是“树莓派5上部署自己训练的YOLOv5模型”，这个场景我实测过，可以给点参考。

树莓派5的 CPU 比前代强很多，但也没有强到能跑大模型的地步。YOLOv5 的 s 和 n 版本经过优化后，在树莓派上推理是可以接受的。我的做法是这样：训练完 YOLOv5 后导出为 ONNX，再用 ONNX Runtime 在树莓派上运行。先pip install onnxruntime,然后把导出好的 best.onnx 配合 cmark export 后处理代码跑起来。没有 GPU 的情况下关键是推理尺寸，输入图片 resize 到 640 或 320，检测速度完全两码事。

实战里的坑也很多。树莓派的内存是共享的，CPU 和 GPU 共用一块 LPDDR 内存，YOLO 后处理里的 numpy 操作如果写得不优化，内存分配会非常频繁。建议把后处理里的循环尽量向量化，避免逐框 for 循环。另外树莓派供电不足会导致 CPU 降频，推理速度骤降，这个不是代码问题，是硬件问题，换一个足功率电源能解决。

如果实在想跑得快一点，可以通过 Hailo-8、Coral TPU 或 RKNN NPU 之类的方案做硬件加速，但工程复杂度会上一个台阶。对多数做原型验证的团队来说，ONNX Runtime 在树莓派 5 上跑 YOLOv5n 已经够用了。

5.2 本地视频模型部署的三个关键点

“本地部署视频模型”也上过热词。视频模型和图像模型不一样，数据量是爆发式的，一秒钟 30 帧，模型稍微慢一点就处理不过来。

这类部署的关键点有三个。第一是解码与推理分离，用 OpenCV 或 PyAV 解码线程专做视频取帧，推理线程专做模型预测，中间用带长度上限的队列缓冲，避免解码过快撑爆内存。第二是帧抽样策略，不是所有视频都需要逐帧推理，先做运动检测，画面变化大的帧才送模型，这种优化在安防和质检场景能省几十倍的算力。第三是推理结果的时序后处理，视频模型输出一般要做平滑或去抖，例如检测目标连续几帧出现才确认，否则画面闪烁会让业务方直接投诉。

本地视频模型部署还有个更基础的问题：别把处理和存储放在同一个机械硬盘上，因为视频文件非常大的情况下 I/O 会成为瓶颈。先确认读帧速率能不能跑满推理消耗，再考虑优化模型，否则你优化的方向就错了。

5.3 pytest搭建模型回归测试

模型部署上了正式环境后，最怕的不是推理慢，而是“悄悄变坏”。模型更新、量化参数调整、推理引擎升级，都可能让结果劣化。我强烈建议你在部署流程里接入基于 pytest 的模型回归测试。

这套测试做起来不复杂，核心是准备一套固定的评测样本集和阈值。每个样本包含输入、期望输出或评测标准，例如分类任务的 label、生成任务的参考答案、相似度任务的标准分值。然后写 pytest 用例，在预发布环境里对候选模型执行推理，计算准确率、F1、BLEU、语义相似度等指标，只要比基线低于设定阈值就直接 fail，阻断发布。

你会发现 pytest 做模型回归有个额外好处：它能和 CI/CD 流程天然整合。你可以在每个模型版本推送到镜像仓库前，自动触发一次回归测试，测试通过才允许打正式标签。这个测试跑一次可能只要几分钟，但能挡住大量质量事故。别忘了测试样本集要定期更新，把线上新出现的异常 case 吸收进去，否则时间一长就会回归盲区。

也可以用类似思路做 LLM 的评测，举个例子，需要自动化评估摘要质量时，可以调用一个更强大的模型当裁判，也就是 LLM as Judge，把这个裁判模型的打分结果和人工抽检结果做对比，保证评测口径可信。这一套我做下来，模型上线的安全感是完全不一样的。

6. 生产环境常见问题与排错记录

6.1 LLM请求失败的典型原因

先说一个我在实际部署中反复见过的报错：llm request failed: provider rejected the request schema or tool payload.这个报错的意思很直白，上游 LLM 服务拒绝了请求的结构或工具调用格式。大多数情况下不是模型本身坏了，而是客户端发出的请求不符合服务端 JSON Schema 的限制。

排查思路很简单：先把请求抓出来，看 messages 里 system、user、assistant 角色是否符合要求，tools 或 functions 的声明有没有多余字段。有些服务端对 tool 名有字符限制，有些对参数对象里的 null 值敏感。我遇到最多的原因，是客户端用了新版本 SDK 增加了字段，但服务端还是老版本的协议。解决方案是固定 SDK 版本，同时在网关层做一次协议格式化，把非标准字段剥掉。

类似的请求失败还有很多种，比如 context length exceeded、bad prompt、unsupported parameters。处理这些问题的根本思路，是在网关层做好统一错误码映射和回滚机制。因为你不可能让业务方直接面对 vLLM 或者 OpenAI SDK 的原始报错，那不是生产环境的体验。

6.2 显存泄漏与并发踩坑

正式环境跑 LLM，显存问题几乎每天都在上演。最常见的是显存缓慢爬升，跑几天后 OOM。先别急着怀疑模型代码，检查推理引擎版本，vLLM 不同版本之间的显存回收行为差异很大，升级到 0.4.x 之后的版本多数问题都有修复。我踩过最郁闷的一次坑，是服务里的日志模块把推理结果全量缓存了一部分，导致显存只增不减，最后靠 dump trace 才发现。

并发和显存的相互作用也容易出问题。max_num_seqs、max_model_len、gpu_memory_utilization这三个参数是调节的关键。显存利用率可以设 0.9 也可以设 0.7，但太高了容易在长文本请求时 OOM,太低了 GPU 利用率又上不去。我习惯先设一个保守值，把线上流量观测两周，再逐步调高。

另外就是别忽略 CUDA 的 context 占用。一个进程内如果多次初始化不同推理引擎，CUDA context 可能被重复创建，每份都是几百 MB 的量级。我做平台层时规定，一个进程只使用一个统一的推理后端，避免混用多个引擎导致显存暴涨。

6.3 框架选型的常见误区

最后聊聊热词里出现的各种框架和选型误区。这些热搜词里夹杂着 Spring Boot、若依、Nuxt、Flutter、Qt MVVM 这些词，乍一看和模型部署无关，但仔细想想，它们其实都在回答同一个问题：模型服务的上层应用怎么做。

常见误区是想用一个框架解决所有问题。比如有人想直接用若依来做模型管理后台，确实能快速出界面，但若依的权限和代码生成思路适合普通业务管理，模型服务的 GPU 调度和推理编排并不在它的视野里。反之，有人想用 Flutter 或 Nuxt 做一个很炫的模型调用前端，这当然可以，但前端再炫，网关层和后端的稳定性才是真正的壁垒。

另外一个误区是照搬网上博客的推荐，不评估团队能力。vLLM 相比 TensorRT-LLM 更容易上手，但如果你团队里没有懂 CUDA 的人，非要去搞 TensorRT 优化，项目大概率会延期。选框架的标准应该是：团队能不能在遇到问题时维护它，而不是谁名气大用谁。框架本身只是工具，生产环境拼的是运维体系、观测能力和团队对工具的理解深度。

还有一类热词，比如 agent 框架、智能体框架、co-star 框架，这类恰恰说明 LLM 部署之后还有一层是应用编排。平台能力稳定之后，你可以在平台上跑多智能体、跑 RAG、跑工具调用，但前提是底层的推理服务有足够的并发和延迟保障。别本末倒置，先把模型服务打稳，再谈上层智能。

6.4 实战排错速查表

我把日常高频问题和排查方向整理成一个速查表，有需要可以直接对号入座。

这张表的每一行背后，都是我踩过的实际案例。如果你也有类似问题，对照着做，基本能省一半排查时间。

7. 最后再分享几个我自己的体会

做到现在，我最深的感受是，模型部署这件事的难度不在单个技术点上，而在怎么把几十个环节串成一条可靠的链路。单模型服务用 FastAPI 能跑，大模型用 vLLM 能跑，但真正让业务方放心使用、让团队能长期维护的，是网关、观测、测试、资源调度这些容易被忽视的周边设施。

我个人更建议团队从单模型服务开始，哪怕慢一点，先把一个模型的部署做扎实，沉淀出可复用的模板和观测指标，再逐步扩展成平台。不要一开始就想搭一个巨大的推理平台，那样大概率会陷入框架的海洋里出不来。先跑通、再优化、最后再做平台化治理，这个顺序几乎不会错。

最后分享一个小技巧：任何模型上线前至少准备好三份东西——一份模型卡（记录模型版本、量化方案、显存占用、延迟指标）、一份回归测试集（能自动跑出质量对比报告）、一份回滚方案（能快速切回旧版本）。这三点看着不起眼，但真到出事的时候，它们能救整个团队于水火。