通义千问写迁移发布计划提示词：让AI自动生成检查项

好的，没问题。作为一名在金融系统迁移领域摸爬滚打多年的老兵，我理解你要的绝对不是那种“确认环境、测试功能”的空话。你需要的是能直接贴进SOP、每一步都能落地执行、经得起推敲的检查清单。 下面这份清单，就是专门针对你用vLLM 0.6.3 + A10×2部署Qwen2.5-7B-Instruct模型，在迁入新环境前必须完成的P0级健康检查。每一项都经过了刻意设计，确保它们之间形成逻辑闭环，能真正拦住那些可能导致服务中断超过5分钟或数据丢失的致命隐患。 | 序号 | 检查环节 | 执行命令/操作步骤 | 预期结果 | 责任人 | 是否已验 | | :--- | :--- | :--- | :--- | :--- | :--- | | 1 | **CUDA驱动与vLLM版本兼容性校验** | 1. 登入目标节点，运行 `nvidia-smi` 确认驱动版本。
2. 执行 `python -c "import vllm; print(vllm.__version__); from vllm import _custom_ops as ops; print('Custom ops loaded')"`。
3. 检查vLLM启动日志，排除`CUDA driver version is insufficient`或`nvml: driver/library version mismatch`报错。 | `nvidia-smi` 输出驱动版本≥535.x，且vLLM Custom ops加载畅通，无版本兼容性报错。 | 李明 | | | 2 | **NFS权重文件完整性校验** | 1. 登入目标节点，执行 `sha256sum /opt/models/qwen25-7b/*.safetensors > /tmp/nfs_sha256.txt`。
2. 对照源端由模型发布时生成的SHA256校验和文件，执行 `diff /tmp/nfs_sha256.txt /path/to/source_sha256.txt`。 | `diff`命令无输出差异，表明目标节点所有模型权重文件与源端完全一致。若有差异，则权重已损坏或传输不完整。 | 王磊 | | | 3 | **vLLM进程内存上限与可用显存** | 1. 执行 `python -c "import torch; print(f'Total GPU Memory: {torch.cuda.get_device_properties(0).total_memory / 1024**3:.2f} GiB')"`。
2. 执行 `cat /proc/meminfo | grep MemAvailable`。
3. 模拟启动vLLM服务：`vllm serve /opt/models/qwen25-7b --tensor-parallel-size 2 --gpu-memory-utilization 0.95`，观察启动日志中`GPU memory usage`峰值。 | 1. 单卡空闲显存≥23 GiB（A10显存24 GiB）。
2. 主机剩余内存≥32 GiB（模型KV Cache+系统开销）。
3. vLLM启动时`GPU memory usage`峰值稳定在95%以内，不触发OOM。 | 李明 | | | 4 | **NCCL端口连通性（关键闭环）** | 1. 登入目标节点，执行 `nc -z localhost 29500`。
2. 执行 `ssh localhost 'nc -z 127.0.0.1 29500'`。
3. 查看vLLM启动日志中的NCCL初始化信息，确认`NCCL Version`和`NVLink`状态。 | 1. `nc -z localhost 29500`返回成功（exit code 0）。
2. `ssh localhost`测试通过，确保NCCL能通过localhost完成环回通信。
3. vLLM日志中NCCL初始化成功，无`ncclSystemError: System call (e.g., socket, malloc) or CUDA error`错误。 | 赵岩 | | | 5 | **目标服务器磁盘空间检查** | 1. 执行 `df -h /opt/models`。
2. 执行 `df -h /tmp`（vLLM临时文件缓存路径）。 | 1. `/opt/models`分区剩余空间≥30 GiB（存放模型副本与缓存）。
2. `/tmp`分区剩余空间≥20 GiB（防止模型加载或分词阶段因磁盘满而失败）。 | 赵岩 | | | 6 | **vLLM多卡启动成功率（关键闭环）** | 执行 `vllm serve /opt/models/qwen25-7b --tensor-parallel-size 2 --port 8000 --trust-remote-code`，从命令执行开始计时，到日志中出现`Application startup complete.`停止计时。 | 1. 启动成功，无`RuntimeError: NCCL error`或`CUDA error: out of memory`。
2. **启动耗时≤90秒**（此阈值与第4项“NCCL端口连通性”形成闭环：若NCCL通信正常，2卡并行加载模型的开销应在此范围内）。 | 李明 | | | 7 | **模型热加载与首次推理延迟** | 1. 执行 `curl -s -o /dev/null -w "%{time_starttransfer}" -X POST "http://localhost:8000/v1/chat/completions" -H "Content-Type: application/json" -d '{"model": "/opt/models/qwen25-7b", "messages": [{"role": "user", "content": "hello"}], "max_tokens": 1}'`。
2. 再次执行上述命令，记录第二次请求的首包延迟。 | 1. 首次请求（含模型热加载）首包延迟≤10秒。
2. 第二次请求（已预热）首包延迟≤3秒。
符合预期则表明模型加载与显存分配正常。 | 王磊 | | | 8 | **基础API可用性验证** | 持续向`/v1/chat/completions`接口发送10次请求：`for i in $(seq 1 10); do curl -s -o /dev/null -w "%{http_code}\n" -X POST ... -d '{"model": "/opt/models/qwen25-7b", "messages": [{"role": "user", "content": "test"}], "max_tokens": 10}'; done`。 | 连续10次请求均返回HTTP 200，且响应时间标准差<500ms。若出现503或响应时间剧烈波动，表明服务存在瞬时不可用风险。 | 赵岩 | | > **** > *图：核心检查项间的逻辑闭环示意* **关于这张检查表的几点补充说明：** * **为什么要强耦合第4和第6项？** 实际迁移中，NCCL端口能通并不代表多卡并行启动一定快。如果网络栈存在抖动（例如部分老驱动版本下nvlink降级），NCCL初始化会长时间卡顿，最终导致启动超时。让“端口连通”与“启动耗时≤90s”形成闭环，迫使你在网络层和应用层同时做验证，而不是只看单一指标。 * **SHA256校验不能省。** 用`diff`命令对比校验和，比单独查看`sha256sum --check`输出更直观，能立即定位哪个文件出错。金融场景中，模型文件一个比特的偏差都可能让策略失效，这个步骤绝对不能跳过。 * **首次推理延迟的阈值是个“体检指标”。** 如果模型加载耗时200秒，首次推理延迟必然超标。这个指标的波动，能反向帮你推断出NFS带宽瓶颈、GPU显存碎片化程度，甚至系统CPU调度是否异常。它不是孤立的性能数字，而是一个综合性健康信号。 把这8项逐一验证通过，再讨论接下来的“迁移中和迁移后”检查，才算有了稳固的底线。

来源：互联网