Spirula Studio：跨厂商显卡可用的 3DGS 训练工具，从视频端到端重建纹理网格
2026/10/23 4:19:33
你有没有遇到过这种情况：一台跑本地大模型推理的 Linux 机器，llama.cpp 服务跑着跑着，进程突然没了；或者更诡异，nvidia-smi 直接查不到显卡，好像卡从机器上掉了一样。网上搜一圈，高赞答案基本都会指向一个开关——NVIDIA GPU 持久化模式（persistence mode）。问题是，很多人照做了，sudo nvidia-smi -pm 1一敲，回车，问题依旧。这不是开关没用，而是大多数人把它的边界搞错了。
这篇文章不打算给你一个万能解法，而是把持久化模式到底管什么、不管什么讲透，再顺着 llama.cpp 常驻、频繁 kill 进程、显卡掉卡这三件事，一步步捋清排查顺序。适合正在维护推理服务器、或者刚把 llama.cpp 部署到 Linux 机器上的朋友。读完之后你会发现，掉卡和 kill 进程这两件事，真正的原因往往在别处，但持久化模式又是你绕不开的一个基础设置。
1. 先把概念锚死：persistence mode 持久化的到底是什么
1.1 从"驱动下班"说起
NVIDIA 的 Linux 驱动并不是一个黑盒，它分成两层：一层是内核态模块，也就是我们常说的 NVRM（NVIDIA Resource Manager），负责直接操作 GPU 硬件；另一层是用户态库，比如 libcuda.so、libnvidia-ml.so，应用程序通过它们跟内核模块通信。
默认情况下，驱动的工作模式是 on-demand，也就是"按需加载"。当最后一个打开 GPU 设备文件（/dev/nvidia0、/dev/nvidiactl 这些）的进程退出之后，驱动会进入空闲状态，把全局上下文释放掉，GPU 软件栈进入一种"下班"状态。在部分配置下，GPU 甚至会进入深度低功耗状态，PCIe 链路也跟着降速。这个状态不是硬件断电，而是驱动不再维持任何活跃的初始化状态。
等下一个进程想用 GPU 的时候，驱动必须重新"上班"——重新初始化 GPU 固件状态、重建设备上下文、重新枚举显存、重新建立 BAR 映射。这个过程一般要花几十到几百毫秒，在 GPU 数量多、PCIe 拓扑复杂、或者机器上有多个 NUMA 节点的时候，耗时还可能更长。
persistence mode 做的事情，就是把"下班"这个动作取消掉。开启后，驱动保持上电且初始化完毕的状态，即使没有任何客户端进程使用 GPU，驱动也处于待命状态。NVIDIA 官方配套的 nvidia-persistenced 守护进程会一直持有 GPU 的设备文件句柄，目的就是让驱动永远不要进入空闲卸载流程。
你可以把它想成两种门卫：默认模式是兼职门卫，有事打电话才来，办完事就走，下次再来得重新换衣服、重刷门禁；持久化模式是专职门卫，常年坐在门卫室里，你来他就直接放行。GPU 还是那个 GPU，区别只在于软件栈是"待命"还是"重建"。
1.2 它不占显存、不占算力，但要付出功耗代价
很多人一听"持久化"，第一反应是"是不是把显存里的数据保存下来"——不是，完全不是。持久化模式持久化的是驱动的初始化状态，不是你的模型权重，也不是推理中间结果。
开启之后，nvidia-smi 里的显存占用并不会增加，GPU 的计算核心也不会因此跑任务。显存分配、CUDA context 这些东西都还是由具体进程管理，persistence mode 不掺和。
但它确实有代价：GPU 无法再进入深度低功耗状态，待机功耗会上升。数据中心显卡本身待机功耗不高，但一台机器插上八张卡，每张多出十几瓦甚至几十瓦，整机的功耗和散热账单是能看出来的。消费级显卡和笔记本上这个差异更明显，这也是为什么 NVIDIA 在部分 GeForce 驱动上直接不开放这个功能——你对着笔记本敲nvidia-smi -pm 1，返回 Not Supported，别奇怪，不是你的机器坏了，是驱动不支持这种使用方式。
把这一点想清楚，你就明白了一个关键结论：persistence mode 解决的是"驱动反复初始化"带来的延迟和偶发失败，它不加速推理计算，也不增加显存，只是让 GPU 软件栈保持在"随时可用"的状态。
2. 解开"llama.cpp 常驻、频繁 kill 进程和掉卡"这团乱麻
2.1 llama.cpp 常驻进程是怎么跟 GPU 打交道的
llama.cpp 的 CUDA 后端在加载模型时，会做这几件事：创建 CUDA context、把量化后的 GGUF 权重拷贝到显存、分配 KV cache 和计算用的临时 buffer。只要进程不退出，这些资源就一直在 GPU 上占着。
llama.cpp 的服务模式（llama-server）是一个长时间运行的进程，它自己就是一个"门卫"，只要服务还活着，驱动就不会下班。所以如果你的服务一直常驻、不频繁重启，persistence mode 开不开，运行期的推理速度几乎没有任何差别。
那"常驻进程"和"掉卡"是什么关系？最直接的关系是：进程常驻期间如果卡掉了，说明问题出在驱动、硬件、供电、散热这些层面，跟持久化模式默认关着的状态关系很小。一个健康的常驻进程，本身就是维持驱动活跃状态的最强保证。
2.2 进程被 kill 的五个最常见原因，以及去哪看日志
我在实际维护推理服务时总结过一个"被杀原因排行榜"，按出现频率排，大致是：
| 现象 | 根因方向 | 去哪看证据 |
|---|---|---|
| CPU 内存 OOM，进程被系统杀掉 | 系统 RAM 不够，或 mmap 模型文件导致 page cache 暴涨 | dmesg -T | tail里看到Out of memory: Killed process |
| GPU 显存 OOM，进程自己崩溃 | KV cache 或 batch 设置过大，显存预算没算清 | llama.cpp 日志里的CUDA error: out of memory |
| 驱动崩溃，Xid 错误后进程被杀 | 驱动 bug、硬件故障、GPU 掉总线 | dmesg -T | grep -i xid或/var/log/kern.log里的 NVRM 报错 |
| 被脚本或 systemd 误杀 | 服务配置、超时策略、监控脚本误判 | journalctl -xe里的 SIGTERM/SIGKILL 记录 |
| CUDA context 初始化失败 | 多进程同时抢初始化，或驱动状态异常 | llama.cpp 日志里的CUDA error: illegal address、initialization error |
看到没有，这里绝大多数 kill 场景，persistence mode 都帮不上忙。CPU 内存 OOM 甚至跟 GPU 完全无关，但它是 llama.cpp 部署中最容易被忽略的坑。很多教程让你加--mlock把模型锁进物理内存，结果内存不够，mlock 失败，照样启动不了。
2.3 持久化模式真正有用的场景：初始化竞态和反复启停
那 persistence mode 在 llama.cpp 生态里真的一点用没有吗？也不是，它解决的是另一类问题：驱动反复上下班带来的初始化开销和竞态。
最典型的是批处理场景。假设你写了一个脚本队列，每个任务都拉起一次 llama-bench 或者一次llama-cli --prompt ...，跑完就退出，接着拉下一个。在默认模式下，每一次拉起都触发一次完整的 GPU 初始化，这个延迟可能从几十毫秒到几百毫秒不等。更糟的是，如果多个任务同时启动，比如一个 for 循环里并行开几个进程，驱动要同时响应多个初始化请求，偶尔会报 CUDA initialization error——这就会让你的队列任务偶发失败，从外面看就像"进程被莫名 kill"。
另外一个场景是共享服务器。多人共用一张卡，A 同学跑完推理进程退出，B 同学马上启动新进程，两者交替过程中，驱动在"下班"和"上班"之间反复切换。如果驱动版本本身有点小毛病，这种反复初始化偶尔就会触发偶发失败，比如某一次启动后 CUDAGetDeviceProperties 报错，或者 GPU 短暂不可见。开启 persistence mode 之后，驱动永远处于就绪状态，这类奇奇怪怪的初始化问题会少很多。
所以结论可以这么归纳：llama.cpp 常驻和 persistence mode 关系不大，频繁 kill 进程中的 OOM 类问题它解决不了，但频繁启停场景下的初始化延迟和偶发失败，它确实能给你抹平。
3. "掉卡"的完整排查链路：从现象到根因
3.1 先分类：是真掉卡、假掉卡，还是驱动级掉卡
"掉卡"这个词在论坛里被用滥了，至少包含三种完全不同的情况。不先分清楚，排查方向就会完全跑偏。
| 现象描述 | 分类 | 第一优先级排查方向 |
|---|---|---|
进程报 CUDA 错误，但nvidia-smi还能看到 GPU，显存也能查询 | 假掉卡：应用层/上下文问题 | 显存预算、CUDA context、驱动版本、并发初始化 |
nvidia-smi看不到 GPU，/dev/nvidia*设备节点也消失 | 驱动级掉卡：驱动崩了或模块退出 | 内核日志、驱动版本、GSP 固件、硬件连接 |
nvidia-smi能看到 GPU，但跑任何任务都报 Xid 错误 | 硬件级或固件级掉卡 | Xid 错误码、供电、PCIe 链路、散热 |
这里有个很实用的判断技巧：ls /dev/nvidiactl是否存在。如果设备节点没了，说明 NVRM 内核模块已经放弃了对 GPU 的管理，这种情况往往是内核日志里的大问题，而不是 llama.cpp 的锅。
3.2 学会看 NVRM 日志和 Xid 错误码
排查掉卡，最重要的日志来源是dmesg。别盯着 llama.cpp 的日志看了，它只负责报告"我联系不上 GPU"，真正的原因在驱动内核日志里。
dmesg -T | grep -i "nvrm\|xid"常见 Xid 错误码的粗略含义我整理了一下：
| Xid 错误码 | 典型含义 | 常见诱发因素 |
|---|---|---|
| 13 | 图形引擎异常 | 驱动崩溃、显存越界访问 |
| 31 | 显存 ECC 错误 | 显存颗粒故障、超频、过热 |
| 43 | GPU 从总线上脱落 | 供电不足、PCIe 链路不稳定、金手指接触不良 |
| 45 | 预取/纹理错误 | 驱动与固件版本不匹配 |
| 79 | GPU 挂起但驱动可恢复 | 长时间高负载、驱动 bug |
其中 Xid 43 是最典型、也最吓人的"掉卡"错误。它对应的英文描述往往是 GPU has fallen off the bus。这种情况下，GPU 在物理层面还能看到，但 PCIe 链路已经断了，驱动无法再访问它。最常见的原因是供电不足——尤其是多卡机器满载推理时，电源峰值功率不够，或者 PCIe 供电线缆老化，导致瞬间掉压。
千万不要一看到 Xid 43 就重装驱动。先检查供电和物理连接，这个顺序能帮你省掉大量无用功。
3.3 把根因排查顺序固定下来，别一上来就怪 persistence mode
掉卡问题的排查，我建议按这个固定顺序走，避免被各种论坛帖子带偏：
- 硬件侧：供电余量够不够，线缆有没有接牢，金手指有没有氧化，散热有没有积灰。用一个 8 卡满载的推理任务压测，同时开
nvidia-smi -q -d POWER观察每张卡的实际功耗峰值。 - 系统侧：BIOS 里 PCIe Gen 设置是否匹配主板和 GPU 的能力，Resizable BAR 是否开启，IOMMU 配置有没有问题。PCIe Gen4 信号完整性在高负载下是掉卡大户。
- 驱动侧：驱动版本和 CUDA 版本是否匹配，GSP 固件加载有没有异常，MIG 模式是否被误开启。
- 应用侧：显存和 CPU 内存预估够不够，并发度是否过高，llama.cpp 的参数是否合理。
把这一整套走完，你大概率已经找到根因了。如果最后发现是"每次启动新进程时偶发初始化失败"，这时候再考虑把 persistence mode 打开，它是这一类问题的正解。
4. 实操：正确开启持久化模式，并验证它对推理进程的影响
4.1 三秒钟的临时开启方式和状态确认
临时开启只需要一条命令，需要 root 权限：
sudo nvidia-smi -pm 1开启后，用nvidia-smi -q查看持久化状态，或者直接过滤：
nvidia-smi -q | grep -i Persistence正常情况下会看到Persistence Mode : Enabled。如果返回的是Not Supported，说明当前显卡驱动不支持持久化模式，这在消费级 GeForce 显卡上很常见，不用纠结，继续用你的默认模式就行。
需要特别提醒：这只是临时设置，重启机器之后会回到默认的 off 状态。如果你想长期保持，必须用下一节说的守护进程方式。
4.2 开机自启的正规姿势：nvidia-persistenced
临时命令只管当前开机周期，真正靠谱的持久化方式是用 NVIDIA 官方提供的 nvidia-persistenced 守护进程。驱动安装包通常自带这个组件，在 Debian/Ubuntu 系系统上，你可以直接安装并启用：
sudo apt install nvidia-persistenced sudo systemctl enable --now nvidia-persistenced systemctl status nvidia-persistenced这个守护进程做的事非常简单：以 root 身份打开 GPU 设备文件，然后一直持有句柄，不让驱动进入空闲卸载状态。它不消耗多少 CPU，内存占用也很小，属于典型的"占着位置但不干活"的服务。
我的建议是，凡是数据中心卡、共享推理服务器、多卡宿主机，一律默认装好 nvidia-persistenced。别用小技巧，别手动后台跑，直接用 systemd 管理，它会帮你处理好多卡设备节点的细节。
4.3 容器和 Docker 环境要注意的边界
如果你用 Docker 跑 llama.cpp，这里有一个容易搞混的点：persistence mode 是宿主机驱动层面的全局设置，容器里是没有办法自己开启的。你在容器内执行nvidia-smi -pm 1，通常没有权限，也不会生效。
容器内nvidia-smi里显示的 Persistence Mode 状态，实际上是宿主机驱动的状态。所以正确做法是：在宿主机上把 persistence mode 开好，然后再启动容器。这样容器里频繁起停推理进程时，也能享受到"驱动永远就绪"的收益。
另外，docker run --gpus all只负责把 GPU 设备和驱动文件挂载进容器，它不负责设置驱动状态。别指望 Docker 帮你搞定这些底层全局配置。
4.4 怎么验证开启前后对 llama.cpp 的实际影响
很多人开了 persistence mode 之后，感觉"没什么变化"，这其实是正常的。为了让你心里有数，我给一个验证方法：对比频繁启停场景下的进程启动耗时。
写一个简单的循环脚本，反复拉起 llama-bench 或任意一个 llama.cpp 可执行文件，记录每次从进程启动到开始第一个 token 计算的耗时。比如：
for i in $(seq 1 10); do /usr/bin/time -f "%e" ./llama-bench -m ./model.gguf -p 32 -n 32 2>&1 | tail -3 done分别在nvidia-smi -pm 0和nvidia-smi -pm 1下跑一轮，对比首次 GPU 初始化耗时。在驱动默认模式下，每次拉起进程都要重建驱动状态，耗时波动会比较大；开启后，这条路径被省掉，启动时间会明显更稳定。
反过来说，如果你的 llama.cpp 服务常年常驻、永不退出，那么开不开 persistence mode，实测推理耗时没有任何可感知差异。理解了这一点，你就不会被网上的玄学说法误导了。
5. 多次部署踩坑后，我建议你先做这几件事
5.1 把显存账单算清楚再开跑
掉卡和崩溃，很多不是"卡掉了"，而是显存爆了之后系统开始连锁反应。llama.cpp 的显存占用可以估算：模型权重（比如 7B Q4_K_M 大概 4.5GB）加上 KV cache 加上计算 buffer。
KV cache 的粗略公式是：(2 \times 2 \times \text{n_layer} \times \text{n_kv_head} \times \text{head_dim} \times \text{n_ctx}) 字节。以 7B 模型为例，32 层、8 个 KV heads、head_dim 128、上下文 4096，算出来是 (2 \times 2 \times 32 \times 8 \times 128 \times 4096 = 512)MB，大约 512MB。如果你的 GPU 显存只有 8GB，模型权重加 KV cache 就已经接近 5GB，再算上 CUDA 计算 buffer 和 CUDA context 自身的开销，能用的余量其实很紧张。
我见过太多人把--ctx-size设成 32768，然后抱怨"GPU 掉卡"，其实就是 KV cache 直接把显存撑爆了。先看 llama.cpp 启动日志里实际打印的显存申请分配情况，再回头调参，问题往往当场解决。
5.2 日常检查项排个优先级
维护推理服务器，日常巡检我只看这几个指标，按优先级排序：
| 检查项 | 命令 | 关注点 |
|---|---|---|
| 温度与功耗 | nvidia-smi -q -d TEMPERATURE,POWER | 满载时温度是否接近降频阈值，功耗是否超过供电余量 |
| PCIe 协商速率 | nvidia-smi -q -d PCIE | Current Link Width/G Speed 是否比 Max 偏低，偏低说明链路退化 |
| 驱动版本记录 | nvidia-smi --query-gpu=driver_version --format=csv | 每次变更驱动前留底，方便对照日志 |
| 显存使用率 | nvidia-smi --query-gpu=memory.used,memory.total --format=csv | 超过 90% 就要检查是否有泄漏 |
其中 PCIe 协商速率下降是一个很隐蔽的掉卡前兆。如果 Current 速率低于 Max，说明金手指接触不良或链路信号问题，早点处理比等掉卡再排查省事得多。
5.3 几个能让你少值夜班的运维小习惯
最后分享几个很朴素的习惯。
用 systemd 管理常驻的 llama-server 时，Restart=on-failure可以加，但一定要配RestartSec和重启次数限制，否则一个 OOM 进程会让 systemd 疯狂拉起，形成重启风暴，看起来就像"频繁 kill 进程"。
每次动驱动之前，把当前驱动版本、CUDA 版本、nvidia-smi -q的完整输出截图存档。出问题的时候翻出来对比，能省掉大量"是不是更新导致的"这类自我怀疑。
遇到偶发崩溃，第一反应是去看dmesg，不是重启机器。很多掉卡问题在重启后日志会丢失，如果当时没来得及记录，就只能靠猜了。
我在某实验室的共享推理服务器上维护过一段时间的 llama.cpp 服务，最深的体会是：稳定性不是靠某个神奇的开关一开就有的，而是先把显存账单算清楚、把日志看明白、把硬件余量留够。持久化模式是好东西，它让批处理任务稳定了很多，但它从来不是"掉卡"和"进程被杀"的万能答案。下次再遇到进程莫名消失，先别急着敲nvidia-smi -pm 1，花五分钟翻翻日志，你大概率会有更直接的发现。