如果你手上正好是一台 Windows 11 Arm64 设备又想在本地跑一个 SLMSmall Language Model小型语言模型这篇文章应该能帮上大忙。我最近把这条链路完整走了一遍从环境准备、Docker 镜像构建到模型加载、接口调用再到性能调优和踩坑排查最终在设备上跑起了一个可用的本地推理服务。和动辄几十上百 GB 参数的大模型相比SLM 的优势非常明显占用资源少、启动快、数据不出本机特别适合做离线问答、文本摘要、日志分析这类轻量任务。如果你是刚接触容器技术、又想在 Arm Windows 设备上尝鲜本地模型的人这套方案可以直接照着做不需要额外购置 GPU 设备。1. 项目定位与整体思路1.1 这个项目解决了什么问题所谓 SLM通常指参数量在 1B 到 7B 之间的小型语言模型。这类模型虽然在复杂推理能力上不如大模型但在特定任务上已经足够实用。举个实际例子我经常需要把一大段会议记录压缩成三条要点或者对技术文档做关键词提取这类任务不需要太强的“智慧”更需要低延迟和可重复性。本地部署 SLM 之后数据完全留在本机不会因为调用外部接口而担心隐私问题也不依赖网络状况。Docker 在这条链路里解决的是环境隔离问题。模型推理涉及的运行库很多包括底层推理引擎、数学优化库、量化工具等等。如果直接在 Windows 上装一旦库版本冲突整个系统环境会被搞得乱七八糟。用 Docker 之后所有依赖都打包在镜像里宿主机只需要装一个 Docker 运行时就能跑起来。我在项目里会先构建出一个包含推理服务的容器镜像以后在任何一台安装好 Docker 的 Arm64 Windows 设备上都能直接复用不用重新配置一遍。另外本地 SLM 还有一个容易忽略的优势接口响应稳定。外部 API 服务受限于网络波动、限流策略而本地服务跑在环回地址上延迟是可控的。我把这个服务跑起来之后测试了连续 12 小时无人值守运行没有出现一次超时。对于写内部工具、做自动化脚本、搭个人知识库这种稳定性非常关键。1.2 为什么选 Docker 而不是直接在本机部署最早我也尝试过不带容器直接部署结果很快就后悔了。Arm64 环境下很多 Python 包没有预编译的 wheel需要现场从源码编译。编译一个大一点的数学库经常要十几分钟而且过程中还会遇到编译器和基础镜像版本不匹配的问题。更麻烦的是卸载不干净总会在系统目录里留下一些动态库文件。换用 Docker 之后这些问题几乎消失因为所有编译过程都发生在容器内宿主机始终是干净的。还有一点是迁移性。Docker 镜像把模型权重之外的所有东西都固化下来了。我拿到另一台配置差不多的设备后只需要把镜像导出再导入再加载模型文件就能运行。这种可复现性是裸机部署很难实现的。另外Docker 天然提供了资源限制能力我可以通过--memory、--cpus这样的参数控制容器最多使用多少内存和 CPU。在 16GB 内存的 Arm64 设备上预留几个 GB 给系统是很有必要的。当然容器也不是万能的。相比直接在宿主进程里运行容器会多一层网络转发和存储驱动开销。不过对于 SLM 推理这类应用瓶颈主要在模型计算容器开销的影响非常小。实测下来同样的模型权重在裸进程和容器内运行token 生成速度几乎一致所以不用太担心。1.3 目标硬件与合理的性能预期先泼一盆冷水不是所有 Windows 11 Arm64 设备都适合跑 SLM。根据我实际测过的设备可以把硬件分为两档。第一档是内存 16GB 以上的笔记本或平板这类设备跑 7B 参数的量化模型比较舒服还能同时开浏览器和其他办公软件。第二档是内存 8GB 左右的小型设备建议只跑 1.5B 到 3B 的模型并且把上下文长度限制在 2048 以内否则很容易出现内存不足导致容器被杀的情况。性能预期方面先把“快”这个字放低一点。在纯 CPU 推理的 Arm 设备上7B INT4 量化模型的生成速度大概在每秒 8 到 15 个 token 之间。这是什么概念大概接近人工阅读速度的三分之一。用来做摘要、分类、短问答是足够的但如果想拿来写长文章等待时间会比较明显。3B 模型会好很多每秒能到 20 token 以上。我在部署时通常会准备两套模型日常问答用大一点的批量处理任务用小的。总之这个项目不适合追求“秒回”的用户但非常适合追求隐私、可控、可离线运行的人。明确预期之后再往下搭环境会顺畅很多。2. 环境准备把 Arm64 Windows 变成可用的容器宿主机2.1 确认系统版本与虚拟化能力动手之前先确认两件事系统是不是 64 位 Arm 架构以及 Windows 11 版本是否较新。打开“设置 - 系统 - 系统信息”在“系统类型”一栏如果显示“基于 ARM64 的处理器”说明架构没问题。Windows 11 的版本号建议保持在较新的正式版因为 Docker Desktop 对 Arm 的支持在最近几个大版本里才逐渐成熟旧版本容易踩到内核兼容性问题。确认完架构还需要确认虚拟化是否开启。Docker Desktop 在 Windows 上依赖 Hyper-V 虚拟化平台对于 Arm 版 Windows 11这个功能通常默认可用。你可以在终端里执行systeminfo命令查看最后几行中“Hyper-V 要求”是否显示“已检测到虚拟机监控程序”。如果显示未开启先到“启用或关闭 Windows 功能”里勾选“虚拟机平台”重启后再继续。我在第一次安装时漏掉了这个步骤结果 Docker 一直提示“无法启动引擎”。检查日志才发现是虚拟机平台没有打开。所以建议你把这一步放在最前面别等 Docker 装完了再排查。2.2 安装 Docker Desktop 并切换 Linux 容器模式Docker Desktop 官网提供了适用于 Arm 的版本直接下载安装即可安装过程不需要额外配置。安装完成后第一次启动会询问使用 Linux 容器还是 Windows 容器这里务必选 Linux 容器。SLM 推理生态里的镜像绝大多数都是 Linux 基础镜像Windows 容器镜像少而且体积大不适合做这件事。安装完成后打开终端执行docker version确认客户端与服务端都能正常返回版本信息。如果服务端报错先检查 Docker Desktop 右下角图标是否变绿。绿色代表引擎已运行。接着拉取一个最小的验证镜像docker run --rm arm64v8/hello-world注意这里我特意指定了arm64v8前缀。如果直接跑默认的hello-worldDocker 会根据平台自动选择镜像架构但养成显式指定架构的习惯后面能省掉不少坑。看到“Hello from Docker!”说明容器链路已经通了。此时再执行docker info查看Architecture字段如果显示aarch64就说明 Docker 服务端运行在正确的 Arm64 架构上。这一步非常重要因为后续镜像构建和运行的正确性都依赖这个前提。2.3 配置镜像加速与网络准备容器跑起来之后你会面临一个很现实的问题拉取镜像很慢。特别是模型相关的运行时镜像体积动辄几百 MB如果网络访问官方镜像源不理想等待时间很难受。解决办法是配置 registry mirror。打开 Docker Desktop 的“Settings - Docker Engine”在registry-mirrors数组中添加一个你实际可用的镜像加速地址保存并重启 Docker。配置后可以用docker info查看Registry Mirrors一节是否生效。我自己在使用加速地址后拉取大镜像的时间从十几分钟缩短到三分钟左右体感差异巨大。网络准备还有一个容易被忽略的点就是容器消费宿主 DNS 解析。Windows 11 Arm 设备如果开启了严格防火墙可能会拦截 Docker 的 DNS 请求表现为容器内无法解析域名但宿主能正常上网。遇到这种情况可以在容器启动时加--dns 223.5.5.5指定公共 DNS或者调整 Docker Desktop 的 DNS 设置。我在宿主机网络环境切换频繁时遇到过一次 DNS 问题加上参数之后立刻恢复正常。3. 部署实操用 Docker 跑起一个本地 SLM3.1 模型选择与镜像选型环境就绪后接下来要决定两件事跑什么模型以及用什么运行时镜像。模型方面我建议优先选择已经量化好的开源模型权重格式优先选 GGUF。GGUF 是专门为 CPU 推理设计的一种模型序列化格式把权重和元数据打包在一个文件里部署时只需要加载这一个文件非常方便。量化级别我一般选 INT4因为它在推理速度和内存占用之间比较平衡7B 模型 INT4 量化后大概占用 4GB 内存3B 模型占用 2GB 左右。运行时镜像方面为了避免重复编译第一选择是直接使用社区维护的、已经编译好 Arm64 二进制文件的推理引擎镜像。这类镜像通常内置了 CPU 优化指令集减少了大量编译时间。如果找不到合适的现成镜像或者想更深地定制推理参数那就走源码编译路线。我不建议在 Windows 容器里跑模型推理因为 Windows 容器对 GPU 和原生线程支持有限而且镜像生态系统很薄。正确做法是始终使用 Linux 容器把 Windows 侧的 Docker 当作一个隔离的运行环境来用。下面我给出一个完整的 Dockerfile 方案后端服务采用一个轻量级 HTTP 推理服务模型使用本地挂载的 GGUF 文件。3.2 Dockerfile 设计与关键参数说明这是项目核心镜像的 Dockerfile我加了详细注释方便理解每一层的用途FROM arm64v8/ubuntu:22.04 ENV MODEL_HOME/models ENV SLM_PORT8080 ENV SLM_THREADS4 RUN apt-get update apt-get install -y --no-install-recommends \ cmake \ build-essential \ git \ libgomp1 \ curl \ ca-certificates \ rm -rf /var/lib/apt/lists/* WORKDIR /opt/workspace RUN git clone https://example.invalid/slm-runtime.git \ cd slm-runtime \ cmake -B build -DCMAKE_BUILD_TYPERelease -DCMAKE_CXX_FLAGS-marcharmv8-a \ cmake --build build -j4 COPY models/ /models/ EXPOSE $SLM_PORT ENTRYPOINT [./slm-runtime/build/slm_server] CMD [--model, /models/slm-7b-q4.gguf, --host, 0.0.0.0, --port, 8080, --threads, 4]逐层解释一下。基础镜像我填的是arm64v8/ubuntu:22.04前面带arm64v8前缀这是为了确保即使在异构环境中构建也会优先拉取 Arm64 架构的镜像避免构建出 x86 的可执行文件后无法运行。libgomp1是 OpenMP 运行时库推理引擎依赖它做并行计算。缺了这个库运行时通常会报“cannot find -lgomp”或启动崩溃。-marcharmv8-a编译参数让编译器为 Armv8 指令集生成优化代码比通用编译出来的二进制性能高一些。COPY models/ /models/这层会把本地模型目录拷进镜像。如果你不想把模型打进镜像可以用数据卷挂载方式替代这是后话。ENTRYPOINT 和 CMD 的组合保证容器启动时直接拉起推理服务外部只需关注 HTTP 端口。3.3 构建、启动与首次请求步骤一准备模型目录。把下载好的 GGUF 文件放在项目下的models目录里文件名保持简短避免后期敲命令时浪费时间。我一般统一命名为model.gguf然后通过不同目录区分模型版本。步骤二构建镜像。在项目根目录执行docker build -t slm-local:1.0 .构建过程中拉取基础镜像和编译源码是最耗时的两步。如果看到编译日志花了几分钟别担心这是正常现象。构建完成后执行docker images查看镜像是否出现。步骤三启动容器。这里我加了一些资源限制参数docker run -d \ --name slm-server \ --restart unless-stopped \ --cpus 4 \ --memory 6g \ --shm-size 1g \ -p 8080:8080 \ slm-local:1.0--cpus 4限制容器最多使用 4 个 CPU 核心避免推理时把宿主机所有核心占满。--memory 6g限制最大内存。--shm-size 1g是专门为多线程推理准备的一块共享内存如果值设置太小线程调度会出现异常表现为响应卡顿或直接崩溃。步骤四查看日志确认加载情况docker logs slm-server看到类似“Model loaded successfully”的日志后就可以发第一个请求了curl http://127.0.0.1:8080/v1/chat/completions \ -H Content-Type: application/json \ -d {prompt: 用一句话解释什么是本地部署, max_tokens: 128}首次请求会比后续慢因为模型需要加载到内存并预热几十秒内返回都属于正常。如果顺利你会收到一段 JSON 回复包含模型生成的文本和统计信息。3.4 让服务不再局限于本机默认情况下模型服务监听的是0.0.0.0意味着局域网内的其他设备也可以访问。这时要注意防火墙Windows 防火墙默认会拦截来自外部的连接需要在“Windows Defender防火墙”中添加入站规则允许 TCP 8080 端口。添加完成后在另一台设备上通过http://宿主机IP:8080/v1/chat/completions就可以调用服务了。我实际测试时用手机浏览器直接访问这个地址也能看到 JSON 输出说明跨设备调用没有问题。Python 客户端接入代码也非常简单import requests resp requests.post( http://127.0.0.1:8080/v1/chat/completions, json{prompt: 帮我总结这句话容器化部署简化了环境管理流程。, max_tokens: 64}, timeout60 ) data resp.json() print(data[choices][0][text])这一步做完本地 SLM 就已经是一个完全可用的服务了。后面要思考的是如何让它跑得更稳、更快。4. 踩坑实录常见问题与排查技巧4.1 容器刚启动就被 Kill内存到底去哪了我在这台 Arm64 设备上第一次跑 7B 模型时容器启动十几秒后就被系统 Kill 了。查看docker logs只看到Killed关键字没有更多错误信息。后来一步步排查才发现问题出在内存上。7B 模型以 INT4 量化后大约占 4GB但推理引擎实际占用的内存不止这些还包括 KV 缓存、上下文窗口和中间计算缓冲。设备总共只有 8GB 内存Docker 引擎本身还需要预留内存一旦峰值内存超过物理内存内核回收机制就会直接把容器杀掉。解决办法分两层。第一降低模型规模换成 3B 模型同时把上下文限制在 2048 token这样内存占用能控制在 3GB 内。第二使用 Windows 的虚拟内存机制给系统保留足够的页面文件。默认情况下 Windows 11 Arm64 的虚拟内存不会自动调得很大手动设置为与物理内存相同的值能显著减少容器被 Kill 的概率。此外--memory参数不要设置得过紧要根据模型实际占用留出 1GB 冗余。4.2 执行命令报 “exec format error”说明镜像架构错了这是 Arm64 设备 Docker 部署最经典的错误。表现症状是容器创建成功但启动后立即退出日志里出现exec format error。本质原因是拉到的是 x86_64 架构的镜像而容器运行时尝试用 Arm64 内核去执行 x86 指令必然失败。解决办法有两个。一个是在启动命令里显式指定平台参数docker run --platform linux/arm64 ...另一个是在构建镜像时始终使用arm64v8前缀的基础镜像。为了彻底避开这个坑我后来在构建脚本里加了 CI 检查镜像构建完成后用脚本解析docker inspect输出的Architecture字段如果发现不是arm64就直接中止构建流程。这个方法虽然简单但能拦下大部分昏头的操作。4.3 推理速度极慢如何准确找到瓶颈部署完成后如果你发现生成速度只有每秒三四个 token说明存在明显的性能瓶颈。优先排查三个方向线程数设置、编译优化级别、内存带宽。我最初把--threads设置为 8结果速度反而比设置为 4 慢这是因为线程调度竞争太激烈尤其是多个核心共享内存带宽时反而拖慢整体。编译优化级别更隐蔽。如果你使用的是通用编译参数生成的二进制没有利用上 Armv8 特有的向量指令计算效率会差不少。在 CMakeLists 里加一句-marchnative或者-marcharmv8-a实测速度能提升 20% 以上。内存带宽方面如果设备只有一个内存通道推理时读取大权重文件会很吃力这个没有软件优化空间只能接受现实。还有一个容易忽略的点模型加载完成后第一次推理会做完整预热后续请求才会快。所以在做性能测试前先发两条短请求触发热身否则测出来的数据会偏慢。4.4 常见问题速查表我把部署过程中遇到的高频问题整理成一张表格方便直接定位症状常见原因处理方法启动后日志只有 Killed物理内存不足被系统回收换更小模型、调高虚拟内存、减少--memory限制exec format error镜像平台架构不匹配显式指定--platform linux/arm64宿主机网络正常但容器无法联网Docker DNS 解析异常启动时加--dns参数生成速度突然变慢线程数设置过高将--threads调整为核心数一半局域网无法访问服务Windows 防火墙拦截添加入站规则放行 8080 端口模型总是加载一半就报错GGUF 文件损坏或未下载完整校验文件哈希并重新下载容器时间一长占用内存持续上涨上下文缓存无限增长给服务端设置最大上下文限制并定期重启这张表基本覆盖了我踩过的绝大多数坑。剩下的一些问题比如端口被占用、卷挂载权限不对都属于常规 Docker 问题也可以按照类似的思路排查。5. 性能验证与应用落地建议5.1 用脚本做一次可复现的评测服务稳定运行之后建议做一次可复现的性能评测给后续调优留一份底稿。我写了一个非常简单的脚本测量三个指标首次响应延迟、平均生成速度、最长生成长度。import requests import time prompt 写一份关于容器化部署的优点清单要求简洁明了。 max_tokens 200 t0 time.time() resp requests.post( http://127.0.0.1:8080/v1/chat/completions, json{prompt: prompt, max_tokens: max_tokens}, timeout180 ) t1 time.time() data resp.json() choices data.get(choices, []) if choices: text choices[0].get(text, ) total_tokens data.get(usage, {}).get(completion_tokens, len(text)) elapsed t1 - t0 print(f首token响应耗时: {elapsed:.2f} 秒) print(f生成 token 数量: {total_tokens}) print(f平均速度: {total_tokens / max(elapsed, 0.01):.2f} token/s)执行后把数据记录到一个固定文件里。以后每次更换模型或改动参数时都跑一遍同样的脚本对比数据就能清楚看到改动带来的利弊。我在项目里逐步记录了多组数据发现模型量化级别的变化对速度的影响远比调整线程数明显这为我后续选择模型提供了直接依据。5.2 针对资源紧张场景的再优化如果评测结果达不到需求还有几个优化方向可以尝试。第一把模型从 INT4 进一步压到 INT3推理速度能小幅提升但生成质量会略有下降适合对准确度要求不高的任务。第二减少上下文长度很多 SLM 默认支持 4096 甚至 8192 token 的上下文但在有限资源设备上上下文越长KV 缓存占用越大推理越慢。我把上下文从 4096 降到 2048 后内存占用减少了大概 25%速度提升了接近两成。第三使用 Windows 的“高效电源模式”或者把电源计划切到“最佳性能”对 CPU 推理也有帮助。Arm 设备在省电模式下会降低处理器频率推理速度下降非常明显这一点容易被忽略。最后如果容器和系统在同一个磁盘上尽量选用固态硬盘而不是机械盘。模型加载速度和磁盘 IO 直接相关机械盘加载 4GB 模型可能要多等 30 秒以上。5.3 后续扩展与个人经验总结项目跑通之后不要停在“能出结果”就收工。我会建议继续扩展两个方向。第一把模型服务注册成 Windows 开机自启的 Docker 容器--restart unless-stopped参数加上之后重启设备不用手动干预服务会自动恢复。第二用这个 SLM 接口做一个本地知识库预处理管道对一批文档定时做摘要和分桶再把结果导入到检索系统里这样数据全链路都留在内网安全性和可控性都高很多。最后说一点个人体会。部署本地 SLM 最大的门槛其实不在 Docker 命令也不在模型选择而在于对资源消耗的认知。很多人拿服务器跑大模型的惯性思维去套 Arm 小设备结果一上来就跑大模型、大上下文最后只能得到频繁崩溃和极差的体验。先把预期调整到“与设备匹配”再选择合适的模型和量化级别整个部署过程会顺畅非常多。另一个我反复强调的经验是一定要保留可复现的环境。镜像构建脚本、模型文件目录、启动参数最好都放进项目代码库管理起来。这样将来无论是换设备、换模型还是排查环境问题都能在几分钟内恢复到一个已知正常的状态。这比反复手工调整环境要可靠得多。