24 GB Mac 上的 Unsloth：界面精致，但在生成第一张图之前就内存不足

安装包是一个 24 MB 的 DMG，测试者形容它是'我见过的最小的文件'。

第一个窗口：'Getting things ready... This won't take long.'，旁边有链接'Show setup details'。测试者说：'比其他应用感觉精致多了……沟通很清楚。'

详细日志写着：'Updating existing Unsloth install'、'frontend bundled (Tauri)'、'node v24.13.0 | npm 11.6.2 (system)'、'unsloth 2026.8.18 -> 2026.10.3 available, updating'，然后是一个 13 步的依赖进度条（pip bootstrap、面向 Apple Silicon 的 MLX 栈、基础包、unsloth extras、编解码器、overrides、studio deps、data designer、本地插件、diffusers pin、收尾）。备注：'torch 2.10.0 detected -- installing torchao==0.16.0'；'transformers 5.3.0, 5.5.0, 5.10.2 pre-installed'；'gpu Apple Silicon (Metal, unified memory)'；'installing prebuilt llama.cpp'。

测试者说大约运行了四五分钟，然后应用打开。日志里没有时间估算，也没有磁盘空间估算。

安装过程四到五分钟。未计时。

这个很小的 DMG 很可能是在这第一步里下载大部分软件。未核实。

'它告诉我它在做什么——很好——但没有告诉我预计耗时、数据量，或者会占多少磁盘空间。'

主窗口打开，显示'How can I help?'，侧边栏有：New chat、Model hub、Library、Images、Train、More。标志上带有 BETA 标记。

测试是从已有的安装开始的（'和以前一样'），所以这是一次更新，而不是首次运行测试。引导方面的结论需要在全新安装上确认。

模型选择器列出了 Recommended 模型，数字如 27.3B 和 271.0M。这些是参数量，不是 GB。有两个条目呈灰色（176.9B 和 320.8B）。

灰色条目大概是对这台机器来说太大了。截取到的应用界面没有这么说。

'列出了很多模型，还带着大小。非常好。'但显示的数字是参数量，所以读者看不出模型需要多少内存。

测试者没有选模型，而是直接输入了一个计算请求。应用自己开始加载模型。按笔记，一个 Qwen3.8-27B MLX 4-bit 模型不到一分钟就启动了；第二个提示显示 Mistral-7B-Instruct-v0.3-4bit 正在加载（截图未收录，与图 5 同类）。

加载提示显示路径 /Users/hanskuepper/.lmstudio/models/lmstudio-community/Qwen3.8-27B-MLX-4bit。模型是从磁盘上 LM Studio 的文件夹读取的。

他怀疑是从硬盘来的，因为'这么大的模型不可能一分钟内从网上下完'。路径印证了这一点。Unsloth 为什么选了这个模型和那个 Mistral 模型，没有记录。

问题'what is 5 times 866'在'Worked for 10s'之后得到回答'5 x 866 = 4,330'（正确），速度 11.0 tok/s。标题栏显示'Local'和上下文计量'120 / 262.1k'。

测试者接着问模型，它是从哪里得到这个模型的。截取到的回答部分谈到了 MLX 权重和 Apple Silicon 统一内存；完整回答没有截取。按笔记，回答是应用不会搜索磁盘。

聊天模型对这个应用的自述不是可靠的证据。其中一个回答把模型称为'Qwen 3 27B MLX 4-bit'，而应用里的名称是 Qwen3.8-27B-MLX-4bit。

On Device 标签页按来源列出模型。在 CUSTOM FOLDERS 下出现两个路径（.lmstudio/models 和 .ollama/models），Ollama 模型有 gemma4:latest、gemma3:1b 和 qwen3-coder:30b。在 LM STUDIO 下，Qwen3.8-27B 模型标着'Loaded'。

这两个文件夹要么是测试者添加的，要么是应用自己找到的。没有记录。此前使用应用时可能已经设置好了。

切换到 qwen3-coder:30b（30.5B、Q4_K_M、GGUF）时显示'Starting model... Switching models. Loading cached model into memory.'，带一个 Cancel 按钮。上下文计量显示'1.3k / 8.2k'，比第一个模型的 262.1k 小得多。

'我喜欢切换模型这么容易。''有些 Ollama 模型在 Unsloth 里不能用，但至少它试了，这很好。'

按笔记，一个较旧的模型能用，一个较新的崩溃了。具体指哪些模型，没有记录。

他说它'试着去用'他的 Ollama 模型，这很好；而且直接读取磁盘上已有的模型，可以避免再下载一次大文件。

模型中心显示设备信息：'0 GiB VRAM + 24 GiB shared'、'24 GiB RAM'、'12/12 CPU'，以及筛选项（格式、能力、最新）。卡片显示点赞数、下载量、发布时间和许可证（embeddinggemma-2-GGUF：apache-2.0，1.5 GB）。

'是的，很棒的模型中心。'中心里列有 Qwen-Image-2.1-GGUF（85.0 万次下载，发布 16 天）、GLM-5.3-GGUF 和 Qwen3.8-Flash-Next-GGUF 等。

按笔记，点击一个对这台 Mac 来说太大的文件时出现了好几条警告（'this file is 30 to 40 gigabytes total'）；但仍然允许下载。没有截图。

unsloth/Qwen3.8-27B-GGUF UD-Q5_K_S 的下载面板显示 20 GB 中的 1.2 GB，1.4 MB/s，剩余 3 小时 47 分；之后是 20 GB 中的 7.1 GB，983 KB/s，剩余 3 小时 31 分。

'这个应用的专业性看得出来。它带着计时器，还告诉你下载速度。'

这些速度说明测试地点的网络较慢；测试者没有这么说。下载是否完成，没有记录。

Z-Image (BF16) 对话框列出模型文件 12.3 GB，加上必需的编码器和解码器 8.2 GB，共 20.5 GB。这说明了测试者在别处提到的'模型本身的 GB 数和另外那部分之间的差别'。

笔记里写着'图像 LLM 已经下载了'。具体是哪一个，没有记录；截图显示设备上有图像模型 FLUX.2-klein-4B 及其 GGUF 版本（图 18）。

测试者粘贴了一个 PromptQuorum 页面的网址，问'from a seo perspective will this help me?'。聊天显示'Using tool: Reading promptquorum.com'和'Waiting for approval: web_search'，按钮有 Allow、Always allow 和 Deny。时间戳下午 5:13；上下文'648 / 34.4k'。

按笔记，第一次尝试说读不了这个页面；点击 Search 功能后，第二次成功了。'第一次也许应该给个警告。'

第一次失败可能是因为没有批准网页搜索，或者 Search 开关是关着的。未核实。

这次运行在 168.10 秒后以'Ran out of memory. Try a smaller model or shorter input.'结束，带一个 Retry 按钮。

语音输入是内置的。使用它会要求下载'Qwen3-ASR 0.6B'语音模型，约 1.0 GB，提示说会一次性下载到 Hugging Face 缓存里。测试者是否下载了，没有记录。

一次本地活动搜索（'What is happening tonight in Heidelberg, Germany?'）经过两轮工具调用，在 110.65 秒后以'Ran out of memory'结束。标题栏有一条红色提示：'Failed to load model: No safetensors found in /Users/.../.cache/huggin...'。

加载错误和内存不足的提示可能有关（内存紧张时正在切换模型）。截图没有显示两者之间的联系。

'不过是啊，本地 AI，总是有些问题。'

测试者的目标是图片。侧边栏有一个'Images'条目。笔记里有一段很长的纽约天际线提示词（布鲁克林视角、布鲁克林大桥、黄金时刻、8K 细节），附带构图和避免项列表。没有记录它的结果、错误或设置。

加载图像模型 flux.2-klein 被拒绝：'needs about 17 GB of memory for its weights, but only about 2 GB is usable on this device (of the 7 GB currently free, after reserving room for the operating system)'。提示还补充说，Mac 只有一个内存池，卸载到 CPU 并不能释放内存，并建议换更小的模型、更低的量化或关闭其他应用。它给出了 UNSLOTH_DIFFUSION_ALLOW_OVERSIZED_LOAD=1 作为覆盖选项。

干净重启之后，提示变成：需要约 17 GB，可用约 6 GB，当前空闲 11 GB。

两条提示中，两组数字都相差 5 GB（7 - 2 和 11 - 6），所以应用似乎为操作系统预留了约 5 GB。只有两个数据点。

设备列表显示 FLUX.2-klein-4B-GGUF（7.8 GB）、FLUX.2-klein-4B（16 GB）和 mistral-7b-v0.3-bnb-4bit（4.1 GB）。测试者：'这个应该够小了。'测试者说，中心里最小的图像模型会让他的 24 GB 机器崩溃，而且他点开的模型都说太大，因为只有'七个 GB'可用。

测试者不明白为什么只有七个 GB 可用（'我的内存多得多'）。对话框写明，当时空闲的是 7 GB，其他应用都在运行；重启之后则显示 11 GB。笔记把'7 GB'这句话放在 Z-Image 对话框旁边；而 7 GB 这个数字出现在 flux.2-klein 的提示里。

'我迷茫了……我有一台 24 GB 的机器，却找不到一个能为我所用、能把事情做完的 LLM。'他认为 24 GB 已经超过他读者所用内存的 80%（他自己的估计，不是实测数据）。

'我的读者中超过 80%'的内存不超过 24 GB。未给出来源。

测试者的结论是，本地模型和日常工作在争用同一份内存，Chrome 和其他应用就要占 5 到 8 GB。他通篇写的都是'VRAM'；Apple Silicon 只有一个内存池，模型中心也是这么显示的（'0 GiB VRAM + 24 GiB shared'）。

活动监视器，一次截取：已使用内存 12.92 GB，缓存文件 10.95 GB，App 内存 9.81 GB，联动内存 1.83 GB，交换 0。

活动监视器，另一次截取：已使用内存 9.67 GB，缓存文件 8.14 GB，App 内存 6.97 GB，联动内存 1.71 GB，交换 0。较短的历史曲线与刚启动不久相符。

图 15 中'当前空闲'的 11 GB，与图 16 的 24.00 - 12.92 = 11.08 GB 吻合。两者是否在同一时刻截取，没有记录。

'即使重启之后，通用的东西就已经占掉九个 GB 了。''要么我关机、重启、停掉所有进程……要么就没法运行 LLM。'

两种可能的出路：模型必须变得更小更好，或者电脑需要 48 或 64 GB。'所有那些说在你的电脑上也能跑的话，有点假。'

48 或 64 GB 能'稳稳地'解决这个问题，未经测试。

启动模型时会出现一个提示'Starting model... Loading cached model into memory.'，带一个转圈图标和 Cancel。没有百分比、大小或时间。

等待时间超过了两三分钟（未计时）。

'对待客户最糟糕的方式，就是把活干了却不告诉客户进展。'测试者称这是用户界面问题。

标题栏的计量显示已用 token 与上下文的对比（例如'648 / 34.4k'）以及每秒 token 数（11.0 tok/s）。

笔记里写着'没有 token 计数器'。但截图显示有上下文计量和每秒 token 数。他指的可能是每条消息的 token 数（假设）。

笔记把本地聊天模型称为'最蠢的主意'，因为它'不会上网查资料'。而同一份笔记和截图里却有 Search 功能、网页搜索批准提示，以及读取页面的工具调用。

他不想训练模型；聊天功能对他用处不大；他想要的是图片和视频工具，而'目前还没看到'。训练和'Train'标签页没有试。

'也许问题出在我这边，但不，不适合我。我三个月或六个月后会再看看，但目前在 M3 24 GB 的 Pro MacBook 上不行。'