我在 Mac Mini M4 Pro 上安装 Ollama，本地运行 Qwen38 和 GLM 模型，实测 VRAM 占用与速度。发现 32k 上下文每次测试额外消耗 3GB 内存，附常见网络搜索工具错误排查步骤
环境准备与 Ollama 安装
我从官方网站下载适用于 macOS 的 Ollama 安装程序，它对 Apple Silicon M4 Pro 芯片的支持非常出色。安装完成后，我通过 ollama --version 命令检查版本，确保使用的是内存管理效率最高的最新版本。
关键步骤是将模型路径设置为指向有足够空闲空间的分区，因为像 Qwen38 这样的大型模型文件高达数十 GB。我使用 OLLAMA_MODELS=/Volumes/AI_Disk 命令将模型存储与系统驱动器分离，这有助于防止主 SSD 过快填满，并减少影响使用寿命的读写操作。
此外，我还使用 chmod -R 755 /Volumes/AI_Disk 命令检查该文件夹的访问权限，确保 Ollama 能够顺利获取数据而不遇到 Permission Denied 问题。这是很多人容易忽视的地方，往往导致模型加载中途失败。因此，做好空间准备是进入下载和实际性能测试阶段的重要基础。
Qwen38 模型的下载与管理
我选择 Qwen38 模型作为主要测试对象，因为它支持长达 32k tokens 的上下文，非常适合泰语文档分析工作。我使用 ollama pull qwen38 命令下载权重文件（Weights），在高速互联网环境下耗时约 15 分钟。
下载完成后，我使用 du -sh ~/.ollama/models/blobs/sha256-* 命令检查实际大小，发现该模型占用约 18GB 存储空间。加上为 32k 上下文分配的内存（KV Cache），总内存将增至 21GB，这与我的测试报告数据一致。
我使用 ollama run qwen38 --num-ctx 32768 命令运行模型并设置最大上下文长度。此配置使系统需要额外预留 3GB RAM 专门用于 KV Cache，这对于维持对话连续性或处理长文档而不遗忘先前信息至关重要。
本机实际测试
2026 年 9 月 2 日，我在 Mac Mini M4 Pro 上运行 resume-verify 测试套件，通过 webui.siam2r.com/api/version API 检查系统状态。结果显示状态码 200，确认服务正常运行。
我用 1x1 像素的 PNG 文件测试 Vision 路径，发现 Qwen3-VL-8B 和 GLM-4.6v-flash 均以 200 状态码通过 3/3 次测试，表明这些模型即使在 Mac 上也能支持基础图像处理。
然而，我在运行 LiteLLM 中的 search_web 函数时遇到了实际问题，在 15:52:43 出现 "failed-to-parse tool-call args" 错误。虽然这是客户端模型的 Bug，但我需要记录的是该问题与我的主要配置无关，无需修改任何代码，只需等待开发团队在源头修复即可。
从错误中吸取的教训及解决方法
我获得的重要教训是，在投入生产环境（Production）前进行 "Dry-run" 测试可以有效防止损坏。我使用别名 qwen38-deep32k-test 在实际运行前模拟场景，这让我发现了内存使用超出预期的问题。
我发现当同时运行 Qwen38 和 7.3GB 的 Qwen2.5VL 时，机器会出现高 Swap 导致速度下降的情况。因此我设计了 predictive.sh 脚本，在测试结束后立即卸载未使用的模型。
另一个要点是 Embedding 维度，我检查确认 Nomic-embed-text 使用 768 维，BGE 使用 1024 维。理解这些数字有助于选择合适的向量数据库，因为如果维度不匹配，系统会出现错误但不会显示明确的 Error 信息，使调试变得非常困难。
性能总结与建议
根据我的实测数据，Qwen38 Deep 32k 版本总内存占用为 21GB（权重 18GB + KV Cache 3GB），而 Fast 版本仅需 18GB，更适合 RAM 较小的机器。
我建议拥有 64GB 及以上 RAM 的 Mac Mini M4 Pro 用户可以流畅运行这些模型，无需过多担心热节流问题。但在运行大型模型时，应关闭其他占用 RAM 的应用程序，如 Chrome 或 Xcode。
最后，我确认 Mac 上的本地 AI 在隐私方面比云端更可靠、更安全，但代价是需要严格管理机器资源。定期监控日志和 VRAM 使用情况对于追求稳定性的开发者来说是必不可少的。
想继续关注这类实验室工作？请添加 LINE @icafefx，或前往 redhatai.net 免费下载工具。
