最近刷 X，经常能看到有人用 NVIDIA DGX Spark 部署百亿、千亿级大模型，看得不少人心痒痒。
不过，DGX Spark 确实性能强悍，价格也并不亲民。对于大多数开发者来说，真正能折腾的，还是手头那台已经服役几年的电脑。
最近，就有网友分享了一套在 2022 款第一代 Mac Studio（M1 Max / 32GB） 上部署 Ling-3.0-tiny INT4 的完整方案。
原本，这位网友认为这台机器已经很难承担如今的大模型推理任务。
但实际测试结果却有些出乎意料。
模型不仅支持聊天、推理（Think Mode）和工具调用（Tool Calling），在 Apple Silicon 上还能保持约 64 Token/s 的稳定生成速度，对于本地聊天、代码辅助、翻译以及个人 Agent 等场景来说，已经相当流畅。
更重要的是，它并不是传统意义上的“1B 小模型”。
Ling-3.0-tiny 为什么值得关注？
Ling-3.0-tiny 的总参数规模约 7.9B。
不过，它采用的是 MoE（Mixture of Experts）稀疏专家架构。
简单来说：
- 模型拥有约 128 个专家（Experts）
- 每个 Token 仅激活其中 8 个专家
- 再配合共享专家共同参与计算
- 实际参与推理的大约只有 1.3B 参数
这种设计兼顾了模型容量与推理成本，也让它能够在 Apple Silicon 上获得不错的推理速度。
测试环境
这位网友使用的设备配置如下：
- Apple Mac Studio（2022）
- Apple M1 Max
- 24 核 GPU
- 32GB Unified Memory
- macOS 15.7.4
- arm64
虽然 Ling-3.0-tiny 支持更长的上下文，但为了兼顾内存占用与稳定性，本次测试将 Context 设置为 8K。
对于聊天、代码补全和日常 Agent 应用来说，这已经足够使用，同时还能避免 KV Cache 持续占用大量统一内存。
整个部署架构如下：
Ling-3.0-tiny INT4
│
支持 Ling 的 Ollama 实验分支
│
MLX Runner
│
Metal / Apple Silicon GPU
│
Ollama API（11434）之所以没有直接使用稳定版 Ollama，是因为目前 Ling 与 Bailing MoE V3 的支持仍然依赖 Ollama 实验分支。
而 vLLM、SGLang 等推理框架则更适合 NVIDIA CUDA 环境，在 Apple Silicon 上并不是最佳选择。
部署之前，先规划好磁盘空间
整个部署过程中，最容易被低估的并不是模型本身，而是磁盘占用。
最终目录占用大致如下：
| 内容 | 大小 |
|---|---|
| Hugging Face INT4 原始权重 | 约 5.4GB |
| Ollama 导入模型 | 约 5.8GB |
| Ollama 源码、MLX 与编译结果 | 约 1.3GB |
| Cache 与配置 | 数十 MB |
整个项目最终约 13GB。
考虑下载临时文件、编译缓存以及 macOS Swap，建议至少预留 20GB 可用空间，更推荐准备 30GB 以上。
一个容易忽略的坑：Git
这位网友分享的最大踩坑经历，并不是模型，而是 Git。
由于整个部署过程是在 Codex 项目目录中完成，而项目默认启用了版本快照。
模型下载完成后，Git 又把整个模型目录保存了一份。
结果一个约 5GB 的模型，很快膨胀到了十几 GB，系统盘空间迅速下降。
最终排查发现，是没有提前将模型目录加入 .gitignore。
建议提前添加：
.cache/
models/
ollama-models/
ollama-ling/重新清理 Git Objects 后，整个 .git 目录仅剩约 132KB。
如果准备部署大模型，这一步最好提前完成。
下载 Ling-3.0-tiny INT4
官方已经提供 Hugging Face INT4 权重。
整个仓库包含：
- 44 个文件
- 32 个 safetensors 权重分片
下载过程中，这位网友主要遇到了两个问题：
第一，Xet 下载速度长时间停滞。
后来关闭 Xet，改用普通 HTTP 下载。
第二，下载过程中频繁出现超时。
由于 Hugging Face CLI 支持断点续传，因此只需要适当提高超时时间即可继续下载。
下载结束后，并没有直接认为模型已经完整。
而是进行了三项校验：
- 检查 32 个权重分片是否全部存在
- 检查模型索引是否引用完整
- 对全部分片计算 SHA-256
最终结果：
- 文件异常：0
- 哈希异常：0
- 缺失分片：0
对于数 GB 的模型而言，建议至少完成分片数量或哈希校验，而不是仅凭下载完成提示判断模型完整。
编译支持 Ling 的 Ollama
目前官方稳定版 Ollama 尚不能直接运行 Ling，因此需要切换实验分支自行编译。
整个过程中，真正卡住这位网友的是 Metal Toolchain。
机器已经安装了：
- Xcode
- Command Line Tools
但 MLX 编译依然报错。
后来才发现，Metal Toolchain 需要单独安装。
更麻烦的是，即使安装完成，系统依然可能找不到 Metal 编译器。
最终查看 Toolchain Identifier 后，需要手动设置：
export TOOLCHAINS=...需要注意的是，这个值会随着 macOS 和 Xcode 版本不同而变化，不建议直接复制其他人的配置。
编译完成后，会生成：
- Ollama 主程序
- MLX Runner
- Metal Kernel
- 动态库
需要特别注意，不要只保留 ollama 可执行文件。
真正运行模型，还依赖 build 目录中的 Runner 与动态库。
导入 INT4 模型
为了避免与系统中的稳定版 Ollama 混用，这位网友将模型目录单独放在项目内部。
导入完成后，Ollama 输出：
26947 tensors
479 layers
preserving source quantization说明 INT4 权重保持原始量化格式，不需要再次转换。
最终模型名称为：
ling-tiny-int4:latest如何确认 GPU 真正在工作？
这一点非常重要。
因为模型有可能静默回退到 CPU。
部署完成后，可以查看日志确认是否出现类似信息：
library=Metal
Apple M1 Max
MLX engine initialized device=gpu只有看到这些日志，才能确认整个推理过程真正运行在 Apple GPU 上。
M1 Max 实测速度
为了避免首 Token 延迟影响结果，这位网友先进行了模型预热。
随后连续进行了三轮完整生成测试。
测试条件统一如下：
- Context：8192
- Temperature：0
- Think：关闭
- 输出长度：384 Tokens
最终成绩如下：
| 测试 | Token/s |
|---|---|
| 第一轮 | 64.26 |
| 第二轮 | 65.18 |
| 第三轮 | 63.67 |
最终平均：
64.37 Token/s
首次加载模型约耗时：
6.93 秒
模型驻留后，占用统一显存约：
6.48GB
对于一台已经发布数年的 M1 Max 来说，这个表现已经相当不错。
实际体验如何？
部署完成后，这位网友将模型接入了 Mac 上常用的截图翻译工具 Bob。
由于 Bob 可以直接调用 Ollama API，因此无需额外配置云端接口。
从实际体验来看，本地翻译响应速度非常快。
尤其是在截图翻译场景下，几乎点击后即可返回结果。
相比在线翻译服务，虽然翻译质量各有侧重，但本地模型具有两项明显优势：
一是响应速度更快；
二是所有数据均保留在本地，更适合处理隐私内容。
除此之外，在以下场景中也表现不错：
- 日常聊天
- 文档总结
- AI 翻译
- 代码辅助
- 本地知识库
- 个人 Agent
整体体验已经能够满足日常使用需求。
写在最后
从整个部署过程来看，这位网友最大的收获并不是“Mac 能不能跑大模型”。
而是 Apple Silicon 的本地 AI 生态已经越来越成熟。
随着 MLX、Metal、MoE 以及更高效量化方案的发展，一台几年前的 M1 Max，也已经能够提供不错的本地推理体验。
当然，它依然无法替代高端 NVIDIA GPU，也不适合高并发生产环境。
但对于个人开发者而言，已经足以胜任：
- 本地聊天
- AI 翻译
- 编程助手
- 私有知识库
- 个人 Agent
- 隐私文本处理
如果预算有限，又希望体验真正的本地大模型，那么 Ling-3.0-tiny INT4 + Apple Silicon + MLX + Ollama，依然是一套值得尝试的组合。
至少，它证明了几年前发布的 Mac Studio，依然拥有不错的本地 AI 推理能力。
暂无评论内容