1、背景

业务上有个需求，希望在 Windows Server 2022 内通过 wsl2 部署 docker 运行类似 Ollama 的 GPU 服务。但 T4 计算卡使用通用方案直接安装官网下载的 GPU 驱动 + docker desktop 无法在 docker 内调用 GPU。

具体表现为：wsl 内nvidia-smi命令正常；nvcc -V命令正常，docker 内nvidia-smi命令异常。网上找到修改注册表可以强启WDDM模式，尝试后，docker 内能看到 GPU，但程序无法调用。

1、背景与方法简介

清华大学交叉信息院赵行老师研究组MARS Lab与理想汽车合作，提出了一种基于大模型的高阶自动驾驶的全新方案DriveVLM。DriveVLM以视觉语言大模型为基础，并与端到端模型实现双系统，在复杂和驾驶场景中表现出色。模型在理想Mega上部署运行，是首个部署上车的自动驾驶大模型。

城市环境中自动驾驶的主要障碍是理解复杂的 Long-tail 场景，例如具有挑战性的道路条件和微妙的人类行为。DriveVLM 集成了用于场景描述、场景分析和分层规划的推理模块的独特组合。此外，认识到 VLM 在空间推理和繁重计算要求方面的局限性，提出一种混合系统 DriveVLM-Dual，可选择将 DriveVLM 与传统 3D 感知和规划模块集成，例如 3D 物体检测器、占用网络和运动规划器，使系统能够实现 3D 接地和高频规划能力。这种双系统设计类似于人脑的慢速和快速思维过程，可以有效地适应驾驶场景中不同的复杂性。 在 nuScenes 数据集和 SUP-AD 数据集上的实验证明了 DriveVLM 和 DriveVLM-Dual 在处理复杂且不可预测的驾驶条件方面的功效。最后，将 DriveVLM-Dual 部署在量产车辆上，验证其在现实自动驾驶环境中的有效性。

2、DriveVLM实现

DriveVLM 的整体流程如下图所示。图像序列由视觉语言模型（VLM）处理，以执行特殊的思想链（CoT）推理，从而得出驾驶规划结果。 DriveVLM 的架构涉及视觉转换器编码器和大型语言模型 ( LLM )。视觉编码器产生图像标记；然后基于注意力的提取器将这些标记与LLM对齐。推理过程可以分为三个模块：场景描述、场景分析和分层路径规划（Hierarchical Planning）。而 DriveVLM-Dual 进一步融合了传统的3D感知和轨迹规划模块，实现空间推理能力和实时轨迹规划。

特性

• ⏯️ 从断点恢复：可随时重新运行或按 Ctrl+C ，再次执行脚本时下载恢复到断点状态。
• 🚀 多线程下载：利用多线程加快下载进程。
• 📦 轻量化：仅依赖git , aria2c/wget 。

基本命令：

1

./hf-downloader.sh *HF_Repo_ID* --tool aria2c -x 16

✨ Tips：文中“显存”指GPU可使用的内存空间，如有SoC使用Unified Memory(如Apple M1~M3系列、Nvidia AGX Orin等)则可简单理解为系统内存。

推理显存

对于一个70亿参数（7B）的模型，以 qwen2-7B 为例，预计需要的显存需求如下：

• FP32浮点精度：28GB
• BF16精度：14GB
• int8精度：7GB

虽然其他因素也在占用显存，但推理期间使用显存的主要是参数量。

• 比如，qwen2-7B-BF16 模型需要的显存等于参数数量乘以类型大小：70亿参数 x 2字节 = 140亿字节。因此，140亿字节 = 14 x 1,000 x 1,000 x 1,000 / 1024 / 1024 / 1024 ≈ 13 GB（考虑1000/1024）³ ≈ 0.93。

  注1：(1000/1024)³ ≈ 0.93，为了估算目的，简单地将此比率视为1。

  注2：对于7B-BF16模型，显存需求大约是7 x 2 = 14 GB。上述估算略高于精确计算，但更实用，因为推理需要超出参数之外的额外内存。

• 假设要估算llama2-13B模型的显存需求，对应各种类型的分别是：float：13 x 4 = 52 GB，half/BF16：13 x 2 = 26 GB，int8：13 GB，int4：13 x 0.5 = 6.5 GB