1. 为什么选择 7900XTX 跑 Qwen 27B 这条路线1.1 一张消费级卡跑 27B 模型的现实账本手里有一张 7900XTX24GB 显存想跑 Qwen 27B 这个量级的模型这件事在 2024 年之前基本属于“想想就好”但到了现在这条路已经能走通了。我前后折腾了大概三周时间从最初的驱动装不上到后来能稳定跑 4bit 量化的 Qwen 27B中间踩的坑足够写一篇完整的复盘。这篇文章就是把这套方案从头到尾讲清楚包括为什么这么选、每一步怎么做、遇到问题怎么排查。先说清楚这个方案适合谁。如果你手上正好有一张 7900XTX或者正在考虑入手一张大显存卡来做本地推理又不想花几万块去买专业卡那这套方案就是给你准备的。如果你只是想跑个 7B 或者 14B 的小模型那其实没必要看这么长的内容直接装个 Ollama 就完事了。27B 这个量级不一样它对显存、对推理框架、对量化方案都有比较明确的要求不是随便装个软件就能跑起来的。7900XTX 这张卡有意思的地方在于它的硬件规格很猛24GB GDDR6 显存、384 位位宽、960GB/s 的显存带宽纸面参数比很多专业卡都好看。但问题也很明显它是 AMD 的卡软件生态跟 N 卡差距不小。CUDA 那一套东西在 A 卡上用不了得走 ROCm 或者 Vulkan 这条路。这就是为什么很多人买了 7900XTX 之后发现跑 AI 模型各种不顺不是硬件不行是软件栈没配对。Qwen 27B 这个模型本身也值得说一下。通义千问系列从 7B 到 72B 都有27B 这个尺寸属于中间档比 7B 聪明不少又不像 72B 那样对硬件要求那么夸张。27B 的原始权重是 FP16 格式大概需要 54GB 显存才能完整加载这显然超出了 7900XTX 的 24GB。所以必须做量化把权重压缩到 4bit 或者更低才能塞进 24GB 显存里。量化之后模型大概占 14GB 到 16GB 显存剩下的空间留给 KV Cache 和上下文刚好够用。1.2 ROCm 和 Vulkan 两条路线的取舍在 7900XTX 上跑大模型绕不开的一个问题就是走 ROCm 还是走 Vulkan。这两条路线我都试过各有各的优缺点得根据你的具体需求来选。ROCm 是 AMD 官方的计算平台对标的是 N 卡的 CUDA。它的优势在于性能释放更充分尤其是矩阵运算这块ROCm 能调用显卡的 AI 加速单元推理速度比 Vulkan 快不少。但 ROCm 的问题也很明显版本兼容性很挑剔驱动、内核、Python 版本、PyTorch 版本这几个东西必须严格对应错一个就可能跑不起来。而且 ROCm 在 Windows 上的支持一直不太行基本上得在 Linux 环境下用或者走 WSL2。Vulkan 是一条更通用的路线它不依赖 AMD 的官方计算栈而是通过图形 API 来做通用计算。llama.cpp 对 Vulkan 的支持很好编译起来也简单基本上装个 Vulkan SDK 就能跑。Vulkan 的优点是跨平台、兼容性好Windows 上也能直接用不用折腾 WSL。但缺点是性能比 ROCm 差一截大概慢 20% 到 30%而且对某些量化格式的支持不如 ROCm 完善。我自己的选择是日常使用走 Vulkan因为稳定、省心需要跑长上下文或者批量推理的时候切到 ROCm把性能榨出来。下面两套方案我都会讲你可以根据自己的情况选。提示如果你用的是 Windows 系统又不想折腾 WSL那直接走 Vulkan 路线是最省事的。ROCm 在 Windows 上的支持一直不完整强行装容易出各种奇怪的问题。1.3 量化方案怎么选才不爆显存量化是这套方案里最关键的一步。27B 模型不量化根本跑不起来但量化方案选不好要么显存爆了要么模型变傻要么推理速度慢得没法用。目前主流的量化格式有几种GGUF、GPTQ、AWQ。在 7900XTX 上我推荐用 GGUF 格式因为 llama.cpp 对 GGUF 的支持最好而且 Vulkan 和 ROCm 都能跑。GPTQ 和 AWQ 主要是给 N 卡用的A 卡上支持没那么好。GGUF 量化有几个档位从 Q2 到 Q8 都有。Q2 压缩最狠模型文件最小但精度损失也最大27B 的 Q2 量化之后可能还不如 14B 的 Q4 聪明。Q4 是甜点档4bit 量化模型大概 14GB 到 16GB精度损失在可接受范围内。Q5 和 Q6 精度更高但显存占用也更大24GB 卡跑 Q5 就比较紧张了上下文一长就容易爆。我的建议是首选 Q4_K_M 这个量化版本。K_M 代表的是混合量化对不同的层用不同的量化精度关键层保留更高精度非关键层压缩得更狠。实测下来Q4_K_M 的 Qwen 27B 在 7900XTX 上跑显存占用大概 15GB 左右留 9GB 给 KV Cache上下文能开到 8K 到 16K日常对话和文档处理够用了。如果你对精度要求特别高可以试试 Q5_K_M但上下文就得压到 4K 以内不然显存会爆。Q6 和 Q8 就不建议在 24GB 卡上跑了除非你只跑很短的上文。量化版本模型大小显存占用推荐上下文精度评价Q2_K约 9GB约 10GB32K损失明显不推荐Q3_K_M约 12GB约 13GB16K-32K勉强可用Q4_K_M约 15GB约 16GB8K-16K甜点档推荐Q5_K_M约 18GB约 19GB4K-8K精度好显存紧Q6_K约 21GB约 22GB2K-4K显存太紧不推荐Q8_0约 27GB超出显存无法运行24GB 卡跑不了2. 环境准备驱动、运行时和推理框架2.1 ROCm 路线的完整安装流程走 ROCm 路线的话我建议用 Ubuntu 22.04 或者 24.04这两个版本的 ROCm 支持最完善。Windows 用户如果非要走 ROCm得用 WSL2但 WSL2 下的 ROCm 性能会有损耗而且驱动问题更多不太推荐。安装 ROCm 的第一步是装驱动。AMD 的驱动分两部分内核模块和用户态运行时。内核模块负责跟显卡硬件通信用户态运行时提供计算接口。在 Ubuntu 上可以用 apt 来装# 添加 ROCm 仓库 wget https://repo.radeon.com/rocm/rocm.gpg.key -O - | sudo apt-key add - echo deb [archamd64] https://repo.radeon.com/rocm/apt/6.0/ ubuntu main | sudo tee /etc/apt/sources.list.d/rocm.list # 更新并安装 sudo apt update sudo apt install rocm-hip-sdk rocm-opencl-sdk装完之后把当前用户加到 render 和 video 组里不然没权限访问显卡sudo usermod -a -G render,video $USER然后重启重启之后用rocminfo检查一下显卡有没有被识别。如果输出里能看到你的 7900XTX说明驱动装好了。如果看不到大概率是内核模块没加载可以试试sudo modprobe amdgpu。接下来装 PyTorch。注意PyTorch 官方对 ROCm 的支持是分版本的你得去 PyTorch 官网查一下哪个版本对应哪个 ROCm 版本。比如 ROCm 6.0 对应 PyTorch 2.2 或者 2.3。装的时候用 pip 指定 ROCm 版本的 wheelpip install torch torchvision --index-url https://download.pytorch.org/whl/rocm6.0装完之后验证一下import torch print(torch.cuda.is_available()) # ROCm 下也是这个接口 print(torch.cuda.get_device_name(0))如果输出是 True 和你的显卡型号那就没问题了。注意ROCm 的版本兼容性非常严格。ROCm 6.0 配 PyTorch 2.2 是稳的配 2.3 可能有问题。装之前一定去 PyTorch 官网查兼容性矩阵别凭感觉装。2.2 Vulkan 路线的轻量级方案Vulkan 路线就简单多了不需要装 ROCm 那一大堆东西只需要装 Vulkan SDK 和显卡驱动就行。Windows 上直接去 AMD 官网下载最新的 Adrenalin 驱动装完之后 Vulkan 运行时就有了。Linux 上装vulkan-tools和mesa-vulkan-drivers就行。然后编译 llama.cpp。llama.cpp 对 Vulkan 的支持是内置的编译的时候加个-DGGML_VULKANON就行git clone https://github.com/ggerganov/llama.cpp cd llama.cpp mkdir build cd build cmake .. -DGGML_VULKANON -DCMAKE_BUILD_TYPERelease make -j$(nproc)编译完之后用./llama-cli --version检查一下如果输出里有 Vulkan 相关的信息说明编译成功了。Vulkan 路线的优点是简单、稳定、跨平台Windows 和 Linux 都能用。缺点是性能比 ROCm 差一些而且 llama.cpp 的 Vulkan 后端对某些量化格式的支持还在完善中Q4_K_M 是肯定没问题的但更冷门的格式可能跑不了。2.3 推理框架选型llama.cpp 还是其他在 7900XTX 上跑 Qwen 27B推理框架的选择其实不多。Ollama 虽然方便但它对 A 卡的支持主要是通过 ROCm而且版本更新比较慢不一定能跟上最新的 ROCm。vLLM 对 A 卡的支持也一般主要是给 N 卡设计的。llama.cpp 是目前最靠谱的选择。它对 Vulkan 和 ROCm 都有支持GGUF 格式也是它主推的社区活跃更新快。而且 llama.cpp 有 server 模式可以起一个 OpenAI 兼容的 API方便跟其他工具集成。如果你想要更好的性能可以试试llama-cpp-python它是 llama.cpp 的 Python 绑定可以在 Python 里直接调用。但注意llama-cpp-python编译的时候要指定 Vulkan 或者 ROCm 后端不然默认是 CPU 推理慢得没法用。# 编译 llama-cpp-python 并启用 Vulkan CMAKE_ARGS-DGGML_VULKANON pip install llama-cpp-python --no-binary llama-cpp-python3. 模型下载与量化文件选择3.1 去哪里下载 Qwen 27B 的 GGUF 文件Qwen 27B 的官方权重在 Hugging Face 和 ModelScope 上都有但官方权重是 FP16 格式的不能直接跑。你需要找已经量化好的 GGUF 文件。目前社区里做 Qwen 量化的主要有几个人比如 TheBloke、bartowski 这些他们的量化质量比较可靠。下载的时候注意看清楚文件名。GGUF 文件的命名规则一般是模型名-量化版本.gguf比如qwen-27b-Q4_K_M.gguf。有些文件会分片比如qwen-27b-Q4_K_M-00001-of-00002.gguf这种要把所有分片都下载下来放在同一个目录里。下载工具推荐用huggingface-cli或者modelscope的命令行工具比浏览器直接下稳定得多而且支持断点续传。# 用 huggingface-cli 下载 huggingface-cli download bartowski/Qwen-27B-GGUF Qwen-27B-Q4_K_M.gguf --local-dir ./models如果下载速度慢可以试试 ModelScope 的镜像国内访问会快很多。3.2 量化版本的实际体验对比我前后试了 Q3_K_M、Q4_K_M 和 Q5_K_M 三个版本说一下实际感受。Q3_K_M 的文件大概 12GB显存占用 13GB 左右上下文能开到 32K。但精度损失比较明显问一些需要推理的问题比如数学题或者逻辑题经常答错。日常闲聊还行但正经用不太够。Q4_K_M 是 15GB 左右显存占用 16GB上下文 8K 到 16K。这个版本的精度已经比较接近原始模型了我拿它做代码生成和文档总结效果都还不错。偶尔会有一些小错误但整体可用性很高。Q5_K_M 是 18GB显存占用 19GB上下文只能开到 4K 到 8K。精度确实更好一些但显存太紧张了稍微长一点的对话就会爆。如果你主要做短文本处理比如分类、抽取那 Q5 可以试试。但如果要做长文档分析还是 Q4 更实用。提示量化版本的选择没有绝对的好坏关键看你的使用场景。短文本高精度选 Q5长文本通用选 Q4显存特别紧张才考虑 Q3。3.3 显存分配的计算逻辑24GB 显存怎么分配这个得算一下。模型权重占一部分KV Cache 占一部分还有推理过程中的临时缓冲区。KV Cache 的大小跟上下文长度、模型层数、注意力头数都有关系。Qwen 27B 大概是 48 层隐藏维度 5120注意力头数 40。KV Cache 的显存占用公式大概是KV Cache 大小 2 * 层数 * 上下文长度 * 隐藏维度 * 精度字节数以 8K 上下文、FP16 精度为例2 * 48 * 8192 * 5120 * 2 约 8GB如果用量化 KV Cache比如 Q8能压缩到 4GB 左右。所以 Q4_K_M 模型占 16GBKV Cache 占 4GB 到 8GB加起来 20GB 到 24GB刚好卡在 7900XTX 的显存上限。这就是为什么上下文不能开太大开到 16K 以上就很容易爆显存。llama.cpp 启动的时候可以指定--ctx-size来控制上下文长度还可以用--cache-type-k和--cache-type-v来指定 KV Cache 的量化精度。我一般用--cache-type-k q8_0 --cache-type-v q8_0能省不少显存。4. 实操从零跑通 Qwen 27B4.1 llama.cpp 编译与参数配置假设你已经装好了 Vulkan SDK 或者 ROCm现在来编译 llama.cpp。我以 Vulkan 路线为例ROCm 路线把-DGGML_VULKANON换成-DGGML_HIPBLASON就行。git clone https://github.com/ggerganov/llama.cpp cd llama.cpp mkdir build cd build cmake .. -DGGML_VULKANON -DCMAKE_BUILD_TYPERelease -DLLAMA_CURLON make -j$(nproc)编译完成之后在build/bin目录下会有llama-cli、llama-server等可执行文件。先跑一下llama-cli测试./llama-cli -m /path/to/qwen-27b-Q4_K_M.gguf \ -p 你好请介绍一下你自己 \ -n 256 \ --ctx-size 8192 \ -ngl 99 \ --cache-type-k q8_0 \ --cache-type-v q8_0参数解释一下-ngl 99是把所有层都放到 GPU 上99 是层数上限实际有多少层就放多少层。--ctx-size 8192是上下文长度。--cache-type-k和--cache-type-v是 KV Cache 的量化精度q8_0 能省一半显存。如果跑起来了你会看到模型开始生成文字。第一次加载模型会慢一些因为要把权重从硬盘读到显存里。加载完之后生成速度大概在 20 到 30 token/s这个速度对于本地推理来说已经很快了。4.2 起一个 OpenAI 兼容的 API 服务llama-cli适合测试但日常用的话起一个 API 服务更方便。llama-server就是干这个的./llama-server -m /path/to/qwen-27b-Q4_K_M.gguf \ --ctx-size 8192 \ -ngl 99 \ --cache-type-k q8_0 \ --cache-type-v q8_0 \ --host 0.0.0.0 \ --port 8080起来之后访问http://localhost:8080就能看到一个 Web UI可以直接在浏览器里跟模型对话。同时它也提供 OpenAI 兼容的 API端点地址是http://localhost:8080/v1/chat/completions可以用任何 OpenAI 客户端来调用。from openai import OpenAI client OpenAI(base_urlhttp://localhost:8080/v1, api_keynot-needed) response client.chat.completions.create( modelqwen-27b, messages[{role: user, content: 写一个 Python 快速排序}], temperature0.7, max_tokens512 ) print(response.choices[0].message.content)这样就能把本地模型接入到各种工具里了比如 Continue、Cursor、Open WebUI 这些。4.3 性能调优让 7900XTX 跑得更快默认配置下7900XTX 跑 Qwen 27B Q4_K_M 大概能到 25 token/s 左右。如果想再快一点可以试试这几个调优手段。第一调整 batch size。llama.cpp 默认的 batch size 是 512可以调到 1024 或者 2048能提高吞吐量。但 batch size 太大会增加显存占用得根据实际情况调。--batch-size 1024 --ubatch-size 512第二用 Flash Attention。llama.cpp 支持 Flash Attention能减少注意力计算的显存占用和计算量。启动的时候加-fa参数就行。第三如果走 ROCm 路线可以试试HSA_OVERRIDE_GFX_VERSION环境变量。7900XTX 的 GFX 版本是 11.0.0但有些 ROCm 版本会把它识别成别的版本导致性能下降。设置这个变量可以强制指定export HSA_OVERRIDE_GFX_VERSION11.0.0第四关闭不必要的后台程序。7900XTX 的显存是共享的如果桌面环境或者其他程序占用了显存留给模型的空间就少了。跑模型的时候尽量关掉浏览器、游戏这些吃显存的程序。调优手段预期提升注意事项增大 batch size10%-20%显存占用增加启用 Flash Attention5%-15%需要 llama.cpp 支持设置 HSA_OVERRIDE10%-30%仅 ROCm 路线有效关闭后台程序5%-10%释放显存5. 常见问题与排查实录5.1 模型加载失败或显存不足这是最常见的问题。报错信息一般是CUDA out of memory或者failed to allocate buffer。原因通常是显存不够或者量化版本选得太高。排查思路先看模型文件大小Q4_K_M 的 27B 模型大概 15GB如果显存只有 24GB加载完之后剩 9GB 给 KV Cache 和计算缓冲区。如果上下文开到 16KKV Cache 就要 8GB 以上很容易爆。解决办法降低上下文长度或者换更低的量化版本。也可以试试--no-kv-offload把 KV Cache 放到内存里但这样速度会慢很多。注意llama.cpp 启动的时候会预分配显存如果预分配失败它会直接报错退出。所以看到显存不足的报错第一反应就是降上下文或者降量化。5.2 推理速度慢得离谱如果生成速度只有几 token/s那大概率是模型没跑在 GPU 上而是跑在 CPU 上了。检查一下启动参数里有没有-ngl 99这个参数控制有多少层放到 GPU 上。如果没加默认是 0全部跑 CPU。另一个可能是 Vulkan 或者 ROCm 没编译进去。用./llama-cli --version看一下输出如果只有 CPU 相关的信息没有 Vulkan 或者 ROCm那就是编译的时候没启用对应的后端。还有一种情况是显卡驱动有问题。ROCm 下可以用rocm-smi看一下显卡状态如果显存占用一直是 0说明模型根本没加载到显卡上。5.3 输出乱码或重复模型输出乱码或者不停重复同一句话通常是量化版本的问题。Q2 和 Q3 的量化损失比较大容易出现这种情况。换成 Q4_K_M 或者 Q5_K_M 一般就能解决。如果换了量化版本还是有问题可能是 prompt 格式不对。Qwen 系列有特定的对话模板llama.cpp 会自动应用但如果你手动构造 prompt格式错了就会导致输出异常。建议用llama-server的 chat 接口它会自动处理模板。还有一个可能是温度参数设得太高。温度太高会导致输出随机性过大看起来像乱码。试试把温度降到 0.7 以下。5.4 ROCm 版本兼容性踩坑记录ROCm 的版本兼容性是我踩坑最多的地方。有一次装了 ROCm 6.0PyTorch 装的是 2.3结果torch.cuda.is_available()一直返回 False。查了半天才发现 PyTorch 2.3 对应的是 ROCm 6.1跟 6.0 不兼容。换成 PyTorch 2.2 就好了。还有一次是内核版本的问题。Ubuntu 22.04 默认的内核是 5.15但 ROCm 6.0 需要 5.19 以上的内核。升级内核之后才正常。所以我的建议是装 ROCm 之前先去 AMD 官网查一下系统要求把内核版本、驱动版本、PyTorch 版本都确认一遍。别嫌麻烦这一步省了后面更麻烦。问题现象可能原因解决办法模型加载报显存不足量化版本太高或上下文太长降量化或降上下文推理速度只有几 token/s模型跑在 CPU 上加-ngl 99参数输出乱码或重复量化损失大或 prompt 格式错换 Q4_K_M 或检查模板ROCm 下 GPU 不可用版本不兼容查兼容性矩阵换对应版本Vulkan 编译失败缺少 Vulkan SDK安装 Vulkan SDK 和驱动5.5 长期运行的稳定性维护本地跑大模型不是跑一次就完事了长期运行的话有几个地方要注意。散热是个大问题。7900XTX 的功耗不低满载能到 350W 以上长时间跑推理显卡温度会比较高。建议机箱风道做好一点或者给显卡单独加个风扇。温度太高会导致降频推理速度会掉。显存泄漏也需要注意。llama.cpp 本身做得不错但如果你用 Python 绑定长时间运行可能会有显存泄漏。建议定期重启服务或者用rocm-smi监控显存占用发现异常就重启。日志要留着。llama-server 会把请求日志打到标准输出建议重定向到文件里方便排查问题。如果遇到崩溃日志里一般会有线索。最后模型文件最好放在 SSD 上。27B 的模型文件 15GB 左右放在机械硬盘上加载会很慢每次启动都要等好几分钟。SSD 上大概几十秒就能加载完。6. 这套方案还能怎么扩展6.1 接入本地知识库做 RAG光跑一个模型只能做通用对话如果要让它回答特定领域的问题得接一个知识库。RAG 是最常见的做法把文档切块、向量化、存到向量数据库里提问的时候先检索相关片段再让模型基于片段回答。llama.cpp 本身不提供 RAG 功能但可以配合其他工具来做。比如用langchain或者llama-index来搭建 RAG 流程向量数据库用 Chroma 或者 Qdrant嵌入模型可以用bge-m3或者text-embedding系列。from langchain_community.llms import LlamaCpp from langchain_community.vectorstores import Chroma from langchain_community.embeddings import HuggingFaceEmbeddings # 加载本地模型 llm LlamaCpp( model_path/path/to/qwen-27b-Q4_K_M.gguf, n_gpu_layers99, n_ctx8192, verboseFalse ) # 加载嵌入模型和向量库 embeddings HuggingFaceEmbeddings(model_nameBAAI/bge-m3) vectorstore Chroma(persist_directory./chroma_db, embedding_functionembeddings) # 检索并生成 query 公司的报销流程是什么 docs vectorstore.similarity_search(query, k3) context \n.join([doc.page_content for doc in docs]) response llm.invoke(f基于以下内容回答问题\n{context}\n\n问题{query}) print(response)这样就能让 Qwen 27B 基于你自己的文档来回答了。注意RAG 的效果很大程度上取决于文档切分和检索的质量切分粒度太粗或者太细都会影响效果。6.2 LoRA 微调让模型更懂你的领域如果 RAG 还不够可以考虑做 LoRA 微调。LoRA 是在预训练模型的基础上加一个小型的适配器层只训练这个适配器不动原始权重。这样显存需求小很多27B 的模型做 LoRA 微调24GB 显存勉强够用。微调工具推荐用LLaMA-Factory或者unsloth。unsloth对显存的优化更好但主要支持 N 卡。A 卡上可以用LLaMA-Factory它支持 ROCm。微调的数据格式一般是 JSONL每条数据包含instruction、input、output三个字段。数据质量比数量重要几百条高质量的数据就能有不错的效果。# 用 LLaMA-Factory 做 LoRA 微调 llamafactory-cli train \ --model_name_or_path /path/to/qwen-27b \ --stage sft \ --do_train \ --dataset my_dataset \ --template qwen \ --output_dir ./lora_output \ --per_device_train_batch_size 1 \ --gradient_accumulation_steps 8 \ --learning_rate 1e-4 \ --num_train_epochs 3 \ --lora_rank 8 \ --lora_target q_proj,v_proj微调完之后把 LoRA 适配器和原始模型合并再转成 GGUF 格式就能用 llama.cpp 加载了。6.3 多模型切换与资源管理如果你不止跑一个模型比如同时跑 Qwen 27B 和一个嵌入模型那就需要做资源管理。24GB 显存跑两个模型比较紧张建议用llama-server的模型切换功能或者用ollama来管理多个模型。ollama的好处是模型管理方便ollama pull和ollama run就能切换模型。但它对 A 卡的支持主要是 ROCm而且版本更新慢。如果你用 Vulkan 路线还是直接用 llama.cpp 更灵活。另一个思路是用llama-swap这类工具它可以根据请求自动切换模型不用手动重启服务。但切换模型需要重新加载权重会有几秒到几十秒的延迟。提示24GB 显存同时跑多个模型不太现实建议一次只跑一个需要切换的时候再加载。如果非要同时跑可以考虑把嵌入模型放到 CPU 上虽然慢一点但省显存。6.4 远程访问与安全注意事项本地跑模型如果想在局域网内其他设备上访问可以把llama-server的--host设成0.0.0.0然后通过 IP 访问。但注意这样局域网内任何人都能访问你的模型如果网络环境不安全建议加个反向代理和认证。如果要在公网访问那就更要注意安全了。不要直接把端口暴露到公网至少加个 HTTPS 和 token 认证。可以用 Nginx 做反向代理配置 SSL 证书和 Basic Auth。server { listen 443 ssl; server_name your-domain.com; ssl_certificate /path/to/cert.pem; ssl_certificate_key /path/to/key.pem; location / { auth_basic Restricted; auth_basic_user_file /etc/nginx/.htpasswd; proxy_pass http://127.0.0.1:8080; } }这样外网访问就需要用户名密码了。虽然麻烦一点但安全第一。我个人在实际操作中的体会是7900XTX 跑 Qwen 27B 这套方案最难的不是技术本身而是耐心。ROCm 的版本兼容性、Vulkan 的编译配置、量化版本的选择每一个环节都可能卡住。但只要按部就班地排查总能跑通。跑通之后本地有一个 27B 的模型随时可用不用担心网络问题不用担心数据隐私这种体验是云端 API 给不了的。最后再分享一个小技巧如果你在 ROCm 和 Vulkan 之间犹豫可以先装 Vulkan 版本跑起来确认模型能用之后再折腾 ROCm 版本对比性能。这样至少有一个能用的版本保底不会两头都卡住。