K8s大模型部署中，模型能在一个Pod里完成启动和本地调用，只证明了整条链路的中间一段。GPU可能没有以预期资源进入调度，Pod可能依赖某台节点的残留环境，模型制品可能只在本地缓存，Service没有可用Endpoint，网关也可能把流量发往未就绪副本。上线排障要从外部请求向内逐跳验证，也要从GPU节点向外检查，直到两条证据链在同一个模型实例上相遇。

前置条件：已有Kubernetes或K8s基础运维能力，正在处理GPU工作负载与模型服务交付。具体设备、驱动、插件、框架和版本兼容性需在真实环境核验。

模型跑通只证明链路中间一段

常见演示路径是在固定节点启动一个Pod，进入容器直接调用本地端口，得到模型返回。这个结果有价值：镜像、部分运行时、权重和进程至少在当前环境能协作。但它没有证明调度器能在其他节点重复放置，没有证明服务发现与健康检查正确，也没有证明外部身份、网关、证书和网络策略允许真实请求顺利获得。

生产就绪至少包含三种不同状态。进程存活表示模型进程未退出；Pod Ready表示配置的就绪检查顺利获得；服务可用表示入口请求到达正确版本，并在业务要求内得到有效响应。这三者不能互相替代。就绪检查若只探测端口，会在模型尚未装载时放流量；检查若调用过重，又可能给大模型服务增加额外压力。

排障记录要保存对象关系：节点上的GPU资源如何上报，调度事件为何选择当前节点，Pod使用哪个镜像和配置，模型从何处装载，Service选择了哪些Endpoint，网关命中了哪条路由。只有同一条请求能关联资源、工作负载、服务和入口，团队才真正拥有端到端证据。

端到端链路有七个必须对齐的跳点

下图从GPU节点开始，依次经过资源发现、调度、Pod、模型装载、Service和网关。阅读时应为每一跳找到一个状态证据和一个失败证据，不要只看箭头是否连通。

GPU节点：设备存在不等于资源可调度

操作系统或节点工具能看到GPU，只能证明设备在某个层面可见。Kubernetes调度还需要对应资源被正确发现、上报并进入节点可分配量；节点标签、污点、健康状态和维护状态也会影响任务能否放置。设备处于异常或隔离状态时，不应继续计入可用资源。

检查应从资源台账与节点状态开始：目标节点是否上报了预期资源，已分配和可分配是否一致，异常事件是否改变资源状态，Pod申请的资源名称和数量是否与平台对象匹配。这里不提供未经环境核验的命令，因为不同设备和插件实现存在差异；重要的是保留资源对象、事件和实际绑定三类证据。

调度：Pending原因比“资源不足”更具体

Pod处于Pending并不只有GPU不足。资源申请可能与节点标签、亲和性、污点容忍、CPU内存、存储拓扑或配额冲突；资源池可能有空闲设备，却无法满足同一节点上的组合约束。反复调整GPU数量而不看调度事件，容易制造更多碎片。

排查时把调度失败原因按资源、策略、配额和依赖分组。若修改一项约束，应记录前后事件，并准备撤销。不要为了让Pod启动而删除所有限制：安全、租户隔离或拓扑要求可能有明确业务理由，绕过后只会把问题带进运行阶段。

Pod与运行时：Running仍可能没有可用模型

Pod进入Running通常表示容器进程已启动，并不表示权重加载、GPU初始化和服务监听已经完成。镜像摘要、启动参数、环境变量、挂载、密钥、资源限制和运行时状态都可能影响模型。若Pod只在某台节点成功，要怀疑节点缓存、手工文件或环境漂移。

验证应包含一次在另一台满足条件的节点上重建，或在清理缓存后重新装载。日志要区分镜像拉取、运行时初始化、设备访问和模型进程错误。重启成功也不代表问题解决，需要确认根因是否仍会在下一次发布或节点故障时出现。

模型装载：制品、存储和权限必须一致

大模型权重、配置、词表、模板和必要的扩展制品往往体积大、文件多。存储挂载成功不代表文件完整，权限可读不代表版本正确。模型路径、分片清单、校验信息、配置版本和加载结果应属于同一发布记录。

共享存储、对象存储、本地缓存各有边界。缓存能缩短重复装载，却可能让节点之间版本不一致；远端存储便于集中管理，但需要验证网络、权限和故障时的行为。具体吞吐与装载时间只能在企业环境测试，不能从存储类型名称直接推断。

服务链路最常断在“看起来正常”的对象之间

Service与Endpoint：选择器和就绪状态必须指向同一版本

Service存在不代表有可用Endpoint。标签选择器可能选不到Pod，也可能同时选中旧版本；Pod Ready状态错误会让未装载模型进入Endpoint；端口名称、协议和目标端口不一致也会造成连接失败。排查应把Service选择器、Endpoint列表、Pod标签和就绪条件放在一起，而不是逐个截图。

在滚动发布时，还要观察新旧版本何时进入和退出Endpoint。若模型装载慢，默认发布节奏可能提前缩减旧副本；若终止前没有停止接流和处理在途请求，客户端会看到间歇错误。

网关与网络策略：入口成功不等于服务内部可达

网关路由、证书、身份、超时、请求大小、重试和限流都会影响模型接口。模型服务可能在集群内可访问，却因网络策略阻断网关命名空间；也可能网关可达，但超时短于模型首个响应时间。盲目增加重试会把慢请求复制成更大压力。

从一条失败请求出发，记录入口路由、身份结果、上游地址、连接、超时和最终Endpoint。集群内与集群外测试要使用相同版本和必要请求头。对AI工作负载与基础设施关系的更多内容，可查看 AI基础设施分类，目标页面应在发布前复核。

观测与告警：没有关联ID就只能靠时间猜

日志分别存在于节点、调度器、Pod、模型框架、Service、网关和应用层。若没有请求ID、工作负载标识、模型版本和时间同步，故障发生后只能用大致时间拼接。部署平台应至少让资源、Pod、模型版本和请求相互关联。

告警也要指向动作。GPU异常应说明影响哪些任务，模型装载失败要关联制品和节点，Endpoint下降要显示版本和入口影响。只有“服务异常”四个字，会让多个团队同时查看各自面板，却没人形成完整判断。

从外向内和从内向外同时排查

从外向内适合处理用户已看到的错误：先确认域名或入口、网关路由和身份，再看Service、Endpoint、Pod和模型；从内向外适合处理部署失败：先确认GPU资源、调度、运行时和模型装载，再看就绪、服务发现与入口。两条路径最终要在具体Pod、模型版本和请求上汇合。

以下是一个不依赖具体工具的证据清单：

这张表用于确定下一跳，不是让团队一次修改所有对象。找到最早出现异常的跳点后，先验证单一假设，再观察上下游是否恢复。

灰度和回滚要覆盖“新节点+冷缓存”

只在已有节点、已有镜像和模型缓存上灰度，会低估生产恢复时间。一次有效回归应至少包含新节点或清理缓存的环境，验证镜像拉取、模型装载、存储访问和就绪节奏。还要模拟一个副本异常，确认流量摘除、在途请求和重建行为。

回滚不能只把镜像标签改回去。模型制品、配置、Service选择器、网关权重和数据依赖都可能变化，必须明确哪些对象作为一个发布单元。回滚后重新执行代表性请求，确认权限、输出契约和业务结果。能启动旧版本不等于回滚完成，旧版本必须重新进入正确服务链。

上线前最小回归集

上线前至少准备成功请求、未授权请求、超时或取消、模型版本核对、一个副本失效和一次冷启动。资源侧验证GPU绑定、节点维护和释放；服务侧验证Endpoint变化、网关路由和在途请求；观测侧验证请求能关联到模型与Pod。

结果建议分为顺利获得、条件顺利获得、待补证据和阻断。仅在缓存节点成功可标记条件顺利获得；无法确认制品版本或入口实际Endpoint则应阻断。任何具体性能、并发和恢复目标由企业根据业务负载设定。

下一步：用一条失败请求贯穿七个跳点

选择一条可复现的失败请求，从网关向内记录路由、Service、Endpoint、Pod、模型版本、调度和GPU绑定，再从GPU节点向外核对同一链路。找到第一个证据不一致的跳点，只修改一个变量并保留回滚。若需要评估更完整的AI平台交付能力，可在核验公开页面后查看 AI解决方案，具体兼容性和服务范围仍以实际环境、POC与方案为准。

常见问题

Pod显示Running为什么模型接口仍然不可用？

Running主要说明Pod中的容器进程已经启动或仍在运行，不代表模型权重装载完成、GPU初始化成功、依赖数据可读，也不代表Pod已顺利获得就绪检查并进入Service Endpoint。即使集群内本地端口能响应，Service选择器、端口映射、网络策略、网关路由、身份和超时仍可能阻断外部请求。

排查时依次确认容器事件与日志、模型加载状态、就绪条件、Endpoint、Service端口和网关上游，并用同一模型版本和请求ID关联。若就绪检查只探测端口，应评估它是否过早放流量；若检查包含重型推理，又要观察是否造成额外压力。不要顺利获得不断重启Pod掩盖制品、挂载或路由问题，重启只能作为验证动作并需记录根因是否消失。

GPU在节点上可见，为什么任务仍调度失败？

节点工具能看见设备，只说明操作系统或某层运行环境发现了GPU。Kubernetes调度需要设备资源被正确上报为可分配对象，Pod申请与资源名称匹配，同时满足CPU、内存、存储、标签、污点容忍、亲和性、拓扑和租户配额等约束。任何一项不满足，任务都可能Pending；资源池总量有空闲，也不代表存在一个节点满足组合需求。

应先查看调度事件并按资源、策略、配额和依赖分类，再核对节点上报、已分配与实际绑定。若只在特定节点成功，还要检查节点环境漂移或缓存依赖。不同设备插件、驱动和运行时的具体行为必须按官方资料与企业环境验证，不能用一套命令或兼容结论覆盖所有组合。调整约束前要理解其安全与拓扑目的，避免为了启动任务破坏隔离边界。

K8s大模型部署上线前要做哪些最小回归？

最小回归应覆盖资源、冷启动、服务与失败路径，而不是只做一次正常调用。资源侧确认GPU申请和实际绑定一致，节点维护或异常时不会继续调度；冷启动在新节点或清理缓存后验证镜像、制品、挂载、权限和就绪时间；服务侧检查Service、Endpoint、网关、身份、超时与代表性请求；失败路径至少模拟一个副本失效和一次回滚。

每项回归要保存模型与配置版本、节点和Pod标识、请求结果、关键事件、执行人和回退结果。性能与容量目标应使用企业真实请求分布和统计口径，不应从单次测试外推。若某项依赖第三方系统或无法在测试环境复现，应列为残余风险和上线限制。完成回归后还要确认告警由谁接、业务由谁签收，否则技术链路顺利获得也不代表运营准备完成。