企业官网建设流程全解析

1. 从单模型服务到推理平台：整体设计的底层逻辑

1.1 单模型服务的边界在哪

聊模型部署，很多人第一反应是“写个接口把模型包起来，往外一发就完事”。这个思路在实验环境、小规模demo里确实没问题，我自己早期做项目也是这么干的：训练好一个模型，转成可推理的格式，用FastAPI包一层HTTP接口，再丢进Docker容器里，然后交给运维去跑。这套流程放在三五年以前，几乎是标准答案，YOLOv5一类的目标检测模型尤其适合这么玩，文件结构干净、推理链路固定、并发模型简单直接。

但真正到了正式环境，单模型服务的短板会暴露得很快。第一个问题就是模型和业务的耦合：每次升级模型版本要重新构建镜像、重新发布服务，中间还要协调数据回流、效果回归、AB测试一堆事情，发布一次模型像做一次外科手术。第二个问题是资源利用率，单模型服务为了扛住峰值，往往要给每个模型预留独立的显存、CPU和内存，结果就是一台8卡机器上只跑一个模型，剩余算力全部闲置。第三个问题是多模型场景根本管不过来，业务方今天要目标检测，明天要OCR，后天要接一个大语言模型做知识库问答，如果每个模型都各自为战，运维成本直接翻倍。

我见过很多团队走到这一步以后，开始认真思考一个问题：模型部署的本质到底是什么？答案其实就一句话，把模型的推理能力作为一种可靠、可观测、可按需供给的服务提供给上层业务。理解了这个底层逻辑，再回头看“从单模型服务到LLM推理平台”这条路径，就非常顺理成章了。

1.2 平台化的核心驱动力

单模型服务往推理平台演进，背后有几个非常实在的驱动力，不是赶时髦，是被问题推着走的。

第一是GPU调度需求。正式环境下显卡是稀缺资源，单模型服务往往绑死在某张卡上，碎片化极其严重。平台化的思路是引入一个推理调度层，把模型按显存需求打散到不同的GPU上，甚至同一张卡上共存多个小模型，显著提升资源利用率。我在实践中见过极端案例，把四个小模型塞进同一张24G显卡后，整体吞吐反而比原来四台单模型服务更高，因为显存和算力都吃满了。

第二是可观测性需求。单模型时代出了问题基本靠看日志，模型服务是黑盒，推理延迟高了、显存溢出了、请求堆积了，往往要等业务方投诉才发现。平台化以后，每个模型、每次请求的耗时、Token消耗、排队长度、GPU利用率都要有指标。没有这些数据，调优和排障都无从下手。

第三是统一的模型接入与治理。平台化的核心收益之一，是把“模型”变成一种可以注册、发布、下线、回滚的资源。模型网关、推理平台、路由策略这些概念，本质上都是在做同一件事：把模型生命周期和业务请求生命周期解耦。

另外还有一个容易被忽略的点，就是多模型混排和LLM引入后的复杂性。大语言模型和传统视觉模型在推理特征上差异很大，传统模型讲究低延迟高吞吐，LLM讲究长上下文、流式输出和显存管理，把这些统一到一个平台里管理，比分别维护两套系统要健康得多。

1.3 方案选型的通用评估框架

部署框架选型，我建议不要一上来就看哪个工具最火，而是先想清楚自己的阶段和约束条件。我自己的经验是看四个维度。

第一个维度是规模：模型数量在个位数、日均请求几千次，那完全没必要上重型平台，一套轻量调度方案就够了，甚至单模型服务加网关也行。第二个维度是团队能力：如果团队没有专职的平台开发人员，引入K8s加定制化推理平台，反而会被运维复杂度拖垮。第三个维度是延迟要求：实时推理和离线批量对平台的要求完全不同，前者需要完善的排队和超时控制，后者更看重吞吐。第四个维度是生态兼容性：选的推理框架能不能跑你手上的模型格式，PyTorch、ONNX、TensorRT、GGUF各有各的适用范围，强行迁移格式可能引入精度损失和性能回退。

举一个很直白的类比：部署方案选型跟装修选材一样，大理石台面好看但未必适合你家厨房的使用习惯。模型部署也是，没有银弹，只有匹不匹配。后续章节我会分别拆解单模型服务和LLM推理平台的具体搭建过程，正好对应从“简单”到“复杂”的两种典型路径。

2. 单模型服务深度拆解：以视觉模型生产部署为例

2.1 模型格式与服务框架选型

单模型服务虽然听起来简单，但里面每一步都有讲究。先说模型格式选型，以视觉模型为例，PyTorch训练出来的模型在推理阶段性能往往不是最优，因为PyTorch的动态图机制、算子分发开销都偏重。正式环境我一般建议走两步：先把PyTorch模型导出成ONNX，再做TensorRT加速（如果用的是NVIDIA显卡）。前者保证框架中立和跨平台可移植性，后者在推理延迟上能压出非常可观的空间。

这一步在实践中经常翻车，主要翻在算子兼容性。我的建议是导出时固定好Opset版本，不要盲目最新，同时把动态维度控制在一个范围内。ONNX的灵活性其实是一把双刃剑，动态维度越多，后续TensorRT构建引擎的耗时和显存占用就越不可控。我自己习惯的做法是，训练阶段就设计好固定的输入尺寸或少量候选尺寸，导出和加速阶段会省掉大量调参时间。

服务框架层面，FastAPI是目前的主流选择，异步支持好、类型校验成熟、文档自动生成，社区里跟推理框架的集成案例最多。但要注意，FastAPI本身只解决HTTP层，真正承载模型推理的还依赖推理引擎，比如ONNX Runtime和TensorRT。我见过不少人把两者混为一谈，接口写得飞起，结果推理引擎没有配置好线程池，并发一上来就崩。这里有个务实建议：FastAPI负责请求解析和结果封装，模型推理部分单独做成一个推理Worker池，避免I/O阻塞和GPU争抢互相影响。实际操作上，可以用Python的concurrent.futures或更重的Celery方案，前者适合单机场景，后者适合跨机场景。

2.2 服务封装中的参数与边界条件

模型服务上线前，有四个参数我建议必须测试和显式配置：请求超时时间、最大并发数、批处理大小、显存预留上限。不配置这些，等同于让服务裸奔。

请求超时这个参数，很多团队默认交给网关兜底，服务本身不设限，结果就是上游请求堆积，模型推理队列越来越长，最终雪崩。深度学习的推理时间不是匀速的，输入尺寸、内容复杂程度都会影响耗时，一定要统计P95和P99延迟后再定超时值，不要拍脑袋。最大并发数要结合推理引擎的线程机制来定，盲目调高并发不仅不会加速，反而会因为线程切换、显存排队把延迟拖垮。批处理方面，如果后端是TensorRT，动态shape加动态batch是常规操作，但batch大小需要反复压测，找到吞吐和延迟的平衡点。

边界条件上有个经典坑：显存预留。特别是多个模型共享一张卡的时候，CUDA的显存分配策略并不是立刻把所有显存占满，TensorRT引擎默认也会做显存池管理，但如果每个服务都认为自己可以独占20G，几个一叠加就要OOM。我自己的做法是在容器层面用环境变量限制CUDA可见显存，再在推理引擎里配置合理的显存池上限，双保险。顺带提一句，树莓派5这类边缘设备上部署YOLOv5模型，核心思路完全一致，只不过把GPU替换成了CPU或NPU，量化精度和线程数这两个参数的重要性会急剧上升。

2.3 从API到极简可视化的一个务实方案

很多做模型部署的人会忽略可视化需求，觉得“服务能通就行”。但业务方不这么想，他们需要一个界面去验证模型效果，你给他一个裸API，他根本不知道怎么用。解决方式其实不复杂，不需要去搞复杂的前端工程，直接用Gradio或者Streamlit包一层，十分钟就能把目标检测的识别结果画框展示出来。

对于纯API场景，我推荐用一个轻量方案做可视化：把模型服务回传的标注结果JSON直接喂给一个极简Web页面，用Canvas或者现成组件画框。Gradio的detection组件天然支持框选可视化，接入难度几乎为零。做这一步的时候，我建议把可视化和正式推理接口分开部署，可视化页面试验环境用，不要跟线上推理服务抢占资源。如果预算允许，还可以加一层简单的截图对比存储，把可视化结果留档，方便做回归评测。这套组合下来，虽然称不上“平台”，但已经比纯API的交付形态完整很多，也足够支撑阶段性业务验证。

3. LLM推理平台的搭建：Ollama、GGUF与vLLM是怎么混用的

3.1 Ollama本地部署GGUF模型的操作链路

LLM的部署跟传统模型完全不是一回事，最大的差异在模型存储格式和推理时的显存管理。以社区最流行的组合为例：Ollama加GGUF格式。GGUF是llama.cpp生态的模型格式，最大的优势是把模型权重、分词器、超参数全部打包进一个文件里，配上极致的量化支持，一个7B模型量化到Q4_K_M之后，体积能从14G压到4G出头，消费级显卡也能跑得动。

用Ollama部署本地模型的流程，网上教程很多，但有几个要点值得反复强调。第一是模型选择，建议先用Qwen 1.5 0.5B这种小模型跑通全过程，再上大模型，链路熟了以后排障效率高很多。第二是Ollama的模型存储目录默认在用户目录下，正式环境一定要迁移到数据盘，不然系统盘被模型文件塞满的事情我见过不止一次。第三是Ollama默认不暴露到外部网络，需要配置环境变量关闭绑定回环地址的限制，同时一定要加反向代理做鉴权，因为Ollama自带的API是没有认证能力的。第四，如果想在Windows上用Docker部署Ollama，要注意Windows容器和Linux容器的差异，建议直接跑Linux容器，WSL2后端是主力方案，性能和兼容性都最稳。

Docker部署Ollama这件事，我多说两句。官方镜像本身是很干净的，但容器化的真正价值在于环境隔离和快速迁移。一个有效的实践是给Ollama容器挂载独立的数据卷，模型文件持久化到宿主机，之后升级或迁移容器几秒钟就能完成。GPU直通需要配置runtime参数，容器里要能看到nvidia-smi输出才算配置成功。这套东西跟传统模型部署的容器化逻辑一脉相承，只是模型体积更大、显存需求更复杂。

3.2 vLLM生产部署与关键优化开关

如果Ollama适合轻量场景和开发调试，那vLLM就是正式环境高并发LLM推理的更主流选择。vLLM的核心是PagedAttention，它把KV Cache拆成小块按需调度，显存利用率比传统方式高出一大截。官方给的吞吐数据我不建议照搬，因为跟模型大小、卡型、并发模式都有关系，但方向是一致的：同样的显存能服务的并发请求数更多，单Token成本更低。

vLLM的部署门槛比Ollama高，但用Docker跑其实也不复杂。需要重点配置的参数有这么几个：tensor-parallel-size用于多卡并行，max-model-len控制上下文长度，gpu-memory-utilization决定显存利用率上限，max-num-seqs限制并发序列数。我这里有一个经验值供参考：A100 40G跑7B模型时，我习惯把gpu-memory-utilization设为0.9，max-num-seqs设为256，max-model-len根据业务场景在4K和8K之间取舍。上下文越长，KV Cache占用越大，实际能并发的请求数就越少，这是一组直接相关的权衡。生产环境千万别在上下文长度上贪大，很多业务场景4K足够，盲目拉到32K只会让并发能力骤降。

还有一个容易忽略的点，是vLLM和Embedding模型的配合。知识库问答类服务通常是两段式：先用Embedding模型把用户问题向量化，再通过向量检索找到相关内容，最后把上下文拼给LLM。这个链路里，Embedding模型单独部署一套服务，不要占用LLM的显存和推理资源。我见过把Embedding模型塞进同一个容器里的做法，短期没出问题，流量一上来，LLM和Embedding的显存互相争抢，延迟直接崩掉。

3.3 Token的认知与上下文管理

聊LLM部署就不能绕开Token。热搜词里有一句特别到位的话：“Token的三个点是Key我是谁、Query我在找什么、Value我能提供什么”，这是从Attention机制本质去理解Token。部署平台层面的Token管理，核心其实是三件事：Token统计、上下文长度预算、计费与流控。

Token统计在网关层面做，每次请求的输入输出Token数都要记录，尤其是按量计费给业务方结算时，这个数据必须准确。上下文长度预算则要在服务层控制好，最常见的坑是用户多轮对话产生的历史消息无限累加，直接把上下文撑爆，或者超过max-model-len导致请求报错。务实做法是在业务侧做一个滑动窗口裁剪，只保留最近几轮对话，或者做摘要压缩历史。

流控层面，可以按Token数而不是请求数来做限流，因为不同请求的Token消耗差十倍都不止。基于Token的流控才能真正保护后端推理引擎，这也是LLM网关相对传统API网关最大的差异点之一。设计限流算法时，Token消耗的预估可以取输入Token加最大输出Token的保守值，宁可多限一些，也不要让某个超大请求把整个服务的KV Cache击穿。

3.4 部署模型后的可视化需求怎么解决

“Ollama部署模型后如何可视化”这个问题，几乎每天都能在各个社区刷到。训练或者部署完一个模型，如果只能看到一个终端黑框，确实没有实感。解决可视化需求，目前最主流的是Open WebUI，它可以直接对接Ollama后端，也可以对接支持OpenAI兼容接口的vLLM服务。界面能做多轮对话、参数调节、知识库上传，还自带用户管理，作为LLM平台的早期形态完全够用。

接入Open WebUI之后，建议顺手把两件事做了。第一是配置好模型间的切换能力，Open WebUI支持一个界面对接多个模型后端，用户侧下拉框就能切换，这正好呼应了后面要讲的“多模型路由”需求。第二是贴一个反向代理在前面，SSL终态和基本的访问控制都放在这层，不要裸奔。Open WebUI本身是Nodejs加Python的混合体系，用Docker容器部署最省事，跟Ollama或vLLM挂同一个Docker网络里，内网IP互通即可。

对于“本地部署视频模型”这类需求，可视化形态会有差异，比如视频理解模型需要展示抽帧结果和时间戳对齐，但底层思路一致：推理服务输出结构化的结果，UI层负责呈现。先保证结构和结果稳定，再谈可视化。

4. 平台化进阶：LLM网关、多模型路由与正式环境治理

4.1 为什么需要LLM网关

当一个平台里同时存在多个模型服务，比如一个目标检测模型、一个OCR模型、一个Embedding模型、两个不同参数的LLM，问题就来了：上层业务该调谁？模型地址变了怎么办？不同模型的接口协议不统一怎么办？这些问题的答案，就是LLM网关。

LLM网关本质上是一个入口层的代理，负责统一接收请求，按路由规则分发到具体的模型服务，再聚合返回结果。你可以把它理解为电话总机，用户只记住总机号码，至于电话转给哪个分机，用户不需要关心。网关解决的不仅是地址管理问题，还包括鉴权、限流、超时控制、日志记录、Token统计、灰度发布。这些能力里，灰度发布是我认为最容易被低估的一项：新模型上线前先在网关层面切1%流量做效果验证，没有问题再逐步放大，这比传统的模型版本直接替换要安全太多。

网关选型上，轻度场景用Nginx做路径转发就够了，模型服务按路径区分，比如/llm/qwen和/llm/chatglm分别指向不同的上游。但要实现动态路由和灰度，就必须引入配置中心或独立网关组件。我建议根据团队规模来决定，不要一上来就上全家桶，先把核心的鉴权、限流、日志做扎实，后面的能力按需补齐。

4.2 多模型切换与路由策略设计

多模型切换在LLM场景里越来越常见，以“autoglm-phone模型切换”这类需求为例，同一个推理平台可能要支持不同尺寸的视觉语言模型VLM，适配不同精度的任务。这时候路由策略就不能只做静态路径映射了，要考虑按请求内容、成本预算、用户等级做动态选择。

简单的路由策略有两类：固定映射和加权轮询。固定映射适合按用户维度隔离，比如付费用户走大模型，免费用户走小模型。加权轮询适合成本优化，比如8成流量走便宜的7B模型，2成走高精度的72B模型，在总成本不变的情况下提升整体效果。如果进一步做语义路由，让网关预判请求的复杂度再分发给不同模型，那就已经进入比较专业的LLM网关配置范畴了，需要多看社区成熟的实践方案。

路由还要兼顾模型服务本身的健康状态。网关必须配置主动健康检查，定期探测后端服务的/health接口，如果某个模型服务实例挂掉，网关要能自动把流量切换到其他实例或降级策略。这个能力在传统模型部署里没有，但在LLM平台里是刚需，因为LLM推理服务显存波动、OOM、长时间无响应的情况远比传统模型频繁。

4.3 生产环境的资源调度与高可用

正式环境部署LLM平台，资源调度是绕不开的坎。GPU是共享资源，一个平台里同时有多个模型的场景，必须要有调度策略。轻量做法是手动绑定模型到某张卡，再在网关层面做流量分配；重型做法是引入K8s加GPU调度插件，让模型按需扩容缩容。

我这里给一个中间态方案，适用于大多数中小团队：每张卡上常驻一个模型，模型实例个数固定，但用显存资源限额约束每个实例的显存使用上限，再通过网关的统一入口做流控和容错。这个方案的优点是实施快、依赖少、稳定性高；缺点是弹性不足，峰值流量只能靠限流扛，无法自动扩容。当业务增长到明确出现等位、排队问题时，再考虑引入弹性调度，一上来就搞K8s，往往得不偿失。

高可用层面，有经验的部署工程师会把“优雅退出”放在和“快速启动”同等重要的位置。模型服务收到终止信号时，要停止接收新请求，把正在处理的请求执行完，再释放显存资源退出。没有优雅退出的服务，每次发布升级都会打断在线推理，业务方体验会非常差。实现方式是用捕获SIGTERM信号，配合网关摘除节点流量，这套流程做顺了之后，模型升级可以做到请求零中断。

5. 常见问题与排查技巧实录

5.1 部署与资源类问题

模型加载慢是部署期最常见的问题。LLM的权重文件动辄好几个G，加载一次可能耗时几十秒。处理思路有两条：一是启动时做模型预热，专门发一个健康请求让模型完成权重加载和编译优化，再开放流量；二是把模型文件放到SSD或内存缓存盘上，机械盘的I/O瓶颈会显著拖慢启动速度。

显存OOM则是运行期最致命的故障之一。我踩过的典型场景是：vLLM集群正常运行几天后突然大量报错，查了一圈发现是某一次请求的上下文长度特别长，把KV Cache打爆了。排查思路是分三层确认：先看网关层有没有限制max-model-len，再看模型服务层的gpu-memory-utilization设置是否留了余量，最后看监控指标里的显存水位是否已经长期超过80%。如果是，必须立刻扩容或降并发。

还有一个常被忽视的是CPU和内存的资源争抢。GPU没有打满不代表机器健康，数据预处理、Tokenization、路由转发都可能成为瓶颈。排查的时候不要只看GPU利用率，要看整机的CPU、内存、网络I/O，全部拉平看才能定位真正的瓶颈。

5.2 推理效果与调用链问题

“llm request failed: provider rejected the request schema or tool payload”这类错误是LLM应用接入期的常客，字面意思是模型服务拒绝了请求的Schema或工具调用参数。这个问题的根因通常在请求构造侧，比如调用了模型不支持的Function Call参数格式，或者某些字段的类型、命名不符合协议规范。排查方法很朴素：把请求体原样保存下来，和模型服务要求的Schema做对比，肉眼比一遍，或者用契约测试工具自动比对。

效果类问题同样常见，典型症状是“模型回答变傻了”。很多人第一反应是模型有问题，但排查下来大概率落在链路里：知识库检索回来的上下文不相关，或者Token裁剪把关键信息剪掉了。处理手段是链路追踪，给每个请求分配一个Trace ID，从网关到检索到模型到响应全链路打日志，逐跳确认“上游传下去的数据”和“实际推理用的数据”是否一致。这里我再提供一个实战判断方法：把同一段Prompt直接手工发给模型服务，如果结果正常，问题出在上游；如果结果异常，问题在模型服务或Prompt本身。

5.3 可落地的排查工具与方法

LLM平台的排障工具有三层：日志、指标、追踪。日志负责“发生了什么”，指标负责“系统状态如何”，追踪负责“一次请求经历了什么”。如果预算紧张，优先把日志和指标做好，追踪可以后面再补。

日志层面，要统一日志格式，至少包含时间戳、请求ID、模型名称、延迟、Token用量、状态码和错误详情。指标层面，Prometheus加Grafana是社区最主流的组合，必看的指标有QPS、P50/P95/P99延迟、Token吞吐、GPU利用率、显存水位、排队长度。告警规则上，我建议重点盯P99延迟超阈值和显存水位持续高企，这两项是模型服务故障的先兆。

关于“RAG GraphRAG LLM Wiki 本体RAG”这类偏知识库的场景，部署完成后一定要做一轮检索效果评测，不要只看“能回答”。具体做法是准备一批标准问题集，人工标注期望答案，然后逐一请求服务，记录检索召回率和答案准确率。这套评测数据积累下来，后续模型升级、路由调优、知识库调整都有参照，比凭空猜测效果变化要靠谱得多。我做过的项目里，只要坚持了这个评测流程，几乎都能在两周内把RAG链路调到稳定可用的状态。

我最后再分享一个小技巧，排查LLM平台问题时，一定要先把“模型服务本身”和“周边链路”割裂开。用测试脚本直接压模型服务的裸API，确认模型本身稳定，再去查网关、查上游应用。很多团队花了一整天排查网关配置，最后发现是上游传参少了一个字段。先隔离，再定位，排障效率至少翻倍。