断网环境下的本地大模型生存指南

上周公司内网进行安全升级，整个研发区域被强制切断了外网连接。对于习惯了云端 API 和在线拉取模型的我来说，这简直是一场“数字荒岛”求生。更棘手的是，我手头的主力机是一台搭载 AMD Ryzen AI 处理器和 Radeon RX 7900 GRE 显卡的工作站。在 NVIDIA 生态统治大模型推理的今天，AMD 平台的本地部署往往伴随着更多的折腾。但这次断网危机，反而逼我彻底摸清了 Ollama 在纯离线环境下与 AMD 显卡协作的整套流程。如果你也身处对隐私极度敏感、网络受限或硬件特殊的场景，这份基于实战的“离线生存手册”或许能帮你少走弯路。

离线模型资产的获取与手动导入

在没有网络的情况下，Ollama 最引以为傲的 ollama pull 命令直接失效。这时候，我们必须转变思路：将模型视为普通的文件资产，通过物理介质（如移动硬盘）进行转移。

首先，你需要在一台有网络的机器上完成准备工作。Ollama 的模型底层实际上是基于 GGUF 格式的文件，但为了方便管理和元数据记录，建议直接导出为 Ollama 专用的打包格式，或者单纯下载 GGUF 文件后重新构建。

在有网机器上，执行以下命令将已下载的模型导出为 tar 包：

ollama save llama3:8b -f llama3-8b-offline.tar

将这个 .tar 文件拷贝到断网的 AMD 工作站上。接下来的导入过程非常直观，Ollama 会自动解析包内的元数据和权重文件：

ollama load llama3-8b-offline.tar

如果你的模型来源是社区下载的原始 GGUF 文件（例如从 Hugging Face 镜像站提前扒下来的），则需要通过 Modelfile 进行手动组装。创建一个名为 Modelfile 的文本文件，内容只需一行：

FROM ./qwen2.5-7b-instruct-q4_k_m.gguf

然后执行创建命令：

ollama create qwen2.5-custom -f Modelfile

这一步看似简单，但在 AMD 平台上有一个关键细节：务必确认 GGUF 文件的量化版本。Radeon 显卡的显存虽然大，但带宽和计算单元架构与 NVIDIA 不同，过高精度（如 FP16）可能导致推理速度骤降，而过低精度（如 Q2_K）又会影响长文本的逻辑连贯性。经过多次测试，Q4_K_M 或 Q5_K_M 是在 Radeon 7000 系列上平衡速度与质量的最佳甜点。

定制 Modelfile 以适配 Radeon 硬件资源

离线环境意味着没有云端的自动优化，一切参数都需要我们手动调优。Ollama 的强大之处在于其 Modelfile 允许我们像编写 Dockerfile 一样定义模型的行为。针对 AMD 显卡的特性，我们需要重点调整上下文窗口和 GPU 卸载层数。

Radeon 显卡在 ROCm 支持下表现不错，但在处理长文本时，显存管理尤为关键。默认的上下文长度（通常是 4096）对于文档分析来说捉襟见肘。我创建了一个专门用于长文本分析的 Modelfile：

FROM qwen2.5-custom

# 设置系统提示词，强化长文本总结能力
SYSTEM """
你是一位专业的文档分析助手。请专注于提取用户提供的长文本中的关键信息，
忽略无关的寒暄。输出结果需结构清晰，使用 Markdown 列表展示。
"""

# 关键参数调整
PARAMETER num_ctx 16384
PARAMETER num_gpu 99
PARAMETER temperature 0.7

这里的 num_ctx 16384 是将上下文窗口扩大到 16k，足以容纳数十页的技术文档。而 num_gpu 99 是一个激进但必要的设置，它指示 Ollama 尝试将所有模型层都卸载到 GPU 上运行。在 NVIDIA 生态中这通常由 OLLAMA_GPU_LAYERS 环境变量控制，但在 Ollama 的 Modelfile 中，num_gpu 参数能更持久地固化这一配置。

保存该文件后，重新创建模型实例：

ollama create qwen-long-docs -f Modelfile_long

这样做的好处是，每次运行 ollama run qwen-long-docs 时，无需重复输入复杂的参数，模型已经“记住”了它专为长文本和全 GPU 加速而生的身份。

显存监控与长文本运行的稳定性观察

在完全离线且无图形界面监控的情况下，命令行是我们唯一的眼睛。AMD 显卡的显存监控不像 nvidia-smi 那样有一个 universally 的标准工具，但在 Linux 环境下，我们可以结合 rocm-smi 和系统自带工具来构建监控闭环。

首先，确保安装了 ROCm 工具包。在另一个终端窗口中，我习惯运行一个简单的脚本来实时刷新显存占用：

watch -n 1 'rocm-smi --showmeminfo vram'

当启动大模型对话时，可以明显观察到 VRAM 占用的爬升。对于 7B 参数量化的模型，在 16k 上下文下，显存占用通常会稳定在 6GB-8GB 之间。Radeon RX 7900 GRE 拥有 16GB 显存，这给了我们很大的冗余空间去尝试更大的上下文或并发请求。

然而，长时间运行大模型对散热是不小的考验。在一次连续 4 小时的文档批处理任务中，我注意到显卡温度逐渐攀升至 78°C。虽然这在安全范围内，但风扇噪音显著增加。为了维持稳定性，我采取了两个措施：

1. 限制并发请求：Ollama 默认会尝试并行处理请求，这在显存紧张时会触发 Swap，导致速度断崖式下跌。通过设置环境变量 OLLAMA_NUM_PARALLEL=1，强制单线程串行处理，虽然总耗时略增，但避免了显存溢出导致的进程崩溃。
2. 动态调整 Batch Size：在 Modelfile 中加入 PARAMETER num_batch 256。较小的 Batch Size 能降低瞬时显存峰值，虽然牺牲了一点吞吐量，但换来了长时间运行的平稳曲线。

在实际测试中，处理一份 50,000 token 的技术规范文档，Ollama 配合 Radeon 显卡的生成速度大约维持在 25-30 tokens/s。这个速度虽不及顶级 H100，但对于本地离线办公而言，已经完全达到了“可用”甚至“好用”的标准。更重要的是，整个过程数据从未离开过本地机箱，彻底杜绝了泄露风险。

结语

这次断网经历让我意识到，依赖云端并不是唯一的路径。通过精心准备离线模型包、定制化 Modelfile 以及细致的资源监控，AMD 平台完全能够胜任严肃的大模型推理任务。Ollama 在其中扮演了极佳的调度者角色，它将复杂的底层 ROCm 调用封装得简洁易用。对于注重数据隐私的企业内部环境，或是网络条件受限的边缘场景，这套"Ollama + Radeon"的离线组合拳，无疑提供了一份可靠且自主可控的解决方案。下次当你面对断网焦虑时，不妨试试这套流程，你会发现，本地的算力其实比你想象的更强大。