4.5 部署 Checklist 与跨硬件迁移

4.5 部署 Checklist 与跨硬件迁移

走过 4.1 到 4.4，你已经能在一个特定环境下把 INT4 模型跑起来、跑得对、跑得稳。但现实是，你的部署不会只发生一次——换模型、换显卡、换服务器、给同事复现，这些场景会反复出现。这一节把整个第4章的实战经验，固化成一份可复用的部署 Checklist，并讲清跨硬件迁移时最容易出错的几个点。

我自己部署过几十次不同的模型-硬件组合，最深的体会是：部署的可靠性来自流程的标准化，而不是个人的熟练度。一份好的 Checklist，能让一个没经验的新人，也能按步骤完成一次正确的部署；而没有 Checklist 的部署，老手也会在某个环节掉链子。

部署 Checklist：从零到可用

我把一次完整的 INT4 本地部署，拆成五个阶段，每个阶段都有必须核对的项。

阶段一：环境准备

• 宿主机 NVIDIA 驱动已安装，nvidia-smi 正常显示 GPU。
• CUDA 版本与 llama.cpp 编译版本匹配（nvcc --version 确认）。
• llama.cpp 已从源码编译（用对应硬件的 CUDA_ARCHITECTURES），llama-server、llama-quantize、llama-perplexity、llama-bench 都可用。
• 系统内存足够（至少是模型权重的 1.5 倍，给 KV Cache 和 offload 留余量）。

这一阶段最容易漏的是 CUDA_ARCHITECTURES。预编译包不一定覆盖你的卡，自己编译时务必带上。我帮人排查的"速度慢 10 倍"问题，一半以上根因在这里。

阶段二：模型准备

• 已下载官方原始权重（F16 或 BF16 的 safetensors），并校验文件完整性（SHA256）。
• 已用 llama-convert 转换为 F16 GGUF 中间文件，转换日志无报错。
• 已决定量化方法（一般起步用 Q4_K_M），了解该方法的特性（2.3 节对比过）。
• 校准集已准备（如果用需要校准的方法如 GPTQ/AWQ；GGUF k-quants 不需要）。

权重完整性校验常被忽略，但很重要。下载中断或不完整的权重，转换时可能不报错，量化后却出各种怪问题。养成下完先校验 SHA256 的习惯。

阶段三：量化与验证

• 已用 llama-quantize 生成目标档位的 GGUF 文件，量化日志无异常。
• 已用 llama-perplexity 测量量化前后 PPL，确认损失在正常范围（Q4 通常 <5%）。
• 已用 llama-bench 测量 prefill 和 decode 速度，建立性能基线。

PPL 验证是质量保险。跳过这一步直接用，万一量化有问题，你要到生产环境才暴露，代价大得多。

阶段四：加载与运行

• 启动 llama-server 时 -ngl 设为全量 offload（或显存不够时的合理部分 offload）。
• -c 上下文长度根据显存余量设定（参考 4.1 的显存账）。
• 启动后 nvidia-smi 确认 GPU 在工作（利用率非零）。
• 已发测试请求验证对话正常（4.3 的 curl 验证）。
• 采样参数已设置合理值（temp 0.7、top-p 0.9 起步）。

阶段五：性能与稳定性

• 已测过并发场景下的表现（如果有并发需求，开 -cb）。
• 已配置日志和监控（至少记录请求延迟、错误率）。
• 已配置自动重启机制（systemd 或 supervisor，进程挂了能拉起）。
• 已准备回滚方案（量化模型出问题时，能快速切回 F16 或上一版本）。

跨硬件迁移：最容易出错的几个点

同一套部署流程，换一张卡就可能出问题。跨硬件迁移时，以下几个点要特别小心。

算力兼容性

不同架构的 GPU 算力不同，llama.cpp 必须为对应算力编译。从 A100 迁到 4090，或者从 4090 迁到 3090，都要重新编译并确认 CUDA_ARCHITECTURES 覆盖了新卡。直接拷贝编译产物到新机器跑，可能报 "no kernel image" 错误（4.4 讲过）。

显存容量差异

不同卡的显存差异巨大，直接套用之前的 -c 和 -ngl 参数很可能 OOM 或浪费。迁到新卡后，要重新算显存账，重新调参。小卡上可能要降低上下文长度或减少 offload 层数；大卡上可以更激进地开长上下文或多实例。

内存带宽差异

INT4 量化是显存带宽敏感的——生成速度很大程度上取决于带宽。消费级卡（如 4090，带宽约 1TB/s）和企业级卡（如 A100，带宽约 2TB/s）的性能差异，在 INT4 上会被放大。不要拿消费级卡的 benchmark 去预期企业级卡，反之亦然。迁移后要重新跑 llama-bench 建立新基线。

驱动和 CUDA 版本

不同机器的驱动版本可能不同，而驱动版本决定了支持的 CUDA 上限。从新机器迁到老机器，可能因为驱动太老而跑不起来。迁移前先确认目标机器的驱动版本是否满足要求，必要时先升级驱动。

给团队推广 INT4 部署的建议

如果你要把 INT4 部署推广到团队，光有 Checklist 还不够，还要有配套的工程化措施。

统一基础镜像。把 llama.cpp 编译产物、常用模型文件、启动脚本打包成一个 Docker 镜像，团队成员直接拉镜像用，不用各自编译。这能消除"编译环境不一致"导致的大量问题（本系列 Docker+Cuda 教程详细讲了镜像化管理）。

文档化每次部署。把"什么模型、什么硬件、什么参数、性能数据"记录下来，形成团队的知识库。下次有人要在类似环境部署，直接参考已有记录，不用从零摸索。

建立模型仓库。常用的量化模型文件统一存放在团队可访问的位置（对象存储或 NAS），避免每个人各自下载和量化。量化一次，全队复用。

第4章的收尾

至此第4章完成。从 4.1 的算账选型，到 4.2 的转换量化，到 4.3 的加载运行，到 4.4 的报错调优，再到 4.5 的 Checklist 和迁移——我们走完了 INT4 本地部署的完整链路。这套流程的核心价值不在于"教会你某个命令"，而在于帮你建立因果链和可复用的流程，让你面对任何新模型、新硬件时，都能有条不紊地把事情做对。

下一章（第5章）是总结展望，把全书的方法论收拢，并聊聊 INT4 之后的进阶方向。