今年年初我们团队在规划“内部大模型落地”这件事时定了一个硬约束模型权重、推理服务和微调实验全部要放在本地硬件上不能依赖外部API。最初的采购清单几乎是清一色的N卡但预算一算16GB以上的N卡要么溢价离谱、要么供货遥遥无期于是我们被迫把目光转向了AMD的A卡方案。三个月跑下来团队成了内部第一批把大模型跑在A卡上的人踩了不少坑也积累了一套能被复制的流程。这篇文章把从选型、装机、装驱动、跑推理到微调的完整过程连同那些折腾到怀疑人生的细节一次性写清楚。适合手里已经有A卡、想跑大模型的个人开发者也适合正在纠结“到底买N卡还是A卡”的团队做决策参考。1. 为什么团队会走A卡这条路选型背后的真实账单1.1 先搞清楚我们的需求到底是什么做硬件选型之前我建议所有团队先问自己一个问题你买显卡是回来干嘛的这个答案直接决定你该花多少钱、买什么卡。我们团队的需求分三块。第一块是推理服务给内部同事提供一个类似私有版问答机器人的服务模型量级在7B到14B之间支持多轮对话偶尔插入几百页的离线文档做RAG。第二块是微调实验拿开源底座模型做LoRA微调跑通领域数据融入到场景里的流程batch size不大但要能稳定跑完一个二三十小时的训练任务。第三块是预留扩展希望以后能尝试33B级别的量化模型多卡推理验证一下未来方案的可行性。这三个需求对应的显存底线的确很清晰——7B模型FP16权重大概占14GB加上KV Cache、激活值和推理框架的开销24GB是最舒服的起步。如果只上16GB的卡7B模型只能开很小的上下文很多真实场景根本跑不起来。所以我们当时给采购定的核心指标不是算力峰值而是“单卡显存必须大于等于24GB价格越低越好能买几张算几张”。1.2 为什么首先想到N卡但最后没买成聊A卡之前先承认N卡的优势。CUDA生态确实是一个护城河跑大模型的主流工具链几乎都是为CUDA准备的PyTorch官方版默认CUDA后端HuggingFace Transformers开箱即用vLLM优化得最好甚至很多新模型发布时的性能测试就是在N卡上跑的。如果预算充足、买卡不受限制我大概率也会推荐团队直接上N卡省下来的时间成本可能就是几周的调参和踩坑时间。但现实是2024年底到2025年初这段时间大显存N卡的行情一直在高位。我们看了一圈RTX 4090 24GB价格一直坚挺二手卡水太深不敢碰RTX 6000 Ada、L40S这种48GB级别的专业卡确实适合跑大模型但单片报价够买两台整机了。团队不是大厂预算有限要的是“单位显存成本最低”的方案。这个对比一拉A卡的性价比立刻凸显出来——RX 7900 XTX 24GB价格大致只是同级N卡的一半出头二手市场甚至更低。四张7900 XTX的显存总量是96GB总价却比一张48GB的专业卡还便宜这对我们这种“显存饥饿型”需求来说实在太香了。1.3 选A卡的三个真实理由显存、价格、供货把当时决策的三条核心理由列出来你们感受一下。第一是显存容量。我们买的是RX 7900 XTX24GB GDDR6显存单卡显存和RTX 4090持平。在跑大模型这件事上显存容量比算力峰值更关键。模型要么装得下要么装不下装不下的卡再快也没用装得下之后推理速度只要不是特别离谱日常使用体验都能接受。第二是价格。同显存容量的N卡和A卡价格差距明显A卡大约只有N卡的一半左右。我们把省下来的预算拿去买了更大的内存、更大的NVMe硬盘还配了两台机器留出了“机器崩了有备用”的余量。这对小团队来说非常实际。第三是供货和购买限制。N卡当时普遍要加价、排队A卡基本现货充足电商平台随手就能下单。团队项目是有时间节点的不能等。当然选择A卡也意味着要把生态差距的所有代价自己扛下来。这个后面会详细讲这里先给一个结论如果你的场景是“能跑通、能省预算、不追求极致性能”A卡是完全成立的方案如果你的场景是“必须用最新框架、需要跑满性能、团队没有Linux折腾经验”那请老老实实买N卡。2. A卡跑大模型的底层逻辑先补上CUDA生态缺失的课2.1 为什么说CUDA是护城河A卡到底缺什么要理解A卡跑大模型的难点首先要知道CUDA在大模型里扮演的角色。CUDA是NVIDIA提供的通用并行计算平台它不只是驱动更是一个完整的软件栈底层有PTX中间语言上面有cuBLAS、cuDNN这些高性能数学库再往上才是PyTorch、TensorFlow这些框架。大模型训练和推理本质上是大量的矩阵乘法、卷积运算开发者不用直接写GPU代码只需要调cuDNN、cuBLAS的接口框架再把计算图快速映射到这些库上。这个栈已经很成熟所以N卡跑大模型能这么顺。AMD的对应方案叫ROCm是AMD的开源GPU计算平台里面有HIP编程模型对标CUDA、rocBLAS对标cuBLAS、MIOpen对标cuDNN等组件。理论上ROCm走的是兼容路线HIP甚至可以自动把CUDA源码转成AMD可用代码。但实际差距在工程成熟度上ROCm的bug更多、文档更混乱、支持矩阵更复杂同一个函数在不同架构的卡上表现可能差很多。这里给一个生活类比CUDA像是苹果的App Store生态完备应用点开就能用ROCm更像是开源软件仓库东西都在但要自己编译、自己解决依赖冲突不适合小白。2.2 ROCm的实际可用范围看清楚哪些卡被支持先说结论ROCm对数据中心卡CDNA架构比如MI100、MI200、MI300系列支持最好因为AMD自己卖的就是这些卡消费级游戏卡RDNA架构是后来才慢慢覆盖的支持质量参差不齐老一代GCN架构卡更是早就进入勉强兼容阶段。我们用过的RX 7900 XTX属于RDNA3架构ROCm的gfx编号是gfx1100。ROCm 6.x官方列表里有RDNA3的消费卡支持但如果你用的是RX 6000系列RDNA2gfx1030就需要确认对应ROCm版本还认不认识它。更老的Vega、RX 580这些GCN卡新版本ROCm目录里基本找不到了但有HSA_OVERRIDE_GFX_VERSION这个环境变量可以绕过显卡型号检查强制让驱动按新架构加载能不能稳定工作就看运气。在我们实际测试中RDNA3的7900 XTX跑PyTorch ROCm版本和llama.cpp的HIP后端是没问题的前提是系统、驱动、ROCm版本三者匹配。Windows上的ROCm支持这几年才开放而且只支持部分显卡稳定性也不如Linux。所以我的建议是如果你准备用A卡认真跑大模型直接用Ubuntu 22.04 LTS别在Windows上较劲。Windows下折腾A卡深度学习光是驱动签名、设备管理器“代码39错误”这类问题就能耗掉你一个周末。2.3 软件栈现状Ollama、llama.cpp、PyTorch分别能做什么我们实际用到的软件栈按“开箱即用”程度排个序。最省心的是Ollama。它本身支持AMD显卡的ROCm后端Linux下安装后会自动检测ROCm环境然后模型就能跑起来基本不需要额外配置。如果你想快速验证“这张A卡能不能跑大模型”装Ollama是最快的路径。第二顺位是llama.cpp。它有很多后端包括HIP走ROCm、Vulkan、SYCL等。HIP后端的性能最好适合原生AMD卡但要自己编译稍微折腾一点Vulkan后端兼容性极强几乎什么卡都能跑只是性能略低。llama.cpp的强项是支持GGUF量化格式可以让模型体积和显存占用大幅下降是我们在A卡上跑大模型的主力工具。第三是PyTorch的ROCm版本。HuggingFace Transformers、PEFTLoRA微调库、Accelerate这些工具链都支持ROCm安装时有独立的pip源index-url指名rocm版本就行。这样就能跑标准微调流程但有个前提你要装对ROCm版本和PyTorch版本的组合否则很可能遇到MIOpen编译失败、算子不支持之类的报错。至于vLLM这类高性能推理框架对消费级A卡的支持相对有限。它主要面向数据中心卡RDNA系列卡能跑但编译和配置复杂度明显高我们后续没有深入。3. 实操过程从A卡驱动到跑通第一个大模型3.1 硬件配置清单和装机注意事项这一步写具体配置。我们最终买了两张RX 7900 XTX装在两台机器上一台专门跑推理服务一台用来做微调实验。核心配置如下CPUAMD Ryzen 9 7950X16核32线程。选多核CPU是因为llama.cpp的推理有一部分任务在CPU上执行核心多对速度有帮助。主板X670E平台PCIe 5.0插槽两路PCIe x16。内存64GB DDR5 6000MHz。跑大模型时内存经常被用来做显存溢出和上下文数据缓存内存大一点没有坏处。硬盘2TB NVMe SSD模型文件动辄几十GB顺序读取速度影响模型加载时间。电源1200W金牌电源。两张7900 XTX满载功耗加起来接近800W加上CPU和主板没有1200W会很难看。系统与驱动Ubuntu 22.04.4 LTSROCm 6.1Linux内核6.5。装机的两个细节一定要提。第一是Resizable BAR可调整大小基地址寄存器要在BIOS里打开AMD显卡在开启Resizable BAR后显存访问效率会好一些跑大模型时收益虽然不像游戏那么明显但免费的性能不要白不要。第二是机箱风道7900 XTX满载时发热可观两张卡之间的间距尽量拉大否则第二张卡容易过热降频。我们用了一个全塔机箱加三前三后的风扇布局实测满载温度稳定在75度左右。3.2 安装AMD驱动和ROCm最容易劝退人的环节安装A卡驱动和ROCm是整个流程里最容易劝退人的环节。这里给一份我们跑通的最小操作序列。# 第一步下载并安装amdgpu-install安装包 wget https://repo.radeon.com/amdgpu-install/6.1.60102/ubuntu/jammy/amdgpu-install_6.1.60102-1_all.deb sudo apt install -y ./amdgpu-install_6.1.60102-1_all.deb # 第二步用--rocmrelease参数安装ROCm运行时和开发库 sudo amdgpu-install --usecaserocm --rocmrelease6.1 # 第三步把当前用户加入render和video组避免权限问题 sudo usermod -a -G render,video $USER这里有两个非常关键的坑。首先安装完驱动后不一定立刻生效有时需要重启系统。重启后如果遇到Secure Boot拦截导致驱动加载失败要么在BIOS里关闭Secure Boot要么对驱动做签名我们直接选择了关闭Secure Boot。其次AMD驱动和Linux内核版本绑定很紧内核升级后模块可能不加载重启后显卡直接变成未识别设备。所以装好稳定组合之后不要手贱执行无脑内核升级。装完之后用这两条命令验证成果rocminfo | head -50 rocm-smirocminfo会列出所有能被ROCm识别的GPUrocm-smi会显示每张卡的温度、功耗、显存占用。如果这两条命令能看到你的显卡信息驱动部分就算过了看不到就回到上一步检查组权限和内核模块加载情况。3.3 第一个跑起来的模型Ollama快速验证驱动和ROCm装好后先用Ollama做一次最快验证这个阶段不要碰编译先确认链路通不通。curl -fsSL https://ollama.com/install.sh | sh ollama run qwen2.5:7b第一次运行会自动下载模型权重然后进入对话界面。输入一句“你好”如果几秒内能收到回复说明A卡已经被Ollama识别并且ROCm后端正常工作了。可以在另一个终端执行rocm-smi查看显存占用你会发现显卡显存占用从几十MB的待机状态跳到了6GB以上这就是模型被加载到显存里的直接证据。这里有一个手动加速的小技巧如果Ollama启动时提示找不到ROCm版本或者识别不到显卡可以设置环境变量强制跳过型号检查export HSA_OVERRIDE_GFX_VERSION11.0.0 ollama serve这个变量对我们gfx1100的卡其实不需要但对某些被ROCm版本列表漏掉的显卡型号这一招经常能救命。原理就是告诉驱动“别管这张卡的真实架构编号按这个版本加载”风险是部分底层算子行为不一致属于典型的“能用就行”方案。3.4 更可控的方案用llama.cpp跑GGUF量化模型Ollama适合快速验证但真要长期跑推理服务我更推荐用llama.cpp。它有更细粒度的控制参数还能明确指定多卡分载最重要的是GGUF量化模型在A卡上的显存利用效率实测比Ollama的默认方式更稳定。先编译HIP后端git clone https://github.com/ggerganov/llama.cpp cd llama.cpp cmake -B build -DGGML_HIPON -DCMAKE_C_COMPILER/opt/rocm/bin/amdclang -DCMAKE_CXX_COMPILER/opt/rocm/bin/amdclang cmake --build build --config Release -j16编译过程中最大的坑是耗时HIP后端编译一次大概要十几分钟到半小时耐心等就行。如果编译报找不到HIP头文件确认一下ROCm是不是装到了/opt/rocm这个默认路径如果是自定义路径CMAKE_PREFIX_PATH也要跟着改。模型文件直接去HuggingFace下载GGUF版本比如Qwen2.5-7B-Instruct-GGUF里的qwen2.5-7b-instruct-q4_k_m.gguf。启动服务用这条命令./build/bin/llama-server \ -m /models/qwen2.5-7b-instruct-q4_k_m.gguf \ --host 0.0.0.0 --port 8080 \ -ngl 999 -c 8192-ngl 999表示所有层尽量放到显存-c 8192是上下文长度。启动后访问http://localhost:8080就能看到一个WebUI也可以直接按OpenAI兼容格式调用API接口。我们团队内部问答服务就是这样跑起来的前端对接代码一行没改把API地址从云服务换成这台机器IP就行。3.5 用PyTorch ROCm做一次LoRA微调推理跑通之后就开始尝试微调。这一步的意义在于验证“我们能在这个硬件上训练模型”而不只是“能跑模型”。安装PyTorch ROCm版本pip3 install torch torchvision torchaudio --index-url https://download.pytorch.org/whl/rocm6.1 pip3 install transformers peft accelerate datasets然后在Python里写一个最小的LoRA微调脚本。我们当时用的是一个内部数据集下面代码用HuggingFace自带例子替换from transformers import AutoModelForCausalLM, AutoTokenizer, TrainingArguments, Trainer from peft import LoraConfig, get_peft_model from datasets import load_dataset model_name Qwen/Qwen2.5-7B-Instruct model AutoModelForCausalLM.from_pretrained( model_name, torch_dtypetorch.bfloat16, # A卡上优先用bf16fp16兼容问题多 device_mapauto, trust_remote_codeTrue, ) tokenizer AutoTokenizer.from_pretrained(model_name) lora_config LoraConfig( r8, lora_alpha32, target_modules[q_proj, k_proj, v_proj, o_proj], lora_dropout0.1, ) model get_peft_model(model, lora_config) dataset load_dataset(text, data_files{train: ./data.jsonl}) training_args TrainingArguments( output_dir./lora_out, per_device_train_batch_size1, gradient_accumulation_steps8, learning_rate2e-4, num_train_epochs3, bf16True, logging_steps50, save_steps500, ) trainer Trainer( modelmodel, argstraining_args, train_datasetdataset[train], ) trainer.train()这一段代码里有几个细节是针对A卡专门调的。第一bf16True一定不要改成fp16True。AMD卡上很多算子在fp16下有精度和速度问题而bf16是ROCm生态里支持得更好的格式。第二batch_size1 gradient_accumulation_steps8的组合是为了在单卡24GB显存下模拟出8的等效batch size如果你直接开batch_size87B模型大概率直接OOM。第三device_mapauto可以让Transformers自动把所有模型参数均衡地放到两张卡上多卡微调初级阶段用这个最省心。我们实际跑了一次7B模型单卡LoRA训练大约能到每秒2到3个step一个5k条数据的三轮微调大概需要十二个小时左右。这个速度相比N卡当然不算快但对于搬数据、做实验的节奏来说完全够用你不可能一天到晚都在做微调。4. 多卡扩展与常见问题排查实录4.1 多卡利用率上不去张量并行的真实体验我们很早就想试一试两张卡跑同一个模型的效果目标是跑33B级别量化模型。llama.cpp对多卡的支持方式很简单——按层切分不同层的计算放到不同GPU上。启动命令加一个显存分配比例就行./build/bin/llama-server \ -m /models/qwen2.5-32b-instruct-q4_k_m.gguf \ -ngl 999 \ -ts 1,1 \ --host 0.0.0.0 --port 8080-ts 1,1表示两张卡按1:1比例分配层。实测下来32B Q4量化模型在双卡7900 XTX上确实能跑起来单卡24GB装不下的模型终于可以加载了。这里要提示一个真实感受双卡槽位下token生成速度大概在每秒20到30 token之间比单卡跑7B模型慢了不止一半。原因是消费级A卡之间没有NVLink这类高带宽互联跨卡通信必须走PCIe总线而张量并行相关的通信又很频繁PCIe带宽立刻成为瓶颈。如果你玩过多机多卡方案感受会更明显——跨机器的以太网带宽更不够消费级环境下跑分布式推理基本是吃力不讨好。所以我的建议是A卡多卡方案适合解决“显存容量不够”的问题让你能加载更大的模型但不适合指望它获得几倍的性能加速。在预算有限的情况下优先把单卡显存买大其次再考虑多卡。4.2 常见问题速查表折腾三个月攒出来的清单把我们在A卡上遇到的高频问题整理成一张表按概率排序现象根因解决方法rocminfo里看不到显卡当前用户不在render组或驱动模块没加载加入video,render组后重新登录sudo modprobe amdgpu手动加载Secure Boot导致驱动加载失败BIOS开启Secure Boot进入BIOS关闭Secure Boot或对驱动做签名内核升级后GPU消失内核版本与驱动dkms模块不匹配sudo dkms status查看状态重装对应版本amdgpu-dkmsPyTorch训练时报Miopen编译错误算子缓存未生成或缓存目录损坏删除~/.config/miopen缓存后重跑设置MIOPEN_USER_DB_PATHOllama检测不到ROCm环境显卡型号被ROCm版本跳过设置HSA_OVERRIDE_GFX_VERSION强制指定架构版本推理速度极慢且CPU占用打满模型层没有完全转进显存或上下文过长导致频繁溢写检查-ngl参数是否够大缩短上下文长度显存不足但没报OOM而是越来越慢数据被溢出到系统内存GTT减小batch size/上下文长度使用量化模型Windows设备管理器提示“Windows无法启动这个硬件设备”驱动签名或驱动版本损坏设备管理器更新驱动执行干净卸载后重装AMD Adrenalin驱动显存占用看得见但加载速度特别慢NVMe磁盘顺序读取带宽不够模型放高速NVMe加载时压力测试SSD速度这张表里我想单独强调一下MIOpen缓存问题。第一次在A卡上跑PyTorch训练整个过程卡在某一个算子上十几分钟不动看起来像死机其实是MIOpen在生成算子缓存。这个缓存生成一次之后就快很多了但如果你切换模型结构或升级ROCm版本缓存失效后会重新生成。遇到长时间无响应的现象先别急着杀进程看看是不是MIOpen在干活。4.3 几个独家避坑经验常规文档里不会写的东西第一个经验是“能别碰vLLM就别碰”。我们曾经试图在7900 XTX上把vLLM跑起来折腾了一个周末最后勉强编译通过但推理速度并没有比llama.cpp快多少反而因为各种算子兼容问题频繁崩。vLLM的核心优化PagedAttention确实好但它是围绕数据中心GPU进行过深度调优的消费级RDNA显卡属于“能跑但不在优化路径上”的状态。对A卡来说llama.cpp的GGUF方案才是投入产出比最高的路线。第二个经验是驱动别追新。很多人习惯装了新版驱动就觉得万事大吉但在A卡跑大模型这件事上稳定压倒一切。我们试过把ROCm从6.1升到6.2结果先是一堆库不兼容之后又重新编译了llama.cpp才恢复正常。从那以后我们所有机器都锁版本除非有明确的功能需要不然不碰升级。第三个经验是“内存别省”。64GB系统内存在大模型工作场景里不是奢侈是刚需。原因是ROCm支持把显存放不下的数据溢到系统内存里虽然速度慢但至少不会直接崩溃。如果你想同时开多个实验、加载多个模型系统内存就是最后的缓冲。我们曾经因为内存只有32GB一加载两个7B模型就各种卡顿加到64GB之后稳定了很多。5. 这套方案能跑多远团队后续扩展思考5.1 三个月实测下来的性能数据参考给一组我们实测的参考数据方便大家做预期管理。以下均为本地Linux环境、Ubuntu 22.04、ROCm 6.1、两张RX 7900 XTX的结果单卡跑Qwen2.5-7B-InstructQ4_K_M量化上下文8kllama.cpp后端每秒生成约35到45 token。日常问答场景体感流畅。单卡跑Qwen2.5-14B-InstructQ4_K_M量化上下文8k每秒生成约20到25 token。够用但长文生成会等一会儿。双卡跑Qwen2.5-32B-InstructQ4_K_M量化上下文8k每秒生成约20到30 token。验证可以加载但跨卡通信对速度有影响。单卡LoRA微调7B模型序列长度2048batch size 1 梯度累积8每秒约2到3步5k条数据三轮约12小时。这些数据仅供同一硬件级别的参考。如果你的CPU更强、内存频率更高、或者用的是更新的ROCm版本数字会有波动但量级差不多。对比N卡同等级别比如RTX 4090单卡跑7B Q4量化每秒大概60到80 tokenA卡大概是它的一半左右。但考虑到价格差距这个性能差是可以接受的。5.2 这三个月我们都在用什么适合A卡落地的真实场景经过几个月的磨合团队内部几个确定能用的场景可以分享给你。第一是私有知识库问答。我们有一个内部RAG服务底座用Qwen2.5-7B向量检索用本地部署的小模型A卡单卡就能扛住日常并发响应速度完全够用。第二是代码补全辅助。本地跑一个CodeQwen的量化版单卡显存占用不到16GB配合编辑器插件体验接近云端服务。第三是离线批处理。比如把一堆文档批量生成摘要晚上挂个任务跑第二天早上收结果对延迟不敏感A卡性价比优势充分体现。不建议做的方向是大规模SFT和全参数微调7B以上的全量训练在24GB单卡上会非常痛苦对生成速度有硬指标要求的在线服务比如每token低于100毫秒的实时流式输出A卡很难和同价位N卡竞争。如果团队的核心业务就是追求极致算力直接考虑数据中心卡或者租用云GPU可能是更合适的选择。5.3 如果重来一次我会怎么选这个问题我认真想过。如果预算不变、需求不变我还是会选择A卡但会做两个调整。第一第一张卡直接上7900 XTX第二张卡应该等明确有32B以上模型需求之后再买而不是一开始就配齐。因为多卡的真实收益比想象中有限省下来的钱可以加到系统内存和NVMe上提升更明显。第二我会把Windows下的探索彻底砍掉所有时间都花在Linux环境上。我们在Windows上浪费了不少时间最后全都推倒重来如果是新团队直接用Linux起步能少走很多弯路。我个人在实际操作中的体会是A卡方案从来不是“最好”的方案但它是“在预算约束下最成立”的方案。它逼着我们把底层环境、模型量化、显存管理这些概念一个个搞透了——这些经验反过来让我们在部署模型时比只会点N卡默认配置的人更扎实。如果你也准备走这条路心态放平不要拿A卡和N卡的性能较劲它给你省下来的钱和学到的经验可能比那一点速度差距更值钱。最后再分享一个小技巧所有跑大模型的A卡机器装完环境之后第一件事就是把rocm-smi的输出做一个监控脚本随时看显存、温度、功耗排查问题的时候能少掉一半头发。