虚拟化AI Agent人工智能CLI【免费下载链接】smolvmAn embeddable, portable, branchable virtual machine to safely run Agents locally.项目地址https://gitcode.com/gh_mirrors/sm/smolvm点击查看免费下载smolvm 通过两条截然不同的路径把宿主机 GPU 交给微虚拟机microVM内的工作负载使用--gpu走 virtio-gpu / VenusVulkan-over-virtio提供图形渲染--cuda走 vsock 上的 CUDA Driver API 远程调用提供 NVIDIA 计算。本文以仓库内的权威参考 docs/gpu.md 为骨架结合 docs/gpu-cuda/SKILL.md 的实测过程与 tests/test_gpu.sh 的集成测试完整讲解宿主机环境准备、两种接口的启用方式、参数语义、验证方法与隔离边界让读者能够在自己的宿主机上可靠地把 GPU 能力安全地带进 smolvm 机器。一、先分清两条 GPU 路径--gpu与--cudasmolvm 的 GPU 能力不是一个开关而是两个互不共享实现的功能唯一共同点只有GPU这个单词特性--gpu--cuda用途Vulkan 图形渲染含 WebGL/ANGLECUDA 计算Driver API传输通道virtio-gpuVenus 协议Vulkan-over-virtiovsock socketAPI 远程调用客机侧驱动Mesa 的 Venus 驱动virtio_icd JSON manifestsmolvm 注入的兼容libcuda.so.1位于/opt/smolvm-cuda宿主机前置要求virglrenderer 宿主机 Vulkan 驱动NVIDIA GPU 可用的 NVIDIA 驱动libcuda.so.1 已加载的内核模块客机是否拿到物理设备否拿到虚拟 virtio-gpu 设备否既无 NVIDIA 驱动也无/dev/nvidia*--gpu暴露的是宿主机 GPU 通过 virtio-gpu / Venus 虚拟出的Vulkan 设备--cuda是API 远程调用API remoting客机内无驱动的 shim 把 CUDA 调用经 vsock 转发给宿主机进程由宿主机通过 NVIDIA 驱动实际执行。docs/gpu-cuda/README.md 中特别强调二者share nothing but the word GPU切勿混淆。二、--gpu图形加速原理与客机视角2.1 渲染链路当machine run带上--gpu时smolvm 的 agent 在启动 VM 前会调用 libkrun 的krun_set_gpu_options2(ctx, virgl_flags, vram_bytes)符号在 src/agent/krun.rs 中声明为可选加载项为客机创建一个 virtio-gpu PCI 设备。该设备由宿主机侧的 virglrenderer 服务渲染请求图形命令经 Venus 协议在 virtio-gpu 上传送。在 macOS 上MoltenVK 负责把 Vulkan 调用翻译到 Metal。客机侧看到的是一个真实的 Vulkan 设备。docs/gpu.md 给出 Linux Intel 上的典型渲染字符串ANGLE (Intel, Vulkan 1.4 (Virtio-GPU Venus (Intel(R) UHD Graphics ...)), venus)客机内核libkrunfw 内置CONFIG_DRM_VIRTIO_GPUy初始化 DRM 子系统后会创建两个设备节点tests/test_gpu.sh 的第 84-91 行注释明确其职责/dev/dri/renderD128—— 渲染节点Vulkan/OpenGL 计算不做 modesetting/dev/dri/card0—— DRM 卡片modesetting、显示。agent 的add_gpu_devices_if_available()见 crates/smolvm-agent/src/oci.rs随后把这两个节点以0o666模式转发进 OCI 容器规范使非特权进程也能打开它们。tests/test_gpu.sh中的test_dri_renderD128_present、test_dri_card0_present、test_interactive_run_has_dri等用例分别验证了非交互与-it交互两种路径下设备节点都正确暴露而test_no_dri_without_gpu验证了不带--gpu时客机内完全没有/dev/dri保证默认隔离成立。2.2 客机内的验证一条命令即可确认 virtio-gpu 已就位无需安装任何 Mesa 组件smolvm machine run --gpu --net --image alpine:latest -- ls /dev/dri/renderD1282.3 补丁 Mesa 与 Apple Silicon 特例tests/test_gpu.sh 的 Fedora 42 段落揭示了一个平台细节标准 Fedora Mesa 存在 16KB 页对齐 bug会在 Apple Silicon 上使 Venus ICD 初始化崩溃宿主页 16KB客机期望 4KB。因此该测试通过启用slp/mesa-libkrun-vulkanCOPR 仓库安装打了上游补丁的mesa-vulkan-drivers随后用vulkaninfo --summary断言输出中出现VenusICD、Virtio-GPU设备名和 Vulkan API 版本。这套用例test_vulkaninfo_venus_icd、test_vulkaninfo_virtio_gpu_device、test_vulkan_api_version是客机 Vulkan 全链路可用的标准验证模板。三、宿主机要求各平台依赖一览macOSvirglrenderer 与 MoltenVK 已随 smolvm 发行包内置无需额外安装。Linuxvirglrenderer 与宿主机 Vulkan 驱动需通过系统包管理器安装docs/gpu.md 给出的对照表发行版安装命令Alpineapk add virglrenderer mesa-vulkan-intelAMD 用mesa-vulkan-atiDebian/Ubuntuapt install virglrenderer0 mesa-vulkan-driversNix / NixOSflake 不会把 virglrenderer 放进 loader 路径需自行导出LD_LIBRARY_PATH包含 nixpkgs 的virglrenderer与libepoxy库目录NixOS 上另加/run/opengl-driver/lib注意virglrenderer 依赖宿主 GPU 驱动栈自带的 libEGL 与 libdrm这些是硬件相关的无法打包进发行版。任何具备 GPU 能力的 Linux 宿主在安装驱动时都已具备它们。3.1 源码层面的依赖处理src/agent/krun.rs 揭示了这套依赖如何在运行时被管理preload_linux_gpu_dependencies()第 478 行会在加载 libkrun 前尝试以RTLD_GLOBAL预载捆绑的或宿主系统的libepoxy.so.0与libvirglrenderer.so.1并设置VIRGL_RENDER_SERVER_PATH指向随包分发的virgl_render_server。这是尽力而为best-effort非 GPU 宿主上找不到这些库完全正常因为相应符号永远不会被调用libkrun 的NEEDED条目在打包时被剥离virgl 符号改为懒绑定lazy binding因此没有 GPU 栈的宿主仍能加载 libkrun 正常启动 CPU/CUDA 机器ensure_gpu_runtime()第 358 行在真正调用 GPU 路径前用RTLD_NOW解析整个 libkrun 对象提前暴露 ABI 不兼容的 virglrenderer实测故障为缺少virgl_set_debug_callback而不是等到第一次 FFI 调用让动态链接器直接终止 VMM 进程。其错误信息直接给出可执行建议例如apt install virglrenderer0 mesa-vulkan-drivers/pacman -S virglrenderer。四、启用 GPUCLI、Smolfile 与参数语义4.1 命令行快速上手docs/gpu.md 的示例在 Alpine 客机内装 Vulkan 组件并枚举设备名smolvm machine run --net --gpu --image alpine -- sh -c apk add --no-cache mesa-vulkan-virtio vulkan-loader vulkan-tools vulkaninfo --summary | grep deviceName # → deviceName Virtio-GPU Venus (Apple M1 Pro)注意--net是必须的镜像拉取发生在 VM 内部tests/test_gpu.sh 注释亦强调。4.2 Smolfile 声明式配置gpu true gpu_vram 2048 # MiB默认 40964.3gpu_vram参数的真实含义该参数不是 GPU 显存直通而是libkrun 为 virtio-gpu 预留的宿主共享内存区域大小纹理、staging、Venus/Vulkan descriptor pool 等传输缓冲区。源码中的定义与校验默认值DEFAULT_GPU_VRAM_MIB 4096注释src/data/resources.rs说明 4 GiB 足够典型 Vulkan 负载含无头浏览器使用又不会让低内存宿主一开 GPU 就提交掉大部分 RAMeffective_gpu_vram_mib()第 251 行在未显式设置时回落到默认值且不变量保证返回值恒 1validate_gpu_vram_mib()第 268 行在入口拒绝0CLI 侧parse_gpu_vram_mibsrc/cli/parsers.rs同样在解析期拒绝 0、非数字、负数与小数tests/test_gpu.sh 的test_gpu_vram_zero_rejected验证了--gpu-vram 0在 VM 启动前就被拒绝最终换算在 src/agent/launcher.rsvram_bytes vram_mib * BYTES_PER_MIB连同gpu_virgl_flags()一起传给krun_set_gpu_options2。若当前 libkrun 未以 GPU 特性编译找不到该符号agent 会明确报错libkrun was built without GPU support (krun_set_gpu_options2 not found)。4.4VK_ICD_FILENAMES通常不需要设置docs/gpu.md 明确说明客机的 Mesa 会安装 ICD manifestVulkan loader 能自行发现在 glibc 镜像上 smolvm 还会 bind-mount 自己的 Venus 驱动并主动把 loader 指向它。只有需要覆盖该选择时才设置此变量且必须注意 manifest 文件名携带架构信息virtio_icd.x86_64.json/virtio_icd.aarch64.json硬编码路径在另一架构上必然失效。五、实战场景无头浏览器硬件加速docs/gpu.md 指向 examples/headless-browser/ 获取可运行的 Chromium 方案在无头 VM 内用 ANGLE Venus 实现硬件加速 WebGL。该目录的browser.smolfile展示了完整的声明式配置形态。类似的图形负载还有 examples/gpu-chrome/gpu-chrome.smolfile。六、CUDA API 远程调用--cuda6.1 设计要点与隔离边界--cuda是 CUDADriver API的远程化客机注入一个兼容libcuda.so.1于/opt/smolvm-cuda把cu*系列调用经 vsock 转发给宿主机守护进程由守护进程持有设备并执行。要点docs/gpu.md 与 docs/gpu-cuda/README.md不是 GPU 直通客机既收不到物理设备也没有 NVIDIA 驱动更没有/dev/nvidia*nvidia-smi在客机内缺席是正确行为它的缺席不能说明 GPU 不可达宿主机要求极简只需可用的 NVIDIA 驱动libcuda.so.1 已加载内核模块不需要 CUDA toolkit也不需要容器 toolkit、device plugin 或 root隔离边界是进程级VM 边界仍然隔离了工作负载的 CPU、内存与文件系统但 GPU 访问由宿主机进程与共享 GPU 中介隔离强度是进程级而非硬件/VM 边界。docs/gpu.md 明确警告不要将 CUDA remoting 视为加固的多租户 GPU 隔离边界已覆盖的 API 面初始化与设备查询、context含 CUDA runtime 使用的 primary-context 流程、PTX/cubin/fatbin 的 module 加载与卸载、双向 allocation 与拷贝、kernel launch、streams、events、cuGetProcAddress。所有*Async调用在返回前同步完成这符合 CUDA 契约。6.2 为什么退出码证明不了任何事因为 API 是远程化的一个程序可以成功链接libcuda.so.1、启动并退出码为 0却从未触达 GPU。docs/gpu-cuda/SKILL.md 的验证铁律是断言设备名和传输结果永不只看退出码。更隐蔽的陷阱当宿主机无法加载 NVIDIA 驱动库时宿主侧会回以一个CPU 模拟设备——cuDeviceGetName返回smolvm CPU emulation device内存报告为 1024 MiB1 MiB 往返数据的前 16 字节也原样回来。设备名是唯一的判别依据probe 脚本会据此输出device_kindcpu_emulation与resultcpu_emulation_not_gpu而不是通过。该现象已在 macOS arm64v1.16.1、v1.18.2、v1.22.2与 Linux aarch64v1.18.2上复现。七、CUDA 完整实操流程preflight → probe → cleanup文档 docs/gpu-cuda/SKILL.md 给出了三段式标准流程脚本位于 docs/gpu-cuda/scripts/。7.1 第一步preflight只读、不启 VMscripts/preflight.shpreflight.sh 只报告环境不启动 VM、不触碰任何 NVIDIA 状态输出 GPU 与驱动版本、你的用户能否打开/dev/kvm、宿主自身的libcuda数量。若回答这台机器能否跑 CUDApreflight 就是全部答案——不要在无 GPU 的宿主上跑 probe 来判断那会启动一台 VM 并得到一份读起来像是的假阳性。有 GPU 的 Linux x86_64 宿主实测 NVIDIA A10上典型输出platformlinux-x86_64 accelkvm accel_accessok gpu_presentyes gpuNVIDIA A10, 580.105.08 host_libcuda1 guest_needs_glibc_imageyes guest_shim_path/opt/smolvm-cuda/libcuda.so.1 resultready无 GPU 的 macOS 输出platformdarwin-aarch64 gpu_presentno unsupportedcuda notemacOS has no CUDA driver, so --cuda has nothing to reach here. resultblocked无 GPU 的 Linux aarch64Limalinux-kvmUbuntu 24.04输出platformlinux-aarch64 accel_accessok gpu_presentno noteno nvidia-smi on this host; --cuda needs the driver library libcuda.so.1, which host_libcuda reports host_libcuda0 notelibcuda.so.1 is not in this hosts loader cache; --cuda loads it on the host, and without it the guest reaches the CPU emulation device resultblockedresultblocked配合gpu_presentno是最省时的答案无 GPU 的跑起来不会失败只会抵达 CPU 模拟设备。7.2 第二步probe断言设备名 数据往返scripts/run-cuda-probe.sh # 默认镜像 python:3.12-slim scripts/run-cuda-probe.sh other glibc image # 可指定其他 glibc 镜像脚本把scripts/挂载进客机在--cuda下运行 cuda-probe.py然后断言输出中的两项device_namedok与data_roundtripok。A10 上的实测输出v1.14.6load_shim - ok /opt/smolvm-cuda/libcuda.so.1 cuInit - 0 cuDeviceGetCount - 0 count 1 cuDeviceGetName - 0 name NVIDIA A10 cuCtxCreate - 0 cuMemGetInfo - 0 total MiB 22587 cuMemAlloc - 0 cuMemcpyHtoD - 0 cuMemcpyDtoH - 0 roundtrip first 16 bytes match: True cuMemFree - 0roundtrip first 16 bytes match: True是最关键的一行——它是唯一证明字节真正到达设备的证据。成功时脚本报告device_kindgpu、resultcuda_ok。7.3 第三步cleanupCUDA 镜像很大scripts/cleanup.sh --purge smolvm machine prune --name NAME --all # 清理你保留下来的持久 --cuda 机器cleanup.sh会先打印waitingup to 20s最多轮询 20 秒等待机器列表清空临时机器的记录在其 run 返回后才会退役。probe 运行是临时的、无需清理machine prune必须带机器名不带名会被拒绝。--cuda不会改变宿主机任何状态shim 只在客机内注入。SKILL.md 记录了一次实测在同一宿主机上连跑多轮 CUDA 后再做 Kubernetes 安装与拆除nvidia-smi仍报告设备全文件系统扫描*smolvm*结果为空。八、关键陷阱清单docs/gpu-cuda/README.md 与 SKILL.md 汇总的实战陷阱细节见 docs/gpu-cuda/references/traps.md零退出码证明不了 GPU 触达——远程化 API 是根因设备名 通过的往返也不够——宿主机加载不了 NVIDIA 驱动库时会以 CPU 模拟设备应答device_kindcpu_emulation/resultcpu_emulation_not_gpu是判别输出客机内没有nvidia-smi与/dev/nvidia*是正确行为都不是有用检查必须用 glibc 镜像并按绝对路径加载 shimshim 是 glibc 的Alpine 客机加载不了/opt/smolvm-cuda/libcuda.so.1而非依赖 loader 路径否则会捡到镜像自带的同名库全新 GPU 云实例默认不给你的用户 KVM 访问权而安装器仍会报告安装成功sg kvm -c可免登出生效probe 报agent did not become ready within 30 seconds多半是内存问题而非 GPUprobe 默认申请 8192 MiB在低内存宿主如只能 boot 2048 MiB 的 aarch64 宿主上会超时同样的 probe 在 1024 MiB 下能正常到达模拟设备--cuda与--gpu是不同功能前者是 vsock 上的计算后者是 virtio-gpu 上的 Vulkan在 Windows 上--gpu能启动但客机没有 GPU 设备见 docs/gpu-cuda/references/windows.md文档所述Windows 上 GPU 加速不可用指的是 Vulkan 的--gpu路径与 CUDA 无关。九、平台支持矩阵与实测记录docs/gpu-cuda/SKILL.md 记录了按平台/版本的实测Linux x86_64 NVIDIA GPUv1.14.6 在 NVIDIA A10驱动 580.105.08内核 6.8.0-1046-nvidia上端到端验证preflight 到 cleanup 全流程probe 对python:3.12-slim与python:3.12-bookworm两个 glibc 镜像都通过Windows x86_64 NVIDIA GPUv1.22.2 在 RTX 4050驱动 32.0.15.6626上验证含设备名与 1 MiB 设备往返v1.14.6 时也验证过Windows 上scripts/*.sh是 bash 无法运行preflight 与 cleanup 改为手工执行macOS arm64 / Intel不适用——macOS 没有 CUDA 驱动--cuda无事可做preflight 直接给出unsupportedcuda不会让运行超时Linux aarch64测试宿主无 NVIDIA 硬件preflight 与对 CPU 模拟设备的 probe 在 v1.18.2 上运行过v1.22.2 上 probe 因宿主内存不足超时未在任何平台验证过多 GPU、--cuda机器的分支fork、从 checkpoint 恢复的 CUDA 机器、训练/推理负载最远的只是 Windows 上的向量加法其余为 Driver API 断言不能据此推断 CUDA API 覆盖面有多大。docs/gpu.md 还提醒fork 密集的 Linux 宿主应使用包含上游 KVM 修复 commit916b7f4的内核受影响内核即使宿主内存充裕也可能在首次KVM_RUN间歇性报ENOMEMsmolvm 会降低暴露面并替换失败的 worker但内核升级才是根治方案。十、安全默认值为什么隔离是这样设计的docs/gpu-cuda/SKILL.md 的安全模型可归纳为三点客机永远拿不到设备这就是隔离本身不直通/dev/nvidia*客机工作负载无法直接触达驱动、重编程设备也无法经由设备窥探其他 VM 的设备状态得到的只是转发的 API 表面该表面暴露的仍然是真实的远程化的 CUDA 调用在宿主机驱动与宿主机内存分配器上执行因此应把--cuda机器视为拥有通往特权宿主组件的通道VM 边界使其可接受但这不是零权限全程不需要 root 或容器 toolkit任何要求安装 device plugin 或要求以 root 运行 CLI 才能用 CUDA 的流程都不是本文档描述的流程。文档脚本只包装公开 CLI只读挂载本技能包自身的scripts/目录进客机cleanup 也只删除自己在smolskill-前缀下记录的机器。十一、进一步阅读GPU 总览与两条路径的权威参考docs/gpu.mdCUDA 技能包版本戳、分平台结果、完整流程docs/gpu-cuda/SKILL.md 与 docs/gpu-cuda/README.md陷阱细节docs/gpu-cuda/references/traps.mdWindows 实测记录docs/gpu-cuda/references/windows.mdGPU 集成测试套件含 pack create --gpu 清单往返验证tests/test_gpu.sh无头浏览器 Venus 示例examples/headless-browser/依赖加载与krun_set_gpu_options2的源码实现src/agent/krun.rs、src/agent/launcher.rs、src/data/resources.rs赞分享虚拟化AI Agent人工智能CLI【免费下载链接】smolvmAn embeddable, portable, branchable virtual machine to safely run Agents locally.项目地址https://gitcode.com/gh_mirrors/sm/smolvm点击查看免费下载相关推荐smolvm GPU-CUDA 陷阱排查手册远程化 CUDA API 下如何验证 GPU 真的被用上smolvm GPU CUDA 陷阱排查手册远程化 CUDA API 下如何验证 GPU 真的被用上 smolvm 的 cuda 采用 API 远程化rem虚拟化AI Agent人工智能CLIQEMU VirtIO 设备全景指南从 virtio-gpu 图形加速到 vhost-user 进程外卸载QEMU VirtIO 设备全景指南从 virtio gpu 图形加速到 vhost user 进程外卸载 VirtIO 是 QEMU 中半虚拟化设备的核心实虚拟化硬件仿真QEMU virtio-gpu 设备配置指南从 2D 显示到 virgl/3D 加速与 Wayland 透传QEMU virtio gpu 设备配置指南从 2D 显示到 virgl/3D 加速与 Wayland 透传 virtio gpu 是 QEMU 中基于 Vi虚拟化硬件仿真上一篇Higress网关连接复用革命HTTP/2与TCP长连接极致优化下一篇GitHub_Trending/by/bytebot前端模块设计单职责原则与接口设计实践创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考