lora-scripts 能否在 Mac M1 上运行？Apple Silicon 适配深度解析
在 AIGC 创作门槛不断降低的今天，越来越多设计师、独立开发者和内容创作者希望用自己的设备训练个性化模型。LoRA（Low-Rank Adaptation）作为当前最主流的轻量化微调技术之一，因其低资源消耗和高效定制能力，成为许多人的首选方案。而像lora-scripts这类自动化训练工具，进一步简化了从数据准备到权重导出的全流程操作。
但问题来了：如果你用的是 MacBook Pro 搭载 M1 芯片——没有 NVIDIA 显卡、不支持 CUDA——还能不能跑得动这些脚本？
答案是：可以，但需要绕点路。
苹果自研的 Apple Silicon 系列芯片虽然性能强劲、功耗极低，但在深度学习生态中始终面临一个核心挑战：缺乏对传统 GPU 加速框架（如 CUDA）的支持。取而代之的是 Apple 自家的 Metal Performance Shaders（MPS），它允许 PyTorch 将计算任务调度到 M1 的 GPU 上执行。这一转变看似平滑，实则暗藏不少坑点。
我们先来看 lora-scripts 的本质。它并不是某个闭源软件，而是一组 Python 脚本集合，依赖于 PyTorch、HuggingFace Transformers 和 Diffusers 等开源库构建。这意味着它的可移植性非常高——只要你的系统能运行 Python 并安装所需依赖，理论上就能跑起来。
真正的瓶颈不在脚本本身，而在底层框架是否能在 ARM 架构 + MPS 后端上正常工作。
PyTorch 从 1.13 版本开始正式引入mps设备支持，也就是你可以通过torch.device("mps")来启用 M1 GPU 加速。这为本地训练打开了大门。然而，并非所有算子都已实现 MPS 后端支持。例如某些归一化层（LayerNorm）、特定卷积模式或随机采样操作，在早期版本中仍会回退到 CPU 执行，导致训练效率大打折扣。
所以关键问题变成了：如何让 lora-scripts 在 M1 上尽可能多地使用 MPS 加速，同时规避不兼容的操作？
实际部署过程中，第一步永远是环境配置。推荐使用 Miniforge 或 Miniconda 创建独立的 Python 环境，因为它们专为 ARM 架构优化，避免 Rosetta 转译带来的性能损失：
# 使用 Miniforge（推荐） conda create -n lora-m1 python=3.10 conda activate lora-m1 pip install torch torchvision torchaudio --index-url https://download.pytorch.org/whl/cpu注意这里虽然用了cpu的 pip index URL，但实际上这个“CPU”包包含了 MPS 支持。这是由于 PyTorch 官方尚未发布独立的mpswheel 包，而是将其集成在 CPU 版本中供 macOS 用户调用。
接下来是修改训练脚本中的设备逻辑。原生 lora-scripts 通常只判断cuda是否可用，而忽略了mps：
import torch def get_device(): if torch.cuda.is_available(): return torch.device("cuda") elif hasattr(torch.backends, "mps") and torch.backends.mps.is_available(): return torch.device("mps") else: return torch.device("cpu") device = get_device() print(f"Using device: {device}")这段代码应当插入到train.py或配置初始化模块中，并确保模型和输入张量都被正确移动至目标设备：
model.to(device) for batch in dataloader: pixel_values = batch["pixel_values"].to(device) outputs = model(pixel_values) loss = outputs.loss loss.backward() optimizer.step()一旦看到日志输出 “Using device: mps”，说明 GPU 加速已经激活。但这只是第一步。
真正影响体验的是内存管理。M1 芯片采用统一内存架构（Unified Memory Architecture），CPU 和 GPU 共享物理内存（通常是 8GB 或 16GB）。这意味着你无法像在 x86 + 独立显卡那样拥有“专用显存”。当 batch_size 设置过高、图像分辨率过大时，很容易触发内存溢出错误（out of memory或metal kernel error）。
实战经验表明，在 M1 Max 以外的普通 M1/M2 芯片上，安全参数应控制为：
-batch_size: 1~2
- 图像分辨率不超过512x512，理想值为448x448或384x384
-lora_rank: 4~8（更高的 rank 增加参数量和显存占用）
- 关闭梯度检查点（gradient checkpointing）除非必要
此外，自动标注脚本（如基于 CLIP 的auto_label.py）也常出现问题。部分第三方库未完全适配 MPS，导致在特征提取阶段崩溃。解决方法是在标注阶段强制使用 CPU：
with torch.no_grad(): inputs = processor(images=image, return_tensors="pt").to("cpu") outputs = clip_model(**inputs)这样虽牺牲速度，但保证流程稳定。
另一个常见问题是某些算子缺失 MPS 实现。比如torch.nn.functional.scaled_dot_product_attention在较早版本的 PyTorch 中无法在 MPS 上运行，会导致 Attention 层降级为 CPU 计算。这类问题可通过升级 PyTorch 至最新稳定版缓解，目前 2.0+ 已大幅改善算子覆盖率。
我们不妨看一个完整的训练配置示例：
# configs/my_lora_config.yaml train_data_dir: "./data/style_train" metadata_path: "./data/style_train/metadata.csv" base_model: "./models/v1-5-pruned.safetensors" lora_rank: 8 lora_alpha: 16 lora_dropout: 0.1 conv_lora: false batch_size: 2 resolution: 512 learning_rate: 1e-4 optimizer: "adamw8bit" scheduler: "cosine" epochs: 10 warmup_steps: 100 output_dir: "./output/cyberpunk_style" save_every_n_epochs: 5其中特别要注意的是：
- 使用.safetensors格式模型文件，加载更快且更安全；
- 避免使用8bit Adam以外的复杂优化器，因部分量化操作不被 MPS 支持；
- 减少保存频率，防止 I/O 占用过高资源。
即便如此，仍需接受一个现实：M1 上的训练速度无法与 RTX 3090/4090 相提并论。以 SD v1.5 为基础进行风格 LoRA 微调为例，在 batch_size=2 下每 epoch 大约耗时 8~12 分钟（M1 Pro），而同条件下高端显卡仅需 2~3 分钟。但对于只需训练几个 epoch 的轻量任务来说，这种差距是可以接受的。
更重要的是，整个过程完全本地化，无需联网上传数据，隐私性强，适合处理敏感图像或商业项目素材。
从应用场景来看，M1 + lora-scripts 的组合最适合以下几类用户：
-数字艺术家：快速训练个人绘画风格 LoRA，用于创作迭代；
-产品设计师：在本地生成符合品牌调性的视觉元素；
-研究者与教育者：教学演示 LoRA 原理，无需依赖服务器资源；
-边缘 AI 探索者：验证小型模型在终端设备上的可行性。
未来的发展趋势也很清晰：随着 PyTorch 对 MPS 的持续投入，更多算子将获得原生支持，半精度（float16）运算也将逐步完善。已有迹象表明，Apple 正在加强与开源社区的合作，推动 Core ML 与 HuggingFace 生态的融合。长远来看，甚至可能出现直接将 LoRA 模型导出为 Core ML 格式，在 iPhone 或 iPad 上实时推理的可能性。
当然，现阶段仍有局限。如果你的目标是训练高分辨率 LoRA、处理大规模文本数据集，或是做 LLM 的完整微调（如 LLaMA-7B 以上），那么 M1 依然力不从心。但对于绝大多数入门级和中级需求而言，它已经足够“能用”，而且越来越“好用”。
最终结论很明确：
lora-scripts 可以部署在 Mac M1 上，且能够利用 MPS 实现 GPU 加速训练。尽管存在算子支持不全、内存受限等问题，但通过合理调整参数和规避已知陷阱，完全可以完成轻量级 LoRA 模型的端到端训练。
这不是高性能解决方案，但它代表了一种新的可能性——让每个人都能在自己的笔记本上完成 AI 模型的个性化定制。而这，正是 AIGC 民主化进程中最值得期待的方向之一。
