单卡RTXA6000运行Qwen-Drive需警惕配置陷阱，基线实验须分离目录与token记录

在大模型驱动的自动驾驶仿真系统Qwen-Drive中，如何在单张消费级专业显卡（如RTX A6000）上建立可靠、可复现的推理基线，已成为研究者面临的基础性挑战。近期一项技术核查揭示了一个易被忽视但影响深远的实践陷阱：即使成功加载了新模型权重并切换推理模式，实际可能并未执行任何新预测——原因在于官方批处理脚本的默认行为逻辑。

Qwen-Drive的推理流程采用“按场景token筛选”的续跑机制：脚本首先加载模型，随后读取已生成的predictions.jsonl文件，提取其中所有已完成场景的token；仅当某场景token尚未出现在该文件中时，才将其纳入本轮待预测列表。若全部场景均已存在，脚本直接返回“nothing to do”，整个过程看似迅速结束，实则未触发任何新的轨迹生成计算。

这一机制本为提升中断续跑效率而设计，但在跨配置实验中极易导致误判。例如，首次以SFT-direct模式完成场景A、B的预测；第二次改用RL专家模式并保持相同输出目录，脚本仍会因A、B token已存在而跳过二者，仅对新增场景C执行预测。最终输出文件虽含三行有效JSON，但内容混合了两种不同配置下的结果。若仅依据总耗时除以行数估算“单次延迟”，所得数值既不能代表SFT模式，也无法反映RL模式的真实性能。

更关键的是，该筛选逻辑完全不校验配置一致性。源码中load_done_tokens()函数仅解析token字段，忽略权重版本（revision）、推理模式（如direct_planning vs reasoning_planning）、随机种子（seed）乃至候选轨迹数量等关键变量。这意味着：

• 同一目录下多次运行不同配置，结果可能隐性叠加；
• 模型加载阶段仍占用GPU资源（如显存分配、CUDA初始化），但终端无提示；
• “无新预测”不等于“未使用GPU”，仅表示未触发新推理计算。

为规避上述风险，研究者提出一套可操作的基线构建规范：

值得注意的是，RTX A6000作为Ampere架构的48GB GDDR6显卡，常被选为中小规模推理的硬件基准平台。但其实际可用性不仅取决于标称显存容量，还受制于具体算子支持（如是否兼容FlashAttention变体）、CUDA驱动版本及系统内存协同调度能力。素材中明确标注：截至2026年10月18日，所核对的代码提交为28091c1532e869bc7aee91fc0aef6b3e6fd0b2e0，对应权重仓库Qwen/Qwen-Drive-1.0-4B的完整revision为28484089a7cc8c335cf5089fb0745cf7c49b6eaa——二者必须同时记录，不可仅引用Git分支名（如main），因其动态变化将破坏实验可复现性。

此外，显存占用亦非简单由模型参数量决定。除主干网络外，图像token嵌入、语言生成缓存、规划专家中间张量、CUDA工作区及内存分配器预留空间均构成峰值显存压力。SFT与RL专家虽为互斥选项，但二者在推理阶段的计算图结构、激活张量规模可能存在显著差异，直接比较“总显存”而不区分配置，同样会导致结论偏差。

行业层面看，此类问题并非Qwen-Drive独有，而是大型多模态推理框架的共性挑战。随着开源模型生态日益复杂，用户从Hugging Face或ModelScope下载权重后，往往仅关注模型名称与版本号，却忽略配套代码、依赖库版本及推理脚本的隐式行为逻辑。当研究者试图在有限算力设备（如单卡A6000）上快速验证新方法时，若未建立严格的实验隔离机制，极易产出“看似高效、实则无效”的伪基线数据，进而误导后续优化方向。

值得肯定的是，Qwen-Drive官方已在脚本中提供--no-resume等控制选项，并通过静态文档说明了load_done_tokens的行为边界。这为研究者提供了修正路径，但关键在于：工具的设计意图不等于实验的严谨要求。在资源受限条件下推进前沿研究，恰恰需要更精细的工程纪律——将“配置即身份”“目录即证据”作为默认实践准则，而非事后补救。

当前，单卡A6000能否稳定支撑Qwen-Drive全链路推理，仍需实测验证。但可以确定的是：在未解决配置混淆问题前，任何基于共享输出目录的“速度对比”或“显存测量”，其科学价值均存疑。构建一条真正可比较的基线，第一步不是跑得更快，而是先确保“这一次到底跑了什么”。