那天早上到办公室手机被一条推送刷屏——NVIDIA要花129.3亿美元收购Hugging Face。我第一反应是打开计算器反复确认零的个数129.3亿美元折合人民币接近930亿一个干模型托管的平台真值这个价群里立刻分成两派有人觉得英伟达疯了有人觉得这是在用美元买下一个时代的“模型分发入口”。但说实话对于我这种几乎每天都跟NVIDIA驱动、Hugging Face下载、本地推理部署打交道的人来说这笔交易最终落地与否有两件事是确定的第一NVIDIA和Hugging Face的生态一定会绑得越来越紧第二这一整条“装驱动→下模型→跑推理”的链路接下来会成为更多开发者绕不开的日常。无论你是刚入门的小白还是已经在边缘设备上折腾过Jetson的老手这篇文章要聊的都不是新闻本身而是新闻背后你那台机器真实会遇到的问题Ubuntu驱动为什么装不上、Hugging Face的大模型从哪里下更快、拿下来之后怎么用TEI镜像跑起来、以及Jetson Nano这类边缘设备上怎么把模型真正落地。这些才是大多数人在这个生态里最想解决的事。1. 129.3亿美元买的是什么AI开发栈从下到上的整合NVIDIA收购Hugging Face的意向传出后很多人的第一反应是“一家卖显卡的怎么去买一个模型社区”。这个疑问很正常但恰恰没看到整个AI产业链的走向。NVIDIA本质上卖的不是显卡而是“算力入口”。Hugging Face握着的也不是几万个模型文件而是几百万开发者每天来搜索、下载、部署模型的用户习惯。这两样东西加在一起等于把“从模型生产到模型推理”的整条链路握在手里。1.1 Hugging Face到底值不值这个价要理解129.3亿美元这个数字得先看Hugging Face在2023年的估值——当时融资后的估值是45亿美元。也就是说传闻中的收购价相当于在一年内把估值抬了近三倍。贵不贵看短期财务数据肯定贵但看生态位就不一样了。Hugging Face是今天事实上的“AI世界的GitHub”它不只是托管模型权重还托管数据集、Spaces在线应用、以及整个开源模型的协作流程。对NVIDIA来说买下Hugging Face等于买下了模型生态的标准入口以后任何开发者想跑模型从Hugging Face取权重在NVIDIA GPU上推理CUDA、TensorRT、容器镜像这些底层服务全都无缝绑定这个闭环的价值远超模型托管本身的收入。这里要补一个背景NVIDIA这些年一直在做“全栈化”。从底层的CUDA算力库到上层的AI Enterprise软件套件、DGX Cloud云服务再到NIM推理微服务NVIDIA一直在往软件层和分发层走。Hugging Face恰好卡在分发层最核心的位置。可以说这不是一次简单的并购而是补上了整个AI开发栈里最关键的一块拼图。当然从后续的公开信息看这笔交易并没有按传闻价落地但“NVIDIA要掌控模型分发入口”这个战略意图已经是明牌了。1.2 收购案对普通开发者的真实影响对普通开发者来说这笔交易最关键的影响不是股价而是“默认路径”的改变。以前我们装完驱动、从Hugging Face拉模型、本地推理是三个相对独立的环节以后这三个环节会越来越像一个整体。NVIDIA的Container Toolkit、NIM服务、TensorRT-LLM都已经在跟Hugging Face的模型格式做深度适配Hugging Face的Transformers库也在把CUDA相关的优化当成默认选项。这意味着什么意味着你现在花时间搞清楚的驱动安装、模型下载、容器部署这套流程在未来几年内都不会过时反而会变成基本功。所以下面这几章我准备按一条真实链路来讲先解决显卡驱动这个最基础的坎再解决模型获取的效率问题最后落到模型跑起来这一步。每一步背后的坑都是我实打实踩过的。2. 第一道坎NVIDIA驱动安装失败与内核模块报错如果去翻各种NVIDIA相关热搜词会发现一个扎心的规律真正困扰大多数人的不是AI框架而是驱动。Ubuntu安装NVIDIA驱动失败、NVIDIA安装程序提示未全部安装、the NVIDIA kernel module was not created、nvrm cant find an IRQ for your NVIDIA card、Windows上NVIDIA App旧电脑安装失败0xE6000000……每一个都是真实存在且反复出现的高频问题。下面我把Linux和Windows两条线分开讲。2.1 Ubuntu装驱动前必须做的三件事很多人在Ubuntu上装NVIDIA驱动失败根本不是驱动本身的问题而是装之前少做了三件事。第一件事确认硬件型号。别笑真的有人装了Intel核显机器或者AMD显卡机器上硬装NVIDIA驱动。先跑一条命令lspci | grep -i nvidia如果输出里能看到类似“NVIDIA Corporation GA106 [GeForce RTX 3060 Lite Hash Rate]”这样的行说明独立显卡被系统识别到了。如果什么都没输出先查一下你的机器是不是真的带N卡。第二件事把系统自带的nouveau开源驱动禁掉。nouveau是Linux内核里的开源NVIDIA驱动实现问题是它跟闭源驱动的冲突非常经典不关掉nouveau闭源驱动装上后极大概率直接黑屏或者报“EE unknown chipset”之类的错误。禁用方法是在/etc/modprobe.d/目录下新建一个blacklist-nouveau.conf文件sudo bash -c echo -e blacklist nouveau\noptions nouveau modeset0 /etc/modprobe.d/blacklist-nouveau.conf sudo update-initramfs -u更新完initramfs后建议重启重启后跑lsmod | grep nouveau确认没有输出再进入下一步。这一步跳过去后面踩的坑可能比你想的多得多。第三件事确认内核头文件已经安装。NVIDIA驱动是以内核模块的形式加载的编译这个模块需要跟当前内核版本完全对应的linux-headers包。很多驱动报错“the NVIDIA kernel module was not created”根因就在这里。提前装好sudo apt install build-essential linux-headers-$(uname -r)$(uname -r)会自动展开成你当前的内核版本号确保headers版本跟内核严格一致。这三种事情做完再用ubuntu-drivers autoinstall或者sudo apt install nvidia-driver-550这类命令安装驱动成功率会高非常多。2.2 “the NVIDIA kernel module was not created”根因分析这个报错我见过太多次了字面意思是“NVIDIA内核模块没有被创建”。它其实不是某一个单一原因而是一类集合报错但绝大多数情况下逃不出三个方向一是刚才说的编译工具链和内核头文件缺失。NVIDIA驱动安装包在安装过程中会调用gcc和make去编译内核模块如果系统里没有这些工具或者头文件版本不匹配模块就编译不出来自然就报这个错误。解决办法就是上面提到的装好build-essential和linux-headers。二是Secure Boot没有关或者没有给驱动签名。现在的电脑主流都开启了UEFI Secure Boot如果系统里没有导入NVIDIA驱动的MOKMachine Owner Key驱动模块是没办法被内核加载的报错也可能表现为module not created。解决方式是进BIOS关掉Secure Boot或者安装过程中按提示配置MOK密钥。最简单的路径还是关掉Secure Boot尤其是一台专门用来做模型训练的机器关掉之后能省很多麻烦。三是旧的驱动残留。如果你之前通过runfile脚本安装过驱动后来改回apt安装可能会有旧模块和库文件冲突。稳妥的做法是彻底清理后再装sudo apt purge *nvidia* sudo apt autoremove sudo reboot清理完再重新装。这个方案在处理“NVIDIA安装程序失败全未安装”这种诡异状态时尤其有效因为它把历史包袱全部清掉了。2.3 Windows侧NVIDIA App、Studio驱动与DXCacheWindows侧的驱动问题不比Linux少只是报错风格不一样。两个热搜词很典型NVIDIA App旧电脑安装失败0xE6000000、NVIDIA Studio 616.92图形驱动程序驱动安装失败。0xE6000000这个错误码通常出现在比较老的Windows 10系统上装新版NVIDIA App时。新版App对系统组件要求变高了比如需要较新的WebView2运行时、UWP组件、以及系统级.NET支持。老机器如果常年不打系统补丁装到一半就会抛这个错。我的处理办法是先升级系统到最新版本单独装好WebView2 Runtime再用DDU工具在安全模式下彻底清理旧版驱动最后重装NVIDIA App和驱动。注意一定要用DDUDisplay Driver Uninstaller清理手动卸载经常卸不干净。Studio 616.92这种版本号属于Studio驱动分支它是为内容创作软件Pr、Blender、DaVinci Resolve优化的。如果你用的是游戏卡又遇到Studio驱动安装失败不要死磕这个分支直接换“Game Ready”驱动功能上完全兼容稳定性反而更高。如果两个分支都装失败优先怀疑旧驱动残留或杀毒软件拦截了驱动写入同样先用DDU清理一遍再试。还有一个常被忽略的隐患是DXCache目录就是热搜词里那个C:\Users\admin\AppData\Local\NVIDIA\DXCache。这个目录存的是DirectX着色器缓存游戏和应用运行时生成的临时编译产物理论上会加速后续启动但实际使用中经常出现缓存损坏导致游戏闪退、画面花屏的情况。如果遇到这种症状但显卡驱动又更新到最新了把DXCache目录内容清空再重启应用就好了。这不是删了会影响系统的东西它会被自动重建。2.4 笔记本上的IRQ报错一个容易忽略的硬件坑nvrm: cant find an IRQ for your NVIDIA card这条报错对笔记本用户来说属于比较难排查的一类因为它的根因经常在BIOS层面。IRQ是硬件中断请求显卡需要分配一个中断通道来跟CPU通信。这个报错通常说明ACPI高级配置与电源管理接口没有给NVIDIA显卡正确分配中断。我遇到过一台双显卡笔记本装驱动时一加载模块就报这个错后来实际验证下来是BIOS里ACPI的Interrupt Routing配置问题。当时网上的通用解法是给内核加pcinoacpi参数也就是让内核绕过ACPI直接做PCI中断分配sudo nano /etc/default/grub # 找到GRUB_CMDLINE_LINUX这一行改成 GRUB_CMDLINE_LINUXpcinoacpi sudo update-grub sudo reboot这个参数能解决一部分问题但代价是可能影响电源管理笔记本续航会变差。如果加了这个参数后能正常进桌面并加载NVIDIA驱动建议再检查BIOS里有没有“Switchable Graphics”或者“Hybrid Mode”选项改成独立显卡直连模式Discrete模式根治这个问题。对于一些新机型升级BIOS版本也能解决中断分配不合理的bug。总体来说这条报错属于“软件报错、硬件根源”排查顺序应该是BIOS设置→内核参数→驱动重装不要一上来就反复卸载驱动那不是根因。3. 从Hugging Face高效拿到模型下载提速与替代渠道驱动装好了接下来就是模型获取。Hugging Face作为模型托管平台用起来不难难的是“高效”。很多人在浏览器里点Download按钮下载Llama-2这样动辄13GB的文件下载到一半断了重来或者下载完了不知道文件到底缓存在哪里到处找。这些其实都有更好的办法。3.1 下载大模型为什么不建议浏览器点下载浏览器下载大文件的问题有三个不支持断点续传到一半容易断下载过程中占用大量内存浏览器容易崩下载完的文件没有任何仓库结构之后要用还得手动整理。Hugging Face官方提供了一套CLI工具挂在huggingface_hub这个Python包里这才是下载模型的正确姿势pip install -U huggingface_hub[cli] huggingface-cli download meta-llama/Llama-2-7b-chat-hf --local-dir ./llama2-7b--local-dir参数会把模型文件完整下载到指定目录同时也保留仓库的目录结构。CLI工具内部支持断点续传哪怕下载到中途断了重新执行同一条命令它会自动跳过已经下载完成的文件。对动辄十几GB的大模型来说这几乎是最重要的特性。3.2 镜像端点与hf_transfer的组合用法下载慢是另一个高频痛点。Hugging Face主站的服务器分布在海外国内直连下载速度经常只有几十KB/s13GB的模型下到天荒地老。很多人第一反应是找各种奇怪的加速工具但更稳妥的做法是使用国内社区和云厂商维护的公开镜像站。Hugging Face的SDK本身支持通过环境变量切换下载端点常见约定是HF_ENDPOINT。比如下载前执行export HF_ENDPOINT镜像站地址然后正常使用huggingface-cli download命令SDK就会自动从镜像端点拉取。镜像站是官方仓库的只读同步副本环境变量设置合法合规不需要任何额外工具。另一个提高下载速度的利器是hf_transfer这是Hugging Face官方推出的高速下载加速库原理是分段并行下载。安装和启用方式很简单pip install hf_transfer export HF_HUB_ENABLE_HF_TRANSFER1实测下来配合镜像端点使用大模型下载速度能提升数倍。唯一要注意的是hf_transfer的断点续传能力相对弱一些如果你网络环境很不稳定下载容易中断建议不要开启这个加速库改用默认下载器。3.3 缓存目录结构搞清楚HF的文件到底存在哪用默认方式下载模型时不带--local-dir文件会进入Hugging Face的缓存目录。很多初学者下载完找不到文件在哪其实是因为HF做了一个按内容寻址的缓存设计。缓存根目录通常在~/.cache/huggingface/hub里面每个模型对应一个以models--开头的文件夹例如~/.cache/huggingface/hub/models--meta-llama--Llama-2-7b-chat-hf/ ├── blobs/ └── snapshots/ └── 8d457f7d8f6b1b3f9f1c1a4b8f7d8a4b8f7d8a4/ ├── config.json ├── model-00001-of-00002.safetensors └── tokenizer.jsonblobs目录存放的是真正的大文件二进制数据snapshots目录里是指向blobs的符号链接。这种设计的好处是如果你下载过多个版本的同一模型不同版本之间相同的文件块在磁盘上只存一份可以大量节省磁盘空间。下载中断也不怕重新执行命令时它会复用已下载的文件块。理解了这套结构你就知道为什么日常使用建议直接用--local-dir指定下载目录——对于要部署到推理服务的模型放到项目目录里管理更清楚也方便容器挂载。3.4 Llama-2-7B除了Hugging Face还能去哪里拿很多人在热搜里问“Llama-2-7B-chat除了从Hugging Face下载还能去哪里下载比较快”这个问题的背后是模型获取渠道多元化的真实需求。除了HF主站和镜像端点之外国内有几条完全合规、速度很快的路子。首先是魔搭社区ModelScope这是国内起步早、模型全的开放模型平台。Meta官方放出Llama-2后魔搭上就有社区上传的权重和转换好的格式国内服务器下载速度非常快。它的使用方式也很汉化直接网页搜索“Llama-2-7B-chat”找到对应模型复制它的下载命令用Python SDK一行代码就能拉下来from modelscope import snapshot_download model_dir snapshot_download(modelscope/Llama-2-7b-chat-ms)其次是百度飞桨的ModelHub、阿里云PAI的模型市场、以及一些云厂商镜像仓库里打包好的模型镜像。这些平台的模型大多经过格式校验拿来即用。需要注意的是Llama-2的使用需要遵守Meta的社区许可协议无论从哪个平台下载商用前都要过一遍许可条款。总结一下我的下载策略优先用huggingface-cli配合镜像端点下载如果对网络速度不满意就换魔搭小模型无所谓大模型一定不要用浏览器直接下载。4. 模型拿到手之后TEI镜像部署、本地推理与Jetson边缘落地模型下下来了最后一个核心问题怎么跑起来。这一步的选择非常多从“直接用Transformers加载”到“用Docker容器部署”再到“边缘设备上推理”难度递增。我挑三个最典型、也跟热搜词关系最紧密的方案拆开讲。4.1 用TEI容器跑Embedding模型这是HF官方的高性能方案热搜词里有一条“hugging face 官方的高性能 tei(text embeddings inference)的镜像”指的就是Text Embeddings Inference简称TEI。这是Hugging Face官方开源的高性能Embedding模型推理服务专门用来部署文本向量化模型比如BGE、E5、GTE系列。这类模型是RAG检索增强生成系统的核心组件需要把文档和查询转成向量再送进向量数据库做相似度检索。TEI镜像的出名之处在于它在GPU上做了大量底层优化动态批处理、CUDA kernel融合、支持Flash Attention、还内置了TensorRT加速路径。一句话总结同样的显卡跑TEI比裸跑Transformers的吞吐量高很多。部署方式非常简单前提是Docker已经配好NVIDIA Container Toolkitdocker run --gpus all -p 8080:80 \ -v $PWD/data:/data \ ghcr.io/huggingface/text-embeddings-inference:1.5 \ --model-id BAAI/bge-large-zh-v1.5启动后通过HTTP接口直接调用curl -X POST http://localhost:8080/embed \ -H Content-Type: application/json \ -d {inputs: NVIDIA收购Hugging Face意味着什么}返回的就是一段向量数组。TEI还自带一个/rerank接口用于重排序以及/predict接口做分类。我在实际项目里RAG系统的向量化服务就是用TEI部署的一个多路复用、动态批处理的优化换来的是GPU利用率肉眼可见的提升。4.2 Llama-2-7B本地推理显存预算与量化选择Llama-2-7B-chat是很多人的第一个本地大模型但7B这个数字对显存不太友好。模型参数是70亿以FP16精度存储一个参数占2字节那么单模型权重就需要约14GB显存。如果你用的是16GB显存的显卡模型能塞下但留给KV Cache和输入序列的空间就很紧张了稍微长一点的对话就会OOM。这时候量化就是刚需。GGUF格式的Q4_K_M量化版把每个参数压缩到约0.5字节7B模型权重降到4.5GB左右8GB显存的卡也能流畅跑。实际在消费级显卡上跑Llama-2-7B我的建议是先用Ollama这类开箱即用的工具把流程跑通ollama run llama2:7b-chatOllama底层用的是llama.cpp的量化推理对显存的要求低很多。如果已经通过Hugging Face下载了原始模型权重想在自己写的服务里调用推荐用vLLM或者llama.cpp作为推理后端。vLLM的优势在于PagedAttention和continuous batching并发场景下吞吐量很高llama.cpp的优势在于几乎没有依赖纯CPU也能跑适合远程服务器上做轻量调试。显存不够又想跑大模型还有一条路NVIDIA的CUDA统一内存和系统内存扩展。在小显存设备上可以开启--enable-unified-memory之类的参数让GPU借用系统内存但速度会掉一个量级只能作为临时方案。预算允许的话还是老老实实升级显存更值。4.3 Jetson Nano边缘设备上跑AI的镜像刷机与调优Jetson Nano是NVIDIA面向边缘计算的入门开发板热搜词里“人工智能边缘计算开发实战基于NVIDIA Jetson Nano”以及“nvidia jetson nano 官方镜像”都指向这个场景。Jetson Nano的官方系统镜像是JetPack里面预装了Linux for TegraL4T、CUDA、cuDNN、TensorRT这些组件刷机后拿到的是一个完整可用的AI开发环境。刷机本身不算难先下载JetPack镜像不同版本对应不同型号用SDK Manager工具或者balenaEtcher写进TF卡插卡开机。真正容易踩坑的是刷完之后的调优。Jetson Nano默认工作在5W低功耗模式跑推理时性能非常憋屈需要手动切换到MAXN模式sudo nvpmodel -m 0切换到MAXN模式后GPU频率和CPU频率才会放开推理速度能提升不少。另外Jetson设备的内存通常只有4GB或8GB跟PC相比非常吃紧建议增加Swap空间。在Jetson上直接跑PyTorch的Transformers是能跑但性能很差正确姿势是把模型转成TensorRT格式再推理。转换流程一般是PyTorch→ONNX→TensorRT中间用trtexec工具做优化。这一点是Jetson开发和高性能PC开发最大的区别PC上可以直接用PyTorchJetson上必须走TensorRT才划算。监控Jetson运行状态也有专门的工具jetson-stats包里的jtop命令会显示GPU/CPU频率、温度、显存占用调试推理性能必备sudo pip install jetson-stats sudo jtop4.4 GPUDirect与容器通信的配置检查凡是涉及多GPU训练或者分布式推理的场景几乎都会碰到GPUDirect和NCCL的配置问题。GPUDirect是NVIDIA提供的一套技术让GPU能直接访问第三方设备比如另一张GPU或网卡的内存跳过CPU的中转延迟更低、带宽更高。日常开发中大家通常不会直接去配GPUDirect而是落在NCCL通信库的配置上。一个基础检查手段是nvidia-smi topo -m查看GPU之间的拓扑连接判断是多PCIe Switch互联还是NVLink直连。如果你在容器里跑分布式训练发现GPU间通信极慢先检查两个东西NCCL_P2P_LEVEL是否被正确设置、是否因为容器权限导致P2P被禁用。常见做法是在运行Docker容器时加上docker run --gpus all --ipchost --shm-size16g ...--shm-size调大共享内存是容器里跑深度学习的常规操作因为DataLoader多进程会用到/dev/shm默认64MB经常不够用。5. 从驱动到推理一条链路上的高频坑位排查清单把前面几章的踩坑经验汇总成一张可以直接对照的清单。这五组问题是我在实际项目里复现频次最高、也最有代表性的。现象根因处理方式Ubuntu装驱动报the NVIDIA kernel module was not created缺编译工具/内核头文件或Secure Boot拦截安装build-essential和linux-headers-$(uname -r)关闭Secure Boot笔记本加载NVIDIA驱动报nvrm cant find an IRQBIOS里ACPI中断分配异常BIOS更新、切换独显直连模式或内核参数pcinoacpi兜底Windows旧电脑装NVIDIA App报0xE6000000系统组件太旧或残留旧驱动冲突更新系统、装WebView2 Runtime、用DDU清理后重装Hugging Face大模型下载到一半停住网络跨地域带宽波动换镜像端点、开hf_transfer加速、用CLI断点续传TEI容器启动后OOM或推理很慢模型过大超出显存或批处理设置不合理换更小模型、限制max_batch_tokens、优先用量化版Jetson Nano推理速度比预期慢很多还在5W低功耗模式未开满GPU频率执行sudo nvpmodel -m 0切到MAXN模式5.1 我复现频次最高的五个问题第一个是“以为驱动没装好其实是内核头文件没装”。这个问题我在不同版本的Ubuntu上至少处理过五回特征是驱动安装日志里有一段编译错误提示找不到/lib/modules/$(uname -r)/build目录。处理步骤固定先sudo apt install build-essential linux-headers-$(uname -r)再重新安装驱动问题消失。尤其是Linux内核大版本升级之后旧内核的headers会被清理掉必须重新装一遍。第二个是“Hugging Face下载卡在0%重试也没用”。这种情况通常是缓存目录里有损坏的锁文件。处理办法是把~/.cache/huggingface/lock目录下的锁文件删掉再设置镜像端点重新下载。锁文件是并发控制用的正常下载结束后会自动释放但网络异常退出时偶尔会残留。第三个是“容器里CUDA不可用但宿主机的nvidia-smi正常”。这个几乎都是NVIDIA Container Toolkit没装好的问题。检查方式是docker run --rm --gpus all nvidia/cuda:12.0-base nvidia-smi如果能正常输出说明容器运行时是通的如果报错“could not select device driver”重新装一遍nvidia-container-toolkit并重启Docker服务。第四个是“TEI镜像拉下来后启动一直初始化失败”。多半是模型下载阶段网络抖动导致权重文件不完整或者/data目录挂载权限不对。把模型文件先单独下载完整再通过本地路径传进容器会比容器内部自动下载稳定得多。第五个是“Jetson Nano刷完JetPack后开机无限循环重启”。常见原因是供电不足。Jetson Nano对电源质量很敏感很多第三方充电头虽然标称5V/4A但实际带载能力不够或者用了劣质MicroUSB线。换成官方原装电源和高质量数据线后问题很少出现。5.2 一个排查驱动与容器问题的通用思路这几章看下来很多人会发现所谓“疑难杂症”其实有共通逻辑。模型太大就量化、驱动装不上就查依赖、容器有问题就查运行时配置、设备性能差就查功耗模式。整个AI落地链路的排错本质上就是把“硬件、系统、软件栈”三层拆开逐层验证。我个人排查时习惯做一个快速链路验证先用nvidia-smi确认驱动OK再用docker run --gpus all nvidia/cuda:12.0-base nvidia-smi确认容器能透传GPU然后用python -c import torch; print(torch.cuda.is_available())确认PyTorch能识别GPU最后才跑模型推理。任何一层失败问题范围立刻缩小不用对着整条链路瞎猜。这套方法我推荐给身边所有刚开始碰NVIDIA生态的朋友先不谈什么高端优化把“驱动→容器→框架→模型”这条默认路径走通再谈性能和部署优化。新手一上来就追求一次性把模型精度、吞吐量都调好往往是这个心态导致一遇到问题就不知道从哪排查。先把最小闭环跑通比什么都重要。最后分享一个小技巧算是这些年反复折腾下来的一点心得不管用什么渠道下载模型只要你用的是Hugging Face生态拿到权重第一件事先跑一遍transformers自带的验证脚本确认权重文件CRC完整再进部署环节。因为模型文件损坏在下载中断时非常常见而它引发的错误往往伪装成“CUDA OOM”或者“Inference failed”极易把人带到错误的排查方向。多花两分钟验证能省下后面几个小时的定位时间。