AI推理服务变慢时，先不要同时加 CPU、内存、磁盘和网络：如果有 OOM、持续交换或模型无法加载，先处理内存或显存；如果 GPU 空闲、CPU 队列持续堆积，优先检查 CPU；如果瓶颈集中在模型加载或持续读写，再升级磁盘；只有真实请求路径的传输时间、丢包或错误表明网络受限，才优先升级网络。GPU 计算或显存已经到边界时，主机资源升级通常不是首选，应评估 GPU 规格、实例数量或推理架构。

这个顺序取决于监控信号，不是固定采购清单。开始调整前，先固定模型、运行时、输入和并发口径，拆分请求耗时，再每次只改变一个主要变量。这样才能判断资源升级是否解决了瓶颈，也能在效果不佳时回滚。

先确认服务能稳定运行的最低条件

判断 AI推理业务选择GPU服务器是否合适，不能只看 GPU 型号或显存。目标 GPU 的显存要容纳模型权重、运行时开销、中间张量及实际批量或上下文缓存；主机内存要覆盖操作系统、推理运行时、数据预处理和后处理、模型加载与缓存，正常服务不应依赖交换空间维持运行。CPU 要能及时完成请求接入、数据转换和调度；磁盘要能存放模型、缓存和必要日志；网络要能承载实际输入输出数据。模型格式、运行时、精度设置与 GPU 架构也必须兼容。

其中一些条件是上线门槛，另一些可以根据监控逐步扩充。例如，模型加载后常驻内存或显存、运行期间没有持续读盘时，磁盘通常不是稳态推理的首要升级项；请求数据较小、调用与推理服务之间传输耗时不显著时，网络也不应仅因“配置看起来较低”而优先升级。反过来，即使主机 CPU 和内存充足，显存不足仍可能导致模型无法加载；显存充足也不代表 CPU 预处理一定跟得上。

用同一组测试拆分耗时

先建立基线，再看资源是否与业务慢点对应。固定模型版本、精度、运行时和启动参数，选取接近真实业务的输入尺寸与数据类型；分别记录空载、稳定负载和业务高峰表现。测试时记录请求排队、预处理、GPU 推理、后处理和完整响应时间，并同步观察吞吐、错误率、超时、显存、主机内存、磁盘等待及网卡统计。不要把连接数当作每秒请求数，也不要用单次请求推断服务吞吐。

Linux 主机可先做以下只读检查。命令输出用于定位线索，不能代替推理服务的分段耗时；iostat、nvidia-smi 是否可用，取决于工具和驱动是否已安装。

date -Is
uname -a
nproc
lscpu | sed -n '1,20p'

free -h
vmstat 1 5

df -hT
findmnt

command -v iostat && iostat -xz 1 5
ip -s link
ss -s

command -v nvidia-smi && nvidia-smi

整机 CPU 平均使用率不高，不足以排除 CPU 瓶颈：单线程任务可能只占用一个核心，却已在该核心排队。网络同样要看真实请求路径，而不能仅凭服务器网卡标称速率作判断。先确认调用节点、测试时间、请求方向和数据大小，再记录往返时延、丢包、重传、网卡错误与服务器内部耗时。网络结论仅适用于实际测试覆盖的节点、时间、环境、方法和样本；内网单点测试不能代表所有调用方，高峰未覆盖的短时测试也不能说明长期表现。

按监控信号确定先升级什么

先处理内存或显存造成的不稳定

主机内存不足会引发交换、磁盘等待和延迟波动；如果模型、批量或上下文超过 GPU 显存容量，则可能无法加载或运行。因此，出现 OOM、内存分配失败、持续交换，或模型因显存不足不能正常启动时，应先解决容量或占用问题，再评估其他资源。

升级前先检查应用缓存、请求队列和并发是否有上限。如果它们持续增长，单纯增加内存只能推迟故障。应先为缓存、并发和队列设置合理边界，再确认是否仍有容量不足。调整后，在相同模型、输入和并发下观察 OOM 是否消失、交换活动是否停止、延迟是否稳定。如果内存压力已消失但 GPU 等待、推理耗时没有变化，原先的内存问题可能不是主要性能瓶颈。

显存不足与主机内存不足需要分开处理：增加主机内存不会扩大 GPU 显存。确认 GPU 显存或计算达到业务边界后，应转向 GPU 规格、实例数量、批量设置或推理架构，而不是继续叠加 CPU、磁盘和网络。

CPU 排队且 GPU 空闲时，再处理 CPU

输入解码、缩放、归一化、文本切分、请求调度和结果封装等工作可能由 CPU 完成。如果这些环节耗时增加，GPU 会因等待数据而空闲。此时应检查分核使用率、运行队列、预处理和后处理时间，而不只是看整机平均 CPU 使用率。

升级 CPU 前，也要检查线程和并发配置。线程过多可能增加上下文切换，过高并发可能拉长队列；并发太低又可能无法充分利用 GPU。固定测试输入后，逐步调整并发或线程配置，一次只改一个主要变量。升级有效的表现是 CPU 侧处理时间或排队下降、GPU 等待输入减少，并且在错误率和延迟目标不变差的情况下吞吐改善。若增加 CPU 后 GPU 仍持续繁忙，瓶颈已转向 GPU 侧，不应继续仅靠增加 CPU 解决。

磁盘主要影响加载、缓存和持续读写

冷启动慢、模型热更新或版本切换耗时明显、推理过程中持续读取数据，且磁盘等待与这些现象同步时，磁盘可排在 CPU 之前。先用加载日志和磁盘指标确认等待发生在哪个阶段，并检查模型文件是否完整、挂载点是否正确、日志是否异常增长。

如果模型加载完成后常驻内存或显存，运行期间没有持续读盘，升级磁盘通常不会直接缩短稳态推理时间。分别测量冷启动加载时间和模型常驻后的稳态延迟：只有启动变快，说明改善的是加载路径，不代表 GPU 计算能力增加；两者均未改善，则应回查 CPU、内存、GPU 或服务排队。迁移模型文件前要保留原目录并核实备份，避免覆盖后无法恢复。

网络必须按真实调用路径验证

网络带宽不足时，大输入或大输出可能增加传输时间；丢包、错误或时延波动也可能使请求传输变慢。但网络升级是否有收益，要看网络耗时是否确实占据完整请求时间的一部分，并确认服务器内部排队和推理耗时没有同步变长。

测试应使用真实调用方所在的节点或与其相符的环境，记录测试时间、请求方向、数据大小、负载条件和样本范围，同时观察时延、丢包、重传及网卡错误。变更后复测完整请求，而不只做连通性检查。若传输耗时下降且错误未增加，服务器内部处理仍符合目标，才可认为网络调整达到了预期；单个节点、单个时段的结果不能外推到未测试的调用方或高峰环境。

从最小配置开始，逐步调整运行参数

缺少业务数据时，不应承诺某个配置能承载固定请求量。可先用能容纳目标模型和运行时开销的单个 GPU 实例，启动时加载模型，并给并发、批量和请求队列设置明确上限。保证主机内存没有持续交换，CPU 能完成数据准备与调度；将模型文件、缓存和日志纳入磁盘监控，同时记录 GPU、CPU、内存、磁盘、网络及各阶段耗时。先验证模型和运行时稳定，再按实际瓶颈调整规格或增加实例。

关键参数应在所用推理运行时中核实对应设置，名称和含义可能因软件而异：

每次只改并发、批量或一个主要资源变量，并保留旧配置。否则多个设置同时变化，即使性能改善，也难以确认原因。

实施变更后按同口径验收，失败就回滚

变更前保存服务配置、模型版本、启动参数和监控基线，记录主机规格、挂载点与网卡状态，并确认模型文件及业务配置可恢复。主机规格调整是否需要重启、迁移或重新部署，取决于部署方式和服务商的变更流程；应先核实影响范围，并准备旧实例或流量切回方式。

实施时先处理会导致不稳定的内存或显存问题；其余情况下，按监控证据选择 CPU、磁盘或网络中的一个方向调整。模型迁移保留原目录，不在未确认备份时覆盖或删除文件。变更后等待服务完成模型加载，再用相同模型、输入、并发和测试环境对比目标指标、完整请求耗时及错误率。

目标指标改善、请求延迟或加载时间按预期下降，且错误率、超时、OOM 和显存异常没有增加，才能考虑保留新配置。若延迟未改善或错误增加，先摘除新实例或切回旧实例，再恢复变更前的并发、批量、队列和超时设置；主机规格按已确认的回退流程恢复。保留失败时的日志和监控，比较分段耗时后再定位原因，不要连续扩大多个资源。

后续是否继续升级，可看瓶颈是否转移：内存交换和 OOM 已消失但 CPU 队列仍高，才进一步处理 CPU；冷启动改善而稳态未变，磁盘升级的作用就限定在加载阶段；网络传输仍占主要耗时且真实节点测试支持这一判断，才继续优化网络；GPU 计算或显存到达边界，则转向更匹配的 GPU 规格、实例数或推理架构。若所有资源指标都未触边而延迟仍高，先查请求排队、线程、锁、模型加载策略和分段耗时。