Mac 本地生图这件事我最近在 M 系列芯片的 Mac 上认真跑了一遍手里这台机器实测下来大约 182 秒生成一张 512×512 的图内存占用控制在 10GB 以内整个过程完全离线、不依赖任何外部服务。如果你的需求是“随手画个概念草稿”“给文章配个临时示意”“研究一下提示词怎么调”这类自用场景这套方案完全够用。但有一点必须提前说清楚——很多开源模型的权重协议明确限制商业用途这一点我在后面专门讲建议赶时间的朋友也先扫一眼那一段。这篇文章面向的是想在 Mac 上本地跑通 AI 生图的初级到中级用户默认你用过终端但不需要太深的机器学习背景只求在实际操作里少走弯路。我用的方法是纯命令行加开源的 Stable Diffusion 权重不套那些一键安装包因为装完你才知道哪里出了问题以后优化也有底。1. 为什么我选择在 Mac 上做本地生图一个不需要理由的理由1.1 云端免费额度用完后的现实选择最初我想得比较简单直接在线平台生成不用装环境也不用下模型。免费额度一开始确实够用等真正批量做测试就尴尬了每天剩的额度连调几组提示词都不够更别提对比采样器差异。用付费额度又有点心疼。后来换成本地方案一次投入把模型和数据都放在硬盘里之后所有生成行为都只消耗电费。这个思路对“高频、碎片化、实验性质”的生图需求非常友好。你不需要开订阅不用担心服务停服最实在的是可以在凌晨三点钟突然想到一个构图随手写个命令就出图。本地生图的另一个隐性优势是延迟可控。网上服务高峰期排队、限速的问题很普遍一套本地脚本从启动到出图时间基本就是纯性能开销没有任何人为限速也不会因为“前面有一千个人在排队”而白等十分钟。1.2 182秒与10GB这两个数字是怎么来的先亮出我的实际环境项目实际配置机器型号Mac mini(M1 芯片,当前实测环境)内存16GB(测试过程内存约10GB)系统版本macOS 14.4生成工具Stable Diffusion WebUI 的命令行后端,具体采样配置见文末模型Stable Diffusion v1.5 官方权重图像尺寸512×512采样步数50平均耗时182秒/张为什么是 50 步而不是 20 步因为我一开始用的默认配置就是 50 步。在这个步数下M1 的 CPU/核显协同推理要跑 182 秒属于一个“等待时间明显但不至于无聊到放弃”的中间档位。你看到网上那些“几秒出图”的截图要么是 A 卡/N 卡 GPU 推理要么是步数降到了 15-20要么加了量化模型同一台机器差异非常大。内存方面Stable Diffusion v1.5 的权重文件本身就是 fp16 精度的 2GB 上下实际运行时会把模型、CLIP 文本编码器、VAE 解码器全部载入再加上 PyTorch 的运行库和系统本身的占用量整体就来到了 10GB 附近。16GB 内存的机器跑起来没有压力8GB 内存的机器需要把交换空间打开但生成速度会明显下降。所以在标题里写“10GB 内存”指的是一个靠谱的最低配置参考线不是官方硬性要求。2. 硬件门槛的真实评估10GB内存到底意味着什么2.1 内存下限为什么会卡在10GB先不谈显存因为 Mac 的统一内存架构跟 PC 不一样CPU 和 GPU 共用同一块内存所以 16GB 内存的 Mac 在推理时真正能用的“显存”其实就是内存的一部分。Stable Diffusion 对内存的需求分三块模型权重:SD v1.5 的 UNet、CLIP、VAE 三项累加起来约 4GB(fp16 精度下,不加载安全检测器)。运行时缓存:采样过程中要维护噪声、latent、中间特征图,512×512 尺寸下大概 2GB 左右。系统与工具链:macOS 自身基础占用 4-5GB,加上 Python、PyTorch 的物理内存和虚拟内存开销。三项叠加非常自然地落在 9-10GB 这个区间。用 8GB 内存的入门级 Mac 跑同一配置系统会开始强制交换内存生成时间从 182 秒膨胀到 300 秒以上过程中如果开着浏览器风扇会拉满。16GB“够用”是底线结论32GB 则可以在出图的同时正常浏览网页。2.2 芯片型号差异对速度的影响我的测试主力是 M1 的基础款M1 Pro/Max 和 M2 系列会有明显差异。M1 的神经网络引擎在 PyTorch 的 MPS( Metal Performance Shaders)后端下并没有完全发挥真正干活的主要是 GPU 核心和 CPU 核心。20 核 GPU 的 M1 Max 和 8 核 GPU 的 M1 基础款同样 50 步出图时间差距可能在 40%-60% 之间。所以合理预期是M1 基础款 182 秒M1 Pro/Max 大约 120-150 秒M2/M3 系列如果散热和内存带宽到位可以压到 100 秒附近。至于网上那些“MacBook 上 3 秒出图”的说法用的是专门的轻量化模型或精简蒸馏模型配置和场景跟我不一样不能直接拿来做基准。性能的核心瓶颈不在 CPU 算力而在 PyTorch MPS 后端对某些算子的支持不够完善导致一部分计算回退到 CPU。这个现象在 intel 芯片的老 Mac 上更严重因为 AMD 显卡的 Metal 支持相对有限。所以结论很直接M 系列芯片跑 SD 是可行的路线intel Mac 勉强能跑但不推荐起步阶段成就感太低。2.3 性能预期管理CPU推理也能出图很多人一听“182 秒一张”就觉得没法用这个感受我理解但需要先分清楚使用场景。如果你是要拿图做设计、做输出、给客户交付182 秒确实低效如果只是测试提示词、研究配置差异、或者给文章配个临时的示意图182 秒完全在接受范围内。说白了你不会连续盯着一张图等它渲染通常是发出命令之后切到其他窗口做别的事等系统通知或者回头看一下输出目录就好。我们算一笔时间账一次完整的生图操作写提示词 30 秒执行命令 10 秒等待 182 秒查看结果 30 秒。整个过程约四分钟。如果你用在线服务输入提示词、等待排队、微调重来很可能也要三到五分钟一轮还不算免费的额度限制。所以本地 182 秒并没有想象中那么不能接受它只是把“排队等”换成了“计算等”而后者至少可控。3. 从零搭环境macOS上最省心的安装链路3.1 先解决Homebrew这个老问题macOS 上装开源工具链的第一步基本绕不开 Homebrew但这个环节也是反馈最多的地方。安装失败的情况很常见崩溃点通常集中在下载阶段因为官方脚本默认走 GitHub 源网络掉链子的概率比较高。我的经验是尽量避免直接执行官网那条/bin/bash -c长命令而是先把安装脚本下载下来再执行这样好处是脚本出问题的时候你能看到具体的报错位置。另外多个版本的 Python 依赖装出问题根因往往是 Homebrew 的权限问题——/opt/homebrew目录被你不小心 chown 到了别的用户。如果你已经遇到这个问题简单处理方式是把 Homebrew 目录所有权还原sudo chown -R $(whoami) /opt/homebrew装完 Homebrew 之后下一步装核心依赖。Stable Diffusion 的 WebUI 命令行版本主要需要 git、Python、CMake、protobuf 编译器这些都可以一次装齐brew install git cmake protobuf rust python3.11细心的朋友会发现我加了一个 rust因为后面编译一些依赖的时候会用到。在这里提前把 rust 装好能省一整套编译环境折腾时间。3.2 Python环境用Miniconda避开系统自带Python的坑系统自带的 Python 版本一般比较保守而且直接往系统路径里装 pip 包非常容易把环境搞乱。我用的是 Miniconda它可以把 Python 和依赖都隔离在一个独立环境里出了问题删掉重建就行不会污染系统。安装 Miniconda 很简单去官网下载 macOS 的 pkg 安装包或者用 Homebrewbrew install --cask miniconda conda init zsh source ~/.zshrc然后新建一个独立的环境conda create -n sd-webui python3.11 -y conda activate sd-webui等于说从现在开始所有 Python 相关的乱七八糟操作都不会碰到系统自带环境。我在这一步踩过一个大坑——当时图省事用系统 Python 直接装后来升级 macOS 系统版本之后一堆依赖全部失效重建环境花了半小时。用 Conda 之后macOS 升级和项目环境完全解耦再也没有这种问题。3.3 模型权重下载放在哪个目录最合适很多人买完硬盘存了几百GB的模型结果导入 WebUI 之后发现模型列表是空的原因就是放错目录。SD WebUI 约定的模型路径是models/Stable-diffusion/注意有连字符且目录名是 WebUI 的默认名不是你自己起的名字。我建议按以下结构组织目录~/sd-webui/ ├── models/ │ ├── Stable-diffusion/ │ │ └── v1-5-pruned-emaonly.safetensors │ ├── VAE/ │ │ └── vae-ft-mse-840000-ema-pruned.ckpt │ └── Lora/ ├── outputs/ │ ├── txt2img/ # 文生图结果 │ └── img2img/ # 图生图结果 └── 其他内容由WebUI自动生成权重文件下载完之后用文件管理器确认文件大小在 2GB 以上完整 fp16 精度小于这个数基本就是半截下载。如果下载到一半断了不要直接接着用重新下或校验一下。此外有些站点会提供“fp16-model”版本和“full-pruned”版本对本地运行来说前者足够且省内存。我在实际跑通之前卡在权重路径错误上整整两次都是因为大小写问题。这个目录名是大小写敏感的S和D必须按规范来改成小写就会直接报错“model not found”。4. 命令行出图实测182秒一张的完整链路4.1 首张图的实际命令与输出启动 WebUI 的命令行后端可以用launch.py界面默认在http://127.0.0.1:7860为了验证参数我一般用纯命令行接口。准备一张测试图的最快捷路径是conda activate sd-webui cd ~/sd-webui python launch.py --api --listen 127.0.0.1:7860然后另开一个终端窗口通过 API 或者直接改脚本传参。如果你不想开浏览器用python scripts/txt2img.py的方式是最直接的python scripts/txt2img.py \ --prompt a photo of a cute corgi puppy, soft lighting \ --ckpt models/Stable-diffusion/v1-5-pruned-emaonly.safetensors \ --n_iter 1 \ --n_samples 1 \ --H 512 \ --W 512 \ --ddim_steps 50 \ --seed 42这条命令会输出图像到outputs/txt2img/目录。跑起来的瞬间终端会显示加载模型的信息然后开始采样循环。前几次运行会有一个“编译算子”的阶段通过 MPS 后端把 PyTorch 里的算子编译成 Metal 着色器这段时间通常要 30 秒到一分钟不等之后再用就快了。4.2 每一秒都花在哪里耗时拆解我把一次完整可复现的生成过程用时间戳记录了下来数据如下环节耗时说明模型加载与权重初始化22秒首次运行较慢,后续有缓存会更快文本编码3秒提示词通过 CLIP 编码为特征向量采样循环148秒50 步 DDIM 采样,每步约 3 秒VAE 解码输出图像5秒把 latent 还原为像素图图像保存与后处理4秒写文件、添加元数据总计182秒与标题数值吻合采样循环占据了 80% 的时间这也是优化空间最集中的地方。50 步的采样循环花费约 148 秒意味着每步约 3 秒。这个 3 秒由 UNet 的前向推理决定而 UNet 在 M1 芯片上的 MPS 执行效率并不能完全发挥因此即使步数减半时间也不会严格减半因为模型加载和 VAE 解码的固定开销会占去剩余部分。举个例子把步数从 50 降到 20预计总耗时从 182 秒降到约 95-100 秒省下的主要是采样循环中间的 30 步大约 88 秒。但如果你开了图生图、放大等附加步骤总时间又会增加。理解这些环节之后你才能根据自己的需求精确地调整参数。4.3 影响出图速度的三个关键因素第一是采样步数。50 步和 20 步的画面差异对大部分普通提示词来说并不大但时间能省将近一半。第二是图像分辨率。分辨率提升后特征图的尺寸也跟着变大每个采样步的计算量是呈平方级增长的——512×512 到 768×768耗时直接翻倍多。第三是 MPS 后端的算子优化。这个问题不归你控制但可以通过换 PyTorch 版本来影响。我实测过从 PyTorch 2.0 升到 2.2在 M1 上同一模型的采样速度大约提升 10%-15%。这三个因素叠加起来足以让你在同一台机器上拥有完全不同的使用体验。反过来如果你在网上看到别人用同款芯片“50 秒出图”不要想当然地认为博主配置了什么黑科技多半只是步数从 50 降到了 20加上图片尺寸没开那么大而已。5. “不能商用”意味着什么许可协议的边界5.1 CreativeML OpenRAIL-M到底限制了什么标题里“不能商用”四个字很多人看一眼就跳过了但这才是整个项目里最该搞清楚的部分。Stable Diffusion v1.5 官方权重采用的许可是 CreativeML Open RAIL-M这是一份专门为生成模型设计的开放许可它跟传统开源协议一点也不一样。核心限制有三条我用自己的话翻译一下不能直接用它做商业用途。比如拿这个模型跑图卖给客户赚钱、把模型集成到商业产品里收费这类行为在默认协议下是不被允许的。不能故意生成不合法或传播有害的内容。这一点不用展开字面意思。你生成的图像如果符合某些特定条件可能会受到条款约束。这一点比较模糊实践中最稳妥的做法是标注“图像由 AI 生成”避免传播环节出现误解。所谓的“不能商用”最直观的例子有人想训练一个配套的美术风格模型卖给设计公司结果刚上架就被下架原因就是使用了v1-5作为底模底模的许可不允许商业衍生品。这种失误属于基础功课没做好下载模型权重之前花两分钟看一眼 license 文件能省后面一大笔纠纷成本。5.2 不同模型许可对比哪些能商用、哪些不能不是所有的开源 SD 模型都不能商用实际情况分四档我用一个表格总结一下模型名称许可类型当前实测环境的商用状态实际条款判断见官方声明Stable Diffusion v1.5CreativeML OpenRAIL-M默认不允许商用Stable Diffusion 2.1CreativeML OpenRAIL-M默认不允许商用Stable Diffusion XLCreativeML OpenRAIL/Playground v2.5自定义社区许可/DreamShaper社区开放许可/SegMind SSD-1B蒸馏模型,许可随上游/具体商用判断需要在下载页面对照当时的授权版本不要只看社区讨论里的一句话结论。一张图这个行业变化很快某个月还在“禁止商用”的模型下个版本可能就改成“允许商用”反之亦然。所以最稳妥的路径是三点模型页面上白纸黑字的 license 链接是唯一可信来源公司内部合规审核最好书面确认个人自用和公开运营是完全不同的状态后者务必字面理解条款。5.3 合法自用的边界与建议在这里我不做法律建议只讲实际操作里怎么最大程度避开风险。个人本地生图、自用学习、做公开的技术分享这类场景风险很低拿模型跑图后挂到电商平台销售、做一个“AI 修图服务”对外接单、把模型集成进 SaaS 产品这类场景风险陡增。如果你确实有商用需求有两条路可走一是联系原模型作者申请商业授权二是直接用明确允许商用的模型比如 SDXL 发布版本、一些商业友好的微调模型或者使用平台的服务。第二条路通常更省事也很好找搜一下“可商用开源模型”就能拿到不少候选。我个人的看法本地跑通之后个人制作、学习探索、内容创作练习的价值已经非常大。商用授权的问题可以先放一放因为你只是拿它做一个思路验证最后交付给别人的时候完全可以换一条合规的生成链路。6. 提速到90秒以内的几个思路6.1 更换采样器与减少步数这是成本最低、收益最高的一个优化方向。WebUI 默认的采样器是Euler a或DDIM这类如果我换成DPM 2M Karras在同样步数下画质略有提升换成少步数选手Euler a则可以用较低的步数得到接近的效果。实际测试50 步 DDIM 出图为 182 秒换成 20 步 Euler a 之后总时间压到约 95 秒画面中的细节损失对非专业用途来讲完全可接受。如果再把分辨率控制到 512×512 且不开高清修复实际生成时间还能再降。总的原则是先降步数再降分辨率优先保证构图和主体内容画质细节可以通过后处理弥补。配置步数平均耗时主观感受原始配置50182秒稳,但等待时间长减少步数2095秒细节减少,整体可接受减少步数轻量采样器2088秒等待时间明显降低比较有意思的一个点是减步数对画面质量的影响并非线性在 15 步以下会出现明显的噪声残留20 步是一个相对安全的阈值。6.2 量化与轻量化模型如果你不满足于“降步数”那下一步就是换模型。业内常说的量化模型把 UNet 的权重从 fp16 压缩到 int8内存占用降约一半速度也有一定提升在 Mac 上实测约能提速 20%-30%。代价是极端细节可能丢失但普通 512 分辨率下肉眼几乎看不出区别。另一个方向是换蒸馏模型在保持视觉质量的前提下把推理步数降到 2-4 步。这类模型在 Mac 上配合 MPS 后端能达到“十几秒一张”的效果。如果看到有人声称“Mac 本地 5 秒出图”大概率用的是这类蒸馏模型加上小尺寸图片。不过我作为第一次接触 Mac 本地生图的人并不建议一上来就用蒸馏模型——它会把很多底层机制藏起来后续调整参数会变得难以理解。先把标准模型跑通再考虑省时间的版本学习路径会更顺。6.3 分批生成与半精度推理在命令行接口里设置n_iter大于 1可以一次生成多张图模型只需要加载一次后续都是采样循环重复利用内存。这样单张平均时间会比单独跑多张命令省 10% 以上因为省掉了重复加载模型的时间。配合半精度推理--precision autocast会有效控制内存占用。像这样python scripts/txt2img.py \ --prompt sci-fi city street, rainy night, neon lights \ --ckpt models/Stable-diffusion/v1-5-pruned-emaonly.safetensors \ --n_iter 4 \ --n_samples 1 \ --H 512 \ --W 512 \ --ddim_steps 30 \ --seed 2024四张图一次性生成每张大约 90 秒总耗时 360 秒左右。如果你一次只跑一张但命令执行四次耗时大约 400 秒以上。批量执行在这个场景下就是实打实的优化手段。7. 我踩过的坑与实用建议7.1 依赖冲突与安装失败安装 WebUI 依赖时看到的最常见一套报错是No matching distribution found for xxx来源基本是网络问题或 Python 版本不匹配。我遇到过一次torch下载完成后校验失败当时的解决方式就是删除环境重建用带镜像地址的方式重装conda install pytorch torchvision torchaudio -c pytorch如果说 Mac 安装过程里有什么唯一该记住的经验那就是环境出问题优先删除重装不要在一个坏的 base 环境上反复补依赖。一次补丁式的修复可能解决当前报错但会带来三个新的奇奇怪怪问题跟直接重建花费的时间完全不成比例。7.2 内存不足的交换迹象8GB 内存的机器跑这套流程时系统日志里会出现频繁的 swap 写入。一个判断方法跑生成任务的终端窗口旁边再开一个Activity Monitor如果“Swap Used”在生成期间飙升到 5GB 以上说明物理内存吃紧。这种情况下没有特别完美的方案我能给出的实用建议是关闭所有浏览器标签页和后台应用把生成的分辨率保持 512×512采样步数控制在 30 以下。如果还不行升级到 16GB 内存的机器或者改用蒸馏模型这两个路线里的任何一条都比内存压缩过程的体验更好。7.3 一套适合Mac用户的起步配置最后分享一下我目前在实际工作里固定的启动参数兼顾画质和等待时间。这组配置适合概念验证、文章配图、和日常杂七杂八的需求python scripts/txt2img.py \ --prompt 这里替换你的提示词 \ --ckpt models/Stable-diffusion/v1-5-pruned-emaonly.safetensors \ --n_iter 2 \ --n_samples 1 \ --H 512 \ --W 512 \ --ddim_steps 20 \ --seed -1n_iter 2保证一次出两张图供挑选ddim_steps 20保证速度seed -1随机种子保证每轮结果不重复。平均单张耗时约 95 秒四舍五入就是标题 182 秒的一半但实际出图效果对大多数日常场景完全够用。如果你愿意接受偶尔的画面瑕疵可以把步数进一步降到 15约 72 秒一张等图的过程正好能看一眼手机消息。我个人的使用习惯是先用低步数快速跑出构图方向选中一张中意的之后再用高步数单独精修一次。这样既能快速探索创意又能在关键产出上保留细节算是 Mac 本地生图这套工作流里最实用的一条经验。