模型部署

想把 vLLM 从单机示例放到 Kubernetes 上运行，难点通常不在启动命令，而在 GPU、模型文件、服务访问和运行状态验证。这篇文章按部署链路拆解可参考的配置思路。

大模型上线不是把容器部署到集群就结束。围绕 LLMOps和Kubernetes 的分工，本文梳理模型从注册、发布、扩缩容到观测回滚的交付链路，让平台团队看清先补哪一段能力。

纠结 KServe 和 vLLM 怎么选时，先别急着做二选一。一个更偏模型服务层，一个更偏推理执行层；读完本文可以用层级、职责和场景矩阵判断它们在平台中的位置。

GPU推理副本数设置容易被 QPS、显存和冷启动同时影响。本篇用单副本显存、并发拐点、GPU调度边界和上线验证流程，帮助团队先定保守初始值，再通过压测和真实流量校准。

把大模型服务搬到 Kubernetes 后，最容易卡在镜像拉取慢、GPU 不可见、模型文件加载和服务暴露上。本篇按资源、镜像、模型和服务四条线梳理上线步骤与检查项。

向量检索服务上线后，问题往往出在索引更新、召回延迟、存储增长和权限边界上。把索引、数据、服务和观测一起设计，才能支撑稳定的 RAG 与语义检索应用。

模型文件越来越多时，团队最先遇到的问题不是存储空间，而是谁能使用、哪个版本可信、能否发布、出了问题能否追溯。模型注册中心把这些信息组织成可管理的生命周期。

模型能不能上线，不能只看一次离线分数。评测流水线需要把样本、指标、版本、业务反馈和发布决策连接起来，让每次模型变化都有可比较、可追溯的依据。

大模型应用上线后，变化的不只是模型文件，提示词、工具调用、知识库、评测集和路由策略都会影响结果。LLMOps 平台要把这些变化纳入可测试、可发布、可回滚的流程。

当模型数量和调用方增加后，直接暴露推理服务会让鉴权、路由、限流和观测分散在各处。AI 推理网关把调用入口统一起来，让多模型服务具备更清晰的治理边界。

在线推理和离线推理都在执行模型，但架构目标完全不同。在线推理关注低延迟、稳定性和弹性，离线推理更看重吞吐、批处理和成本效率。区分两者的资源和治理方式，有助于避免用同一套平台策略处理不同任务。

模型版本管理不只是给文件起编号，而是记录模型从实验、评估、部署到回滚的完整上下文。训练数据、指标结果、镜像配置和发布记录串起来，团队才能解释某个线上版本从哪里来、为什么上线、出了问题如何恢复。

推理服务观测不能只看服务是否存活。延迟、吞吐、错误率、资源水位能反映系统稳定性，输出分布、置信度和关键样本能反映模型结果质量。把两类指标结合起来，才能判断服务是否真正可用。

模型回滚如果只切回旧模型文件，仍可能因为镜像、配置、特征逻辑、路由规则或依赖版本不一致而失败。真正可靠的回滚，需要恢复一组可运行上下文，让模型结果和服务行为同时回到可验证状态。

多模型共用同一平台后，难点会从“能否部署”转向资源隔离、版本边界、路由规则和故障影响范围。提前设计租户、资源池和模型版本关系，可以避免一个模型的流量、显存或配置问题影响整个平台。

模型离线评估通过，不代表上线一定稳定。环境差异、依赖版本、输入输出格式、资源配置和超时策略都会让模型在生产中失败。把这些问题前置检查，可以减少“实验能跑、线上不可用”的发布风险。

模型服务化的关键，不是把推理脚本包成一个接口，而是让模型具备稳定调用、版本管理、流量治理和运行观测能力。把接口、版本和指标设计清楚，模型才能从实验产物变成可持续运维的在线服务。

推理服务延迟升高时，问题可能出在请求路由、批处理窗口、模型冷启动、显存水位或下游依赖，而不一定是模型本身变慢。按链路拆解延迟来源，可以帮助平台团队更快区分是服务容量、资源调度还是模型运行时问题。

评估模型部署平台时，不能只看是否能启动一个推理服务。版本管理、流量路由、资源调度、灰度回滚和观测能力，决定了模型能否持续稳定地进入生产。

新模型上线前，需要先把风险控制在小范围流量中。围绕流量切分、指标对比和回滚预案建立灰度流程，可以避免模型效果和系统稳定性问题在全量发布后才暴露。