你手里是一台 MacBook Air M5，想不联网跑本地模型，结果一搜全是「能跑」和「跑不动」两种极端说法，真正落地时又卡在内存够不够、量化选哪档、输出速度能不能忍。这篇不给你打包票，只给一套判断顺序：先量内存余量，再按量化档位反推模型体积，最后用实际任务试一遍体验，跑不动就降档或换任务，而不是硬扛。
你手里是一台 MacBook Air M5，想不联网跑本地模型，结果一搜全是「能跑」和「跑不动」两种极端说法，真正落地时又卡在内存够不够、量化选哪档、输出速度能不能忍。这篇不给打包票，只给一套判断顺序：先量内存余量，再按量化档位反推模型体积，最后用你的真实任务试一轮，跑不动就降档或换任务，而不是硬扛。
判断能不能跑，不靠别人说「我跑过」，靠三个变量：可用内存、量化档位、上下文长度。这三个是互相挤的，动一个另外两个就变。先把它们摆到桌面上，再谈模型名字和体验。
先看内存和统一内存架构，别先看模型名
Air 用的是统一内存，模型权重、上下文缓存、系统和常驻软件抢的是同一块，你能用的余量永远小于标称内存。所以第一步不是挑模型，是把占用看清楚：关掉浏览器、同步盘、常驻聊天软件，再看实际还能剩多少。
- 统一内存
- CPU 和 GPU 共用同一池内存，模型加载和系统开销互相挤占
- 换页
- 内存被占满后系统把数据写到磁盘，表现就是输出突然变慢甚至卡住
- 可用余量
- 关掉后台常驻软件后能分给模型的那部分，通常明显小于标称值
- 清后台关掉浏览器多标签、同步盘、常驻聊天工具，让内存占用回到日常低位
- 看余量打开活动监视器，看内存压力和可用内存，把这两个数字记下来，作为你的实际上限
- 留安全垫再从这个余量里扣掉一块给上下文和系统波动，剩下的才是模型权重能占的空间
- 验证加载模型后再看一次内存压力，如果一直飘红，别接着加上下文长度
按量化档位反推模型体积上限
同一模型不同量化档位，体积能差好几倍。先用一个粗略公式框住范围：模型体积约等于参数量乘每权重字节数，再给上下文和运行时留出余量。这个估算不精确，但足够帮你排除明显超标的文件，不用反复下载试错。
| 量化方向 | 每权重大致字节量 | 适合什么情况 | 代价 |
|---|---|---|---|
| 低档位 | 小 | 内存紧张、先跑通、短任务 | 质量损失更明显，长上下文容易崩 |
| 中档位 | 中 | 日常改写、摘要、翻译、单轮问答 | 体积翻倍，需要你先确认内存扛得住 |
| 高档位 | 大 | 结果质量要求高、愿意等 | Air 上很可能换页或加载时间过长 |
| 不确定时 | 从低往高试 | 拿不准就先跑低档位，跑通再加 | 每次升级都要重测速度和质量 |
- 先跑小档位确认链路通，再往上加，别一次性下最大的那个
- 同一模型不必只留一档，按任务分：短任务用低档，质量关键任务再换高档
- 上下文长度要和量化档位一起算，两者都在吃同一块内存
- 下载前先看文件体积，体积明显超过你算出来的余量就别下
- 把每次试跑的体积、内存压力、等待感记一行，形成自己的上限表
各档位的实际体积、各模型的资源占用，站内整理过对照，去 模型资料库（/models） 核对当时的数字，比凭印象估更稳。
什么任务适合在 Air 上跑，什么任务别指望
加载成功不代表好用。先按任务类型分档，再决定要不要在 Air 上跑：短文本改写、摘要、翻译、格式整理、代码补全这类单轮或短上下文任务，体验最接近可用；长文档分析、大代码库问答、多轮复杂推理容易触发上下文膨胀，延迟和内存压力都会明显上升。
| 任务类型 | Air 上的大致体验 | 建议 |
|---|---|---|
| 摘要、翻译、改写 | 单轮短上下文，等待感可控 | 优先在这类任务上长期用 |
| 代码补全、格式整理 | 输入短、输出短，适合轻机身 | 配合小档位模型即可 |
| 长文档问答 | 上下文膨胀，速度明显下滑 | 先拆段，或改用检索式流程 |
| 大代码库分析 | 内存与延迟双重压力 | 别硬上，先算上下文和并发 |
| 多轮复杂推理 | 轮数越多越吃内存 | 限制轮数，及时清会话 |
- 定任务写下你真正要做的三件事，越具体越好，比如「把周报改成邮件语气」
- 套档位按上表判断属于短任务还是长任务，长任务先拆小再试
- 算资源到 部署测算（/deploy） 把上下文长度和并发估一遍，算不平就换方案
- 定门槛提前想好你能接受的首字延迟和输出等待感，超过就降档或换任务
运行时选哪个，以及怎么验证跑没跑起来
Mac 上常见的几条路是 Ollama、LM Studio 以及走 Metal 加速的方案，选择逻辑看你要命令行还是图形界面、要不要一键换模型。选哪个不是关键，关键是先确认链路通，再谈性能。
- 要命令行、想脚本化：优先看 Ollama 这类可命令行驱动的方案
- 要图形界面、常换模型：看 LM Studio 这类带界面的方案
- 只求最快验证：先用最小的模型跑一句话，确认能出结果
- 环境排查：跑不动先看是不是 Metal 没启用、模型路径不对、内存被别的软件占了
- 记录基线：跑之前先量一次，跑之后再量一次，才知道慢在哪
速度基线别用感觉记，去 测速工具（/tools/speed-test） 量一次首字延迟和持续输出，跑完大模型再量一次，两次对比才能分清是模型本身慢还是环境没配对。同样一个模型，不同中转或本地方案的表现差异，可以在 站点导航（/sites） 里对比同类方案的公开记录，但数字以你实测为准。
用真实任务试一轮，别只看能不能加载
加载成功不等于好用。用你自己的任务跑一轮，感受首字延迟和持续输出的等待感，连续跑十几分钟观察有没有降频、风扇声变大、速度下滑——这类现象在轻机身设备上很常见。
- 跑真实任务别用「你好」测，用你日常最常做的那件事，跑三到五轮
- 记等待感首字等多长时间、中间有没有明显停顿，写下来，和别人说的「流畅」对不上就相信自己的记录
- 观察持续表现连续跑十几分钟，看速度是否下滑、机身是否发烫，下滑明显就缩短单次任务
- 核对质量人工检查输出，量化档位高不等于你的任务效果更好，很多任务低档位就够用
- 决定去留如果延迟和内存压力都超出你能忍的范围，降档、拆任务或换回云端，不丢人
能不能跑是资源问题，好不好用是任务匹配问题，两件事分开判断，不容易被别人的结论带偏。下一步把你机器的实际可用内存、跑过的模型体积和等待感记成一张表，再去对照站内资料；比起反复问「能不能跑」，自己有一组实测数据最省事。→
常见问题
MacBook Air M5 到底能跑多大的本地模型？
没有统一答案，取决于你机器上实际空出来的统一内存和选的量化档位。做法是先量可用内存，再按「参数量 × 每权重字节数」估模型体积，留出上下文和系统余量。想知道当前主流模型的体积和量化对照，去 /models/deploy 按你的内存条件试算。
Air 没有独显，跑本地模型是不是基本没戏？
不是没戏，是场景要挑。它靠统一内存和集成 GPU 跑推理，短文本、翻译、摘要、代码补全这类任务通常能撑住；长上下文、大批量并发、大参数模型就会明显吃力。判断标准是你对首字延迟的容忍度，而不是能不能启动。
为什么加载成功但输出很慢？
常见原因有三个：内存不够开始换页、上下文设得太长、运行时没走对加速后端。排查顺序是先关后台降内存占用，再把上下文调小试一次，最后换一个运行时对比。基线可以用 /tools/speed-test 量，别凭感觉判断。
