企业官网建设流程全解析

今年年初，我们团队在规划“内部大模型落地”这件事时，定了一个硬约束：模型权重、推理服务和微调实验全部要放在本地硬件上，不能依赖外部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 XTX，24GB 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系列（RDNA2，gfx1030），就需要确认对应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、PEFT（LoRA微调库）、Accelerate这些工具链都支持ROCm，安装时有独立的pip源，index-url指名rocm版本就行。这样就能跑标准微调流程，但有个前提：你要装对ROCm版本和PyTorch版本的组合，否则很可能遇到MIOpen编译失败、算子不支持之类的报错。

至于vLLM这类高性能推理框架，对消费级A卡的支持相对有限。它主要面向数据中心卡，RDNA系列卡能跑，但编译和配置复杂度明显高，我们后续没有深入。

3. 实操过程：从A卡驱动到跑通第一个大模型

3.1 硬件配置清单和装机注意事项

这一步写具体配置。我们最终买了两张RX 7900 XTX，装在两台机器上，一台专门跑推理服务，一台用来做微调实验。核心配置如下：

• CPU：AMD Ryzen 9 7950X，16核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 LTS，ROCm 6.1，Linux内核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 --usecase=rocm --rocmrelease=6.1 # 第三步：把当前用户加入render和video组，避免权限问题 sudo usermod -a -G render,video $USER

这里有两个非常关键的坑。首先，安装完驱动后不一定立刻生效，有时需要重启系统。重启后如果遇到Secure Boot拦截导致驱动加载失败，要么在BIOS里关闭Secure Boot，要么对驱动做签名，我们直接选择了关闭Secure Boot。其次，AMD驱动和Linux内核版本绑定很紧，内核升级后模块可能不加载，重启后显卡直接变成未识别设备。所以装好稳定组合之后，不要手贱执行无脑内核升级。

装完之后，用这两条命令验证成果：

rocminfo | head -50 rocm-smi

rocminfo会列出所有能被ROCm识别的GPU，rocm-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_VERSION=11.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_HIP=ON -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_dtype=torch.bfloat16, # A卡上优先用bf16，fp16兼容问题多 device_map="auto", trust_remote_code=True, ) tokenizer = AutoTokenizer.from_pretrained(model_name) lora_config = LoraConfig( r=8, lora_alpha=32, target_modules=["q_proj", "k_proj", "v_proj", "o_proj"], lora_dropout=0.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_size=1, gradient_accumulation_steps=8, learning_rate=2e-4, num_train_epochs=3, bf16=True, logging_steps=50, save_steps=500, ) trainer = Trainer( model=model, args=training_args, train_dataset=dataset["train"], ) trainer.train()

这一段代码里有几个细节是针对A卡专门调的。第一，bf16=True一定不要改成fp16=True。AMD卡上很多算子在fp16下有精度和速度问题，而bf16是ROCm生态里支持得更好的格式。第二，batch_size=1 + gradient_accumulation_steps=8的组合是为了在单卡24GB显存下模拟出8的等效batch size，如果你直接开batch_size=8，7B模型大概率直接OOM。第三，device_map="auto"可以让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卡上遇到的高频问题整理成一张表，按概率排序：

这张表里我想单独强调一下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-Instruct，Q4_K_M量化，上下文8k，llama.cpp后端：每秒生成约35到45 token。日常问答场景体感流畅。
• 单卡跑Qwen2.5-14B-Instruct，Q4_K_M量化，上下文8k：每秒生成约20到25 token。够用，但长文生成会等一会儿。
• 双卡跑Qwen2.5-32B-Instruct，Q4_K_M量化，上下文8k：每秒生成约20到30 token。验证可以加载，但跨卡通信对速度有影响。
• 单卡LoRA微调7B模型，序列长度2048，batch size 1 + 梯度累积8：每秒约2到3步，5k条数据三轮约12小时。

这些数据仅供同一硬件级别的参考。如果你的CPU更强、内存频率更高、或者用的是更新的ROCm版本，数字会有波动，但量级差不多。对比N卡同等级别，比如RTX 4090单卡跑7B Q4量化，每秒大概60到80 token，A卡大概是它的一半左右。但考虑到价格差距，这个性能差是可以接受的。

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的输出做一个监控脚本，随时看显存、温度、功耗，排查问题的时候能少掉一半头发。