1. 实时推荐系统遇上显卡服务器先看清延迟花在哪如果你负责过实时推荐系统应该知道最难受的不是模型 AUC 上不去而是线上请求一多响应时间立刻变得很难看。我最近把一套 AI 驱动的实时推荐服务跑在 RHEL 8 显卡服务器上踩了一圈坑之后最大的感受是显卡不是装完驱动就能变快的RHEL 8 上从驱动、算力运行时到推理服务的整个链路任何一个环节配置不对最终都会体现在用户体验的 P99 延迟上。推荐系统不是单点模型。一次完整的线上推荐通常要经历用户画像读取、候选集召回、特征拼接、排序模型推理、重排规则过滤、组装返回这么几步。这里面的延迟账单非常有意思召回阶段可能占用 30% 的时间特征处理占用 20%排序模型推理占用 30%剩下的花在网络和序列化上。很多人一开始只盯着模型推理时间但其实特征服务、缓存命中率、召回候选数量都会直接影响 GPU 服务吃到的请求量和 batch 形态。所以在 RHEL 8 上配置显卡服务器本质上不是装一个驱动、跑一个模型那么简单而是要重新梳理推荐链路把最重的排序计算卸载到 GPU 上同时把 CPU 资源留给召回和特征工程让整个系统在同样的硬件成本下把响应时间从“可用”压到“顺畅”。1.1 推荐链路里那些被忽略的延迟我遇到过一套线上推荐服务最初所有模块都在 CPU 上跑。单路请求看模型推理 40ms 左右看起来还能接受但一旦 QPS 上来CPU 占用很快冲到 90% 以上。原因不是模型本身有多复杂而是推荐排序模型里大量使用 Embedding 查表和特征交叉这种计算模式在 CPU 上跑单个请求不慢但并发一高线程切换和内存带宽就顶不住了。用户能感知的延迟不是平均值而是尾延迟。CPU 服务在低负载下可能 P99 只有 120ms但高负载下能轻松飙到 300ms 以上。推荐页面每慢 100ms用户跳出率都会明显上升。显卡服务器的价值就在这里把排序这种计算密集型的环节放到 GPU 上CPU 从繁忙的矩阵运算中解放出来专心做召回和特征处理整体延迟会更稳定。还有一部分延迟是模型加载和框架初始化造成的。很多人部署推理服务的时候只测了上线之后正常请求的耗时却忽略了服务启动时模型加载、运行时初始化、首次推理预热这几个阶段。在 RHEL 8 上做显卡服务器优化我会把模型预热也当成正式流程的一部分否则上线后的第一个请求可能就会超时。1.2 GPU 真正能加速的部分需要澄清一点GPU 不是对推荐系统里的所有环节都有用。候选召回如果是基于向量检索比如用近邻检索库做相似度计算显卡有帮助但通常网络传输和特征过滤才是瓶颈。真正的深度排序模型尤其是多任务学习、DNN 交叉层、Attention 结构这一类计算量集中在矩阵乘法和激活函数上这才是 GPU 发挥优势的主场。以排序模型为例一个请求进来系统要为每个用户生成一个“用户 Embedding”再和几百个候选物品的 Embedding 拼接过几个全连接层。单看一个请求的 FLOPs 不高但线上推荐往往是一次请求返回几十个甚至上百个物品模型侧要同时计算多个候选的得分。这种批量候选计算在 GPU 上可以被天然地并行化。GPU 的另一个优势是“延迟换吞吐”的灵活性。如果每个请求都单独做一次推理显卡的利用率会很低。所以我在实际项目中一定会做动态批处理也就是把一小段时间窗口内的多个推理请求攒在一起组成一个批次再一次性交给 GPU。这样单个请求的延迟会增加几毫秒但整体吞吐能翻好几倍。RHEL 8 下配置这类推理服务时CPU 核数、内存和显存大小决定了你能把批处理做到多激进。1.3 RHEL 8 在整条链路里的位置RHEL 8 在服务器市场很常见但它的默认配置并不是为 GPU 推理准备的。系统里可能带有开源显卡驱动内核启用了安全模块网络栈和内存参数也都是通用默认值。要在这样的系统上跑 AI 实时推荐需要做不少“面向推理场景”的调整。很多团队用 CentOS 类系统习惯了“开箱即用”到了 RHEL 8 上会碰到几个特点一是软件源里默认没有显卡厂商的驱动包需要自行添加二是默认的 Nouveau 开源驱动会和新驱动冲突必须在内核层面禁用三是 RHEL 8 使用 grubby 管理内核启动参数和老的 grub 配置方式不完全一样。这些细节如果没处理好显卡看起来被系统识别了但实际算力不可用。我通常会先把 RHEL 8 当做一个“需要主动喂驱动和运行时的底座”来对待。系统的定制化越少越好驱动版本固定内核版本锁定算力运行时和模型推理框架的版本对应关系记录清楚。这样排障的时候你才不会陷入“驱动显示正常但程序报错”的尴尬境地。2. 显卡服务器准备先把地基打稳2.1 硬件配置怎么定聊显卡服务器之前先说硬件选型。推荐系统的排序模型参数量一般在几百 MB 到几个 GB 之间。如果模型是稀疏特征特别多的宽深模型显存需求主要由 Embedding 表决定。我的经验是排序模型的显存预算不要只算模型权重还得把推理时的中间激活、动态批处理的临时张量、框架运行时的缓存都留出来。简单算一本账模型权重 1GBEmbedding 表 2GB动态批处理最大 batch 32 时中间激活可能要占 500MB再加上推理框架的缓存预留一块 16GB 显存的显卡基本够用。但如果要同时部署多个模型或者做模型版本灰度切换最好选 24GB 或更高显存的计算卡。CPU 方面不要觉得上了显卡 CPU 就不重要。推荐系统的召回、特征拼接、序列化、网络传输都在 CPU 上跑。我建议至少配 16 核以上且核心频率不要过低因为很多特征处理是单请求串行完成的主频高一些P99 会更好看。内存最好 64GB 起步特征服务和缓存也会占用不少。硬盘反而不是重点但模型文件和日志需要一定空间。建议系统盘和数据盘分开避免日志写满后影响内核和驱动。RHEL 8 安装时我会把 /var、/opt 单独分区避免模型长期堆积导致根分区爆掉。2.2 系统分区与内核参数系统安装阶段尽量选择最小化安装不要装不必要的图形界面组件。显卡服务器跑在线推理稳定性和资源利用率优先图形环境除了多占内存没有任何好处。装完系统后有几个内核参数值得调整。网络方面如果推荐服务大量使用远程调用我会调大 socket buffer 和 TCP 连接队列长度。内存方面适当的 vm.swappiness 和 vm.overcommit_memory 可以避免推理进程在内存紧张时被频繁回收。还有 GPU 推理服务常用线程池进程数、文件描述符上限要调大否则高并发时会出现奇怪的 connection reset。RHEL 8 上可以用系统自带的性能调优服务来管理。如果没有特殊需求就不需要每台机器手工改一堆 sysctl 参数而是把配置沉淀到统一的模板里。这样后续扩容显卡服务器时可以直接复用。2.3 选定驱动安装方式显卡驱动安装方式通常有两种一种是用显卡厂商提供的软件仓库直接安装另一种是下载 runfile 手动安装。RHEL 8 上我建议优先用仓库方式因为能通过系统包管理统一升级和卸载但前提是你对仓库的更新策略有控制。手动 runfile 安装的好处是版本非常明确不容易被系统自动更新破坏。坏处是每次内核升级之后驱动模块可能无法自动重新编译如果你没给内核做版本锁定一次普通的 system update 就能让 GPU 服务突然挂掉。我个人在实际项目中会给内核包设置版本锁定或者启用 DKMS 机制让驱动在内核升级后自动重新编译。另外RHEL 8 默认可能开启了 Secure Boot。这时安装驱动会遇到模块签名问题要么在固件里关闭要么把驱动模块做 MOK 签名。不要图省事直接跳过签名否则重启后模块加载失败排查起来非常痛苦。3. 驱动与算力环境安装实录3.1 屏蔽开源驱动在 RHEL 8 上GPU 驱动安装的第一步往往不是装新驱动而是先禁用系统自带的开源驱动。实际操作时我会先查看系统是否识别到显卡设备以及当前使用的驱动模块是什么。cat /etc/redhat-release uname -r lspci | grep -i vga lsmod | grep nouveau如果 lspci 能识别显卡但 lsmod 里看到 nouveau那就说明系统默认加载了开源驱动。直接安装新驱动时会因为模块冲突失败或者装完不生效。RHEL 8 下推荐用 grubby 修改内核命令行参数把 nouveau 屏蔽掉。cat /etc/modprobe.d/disable-nouveau.conf EOF blacklist nouveau options nouveau modeset0 EOF grubby --update-kernelALL --argsrd.driver.blacklistnouveau nouveau.modeset0改完之后要执行一次 initramfs 重建再重启系统。注意RHEL 8 的 initramfs 命令是 dracut如果忘了重建重启后可能还是老样子。重启之后再用 lsmod 检查确认 nouveau 不再加载才能继续进行驱动安装。提示这步很多人会跳过结果装完驱动后 nvidia-smi 报“couldnt load kernel module”。不要怀疑是安装包坏了先检查是不是 nouveau 占着设备。3.2 安装驱动与算力运行时驱动安装成功之后还需要安装算力运行时和深度神经网络加速库。这里的版本对应关系非常关键。显卡驱动、算力运行时和深度学习框架不是越新越好而是要互相兼容。我见过太多因为“追新”导致的不兼容问题。我的做法是先确定推荐模型要用的深度学习框架版本再根据框架的安装文档确定它支持哪一版算力运行时最后反向选择显卡驱动的版本。整个版本组合确定之后写到一个 requirement 文件里作为这台服务器的标准配置。RHEL 8 上安装驱动之后可以用系统自带的状态工具确认显卡和算力运行时是否正常nvidia-smi这个命令会输出显卡型号、驱动版本、显存占用和 GPU 利用率。如果这里能看到显卡说明内核层面的驱动没问题。接着可以跑一个简单的 Python 脚本确认算力运行时能被模型框架调用。3.3 验证 GPU 是否真正可用只看到 nvidia-smi 不算完还要验证整条 GPU 计算链路。一个比较实用的验证方法是把推荐模型里的一个中等规模的张量计算放到 GPU 上对比 CPU 的时间。很多框架默认使用显存的“缓存分配器”第一次在 GPU 上创建张量时会把一整块显存预留出来看起来显存占用很高但这不能说明模型真的在 GPU 上跑。真正需要确认的是模型推理时 GPU 利用率有没有上去以及显存会不会持续增长。我在生产环境里会记录两个指标GPU 利用率和显存峰值。如果模型已经接流量但 GPU 利用率不到 20%大概率是批处理策略没生效如果显存持续增长那就是推理过程中有持久化张量没有被释放需要排查代码或框架配置。4. 模型服务化与实时推荐链路优化4.1 模型导出与格式选择在 RHEL 8 上跑实时推荐模型不能直接用训练时的脚本方式上线。训练时模型是动态图方便调试但线上推理需要把计算图固定下来减少 Python 解释层的开销。我通常会先把训练好的模型导出成静态计算图格式再用推理框架加载。导出模型的时候推荐系统有个坑Embedding 查表通常是稀疏操作动态图里可以接收任意长度的候选列表但静态图导出如果没固定动态维度推理引擎就会报 shape 相关的错误。我的经验是导出时把候选数量设成线上可能出现的最大值并且把用户特征和候选特征分开输入避免在模型内部拼接时出现尺寸不匹配。模型导出之后还得做一个“等价性验证”。也就是用同一批样本跑导出前后的模型比较输出结果是否一致。不同框架导出时数值精度可能有细微差异而推荐排序结果是连续分数微小的误差不影响排序但需要设定一个可接受的阈值范围。4.2 推理服务怎么接进推荐系统实时推荐服务的架构上我建议把 GPU 推理封装成一个独立的模型服务不要和推荐业务主服务混在一起。业务主服务负责用户请求解析、召回、特征组装模型服务只负责“接收特征向量返回分数”。中间用高效的远程调用协议通信避免大量 JSON 序列化。RHEL 8 上跑模型服务可以直接用系统服务托管也可以用容器。系统服务方式更简单直接资源隔离靠 systemd 的 cgroup 就能做到。容器方式便于版本管理和资源配额但要额外处理驱动映射问题。我的建议是如果只有一台或几台显卡服务器用 systemd 直跑更省心如果需要频繁扩缩容容器更合适。模型服务启动时要做模型预热。推荐模型里有些算子第一次执行时需要进行内核编译延迟可能是正常推理的好几倍。预热的方式是启动后往回放一批历史请求让所有算子都执行一遍再把服务注册到可用列表里。否则优雅上线瞬间进来的实际流量会直接撞上冷启动延迟。4.3 动态批处理与并发控制显卡推理服务最关键的优化点就是动态批处理。简单说就是不让每个请求单独进 GPU而是让请求在队列里等一小段时间凑成一个 batch 再统一计算。RHEL 8 上的推理服务我会把批处理参数分成四个参数建议值说明max_batch_size16~32超过这个值会执行拆分避免单次耗时过长max_wait_time3~5ms队列里等待的最长时间超过就立刻推理queue_capacity200~1000队列长度防止流量洪峰时无限排队timeout_ms100ms整次推理请求的超时时间保护上游动态批处理的收益非常明显。单请求推理时显卡大多数计算单元是空闲的但因为每个请求都要走一次调用延迟并不低。把 8 个请求拼成一个 batch 后总计算时间可能只比单个请求多 20% 到 40%单请求平均耗时反而更可控。但批处理不是越大越好。batch 太大会导致单个推理任务执行时间变长P99 延迟上升等待时间太短批处理命中率就会很低。实际调参时我会看一个指标批处理命中率也就是一个 batch 里平均装了多少个请求。如果平均 batch size 不到 2说明等待窗口太短如果平均 batch size 长期满额说明 max_batch_size 可能太小或者流量本身已经压满了。4.4 缓存和召回侧配合GPU 推理再快也架不住每个请求都推全量候选。推荐系统里的“实时推荐”四个字不代表每次都要重新计算所有环节。合理使用缓存能把真正需要 GPU 推理的请求数量降一个数量级。我常用的三种缓存策略第一用户画像和特征缓存减少特征服务的重复计算第二召回候选集缓存如果一个用户在短时间内重复访问可以直接复用候选集合第三热门物品的模型预测分数缓存对于少数高热物品不必每次重新推理。需要注意缓存引入之后推荐结果可能出现“不够实时”的问题。所以缓存命中率不是越高越好而是要在响应时间和推荐新鲜度之间做平衡。实操中我会给不同类型的推荐位设置不同的缓存 TTL比如首屏推荐用短缓存下拉刷新时用长缓存。召回侧也要配合 GPU 负载。如果召回结果动辄上千个候选排序模型即使再快特征拼接和传输也会拖慢整体响应。我一般会把召回候选数量控制在几十到几百个再根据 GPU 推理能力和业务需求调整。候选少了推荐多样性可能下降候选多了延迟又会上升。5. 性能验证、容量评估与常见问题5.1 上线前的压测指标上线前我会搭一套和线上环境一致的压测环境用历史流量回放来做验证。压测的目的不是看 GPU 能不能跑而是确定这台显卡服务器到底能扛多少 QPS以及不同并发下的延迟表现。我习惯记录四个指标指标关注原因P50 延迟大多数用户体验P99 延迟尾延迟决定用户是否会投诉GPU 利用率显存是否成为瓶颈错误率超时、排队丢弃、服务不可用压测时我会从低并发开始逐步增加直到 P99 延迟超过业务容忍线。记录这个临界 QPS 作为容量基准。之后所有模型更新或配置调整都要用同一套压测流程做回归。只有这样做你才能回答“显卡服务器到底值不值”这个问题。一个参考经验值是在 CPU 方案下 P99 可能在 200ms 以上的系统换到 GPU 推理并且做好动态批处理后P99 有可能压到原生 CPU 方案的一半以下。但要强调的是数值完全取决于模型复杂度、特征数量和流量模型不能拿别人的压测数据直接当自己的容量规划。5.2 驱动与进程常见故障驱动层面的故障大多是版本和内核不匹配造成的。比如升了一次内核后驱动模块没有重新编译nvidia-smi 命令会消失或者程序报找不到驱动设备。遇到这种情况先看系统日志里是不是 module load error再决定是回滚内核还是重新编译驱动模块。另一种常见问题是驱动安装完成但 Python 推理脚本仍然报算力运行时不可用。这类问题通常不是驱动的问题而是动态库路径没配对。RHEL 8 上我会把算力运行时的库路径写进 ld.so.conf并执行 ldconfig 刷新缓存避免每次都靠手动设置环境变量。进程层面最容易踩到的是显存泄漏。推荐模型上线后显存占用缓慢上涨几天后突然 OOM。这类问题大多来自推理框架的显存缓存策略而不是代码真的泄漏。解决思路是设置显存分配器的最大缓存比例或者定期释放缓存。直接重启服务治标不治本关键是找到哪个环节在持续累积显存。5.3 延迟抖动排查有时 GPU 利用率不高但 P99 延迟就是不稳定。我排查过几个方向比较有效的是检查 CPU 核数是否正确绑核。Python 推理服务如果线程数很多但 CPU 配额不足调度延迟会直接反映在 P99 上。我会用 taskset 把推理进程固定到一组专属 CPU 核避免和其他服务抢调度。检查模型服务的线程池是否被阻塞。推理框架里获取 GPU 结果通常是阻塞式的如果线程池满了后续请求只能排队。这时候需要调大线程池或者减少同步调用把推理请求改成异步回调。检查缓存命中率波动。缓存过期时间设置不合理会导致缓存整片失效流量瞬间透传到 GPU 服务延迟在一个时间点突然飙高。我的做法是给缓存增加随机偏移避免所有 key 在同一时刻过期。5.4 长期运行稳定性保障显卡服务器长期运行还有两个不能忽略的维度温度和驱动升级。GPU 在高负载下发热量很大机房散热如果压不住显卡会自动降频表现为延迟缓慢上升。我会在压测时同步查看显卡温度和核心频率如果温度过高先解决散热再谈优化。驱动升级这件事很多团队要么完全不升要么一升就升最新版。我的建议是固定在一个经过验证的驱动版本上除非有安全漏洞或者新算力运行时强依赖否则不要动。每次升级都要做完整回归包括 nvidia-smi 输出、模型推理正确性、压测延迟曲线。最后分享一个我自己的体会在 RHEL 8 上做 AI 推荐系统的 GPU 优化本质上是在“算力、延迟、成本”之间找平衡。驱动和算力环境只是地基真正让用户体验变好的是动态批处理、缓存策略、特征链路这些系统工程层面的细节。参数可以照着别人的经验调但一定要结合自己的流量模型去压测验证这样才不会在线上被 P99 打脸。 
长河君 · 2026/10/19 11:34:56 · 阅读 1.2k RHEL 8显卡服务器上实时推荐系统GPU推理优化实践
1. 实时推荐系统遇上显卡服务器先看清延迟花在哪如果你负责过实时推荐系统应该知道最难受的不是模型 AUC 上不去而是线上请求一多响应时间立刻变得很难看。我最近把一套 AI 驱动的实时推荐服务跑在 RHEL 8 显卡服务器上踩了一圈坑之后最大的感受是显卡不是装完驱动就能变快的RHEL 8 上从驱动、算力运行时到推理服务的整个链路任何一个环节配置不对最终都会体现在用户体验的 P99 延迟上。推荐系统不是单点模型。一次完整的线上推荐通常要经历用户画像读取、候选集召回、特征拼接、排序模型推理、重排规则过滤、组装返回这么几步。这里面的延迟账单非常有意思召回阶段可能占用 30% 的时间特征处理占用 20%排序模型推理占用 30%剩下的花在网络和序列化上。很多人一开始只盯着模型推理时间但其实特征服务、缓存命中率、召回候选数量都会直接影响 GPU 服务吃到的请求量和 batch 形态。所以在 RHEL 8 上配置显卡服务器本质上不是装一个驱动、跑一个模型那么简单而是要重新梳理推荐链路把最重的排序计算卸载到 GPU 上同时把 CPU 资源留给召回和特征工程让整个系统在同样的硬件成本下把响应时间从“可用”压到“顺畅”。1.1 推荐链路里那些被忽略的延迟我遇到过一套线上推荐服务最初所有模块都在 CPU 上跑。单路请求看模型推理 40ms 左右看起来还能接受但一旦 QPS 上来CPU 占用很快冲到 90% 以上。原因不是模型本身有多复杂而是推荐排序模型里大量使用 Embedding 查表和特征交叉这种计算模式在 CPU 上跑单个请求不慢但并发一高线程切换和内存带宽就顶不住了。用户能感知的延迟不是平均值而是尾延迟。CPU 服务在低负载下可能 P99 只有 120ms但高负载下能轻松飙到 300ms 以上。推荐页面每慢 100ms用户跳出率都会明显上升。显卡服务器的价值就在这里把排序这种计算密集型的环节放到 GPU 上CPU 从繁忙的矩阵运算中解放出来专心做召回和特征处理整体延迟会更稳定。还有一部分延迟是模型加载和框架初始化造成的。很多人部署推理服务的时候只测了上线之后正常请求的耗时却忽略了服务启动时模型加载、运行时初始化、首次推理预热这几个阶段。在 RHEL 8 上做显卡服务器优化我会把模型预热也当成正式流程的一部分否则上线后的第一个请求可能就会超时。1.2 GPU 真正能加速的部分需要澄清一点GPU 不是对推荐系统里的所有环节都有用。候选召回如果是基于向量检索比如用近邻检索库做相似度计算显卡有帮助但通常网络传输和特征过滤才是瓶颈。真正的深度排序模型尤其是多任务学习、DNN 交叉层、Attention 结构这一类计算量集中在矩阵乘法和激活函数上这才是 GPU 发挥优势的主场。以排序模型为例一个请求进来系统要为每个用户生成一个“用户 Embedding”再和几百个候选物品的 Embedding 拼接过几个全连接层。单看一个请求的 FLOPs 不高但线上推荐往往是一次请求返回几十个甚至上百个物品模型侧要同时计算多个候选的得分。这种批量候选计算在 GPU 上可以被天然地并行化。GPU 的另一个优势是“延迟换吞吐”的灵活性。如果每个请求都单独做一次推理显卡的利用率会很低。所以我在实际项目中一定会做动态批处理也就是把一小段时间窗口内的多个推理请求攒在一起组成一个批次再一次性交给 GPU。这样单个请求的延迟会增加几毫秒但整体吞吐能翻好几倍。RHEL 8 下配置这类推理服务时CPU 核数、内存和显存大小决定了你能把批处理做到多激进。1.3 RHEL 8 在整条链路里的位置RHEL 8 在服务器市场很常见但它的默认配置并不是为 GPU 推理准备的。系统里可能带有开源显卡驱动内核启用了安全模块网络栈和内存参数也都是通用默认值。要在这样的系统上跑 AI 实时推荐需要做不少“面向推理场景”的调整。很多团队用 CentOS 类系统习惯了“开箱即用”到了 RHEL 8 上会碰到几个特点一是软件源里默认没有显卡厂商的驱动包需要自行添加二是默认的 Nouveau 开源驱动会和新驱动冲突必须在内核层面禁用三是 RHEL 8 使用 grubby 管理内核启动参数和老的 grub 配置方式不完全一样。这些细节如果没处理好显卡看起来被系统识别了但实际算力不可用。我通常会先把 RHEL 8 当做一个“需要主动喂驱动和运行时的底座”来对待。系统的定制化越少越好驱动版本固定内核版本锁定算力运行时和模型推理框架的版本对应关系记录清楚。这样排障的时候你才不会陷入“驱动显示正常但程序报错”的尴尬境地。2. 显卡服务器准备先把地基打稳2.1 硬件配置怎么定聊显卡服务器之前先说硬件选型。推荐系统的排序模型参数量一般在几百 MB 到几个 GB 之间。如果模型是稀疏特征特别多的宽深模型显存需求主要由 Embedding 表决定。我的经验是排序模型的显存预算不要只算模型权重还得把推理时的中间激活、动态批处理的临时张量、框架运行时的缓存都留出来。简单算一本账模型权重 1GBEmbedding 表 2GB动态批处理最大 batch 32 时中间激活可能要占 500MB再加上推理框架的缓存预留一块 16GB 显存的显卡基本够用。但如果要同时部署多个模型或者做模型版本灰度切换最好选 24GB 或更高显存的计算卡。CPU 方面不要觉得上了显卡 CPU 就不重要。推荐系统的召回、特征拼接、序列化、网络传输都在 CPU 上跑。我建议至少配 16 核以上且核心频率不要过低因为很多特征处理是单请求串行完成的主频高一些P99 会更好看。内存最好 64GB 起步特征服务和缓存也会占用不少。硬盘反而不是重点但模型文件和日志需要一定空间。建议系统盘和数据盘分开避免日志写满后影响内核和驱动。RHEL 8 安装时我会把 /var、/opt 单独分区避免模型长期堆积导致根分区爆掉。2.2 系统分区与内核参数系统安装阶段尽量选择最小化安装不要装不必要的图形界面组件。显卡服务器跑在线推理稳定性和资源利用率优先图形环境除了多占内存没有任何好处。装完系统后有几个内核参数值得调整。网络方面如果推荐服务大量使用远程调用我会调大 socket buffer 和 TCP 连接队列长度。内存方面适当的 vm.swappiness 和 vm.overcommit_memory 可以避免推理进程在内存紧张时被频繁回收。还有 GPU 推理服务常用线程池进程数、文件描述符上限要调大否则高并发时会出现奇怪的 connection reset。RHEL 8 上可以用系统自带的性能调优服务来管理。如果没有特殊需求就不需要每台机器手工改一堆 sysctl 参数而是把配置沉淀到统一的模板里。这样后续扩容显卡服务器时可以直接复用。2.3 选定驱动安装方式显卡驱动安装方式通常有两种一种是用显卡厂商提供的软件仓库直接安装另一种是下载 runfile 手动安装。RHEL 8 上我建议优先用仓库方式因为能通过系统包管理统一升级和卸载但前提是你对仓库的更新策略有控制。手动 runfile 安装的好处是版本非常明确不容易被系统自动更新破坏。坏处是每次内核升级之后驱动模块可能无法自动重新编译如果你没给内核做版本锁定一次普通的 system update 就能让 GPU 服务突然挂掉。我个人在实际项目中会给内核包设置版本锁定或者启用 DKMS 机制让驱动在内核升级后自动重新编译。另外RHEL 8 默认可能开启了 Secure Boot。这时安装驱动会遇到模块签名问题要么在固件里关闭要么把驱动模块做 MOK 签名。不要图省事直接跳过签名否则重启后模块加载失败排查起来非常痛苦。3. 驱动与算力环境安装实录3.1 屏蔽开源驱动在 RHEL 8 上GPU 驱动安装的第一步往往不是装新驱动而是先禁用系统自带的开源驱动。实际操作时我会先查看系统是否识别到显卡设备以及当前使用的驱动模块是什么。cat /etc/redhat-release uname -r lspci | grep -i vga lsmod | grep nouveau如果 lspci 能识别显卡但 lsmod 里看到 nouveau那就说明系统默认加载了开源驱动。直接安装新驱动时会因为模块冲突失败或者装完不生效。RHEL 8 下推荐用 grubby 修改内核命令行参数把 nouveau 屏蔽掉。cat /etc/modprobe.d/disable-nouveau.conf EOF blacklist nouveau options nouveau modeset0 EOF grubby --update-kernelALL --argsrd.driver.blacklistnouveau nouveau.modeset0改完之后要执行一次 initramfs 重建再重启系统。注意RHEL 8 的 initramfs 命令是 dracut如果忘了重建重启后可能还是老样子。重启之后再用 lsmod 检查确认 nouveau 不再加载才能继续进行驱动安装。提示这步很多人会跳过结果装完驱动后 nvidia-smi 报“couldnt load kernel module”。不要怀疑是安装包坏了先检查是不是 nouveau 占着设备。3.2 安装驱动与算力运行时驱动安装成功之后还需要安装算力运行时和深度神经网络加速库。这里的版本对应关系非常关键。显卡驱动、算力运行时和深度学习框架不是越新越好而是要互相兼容。我见过太多因为“追新”导致的不兼容问题。我的做法是先确定推荐模型要用的深度学习框架版本再根据框架的安装文档确定它支持哪一版算力运行时最后反向选择显卡驱动的版本。整个版本组合确定之后写到一个 requirement 文件里作为这台服务器的标准配置。RHEL 8 上安装驱动之后可以用系统自带的状态工具确认显卡和算力运行时是否正常nvidia-smi这个命令会输出显卡型号、驱动版本、显存占用和 GPU 利用率。如果这里能看到显卡说明内核层面的驱动没问题。接着可以跑一个简单的 Python 脚本确认算力运行时能被模型框架调用。3.3 验证 GPU 是否真正可用只看到 nvidia-smi 不算完还要验证整条 GPU 计算链路。一个比较实用的验证方法是把推荐模型里的一个中等规模的张量计算放到 GPU 上对比 CPU 的时间。很多框架默认使用显存的“缓存分配器”第一次在 GPU 上创建张量时会把一整块显存预留出来看起来显存占用很高但这不能说明模型真的在 GPU 上跑。真正需要确认的是模型推理时 GPU 利用率有没有上去以及显存会不会持续增长。我在生产环境里会记录两个指标GPU 利用率和显存峰值。如果模型已经接流量但 GPU 利用率不到 20%大概率是批处理策略没生效如果显存持续增长那就是推理过程中有持久化张量没有被释放需要排查代码或框架配置。4. 模型服务化与实时推荐链路优化4.1 模型导出与格式选择在 RHEL 8 上跑实时推荐模型不能直接用训练时的脚本方式上线。训练时模型是动态图方便调试但线上推理需要把计算图固定下来减少 Python 解释层的开销。我通常会先把训练好的模型导出成静态计算图格式再用推理框架加载。导出模型的时候推荐系统有个坑Embedding 查表通常是稀疏操作动态图里可以接收任意长度的候选列表但静态图导出如果没固定动态维度推理引擎就会报 shape 相关的错误。我的经验是导出时把候选数量设成线上可能出现的最大值并且把用户特征和候选特征分开输入避免在模型内部拼接时出现尺寸不匹配。模型导出之后还得做一个“等价性验证”。也就是用同一批样本跑导出前后的模型比较输出结果是否一致。不同框架导出时数值精度可能有细微差异而推荐排序结果是连续分数微小的误差不影响排序但需要设定一个可接受的阈值范围。4.2 推理服务怎么接进推荐系统实时推荐服务的架构上我建议把 GPU 推理封装成一个独立的模型服务不要和推荐业务主服务混在一起。业务主服务负责用户请求解析、召回、特征组装模型服务只负责“接收特征向量返回分数”。中间用高效的远程调用协议通信避免大量 JSON 序列化。RHEL 8 上跑模型服务可以直接用系统服务托管也可以用容器。系统服务方式更简单直接资源隔离靠 systemd 的 cgroup 就能做到。容器方式便于版本管理和资源配额但要额外处理驱动映射问题。我的建议是如果只有一台或几台显卡服务器用 systemd 直跑更省心如果需要频繁扩缩容容器更合适。模型服务启动时要做模型预热。推荐模型里有些算子第一次执行时需要进行内核编译延迟可能是正常推理的好几倍。预热的方式是启动后往回放一批历史请求让所有算子都执行一遍再把服务注册到可用列表里。否则优雅上线瞬间进来的实际流量会直接撞上冷启动延迟。4.3 动态批处理与并发控制显卡推理服务最关键的优化点就是动态批处理。简单说就是不让每个请求单独进 GPU而是让请求在队列里等一小段时间凑成一个 batch 再统一计算。RHEL 8 上的推理服务我会把批处理参数分成四个参数建议值说明max_batch_size16~32超过这个值会执行拆分避免单次耗时过长max_wait_time3~5ms队列里等待的最长时间超过就立刻推理queue_capacity200~1000队列长度防止流量洪峰时无限排队timeout_ms100ms整次推理请求的超时时间保护上游动态批处理的收益非常明显。单请求推理时显卡大多数计算单元是空闲的但因为每个请求都要走一次调用延迟并不低。把 8 个请求拼成一个 batch 后总计算时间可能只比单个请求多 20% 到 40%单请求平均耗时反而更可控。但批处理不是越大越好。batch 太大会导致单个推理任务执行时间变长P99 延迟上升等待时间太短批处理命中率就会很低。实际调参时我会看一个指标批处理命中率也就是一个 batch 里平均装了多少个请求。如果平均 batch size 不到 2说明等待窗口太短如果平均 batch size 长期满额说明 max_batch_size 可能太小或者流量本身已经压满了。4.4 缓存和召回侧配合GPU 推理再快也架不住每个请求都推全量候选。推荐系统里的“实时推荐”四个字不代表每次都要重新计算所有环节。合理使用缓存能把真正需要 GPU 推理的请求数量降一个数量级。我常用的三种缓存策略第一用户画像和特征缓存减少特征服务的重复计算第二召回候选集缓存如果一个用户在短时间内重复访问可以直接复用候选集合第三热门物品的模型预测分数缓存对于少数高热物品不必每次重新推理。需要注意缓存引入之后推荐结果可能出现“不够实时”的问题。所以缓存命中率不是越高越好而是要在响应时间和推荐新鲜度之间做平衡。实操中我会给不同类型的推荐位设置不同的缓存 TTL比如首屏推荐用短缓存下拉刷新时用长缓存。召回侧也要配合 GPU 负载。如果召回结果动辄上千个候选排序模型即使再快特征拼接和传输也会拖慢整体响应。我一般会把召回候选数量控制在几十到几百个再根据 GPU 推理能力和业务需求调整。候选少了推荐多样性可能下降候选多了延迟又会上升。5. 性能验证、容量评估与常见问题5.1 上线前的压测指标上线前我会搭一套和线上环境一致的压测环境用历史流量回放来做验证。压测的目的不是看 GPU 能不能跑而是确定这台显卡服务器到底能扛多少 QPS以及不同并发下的延迟表现。我习惯记录四个指标指标关注原因P50 延迟大多数用户体验P99 延迟尾延迟决定用户是否会投诉GPU 利用率显存是否成为瓶颈错误率超时、排队丢弃、服务不可用压测时我会从低并发开始逐步增加直到 P99 延迟超过业务容忍线。记录这个临界 QPS 作为容量基准。之后所有模型更新或配置调整都要用同一套压测流程做回归。只有这样做你才能回答“显卡服务器到底值不值”这个问题。一个参考经验值是在 CPU 方案下 P99 可能在 200ms 以上的系统换到 GPU 推理并且做好动态批处理后P99 有可能压到原生 CPU 方案的一半以下。但要强调的是数值完全取决于模型复杂度、特征数量和流量模型不能拿别人的压测数据直接当自己的容量规划。5.2 驱动与进程常见故障驱动层面的故障大多是版本和内核不匹配造成的。比如升了一次内核后驱动模块没有重新编译nvidia-smi 命令会消失或者程序报找不到驱动设备。遇到这种情况先看系统日志里是不是 module load error再决定是回滚内核还是重新编译驱动模块。另一种常见问题是驱动安装完成但 Python 推理脚本仍然报算力运行时不可用。这类问题通常不是驱动的问题而是动态库路径没配对。RHEL 8 上我会把算力运行时的库路径写进 ld.so.conf并执行 ldconfig 刷新缓存避免每次都靠手动设置环境变量。进程层面最容易踩到的是显存泄漏。推荐模型上线后显存占用缓慢上涨几天后突然 OOM。这类问题大多来自推理框架的显存缓存策略而不是代码真的泄漏。解决思路是设置显存分配器的最大缓存比例或者定期释放缓存。直接重启服务治标不治本关键是找到哪个环节在持续累积显存。5.3 延迟抖动排查有时 GPU 利用率不高但 P99 延迟就是不稳定。我排查过几个方向比较有效的是检查 CPU 核数是否正确绑核。Python 推理服务如果线程数很多但 CPU 配额不足调度延迟会直接反映在 P99 上。我会用 taskset 把推理进程固定到一组专属 CPU 核避免和其他服务抢调度。检查模型服务的线程池是否被阻塞。推理框架里获取 GPU 结果通常是阻塞式的如果线程池满了后续请求只能排队。这时候需要调大线程池或者减少同步调用把推理请求改成异步回调。检查缓存命中率波动。缓存过期时间设置不合理会导致缓存整片失效流量瞬间透传到 GPU 服务延迟在一个时间点突然飙高。我的做法是给缓存增加随机偏移避免所有 key 在同一时刻过期。5.4 长期运行稳定性保障显卡服务器长期运行还有两个不能忽略的维度温度和驱动升级。GPU 在高负载下发热量很大机房散热如果压不住显卡会自动降频表现为延迟缓慢上升。我会在压测时同步查看显卡温度和核心频率如果温度过高先解决散热再谈优化。驱动升级这件事很多团队要么完全不升要么一升就升最新版。我的建议是固定在一个经过验证的驱动版本上除非有安全漏洞或者新算力运行时强依赖否则不要动。每次升级都要做完整回归包括 nvidia-smi 输出、模型推理正确性、压测延迟曲线。最后分享一个我自己的体会在 RHEL 8 上做 AI 推荐系统的 GPU 优化本质上是在“算力、延迟、成本”之间找平衡。驱动和算力环境只是地基真正让用户体验变好的是动态批处理、缓存策略、特征链路这些系统工程层面的细节。参数可以照着别人的经验调但一定要结合自己的流量模型去压测验证这样才不会在线上被 P99 打脸。