这些年我部署过的模型从最早的 TensorFlow Serving、TorchServe到后来的 Triton再到这两年彻底转向 LLM 推理平台最大的感受是模型部署这件事在 LLM 时代被彻底重写了。以前部署一个 ResNet 或者 Bert核心工作是倒腾 API 封装和流量转发现在部署一个大语言模型你要面对的是显存碎片、动态 batch、上下文窗口溢出、吞吐和延迟的博弈甚至还有一套独立的评测体系和网关治理。标题里那句从单模型服务到 LLM 推理平台我理解不是一句口号而是一条真实的技术升级路径。这篇文章我就把自己在这条路上反复踩过坑、也沉淀下来的框架性认知完整写下来内容覆盖单模型服务的选型、vLLM/Triton/Ollama 这类推理引擎的差异、容器化 GPU 环境的配置、OpenAI 兼容网关的设计以及部署之后的评测和治理。不管你是刚在树莓派上把 YOLOv5 跑起来的小白还是在公司里负责大模型落地的后端工程师这篇文章的框架都能帮你把部署这件事从零散的实操整理成一套可以复制的方法论。我会把每一步的为什么讲清楚也会把那些文档里不会写的细节暴露给你。1. 单模型服务与 LLM 推理平台差的不只是规模1.1 从一次部署到一个产品很多人第一次接触模型部署都会从把模型跑起来开始。你用 Docker 把镜像 build 好显卡驱动装好python app.py一敲模型 load 进来一个 HTTP 端口对外提供服务这就算部署完了。这种做法在单模型、单副本、内部使用的场景下完全没问题我自己也经常这么干尤其是调试阶段一个 FastAPI 包一个模型再配合 Postman 或者 Apifox 就能把联调做完。但一旦进入正式环境问题就全来了。请求量上来之后单副本的吞吐扛不住模型升级了你想灰度结果发现没有第二套环境一个接口被多个业务方使用有的要流式输出有的要 JSON mode有的要求 4000 token 上下文你不得不在网关层做各种策略。更现实的是一个模型 service 不够用了团队开始部署第二个、第三个模型每个模型都有自己的端口、自己的镜像、自己的监控运维成本直线上升。这时候你才意识到单模型服务解决的是模型能跑推理平台解决的是模型能稳定地批量对外服务。我的判断标准很简单如果你的模型只有一两个下游调用方单模型服务就够了当调用方超过五个或者模型数量超过三个或者你开始关心 QPS、P95 延迟、显存利用率这些指标时就必须上平台化设计。这不是规模升级是架构范式的切换。1.2 推理平台要解决的三个核心问题所谓 LLM 推理平台我个人的定义是以一组推理引擎为底座配合网关、调度、观测、评测组件对外提供统一模型服务能力的基础设施。它要解决的核心问题有三个这三个问题也是单模型服务阶段最容易忽略的。第一个是资源调度。单模型部署时一个模型独占整张卡很常见但到了平台阶段你会发现一张 80G 的 A100 只跑一个 7B 模型显存利用率其实不到一半。平台需要根据模型的参数量、量化等级、预估 QPS自动决定把一个模型放几卡、几个副本这个计算可以手工做也可以交给调度器。实操中我一般用下面这个公式粗估显存需求模型权重占用按参数量乘以精度字节数算比如 7B FP16 是 14GBKV cache 按最大并发数和上下文长度再预留 20% 到 30% 的余量。第二个是请求治理。包括限流、鉴权、优先级队列、超时控制。没有网关统一接管的推理集群每个模型服务自己处理这些东西代码大量重复不说行为还不一致。同一个 token 配额在不同服务里可能算法都不一样这种不一致在排障时非常痛苦。第三个是可观测性。你要能回答三个问题现在哪些模型在跑每个模型当前的吞吐和延迟是多少最近一次模型更新之后效果有没有回退。单模型服务靠打印日志和看 Docker stats 勉强能撑平台层面必须引入指标采集和链路追踪。后面我会展开讲这块具体怎么做。1.3 什么时候该升级到平台我见过不少团队在只有一个模型、几十个请求的规模下就兴师动众搭了一整套 Kubernetes KubeFlow 推理平台的方案结果三个月了平台还没跑起来模型一直是开发机在顶着。说实话这属于过度设计。反过来我也见过业务量已经上来了还在用脚本nohup python app.py起模型的团队每次发版都全靠人肉运维这是另一个极端。我个人的经验是触发平台化改造的信号一般有这几个模型数量到 3 个以上单模型服务已经做过一次灰度发布并且过程很痛苦或者老板开始问我们模型的 QPS 上限是多少而你答不上来。这些信号出现任意两个就应该认真考虑平台化。至于用什么来搭不一定非得是千帆、阿里云 PAI 这类商业平台自建基于 vLLM 网关 监控的轻量方案也完全可以重点是想清楚边界。2. 单模型服务落地框架选型与容器环境2.1 推理引擎三选一Ollama、vLLM、Triton模型部署框架的核心是推理引擎。这个领域现在三足鼎立各自定位不同我按使用场景分一下方便你选型。Ollama主打的是本地开发和个人使用它把模型拉取、下载、运行、命令行交互整合得非常顺滑。你一条ollama run qwen2.5:7b就能把模型跑起来默认还带 OpenAI 兼容的 HTTP 接口配合 Docker Desktop 在 Windows 和 macOS 上都能跑。但它的问题也很明显调度策略、并发控制能力比较弱对多卡、多副本集群场景支持有限生产环境想精细控制吞吐和显存不太容易。如果你是在个人电脑上做原型验证或者给团队搭一个内部试用环境Ollama 非常合适如果你要面对线上流量我会谨慎推荐。vLLM是目前自建 LLM 推理服务的主流选择。它的核心优势是 PagedAttention 和 Continuous Batching这两个技术直接把推理吞吐拉高了一个量级后面我会单独解释。vLLM 对 HuggingFace 模型格式支持很到位Qwen、DeepSeek 这些主流开源模型基本开箱即用启动一个 OpenAI 兼容服务只需要一行命令。它的问题是依赖管理较重需要 Python 环境和 CUDA 环境匹配对新人来说第一次装 vLLM 可能会被各种依赖报错劝退。Triton Inference Server是老牌工业级方案NVIDIA 出品支持模型类型极多不光 LLMCV、推荐、传统 ML 模型都能统一管动态 batch、模型集成、并发模型加载都是它的强项。但它的学习曲线陡配置复杂LLM 场景需要配合 TensorRT-LLM 后端来用性能和灵活性最好成本也最高。我的经验总结如下个人实验用 Ollama中小团队自建 LLM 服务用 vLLM如果公司已经有 NVIDIA 全家桶生态或者需要多模型异构管理再考虑 Triton。2.2 模型格式GGUF 与 safetensors 的选择逻辑刚开始部署 LLM 的时候最容易被绕进去的就是模型格式问题。同一个模型在网上能找到 GGUF、GPTQ、AWQ、safetensors 等各种版本到底下载哪个取决于你的推理引擎和硬件。这是一个框架决定格式的强绑定关系。GGUF 是 llama.cpp 生态带火的格式它把模型权重和 tokenizer 元数据打包成一个文件设计目标就是能在 CPU、Apple Silicon、低显存显卡上高效运行配合 Ollama、llama.cpp 这类加载器效果很好。如果你用的是 Ollamaollama run qwen2.5:7b背后下载的就是 GGUF 格式不需要自己操心。safetensors 是 HuggingFace 主推的安全格式设计上避免了 pickel 反序列化的安全风险。vLLM、Transformers、TensorRT-LLM 都原生支持。如果你走 vLLM 路线默认下载的模型就是这个格式。在量化兼容性上GGUF 主要面向 CPU/轻量场景GPTQ 和 AWQ 更针对 GPU 推理优化而 vLLM 对 AWQ 和 GPTQ 的支持非常成熟实测下来 AWQ 在保住大部分精度的同时能让显存占用降一大截。实操建议就一条先定引擎再选格式。不要因为看到某个模型只有 GGUF 版就强行换成 llama.cpp 路线也不要为了用 vLLM非把一个 GGUF 文件转来转去。在自己没把握的时候优先选 vLLM safetensors AWQ 量化这条路径踩坑最少。2.3 容器与 GPU 环境CUDA、驱动与 Docker 的组合坑不管选什么框架最终落到正式环境大概率打包成容器。而 GPU 容器这块坑全集中在 CUDA 和驱动版本的匹配上。我在 Windows 上部署 Ollama 时其实还好因为它自带 runtime但一到 Linux 用 Docker 跑 vLLM各种兼容问题就出来了。先理清基本概念Python 层看到的 CUDA 是 PyTorch/CUDA toolkit 自带的镜像里的 CUDA 是你pip install torch时编译所依赖的 CUDA 版本宿主机驱动层的 CUDA Driver 是独立存在的。两者必须兼容但不是简单相等。NVIDIA 官方的原则是容器内的 CUDA 版本不能高于宿主机驱动的最大支持版本。比如你的驱动是 535.104它支持的最高 CUDA 是 12.2那你容器里装 CUDA 12.1 没问题装 13.x 就会报CUDA driver version is insufficient。所以部署时我建议按这个顺序检查先nvidia-smi看驱动版本和显存占用再决定容器镜像里选哪个 CUDA 基础镜像。vLLM 官方镜像一般已经有默认版本直接 pull 然后跑docker run --gpus all即可但如果你的驱动太旧就得选老版本的 vLLM 镜像。另外一个容易翻车的细节是--ipchostvLLM 和 PyTorch 的 DataLoader 都会用到共享内存不加这个参数你十有八九会碰到OutOfMemoryError发生在 shared memory 层面的诡异报错。3_ : 单 say菜单。容器的退出、日志采集、健康检查探针这些都是平台化之后容器编排层要解决的问题。无论如何不要在宿主机上裸跑推理进程哪怕现在是单模型服务也要先习惯容器化的思维这会让你后续迁移平台时省掉大量重构成本。3. 从单模型到平台网关、并发与可视化3.1 推理网关为什么需要一个统一入口单模型服务阶段每个模型各开各的端口调用方直接拼 IP 和端口去访问这在早期完全可行。但模型多了之后调用方需要知道每个模型的地址、鉴权方式、限流规则这会产生两方面的负担调用方集成成本陡增服务方的变更影响面被无限放大。我见过最混乱的现场是一个 7B 模型因为显存问题从 GPU1 挪到 GPU2IP 变了结果下游三个业务组的配置全要跟着改改漏一个就接口报错。推理网关的意义就在于把模型地址和模型逻辑名解耦。调用方只认识一个固定的网关地址和类似/v1/chat/completions这样的统一接口网关内部再做路由、鉴权、限流、负载均衡。实现这个需求行业里可以直接用 Kong、APISIX 这类通用 API 网关加自定义插件也可以用一个轻量的 LLM 网关框架或者干脆自己在 FastAPI/Spring Cloud Gateway 里写路由逻辑。我个人在自建平台里用的是 APISIX配合它的服务发现能力把 vLLM 的多个副本自动挂到同一个 upstream 下实现最基础的负载均衡。网关层还承担一个关键职责安全与配额管理。公司内部多个业务方共用模型服务时总有人会写个定时任务疯狂刷接口如果不按应用维度做限流一个毛糙的调用方就能把整个模型的显存打爆连累其他正常业务。这块在网关层直接拦掉最干净。3.2 连续批处理与 PagedAttention推理平台的性能内核如果你只做单模型推理可能不会太在意推理引擎内部的调度机制但一上平台吞吐就成了核心矛盾这时候就必须理解 vLLM 的两个核心技术Continuous Batching 和 PagedAttention。传统 Batching 的做法是等一个 batch 里所有请求都生成完才统一返回再接收下一批。这有个致命浪费不同请求的 token 生成速度天然有快有慢快的生成了 20 个 token慢的才生成 2 个快的必须等慢的跑完GPU 在等待期间是空闲的。Continuous Batching 的思路是来一个处理一个每步推理后就把已完成请求踢出 batch把新请求加进来。这就把 GPU 的空闲时间压到最低吞吐自然大幅上涨。实测下来同一个模型、同样的硬件vLLM 的吞吐可以比 naive 实现高 3 到 5 倍这个数字一点都不夸张。PagedAttention 解决的则是 KV Cache 的显存碎片问题。推理时每生成一个 token都要把历史的 Key 和 Value 缓存存在显存里这些缓存大小和请求的上下文长度强相关。传统实现要预先分配一块连续的最大长度显存短请求也占着长空间碎片率很高。PagedAttention 把 KV Cache 分成固定大小的页按需分配类似操作系统虚拟内存的分页机制显存利用率显著提升。简单说它允许你在显存完全打满的情况下也能排队处理更多请求。理解了这两个机制你就知道为什么选型时我特别看重推理引擎对 Continuous Batching 的支持程度这是平台吞吐的天花板。3.3 模型部署后的可视化从日志到指标大盘热搜词里有一个是ollama部署模型后如何可视化这个问题我太熟了。部署完成只是第一步业务方肯定会问你的模型服务是不是正常性能怎么样你要是不给点视觉化的东西就只能甩日志截图特别不专业。可视化的层级应该是日志Log - 指标Metrics - 链路Trace - 看板Dashboard。第一步把 FastAPI/vLLM 的访问日志接到 Loki/ELK确保出错能定位到请求。第二步给服务加 Prometheus 指标最核心的四个QPS、P50/P95 延迟、GPU 显存利用率、GPU 利用率。vLLM 本身自带 Prometheus 指标端点直接/metrics拖出来就能用。第三步如果业务链路复杂比如一个请求从网关打到 vLLM还要查知识库再返回到前端最好接入 OpenTelemetry 做链路追踪否则跨服务排查问题会看到上游超时这种没头没尾的报错根本不知道慢在哪个环节。把这些数据集合到 Grafana 上做成一个模型服务总览大盘是我每一套部署的标配。大盘不需要复杂几块核心面板就够了当前活跃模型列表、每个模型的 QPS 和延迟折线、GPU 温度与显存水位、最近一小时的错误码分布。有了这些你就能在业务方找你说模型好像卡了的时候不慌不忙地打开大盘先看显存水位再看 P95 延迟曲线基本几十秒就能定位问题方向。这个能力比你会调多少模型参数更能体现正式环境的成熟度。4. 实操用 vLLM Docker 部署一个 OpenAI 兼容服务4.1 环境准备与 GPU 驱动检查下面我把一套可复用的部署流程完整写出来以手头常见的单卡 24G 显存比如 RTX 3090 / 4090跑一个 7B 模型为例。先看环境准备这步做好后面能省两小时。# 第一步确认驱动和 CUDA 能力 nvidia-smi # 期望输出里 CUDA Version 12.1如果没输出先装驱动 # 第二步拉取 vLLM 官方镜像 # 注意 tag 里的具体版本要和你的驱动支持范围匹配 docker pull vllm/vllm-openai:latest # 第三步启动容器保留交互式 shell 方便调试 docker run -it --rm \ --gpus all \ --ipchost \ -v /root/models:/models \ -p 8000:8000 \ vllm/vllm-openai:latest \ bash这里有几个点值得展开。--gpus all表示让容器看到宿主机全部 GPU如果你要限制容器只用某一张卡通过NVIDIA_VISIBLE_DEVICES0环境变量控制更精细。--ipchost前面提过必须加上不然 PyTorch 的多进程 DataLoader 会在共享内存上翻车报错内容类似Cannot allocate memory但你的内存明明还有大量富余这个错是最迷惑人的一种。模型的权重文件建议放到宿主机统一目录比如/root/models再挂载进容器这样模型版本切换、多容器复用都方便不用每次进容器重新下载。4.2 启动模型服务一条命令背后的参数细节在容器内启动 vLLM 服务一条命令就能起一个 OpenAI 兼容接口# 启动一个 Qwen 7B chat 模型映射到 OpenAI 的 /v1 接口 python -m vllm.entrypoints.openai.api_server \ --model /models/Qwen2.5-7B-Instruct \ --served-model-name qwen7b \ --tensor-parallel-size 1 \ --max-model-len 8192 \ --gpu-memory-utilization 0.85 \ --port 8000参数不难理解但每个都有讲究。--tensor-parallel-size是张量并行度单卡就是 1两张卡可以设 2它会自动把模型切分到多卡。--max-model-len控制最大上下文长度设得越大KV Cache 占的显存越多如果你的业务不需要长上下文建议控制在 4096 或 8192避免白白浪费显存。这里有个公式可以帮你算显存预算总显存 模型权重 KV Cache 激活值。以 7B FP16 为例权重约占 14GB24G 显存下剩 10GBgpu-memory-utilization设为 0.85 就是告诉 vLLM 可以占满 85% 的显存大概 20.4GB剩下 4GB 留给 CUDA context 和临时激活值。启动完成后用 curl 做一个最基础的冒烟测试确认服务可用curl http://localhost:8000/v1/chat/completions \ -H Content-Type: application/json \ -d { model: qwen7b, messages: [{role: user, content: 你好介绍一下你自己}], stream: true }注意请求体里的model字段必须和启动参数--served-model-name一致这个值和路径里的模型目录名无关很多人在这里踩坑调用时报 model not found折腾一圈发现只是名字匹配不上。4.3 下游接入Spring Boot 与 FastAPI 消费 OpenAI 接口服务起来了下游怎么接如果你团队技术栈是 Java用 Spring Boot 接 OpenAI 兼容接口很简单因为 vLLM 完全实现了 OpenAI 的协议规格连chat/completions的路径都一样。HTTP 调用方式如下// 使用 Spring 的 RestTemplate 或 WebClient 均可 String endpoint http://你的vllm网关地址:8000/v1/chat/completions; HttpHeaders headers new HttpHeaders(); headers.setContentType(MediaType.APPLICATION_JSON); // 如果网关做了鉴权在这里带 token headers.setBearerAuth(your-gateway-token); MapString, Object body new HashMap(); body.put(model, qwen7b); body.put(messages, List.of(Map.of(role, user, content, 你好))); body.put(stream, true); // 发起请求并用 SSE 方式流式读取返回流式场景下服务端返回的是text/event-stream不能按普通 JSON 一次性读取。你在 Spring Boot 里要么用 WebFlux 配合FluxString消费 SSE要么直接在网关层把流式聚合好再向外抛。我建议在网关做流式转发用 SSE 直通模式减少 Java 侧的解析工作。Python 侧就更简单了直接用 OpenAI Python SDK配置base_url指向 vLLM 地址就行连api_key随便填个字符串就过因为本地服务不会真正校验。from openai import OpenAI client OpenAI( base_urlhttp://localhost:8000/v1, api_keynot-needed, ) resp client.chat.completions.create( modelqwen7b, messages[{role: user, content: 你好}], ) print(resp.choices[0].message.content)到这里一个单模型服务就跑通全链路了。你会注意到整个过程里除了 vLLM 本身其他组件几乎都不需要为模型做定制这正是 OpenAI 兼容协议的好处它把模型部署的差异全部封装在服务端下游所有语言都可以用一套标准方式接入。这也是为什么我强烈建议不管团队内部怎么封装对外永远暴露 OpenAI 兼容接口。5. 部署之后评测、知识库与 Agent 编排的工程化5.1 模型评测落地为什么需要 DeepEval 这类框架模型部署上线不等于交付你还要回答这个模型的效果到底行不行调了一版 prompt 之后有没有变差。如果没有评测工具团队就很容易陷入凭感觉判断模型好坏的泥潭而这恰恰是 AI 工程里最需要量化的事情。所以我把评测放在部署后阶段来讲因为在实际流程里评测框架通常是在模型服务跑起来之后才被认真对待。DeepEval 是我这两年用得比较多的模型评测框架它专门为大语言模型应用设计支持 LLM 相关断言、单元测试、和 CI/CD 集成。和传统测试框架 pytest 的定位不同DeepEval 的断言不是验证函数返回值而是验证像回答是否包含关键信息答案是否忠实于检索资料这种开放性问题。它内置了一套指标系统包括忠实度、答案相关性、上下文相关性、幻觉检测等底层用 LLM 做裁判来打分。实际用起来核心流程是三步定义数据集、写断言、跑测试。数据是评测的地基你可以收集线上真实请求构造一个 golden 数据集也可以手工构造边界场景比如模型对专业名词的解释对长文本的总结能力。然后在测试用例里写断言比如要求答案中包含特定关键词或者要求忠实度大于 0.8。跑完测试框架会输出一个可读的报告直接接进 CI 流水线。这样一来每次更换模型版本或者调 prompt你都能通过数字看到变化而不是靠感觉好像更强了来决策。5.2 RAG 知识库接入从 LLM Wiki 到 GraphRAG部署 LLM 之后下一步几乎肯定会接知识库。热搜词里llm wiki知识库RAG GraphRAG都是这个方向的高频词。LLM 本身就预训练了很多知识但企业的私有知识它不可能知道RAG检索增强生成就是解决让模型基于企业自己的资料回答问题的主流方案。我画一条最简单的 RAG 链路文档切片 - 向量化 - 存入向量库 - 用户提问时召回 topK - 拼进 prompt - 让 LLM 生成回答。这个链路里最容易出错的是切片策略切片过大召回内容噪音多回答容易跑偏切片过小上下文不完整模型理解不到全局。我的经验是先用固定 token 切一般 500 到 1000 个 token 一块加上 50 到 100 token 的重叠跑一个评测集看效果再针对性地调切片器。向量化的 embedding 模型选择也比较重要中文场景下用 BGE 系列或 M3E 的实测效果普遍比通用 embedding 模型好。GraphRAG 则是把 RAG 从向量相似度升级到知识图谱关系推理。你不仅把文档切成向量还抽取文档里的实体和关系组成图谱查询时既能做向量召回又能做多跳关系查询。这对处理企业管理层名单产品之间的从属关系这种需要多步推理的问题很有效。但 GraphRAG 的构建成本明显高于普通 RAG你需要额外的实体抽取和关系建模流程前期数据量小的时候收益不明显我建议先从普通 RAG 起步等用户反馈出明显需要多跳推理的需求再升级。5.3 Agent 框架编排LLM 应用的最后一环知识库解决的是模型怎么回答领域问题Agent 解决的是模型怎么干活。搜索热词里agent框架与编排eino框架频繁出现这块确实是大模型应用落地的兵家必争之地。一个典型的 Agent 场景是用户说帮我查一下上个月某产品线的报销情况Agent 需要先解析意图判断需要调用财务系统的接口然后生成查询参数、调用接口、把结果整理成自然语言回到用户。编排层面现在主流有两种思路。一种是用 LangChain / LlamaIndex 这类通用编排框架它们提供了大量工具集成的现成组件抽象层次高上手快缺点是抽象太厚出了问题你不好定位性能也没有极致优化。另一种是直接用代码编排把工具调用、LLM 调用写成普通异步流程再用一个状态机或者简单的 while 循环控制多步对话。我个人在实际生产中对 LangChain 这类框架的态度是谨慎使用因为 LLM 应用的核心逻辑往往不强真正复杂的是业务系统对接这恰好是通用框架帮不了你的地方。生产环境我更建议自己写 Agent loop把每一步的输入输出都清晰地打进日志排障体验会好很多。这里还必然会遇到一个热词里提到的问题llm request failed: provider rejected the request schema or tool payload。这个报错我在接入各种工具调用时见过不下五次。原因基本都是模型版本对 function calling / tool calling 的支持不完整或者你传给它的 tools 参数格式不符合模型微调的预期。排查时先确认模型是否原生支持 OpenAI 格式的 tools再确认工具的 JSON Schema 里有没有用上 model 不支持的 type比如anyOf、$ref最后确认你的模型温度参数是否在工具调用场景下被设得太高。一个小经验是工具调用的 temperature 建议设 0 或接近 0让模型严格输出结构化结果。6. 正式环境排障速查我的问题库与你共享最后把我在正式环境里反复遇到的几类问题整理成一个速查表这些问题在单模型服务和平台化阶段都很典型建议直接收藏现象直接原因排查思路调用时报CUDA driver version is insufficient容器内 CUDA 版本高于驱动支持上限先看nvidia-smi里的 CUDA 版本再选低版本的基础镜像请求都通但吞吐很低没开启连续批处理或并发度太低确认用 vLLM/Triton而不是 naive 的逐请求处理调整--max-num-seqs提升并发窗口显存占用一直很高OOM 偶发KV Cache 配置过大或者并发无上限调低--gpu-memory-utilization或--max-model-len在网关做 QPS 限流流式请求偶发断连客户端超时时间太短或网关缓冲过小确认网关 SSE 超时可配置建议 5 分钟以上客户端设置 read timeout上下文越长回答越差长文本场景下模型精度衰减使用支持长上下文的版本或做摘要预处理开启rope_scaling时注意精度损失工具调用报 schema rejectedtools 参数格式与模型不兼容简化 JSON Schema避开anyOf/$reftemperature 设 0确认模型支持 function calling容器内报 shared memory 不足没加--ipchost运行容器时务必加--ipchost或设置大共享内存网关转发后延迟陡增网关做了不必要的 JSON 重解析或缓冲流式接口在网关层走 SSE 直通不聚合、不重封装除了表里的内容还有两个偏软性但很重要的经验。第一个是每次改动模型或 prompt都要跑一遍固定评测集哪怕你只改了一个 prompt 模板都可能让模型在特定问题上的行为发生剧烈变化这种回归用 DeepEval 在 CI 里跑最靠谱。第二个是在正式环境压测时不要只测 QPS还要测长尾延迟LLM 推理服务的 P95 延迟很容易和 P50 拉开一个数量级如果你只优化平均延迟线上用户仍会感受到明显的卡顿。我的习惯是把 P95 延迟和显存水位这两个指标贯穿在所有操作决策里。最后一个非常容易踩的坑发生在多人协作场景。模型存储在共享目录时A 同事为了省显存把某个模型换成了量化版本但文件名没变。B 同事重新部署时加载的是新的量化权重却以为还是原来的精度最后线上效果下降怎么都查不出来。模型文件必须做版本管理文件名或目录名带版本标识是最低要求有条件的话在模型元数据里记一个 md5 值启动脚本里自动校验这个成本极低避免的麻烦却很大。我只能说模型的部署框架这个话题单靠一篇文章其实讲不完而且这个领域还在快速演进。今天主流的 vLLM半年前还是新事物未来可能又会被新的引擎取代。但底层的方法论是稳定的先想清楚自己是需要部署还是平台选型时尊重框架和格式的绑定关系部署时把环境、容器、版本这些基础打牢上线后建立网关、观测、评测三位一体的治理体系。把这套骨架立住不管底层引擎怎么换你的平台都能平滑演进。我自己走过不少弯路希望这些经验能帮你少踩几个坑。