Windows上用WSL2和Docker跑通vLLM部署Qwen3-8B-FP8实战

直接说结论官方 vLLM 不支持原生 Windows但借助 WSL2 和 Docker你完全可以在 Windows 上把 Qwen3-8B-FP8 跑起来而且性能和 Linux 几乎没差别。我实测过好几台机器包括 4090 和 4070 Ti走通之后你会得到一个标准 OpenAI 兼容的 API 服务可以用来接各种前端、脚本甚至配合 Dify 这类编排工具。这篇文章就是完整记录我在 Windows 11 上从零跑通 Qwen3-8B-FP8 的整个过程包括方案选型、环境配置、启动命令、参数计算和一堆排坑实录照着抄基本不会翻车。1. 为什么要在 Windows 上折腾 vLLM方案选型和底层逻辑1.1 先说清楚 vLLM 是什么能解决什么问题vLLM 是目前大模型推理服务领域最主流的框架之一核心价值有两个。第一是 PagedAttention 显存管理机制这个思路跟操作系统里的分页机制很像把 KV Cache 切成小块按需分配大幅提升显存利用率同一张卡上能同时服务的请求数量明显增加。第二是 Continuous Batching可以理解为餐厅翻台机制传统方案要等一批请求全部结束才处理下一批vLLM 是每完成一个就补一个新请求吞吐量自然高。对比一下LM Studio 或 Ollama 这类工具更适合个人本地试用安装简单、开箱即用但并发能力、服务化能力和自定义程度都比较有限。你在 Windows 上装了 LM Studio跑个对话没问题但如果要做并发压测、接多个客户端、调采样参数、做流式输出就会感觉不顺手。vLLM 的定位是生产级的推理服务OpenAI 兼容接口是标配吞吐量和并发能力是专门优化过的适合认真跑服务的场景。另外 SGLang 也是一个不错的框架性能和 vLLM 各有千秋但 vLLM 的生态更成熟文档更全遇到问题搜到的解决方案也更多所以我选 vLLM。1.2 Windows 官方不支持路线只有三条我选这条vLLM 官方团队没有提供 Windows 原生支持原因主要是依赖了 Linux 生态里的一些底层库和系统调用。但这不代表 Windows 用户玩不了实操下来主流路线有三条。第一条是原生 Windows 硬编译理论上可以在 Windows 上装 CUDA 工具链和 MSVC然后源码编译 vLLM但这条路非常痛苦编译依赖冲突多、耗时长、后遗症多我真的不建议你浪费时间。第二条是 WSL2Windows Subsystem for Linux里装 Linux 环境直接跑不装 Docker直接在 WSL2 里用 conda 建环境、pip 安装 vLLM、直接执行 vllm serve 命令。这条路可行很多人也在用缺点是环境隔离性差改坏了不好恢复。第三条是 WSL2 Docker Desktop这也是我采用的方案。核心逻辑是 WSL2 提供一个完整的 Linux 内核Docker 在里面跑容器vLLM 官方镜像已经装好了所有依赖你只需要把宿主机Windows的模型目录和显存透传进容器就能直接跑。隔离性好、可复现性强、升级回滚方便而且以后换 GPU 机器部署到 Linux 服务器这套配置直接平移。1.3 为什么模型选 Qwen3-8B-FP8显存和性能的平衡Qwen3-8B-FP8 是通义千问 3 系列的 8B 参数版本但权重用 FP88 位浮点格式做了量化。量化可以理解为把照片从原始大图压缩成高质量 JPEG尺寸小很多肉眼观感差异不大但要付出少量画质代价。对模型来说FFP8 量化通常能把权重大小减半同时借助现代 GPU 的 FP8 计算单元让推理更快。我选这个模型做 Windows 部署实战还有几层考虑。第一8B 参数规模是性价比最均衡的档位比 0.5B、1.5B 的小模型能力明显强不少又不会像 14B、32B 那样对显存和算力要求那么苛刻。第二FP8 量化版对单卡用户极其友好权重占用大概 8GB 左右留足 KV Cache 和激活值后24GB 显存显卡能跑很长的上下文16GB 显卡也能用12GB 有点紧张但小并发能跑。第三Qwen3-8B 本身能力足够应对代码生成、文本总结、知识问答等常见场景能展示 vLLM 的价值又不会因为模型太大导致部署门槛过高。1.4 部署前的硬件和软件清单先说硬件。我实测主力机配置是 i7-13700K 64GB 内存 RTX 4090 24GB跑这个模型头部几乎没有压力。另一台测试机是 i5-12400F 32GB 内存 RTX 4070 Ti 12GB也能正常跑但把 --max-model-len 调低一些并发数受点限制。如果你想跑得舒服显卡显存建议 16GB 起步24GB 是舒适区。内存在 Windows WSL2 Docker 这个组合里也很重要建议至少 32GBWSL2 默认会吃掉一部分内存如果模型加载后还需要跑多个进程16GB 会明显吃紧。软件层面的核心组件是 Windows 11我用的 23H2 和 24H2 都验证过、WSL2、Docker Desktop、NVIDIA 显卡驱动以及 CUDA 在 WSL2 里的配套支持。特别注意Windows 侧的显卡驱动必须是较新的 Game Ready 或 Studio 驱动因为 WSL2 里跑 CUDA 依赖 Windows 驱动直接透传不是虚拟化的而是通过 WSL 的 GPU-PV 机制直接把物理显卡能力映射进去性能非常接近裸机。具体到版本我建议直接把 NVIDIA 驱动更新到最新稳定版省得踩老驱动的坑。注意不要额外在 WSL2 里安装 CUDA ToolkitWSL2 会自动从 Windows 驱动层获取 CUDA 能力。很多新手在这步多手装了一套 Linux 版 CUDA结果环境变量冲突反而不稳定。2. 环境准备把 WSL2 和 Docker Desktop 调教好2.1 安装 WSL2 和 Docker Desktop注意三件事安装 WSL2 非常简单用管理员权限打开 PowerShell 或 Windows Terminal执行wsl --install然后按提示重启。重启后系统会自动装好 Ubuntu 发行版默认是最新的 LTS 版本。如果你之前装过旧版 WSL建议执行wsl --update更新到最新内核然后在 PowerShell 里用wsl --set-default-version 2确保用的是 WSL2 而不是 WSL1二者性能和兼容性差距非常大WSL1 基本跑不了 vLLM。装完 WSL 后安装 Docker Desktop下载安装包一路下一步就行。安装到选择 backend 那一步务必选 “Use the WSL 2 based engine”这样才能让 Docker 容器跑在 WSL2 里而不是 Hyper-V 虚拟机里前者才能透传 NVIDIA GPU。装好后在 Docker Desktop 的 Settings - Resources - WSL Integration 里确认你的 Ubuntu 发行版已经打开集成开关。这一步很容易漏掉漏了之后在 WSL 里执行docker命令会用不了报错信息还特别迷惑。2.2 确认 CUDA 能透传进 WSL2这是成败关键环境搭好之后不要急着拉镜像先做一次 GPU 透传验证。打开 WSL2 终端在 PowerShell 里输入wsl进入执行nvidia-smi如果能看到类似下面的输出说明 NVIDIA 驱动已经成功透传到 WSL2----------------------------------------------------------------------------- | NVIDIA-SMI 550.54.15 Driver Version: 550.54.15 CUDA Version: 12.4 | -----------------------------------------------------------------------------注意看右上角的 CUDA Version这个是驱动支持的 CUDA 最高版本不要求它和容器里 vLLM 需要的版本完全一致只需要不小于容器内需要的版本即可。因为容器内跑的 CUDA 运行时库会和驱动进行兼容协商。如果nvidia-smi报错说找不到设备多数情况是 Windows 显卡驱动太旧或者 Docker Desktop 的 WSL Integration 没开。先更新驱动再看设置基本能解决。这一步没通过之前不要往下走否则后面所有问题都会归因到这一层排查起来极其痛苦。2.3 下载模型权重推荐用 ModelScope避开下载慢的坑vLLM 服务启动时需要读取模型权重目录所以先把 Qwen3-8B-FP8 下载到 Windows 文件系统里。默认推荐的当然是 Hugging Face但国内网络环境下访问不太稳定下载速度也看运气。我实测更省心的是从 ModelScope 下载它的服务器在国内速度稳定得多。ModelScope 上搜索Qwen/Qwen3-8B-FP8找到模型主页之后可以直接用 git 方式克隆速度很理想git lfs install git clone https://www.modelscope.cn/Qwen/Qwen3-8B-FP8.git这个仓库大小大概在 8GB 到 9GB 之间里面主要是一个或多个大型权重文件通常是.safetensors格式以及模型配置相关的文件。下载完成后把整个模型文件夹放到一个你自己记得住的目录比如D:\models\Qwen3-8B-FP8或E:\ai-models\Qwen3-8B-FP8后面挂载进 Docker 容器时要用。如果你已经通过其他途径拿到了模型文件夹也可以核心是确认里面包含config.json、tokenizer.json、tokenizer_config.json、vocab.json和.safetensors权重文件。如果是 fp8 量化版本通常还会有一个quant_config.json或者配置里标注了quantization_config字段这个后面启动时有用。2.4 拉取 vLLM 镜像版本怎么选才稳Docker Desktop 装好并验证 GPU 透传成功后接下来拉取 vLLM 官方镜像。打开 WSL2 终端输入docker pull vllm/vllm-openai:latest这里我推荐用vllm/vllm-openai系列镜像它已经内置了 OpenAI 兼容 API 服务启动后可以直接通过 HTTP 调用不用自己再写 FastAPI 封装层。如果你拉取官方镜像较慢可以配置 Docker 镜像加速器具体方法可以搜一下 Docker Desktop 配置国内镜像源的操作。版本选择上日常使用优先latest标签即可但如果你要追求稳定、给生产环境用建议拉取具体版本号比如vllm/vllm-openai:v0.8.4或你测试时验证过的某个版本。因为latest可能会在未来某个时间点更新导致行为变化而版本号镜像能保证复现。我这次用的是latest拉下来后可以执行docker images确认镜像存在。提示镜像体积通常好几 GB拉取需要一段时间耐心等。下载过程中不要强制中断中断后 Docker 虽然能断点续传但偶发会导致镜像损坏到时还得清理重拉更浪费时间。3. 实战启动从 docker run 到 OpenAI 兼容 API3.1 启动 vLLM 服务命令逐行拆解环境都准备好之后进入核心环节——启动 vLLM 服务。先给出我验证过的完整命令然后再逐行解释docker run --gpus all \ -p 8000:8000 \ -v D:/models/Qwen3-8B-FP8:/models/Qwen3-8B-FP8 \ --shm-size16g \ --name vllm-qwen3 \ --restart unless-stopped \ vllm/vllm-openai:latest \ --model /models/Qwen3-8B-FP8 \ --max-model-len 16384 \ --gpu-memory-utilization 0.92 \ --enforce-eager \ --served-model-name qwen3-8b-fp8--gpus all让 Docker 把宿主机所有 GPU 透传给容器。如果你的机器有多张卡可以先不加这个参数或者改成--gpus device0指定某一张。-p 8000:8000端口映射把容器内的 8000 端口映射到 Windows 主机的 8000 端口。vLLM 默认监听 8000你也可以改成其他端口但两边要对应。-v D:/models/Qwen3-8B-FP8:/models/Qwen3-8B-FP8将 Windows 里的模型目录挂载到容器内的路径。注意 Windows 路径格式盘符大写正斜杠这个细节容易出错。--shm-size16g设置共享内存。vLLM 的 tokenizer 和部分数据处理逻辑会用到/dev/shmDocker 默认只有 64MB不调大会在并发请求时被卡住这个参数必须加。--name vllm-qwen3容器名称方便后续查看和操作。--restart unless-stopped容器异常退出时自动重启配合 Windows 开机自启 Docker Desktop可以让服务常驻。镜像后跟的是容器启动时执行的命令即给 vLLM 服务传入的启动参数。首次启动时vLLM 需要读取模型权重、构建 CUDA graph这个过程根据机器性能不同需要一两分钟。你会看到日志里出现类似Starting vLLM server和Application startup complete的输出这代表服务已经起来了。如果报错先别慌直接翻到 4.2 节查常见问题。3.2 几个关键启动参数和显存估算心里要有数参数--max-model-len控制模型最大上下文长度。Qwen3-8B-FP8 本身支持很长的上下文但实际部署时不能只看模型能力还要看显存。你需要考虑三块显存开销模型权重、KV Cache、激活值和其他运行时开销。先算权重。FP8 格式下 Qwen3-8B 的模型权重大约占 8GB 多一点。KV Cache 的大小取决于上下文长度、并发请求数和 batch size可以粗略估算为每 1000 token 大约占 50MB 到 100MB具体受层数、注意力头数影响。如果设置--max-model-len 16384并发 8 个请求KV Cache 大概会占用 6GB 到 10GB 不等。最后还有 CUDA graph 和激活值加起来也会占 1GB 到 2GB。这里就引出--gpu-memory-utilization参数我设的 0.92 表示 vLLM 最多占用 GPU 显存的 92%剩下的留给显示输出和系统缓冲。24GB 显卡上大约 22GB 可供使用扣掉权重大约 8GB剩下约 14GB 给 KV Cache跑--max-model-len 16384够用。如果显卡是 12GB 或 16GB建议把--max-model-len降到 8192再把利用率调到 0.9基本也能稳定运行。--enforce-eager的意思是关闭 CUDA graph 优化改用即时模式。CUDA graph 能减少调度开销、提升吞吐但首次启动时会花额外时间做图形捕获在显存不足的机器上也可能导致失败。开启--enforce-eager后启动更快、更省显存但吞吐量会有一定损失。如果你的显存比较紧张建议先加这个参数跑通流程后续想提升性能再移除它观察差异。3.3 用 curl 和 Python 验证服务是否正常服务启动后打开 Windows 的 PowerShell 或 WSL2 终端先做一个基础联通性测试curl http://localhost:8000/v1/models如果一切正常返回结果里会包含你设置的模型名就是--served-model-name参数的值这里设置的是qwen3-8b-fp8。这一步确认了服务端口正常、模型加载成功。接下来用 curl 发一个真正的对话请求curl http://localhost:8000/v1/chat/completions \ -H Content-Type: application/json \ -d { model: qwen3-8b-fp8, messages: [ {role: user, content: 用一句话解释什么是量子纠缠} ], temperature: 0.7, max_tokens: 512 }返回 JSON 里的choices[0].message.content就是模型生成的回答。如果你在代码里集成推荐用 OpenAI 的 Python SDK只需要把 base_url 指向本地服务即可from openai import OpenAI client OpenAI( base_urlhttp://localhost:8000/v1, api_keyEMPTY, ) resp client.chat.completions.create( modelqwen3-8b-fp8, messages[{role: user, content: 写一段 Python 快排代码}], temperature0.6, max_tokens1024, ) print(resp.choices[0].message.content)vLLM 的 OpenAI 兼容性做得很完整/v1/models、/v1/chat/completions、/v1/completions、/v1/embeddings这些常用接口都有意味着你用惯了 OpenAI API 的代码只需要换一个 base_url 就能切到本地模型非常省事。注意api_key参数在本地环境下随便填vLLM 不校验但它要求这个字段必须存在否则有些客户端会报认证错误。3.4 关于 FP8 量化参数什么时候需要显式指定启动时需要不需要额外指定--quantization fp8这取决于模型权重目录里的配置。Qwen3-8B-FP8 是官方量化过的版本权重目录里的config.json通常会带有quantization_config字段vLLM 加载时会自动识别。我的实测经验是如果我直接用--model /models/Qwen3-8B-FP8启动日志里会出现类似Loading model with quantization: fp8的提示说明它已经自动切换到了 FP8 推理路径不需要手动加参数。如果你的模型是从其他渠道转过来的或者 config 里没有正确的量化配置vLLM 把 FP8 权重当成 BF16 加载要么报错要么行为异常这种情况下才需要显式加上--quantization fp8。另外补充一个经验FP8 推理在 Ampere 架构如 A100、RTX 30 系列和 Ada Lovelace 架构如 RTX 40 系列上的表现不太一样。RTX 40 系列有专门的 FP8 计算单元收益明显RTX 30 系列做 FP8 推理时会走模拟路径速度和显存收益打折扣。如果你手头是 30 系显卡建议考虑直接用 BF16 版本的模型或者把 FP8 当成显存不足时的备选方案。4. 性能观察、常见问题与排查实录4.1 首 token 延迟和吞吐量实测数据参考服务跑起来之后我简单做了一轮实测。使用脚本连续发送 50 个并发请求每个请求要求生成 256 个 token测试结果作为参考首 token 延迟在 RTX 4090 上一般在 200ms 到 400ms 之间跟请求内容的长度有关输入越长首 token 越慢。生成速度单请求并发 1 时吞吐大约 3000 到 4000 token/s注意是生成速度不包含首 token 延迟。并发 50 时总吞吐能到 8000 到 12000 token/s平均每个请求的响应时间会有明显增加但总吞吐量更高。这些数据仅供参考实际数值受核显配置、显存余量、系统负载影响很大。我的核心建议是不要拿个人电脑的数据去苛求生产级性能但通过 vLLM 的 PagedAttention 和 Continuous BatchingWindows 单机上已经能体验接近服务器级别的并发吞吐这点是 Ollama 或 LM Studio 这类工具做不到的。4.2 常见报错速查表我踩过的那些坑报错或现象根本原因解决方案docker: Error response from daemon: could not select device driver nvidiaDocker Desktop 没装 GPU 支持或 WSL Integration 没开确认 NVIDIA 驱动已更新检查 Docker Desktop 设置里的 WSL Integration 是否勾选对应发行版重启 Docker DesktopCUDA error: no kernel image is available for execution on the device容器内 CUDA 版本与显卡算力不匹配或驱动太旧更新 Windows 显卡驱动拉取更新的 vLLM 镜像确认镜像内 CUDA 版本能覆盖你的显卡架构ValueError: The models max seq len (131072) is larger than the maximum number of tokens that can be stored in KV cache显存不够模型最大上下文超过 KV Cache 容量调低--max-model-len比如 8192降低--gpu-memory-utilization或者两者同时调服务启动时卡在Loading model weights很久磁盘读取慢或模型文件跨网络挂载把模型放到本地 SSD检查模型目录是否挂载正确Windows 磁盘 IO 慢时启动时间可能长达几分钟属正常现象RuntimeError: DataLoader worker (pid(s) ...) exited unexpectedly/dev/shm空间不足启动容器时加--shm-size16g或更大启动日志出现[pynccl.py:113] vllm is using nccl2.30.7类似输出vLLM 在初始化 NCCL 通信库单卡推理可以忽略不影响结果多卡部署需要检查网卡/NVLink 配置从 Windows 访问http://localhost:8000超时Docker Desktop 端口映射异常或 Windows 防火墙拦截检查docker ps是否显示端口映射Windows 防火墙放行对应端口确认没有再占用 8000 端口的进程模型服务正常但响应内容乱码权重下载不完整或模型格式不对重新下载模型权重检查config.json内容是否合法确认模型目录确实包含 tokenizer 相关文件上面这个表覆盖了我在这个项目里遇到的 80% 问题每个坑我都实际踩过所以写出来的时候都特别有画面感。4.3 排坑心得pynccl 警告、共享内存、端口占用先说pynccl.py:113这个日志。很多刚接触 vLLM 的朋友看到日志里有vllm is using nccl2.30.7会以为是报错其实不是。这是 vLLM 在初始化 NCCL 通信库时的正常输出单卡环境跑完这段日志后正常加载模型完全不用管它。如果你用的是多卡才需要关注 NCCL 是否能正常建立通信链路。再说共享内存。vLLM 对/dev/shm的依赖比较大除了数据加载器tokenizer 在多并发下也会用到Docker 默认的 64MB 肯定不够用。我见过不少人服务在低并发时正常一旦并发上来就随机报错最后排查半天发现是/dev/shm不够。所以--shm-size16g基本是我跑 LLM 容器的标配32G 内存的机器也可以用 8g总之别省。端口占用也是常见问题。如果你之前启动过旧服务端口 8000 可能被残留进程占用此时docker run会报端口映射冲突。先执行docker ps -a docker rm -f vllm-qwen3清理掉旧容器再启动即可。如果是 Windows 本机的其他程序占用了端口可以在 PowerShell 里执行netstat -ano | findstr :8000找到对应 PID 之后用任务管理器结束进程或者换一个端口映射。4.4 启动方式选择与 Docker Desktop 常驻设置关于启动方式我发现不少人习惯每次重启 Windows 后手动开 Docker Desktop、再手动跑容器。其实可以做两个设置让体验接近“开机即用”。第一打开 Docker Desktop 的 Settings - General勾选Start Docker Desktop when you sign in这样开机后 Docker Desktop 会自动启动。第二因为容器创建时已经加了--restart unless-stoppedDocker 起来后会自动拉起 vLLM 容器整个过程完全不用手动干预。这与直接在 WSL2 里裸装 vLLM 相比最大的优势是可维护性。裸装环境里如果你把 Python 包搞乱了模型服务起不来排查链路很长。而用 Docker 方案出问题直接重新创建一个容器就行宿主机环境基本上不会受影响。Qwen3-8B-FP8 换成一个更大模型也只是换个挂载目录、改几个参数的事不用重新装任何依赖。另外补充一点关于 vLLM 服务嵌入式模型的情况。vLLM 除了跑 LLM也支持 embedding 模型比如 BGE 系列。如果你后续要做 RAG 应用可以用同一个 vLLM 实例加载 embedding 模型通过--task embedding启动接口路径是/v1/embeddings在某些场景下可以省掉单独部署 embedding 服务的成本。这和主话题不是同一个流程但属于同一个工具链的延伸值得了解。5. 场景扩展这套服务还能做什么服务跑通之后你会发现一个标准 OpenAI 兼容 API 在本地运行能玩的花样就多了。我简单列举几个实际用过的场景。第一接各类开源前端。Open WebUI、ChatGPT-Next-Web 这类项目都支持自定义 base_url你把接口地址填成http://localhost:8000/v1就能拥有一套本地版的类 ChatGPT 界面支持对话记录、多会话管理体验比直接 curl 舒服太多。第二接入 Dify 这类 AI 编排平台。Dify 支持自定义模型供应商把 Qwen3-8B-FP8 作为推理模型接入后可以配合知识库、工作流搭建一些自动化的智能体应用。我在 Windows 上把 Dify 跑在 Docker 里和 vLLM 服务互不干扰整个链路非常稳定。你本地跑一个 Dify 实例管理流程vLLM 负责提供底座模型能力这个组合很适合一个人慢慢做原型验证。第三写自动化脚本或小工具。比如批量文本总结、代码审查只需要写一个 Python 脚本调用 OpenAI SDK把 base_url 指到本地即可。加上 vLLM 的并发能力批量处理几百条文本的速度远快于普通逐条推理。我写过给一批 Markdown 文件生成摘要的脚本配了 8 并发几分钟就能处理完一个项目文档库。这些场景的本质都是利用 vLLM 提供的服务化能力让本地模型变成局域网内可调用的基础设施。Windows 不再是摆设而是实打实的推理节点这个价值是单纯用聊天软件试模型体会不到的。6. 一些个人体会和进一步优化建议部署这件事跑通只算入门真正折腾的是后续的调优和稳定运行。我在这套方案上连续跑过几天总结了三个值得再优化的方向。第一vLLM 服务本身的调度参数值得多试。--max-num-seqs控制并发序列数默认值可能偏保守如果你的显存够用可以调大一点观察吞吐量的变化。--enable-prefix-caching开启前缀缓存在多轮对话和知识库问答场景下能明显减少重复计算我实测在某些 RAG 场景下能带来 20% 以上的性能提升。第二模型服务之外量化感知的部署思路可以继续延伸。Qwen3-8B-FP8 只是 Qwen3 家族的其中一个版本后续如果你觉得模型能力不够可以试试更大参数的量化版本比如 Qwen3-14B 的量化版或 32B 的量化版在显存充足时能获得更强的推理能力。如果显存不够还可以进一步用 AWQ 或 GPTQ 做 4-bit 量化牺牲一些精度换更低的显存占用这在 Windows 单机上同样可行。第三Windows 平台的容器化部署思路也能复用到其他大模型工具链。vLLM 只是其中一个环节现在 ComfyUI 跑 SD 模型、Dify 编排 AI 工作流的生态都很成熟它们也都支持 Docker 部署。把不同 AI 能力以容器为边界隔离开再通过端口和服务协议打通是一套很清晰的本地方案架构。就我个人经验来说Windows 上跑 vLLM 其实比想象中可靠核心瓶颈还是显存和内存。只要环境版本匹配、参数合理Docker WSL2 这套方案完全能承担日常开发和轻量生产的任务。如果你的机器是 4090 或同级别显卡看完这篇应该能在半小时内跑通 Qwen3-8B-FP8如果是 12GB 显存的卡把上下文长度和并发调低一点也能获得不错的效果。最后再提醒一句模型权重目录一定要放在本地 SSD 上机械硬盘加载 8B 模型真的会等到你怀疑人生。