本地大模型 on 鬼哥的空间

32G 的 M6 Mac mini，怎么同时养活聊天和画图两个大模型

Fri, 25 Sep 2026 00:00:00 +0000

新 Mac mini 让人等了快两年。8 月 25 日，苹果终于发布了新款，入门款是苹果第一颗 2nm 芯片 M6，高配款是 M5 Pro。

鬼哥盯着 M5 Pro 看了很久。64G 内存，带宽快了将近一倍，拿来跑本地大模型确实香。可顶配要 3199 美元，折合两万多人民币。鬼哥掐指一算：这得是多少碗米粉。

最后下单的是 M6、32G 那一款。为了它，鬼哥省了好几个月早餐的米粉加一个蛋。

倒也不全是穷。鬼哥的主力工作，写代码、查资料、改长文，都是靠 Claude 和 Codex 的订阅在云端完成的。本地模型对鬼哥来说还是探索：看看它在写作、内容创作、日常开发里到底能帮上多少忙。为一个还在摸索的爱好，把早餐钱全搭进去，不太划算。

问题就来了：32G 这个"够用的下限"，能不能撑起一台私人 AI 工作站？不连云、不花 API 费，能陪鬼哥写东西，也能按一句话画出一张像样的图。

鬼哥决定从写作和内容创作开始试。折腾了两个晚上，答案是能。不过真正难的地方，跟一开始想的不一样。

先让它开口：一行命令的 Open WebUI

机器上原本就装着 Ollama，拉好了 Qwen3.8 的 27B 模型。缺的是一个像样的聊天界面。

Open WebUI 基本就是一个自己托管的 ChatGPT 网页版，对话历史、多用户、知识库、联网搜索一应俱全，还能接各种模型。鬼哥原以为要跟 Python 环境搏斗一晚上，结果官方包用 uv 一行就能跑：

1

DATA_DIR=~/.open-webui uvx --python 3.11 open-webui@latest serve

指定 Python 3.11，是因为 Open WebUI 只认 3.11 到 3.12，而鬼哥系统里的 Python 已经 3.14 了，太新，人家不要。浏览器打开 localhost:8080，第一个注册的账号自动当管理员。它会自己找到本机 11434 端口上的 Ollama，下拉框里直接就有 qwen3.8。

第一题鬼哥出得有点刁：用辛弃疾《青玉案·元夕》的场景，写一篇书生和姑娘惊鸿一瞥的小故事。

它写了一千来字，题目叫《灯火阑珊》。开头是"元宵那夜，汴京的东风是带着花香来的"，结尾有一句鬼哥挺喜欢：

他写的时候手是稳的，可墨迹落纸，“阑珊"二字却洇开了。

一台比饭盒大不了多少的盒子，能写到这个份上，鬼哥是有点意外的。当然也有翻车的地方：写到烟花炸开那句，它突然冒出一个 “fireworks”。辛弃疾要是看到自己的元宵节里放的是洋烟花，大概也会洇开。

Open WebUI 在每条回复下面记了速度：这篇生成了 1021 个 token，每秒约 14 个；读入提示词每秒约 276 个 token。从回车到写完，不到两分钟。

模型在内存里占 18G 左右，是 27.8B 参数、nvfp4 量化的 MLX 版本。其他几段对话里，生成速度大多在每秒 14 到 20 个 token 之间，比鬼哥读小说的速度快。

还有个意外之喜：Open WebUI 默认监听所有网卡，所以装了 Tailscale 的其他设备，用 http://mac-mini的机器名:8080 就能直接访问。桌上这台 Mac mini，从此成了随身 AI 的后端。

想让它画画，先撞上一堵 33G 的墙

会写字了，自然想让它会画画。鬼哥看中的是 Qwen-Image-2.1：7B 参数的图像生成模型，文字渲染是出了名的强，还支持图片编辑和透明背景。

打开模型页，算了一下账：

组件	官方 BF16 大小
文本编码器（Qwen3-VL-8B）	17.5 GB
图像生成模型（7B DiT）	14.2 GB
VAE	1.4 GB
合计	33.1 GB

鬼哥的机器是 32G。差了 1G，就像米粉钱差一块，老板也不会给你加蛋。

这里得先说清楚 Mac 的内存是怎么回事。PC 上，显卡有自己的显存，显存不够时可以把模型"卸载到内存”。Mac 的 CPU 和 GPU 共用同一块统一内存，所谓卸载到内存，就是把东西从左边口袋放进右边口袋，总重量一克没少。何况 macOS 默认也不会把全部内存都分给 GPU。所以官方示例里的 enable_model_cpu_offload()，在这台机器上帮不了什么忙。

解法是量化。ComfyUI 官方整理了一套 int8 版本：图像模型 7.3G，文本编码器 9.4G，VAE 0.7G，一共 17.3G，差不多瘦身一半。

接下来要挑一个生图工具。Mac 上最省事的是 Draw Things，原生 App，对 Apple 芯片做了深度优化。但鬼哥想要的是在 Open WebUI 里聊着天就能出图，这条路只有 ComfyUI 走得通：它自带 API，Open WebUI 支持把它当生图后端。ComfyUI 的界面是一块节点画布，加载模型、编码提示词、采样、解码、保存，每一步一个方块，用线连起来。第一次看像在拆电视机，看熟了发现什么都能拆开调。

安装本身不复杂：克隆仓库，用 uv 建一个 Python 3.13 环境，装 PyTorch nightly（Mac 上靠它的 MPS 后端调用 GPU），再把三个模型文件放进对应的文件夹。更省心的是，ComfyUI 自带的模板里已经有 Qwen-Image-2.1 的文生图工作流，用的正是这套 int8 文件，推荐参数是 25 步、CFG 1、euler 采样器。鬼哥照着它写了一份 API 格式的工作流，自己测试用，也给 Open WebUI 用。

第一张图：招牌上的字，一个都没错

测试提示词是模型卡上的例子：雨夜里一块霓虹招牌，写着 “QWEN IMAGE 2.1”，湿漉漉的路面有倒影。

1024×1024、25 步，用了 222 秒，每步大约 8 秒。够鬼哥下楼嗦半碗粉。

慢是真慢，但看到图的那一刻，鬼哥原谅它了。“QWEN” 是冷白色的霓虹管，“IMAGE 2.1” 是红色，字母一个没错，连 2 和 1 中间的小数点都在。地面上红灯的倒影、斑马线、远处橱窗里的灯，都像雨夜里手机随手一拍。几年前，本地生图模型写字还像鬼画符。

接入 Open WebUI 之后，鬼哥又画了几张。最喜欢的是这张北京微缩沙盘：长城沿着山脊蜿蜒，故宫、天坛、鸟巢、水立方、央视大楼挤在同一块地图上，浅景深把周围的地图虚化掉，很像旅行杂志的内页。

它也有露怯的时候。让它画一页插画师的手绘设定稿，人物的造型、表情、比例都很有样子，页面上那些手写批注却全是天书。它擅长的是提示词里点名要写的大字；画面里顺手添的小字，基本就是装饰花纹。

还有一张时装人像，左下角冒出来一个谁也没要求的"签名"，看着还挺像那么回事。鬼哥第一反应是在负面提示词里写上"不要水印"，查了参数才发现写了也白写：这套工作流的 CFG 是 1，负面提示词根本不起作用。想去掉签名，得把 “no text, no watermark, no signature” 这类要求直接写进正面提示词。官方模板的示例提示词，结尾就是一长串 “no text, no letters, no logos, no watermark”，看来官方早就防着它这一手。

两个大模型，挤不进同一块内存

聊天和生图各自都能跑了，鬼哥在 Open WebUI 的图像设置里填上 ComfyUI 的地址，上传工作流，把提示词、尺寸、步数、种子分别对应到工作流里的节点。然后在聊天框里打开生图开关，直接用中文描述想要的画面。

流程是这样的：Qwen3.8 先把你的描述扩写成一段详细的英文提示词，交给 ComfyUI；四分钟后，图片出现在对话里，Qwen3.8 再补一句说明。

第一次端到端跑通，图出来了，鬼哥顺手看了一眼系统状态，笑容凝固了：swap 已用从 4G 涨到了 14G，交换空间上限才 15G。

原因不复杂，但事先没想到：两边都舍不得放下模型。Ollama 默认会把模型在内存里留 5 分钟，方便你接着聊；ComfyUI 出完图，也会把模型留着，方便画下一张。Qwen3.8 刚写完提示词，占着 18G 不走，ComfyUI 紧接着又要加载将近 17G 的生图模型。两个加起来超过 32G，macOS 只能把内存往 SSD 上的 swap 里硬塞。

两个胖子挤一张单人床，谁也睡不好。这次速度倒没怎么掉，但每生成一张图，SSD 上就要写进去十来 G 的 swap。swap 一旦用满，轻则卡顿，重则进程被系统请出去。

**在 32G 的统一内存上，两个大模型不能同时在内存里，只能轮流用。**如果当初买的是 64G 的 M5 Pro，这一节大概可以直接跳过。可谁让鬼哥省下的只是米粉钱，那就只能让它们学会排队。一共三处调整。

第一处，让 Ollama 早点放手。鬼哥先用 launchctl setenv OLLAMA_KEEP_ALIVE 1m 把全局保留时间改成 1 分钟，然后就以为万事大吉了。后来查进程的环境变量才发现，Ollama 一直没重启，这个设置根本没生效。真正起作用的，是在 Open WebUI 里给 qwen3.8 设的 keep_alive = 1m。这个设置存在 Open WebUI 的数据库里，电脑重启也不会丢。

第二处，ComfyUI 一接到任务，就立刻请 Ollama 让位。Qwen3.8 的提示词已经写完、交到 ComfyUI 手里了，这一步它没事可干，占着位置纯属浪费。鬼哥在 ComfyUI 的起停脚本里加了一个后台循环：发现队列从空变成有任务，就查一下 Ollama 当前加载了哪些模型，挨个发一个 keep_alive: 0 的请求。这只是把模型请出内存，文件还在硬盘上。

第三处，ComfyUI 出完图，5 秒内收拾走人。这里 Mac 又有个特别的地方：ComfyUI 的 /free 接口，只带 unload_models 参数的话，模型只是从"显存"挪到"内存"，在 Mac 上又是左口袋换右口袋。必须同时带上 free_memory，把节点缓存也清掉，内存才会真正还回来。实测，出完图后 ComfyUI 的内存占用从 9.8G 降到了 0.6G。

第一处调整之后，鬼哥每改一步就盯一次生图，每 5 秒记一次 swap。三次记录放在一起看：

	只把 keep_alive 改成 1 分钟	再加上生图开始时卸载 Ollama	再加上出图后 5 秒释放
生图开始时 swap 峰值	15.5 GB	3.7 GB	4.0 GB
生图过程中 swap	约 5 GB	3.7 GB	3.8 GB
出图后 swap 峰值	—	12.0 GB	7.5 GB，几秒后回落
1024 图耗时	243 秒	234 秒	235 秒

最后那 3.8G 是其他程序早先换出去的内存，一直留在 swap 里，跟这套工作站无关。出图后那几秒的小峰值，是 Qwen3.8 急着回来写回复，ComfyUI 还没来得及收拾完，两边在门口撞了一下。内存压力不大，鬼哥决定不跟它计较。

现在这台工作站长什么样

整理下来，一次"聊着天出张图"的完整过程是这样的：

鬼哥在 Open WebUI 里用中文说想要什么画面；
Qwen3.8-27B 把它写成详细的英文提示词；
ComfyUI 接到任务，先请 Ollama 把 Qwen3.8 卸载掉，再加载 Qwen-Image-2.1 的 int8 模型；
大约 4 分钟后出图，图片回到对话里；
ComfyUI 5 秒内释放模型，Qwen3.8 重新加载，补一句说明。

有几件事最好提前知道。速度上，一张 1024 的图要 4 分钟左右；官方默认的 2048 尺寸像素是它的 4 倍，按比例估算要十几分钟，这个鬼哥还没试，怕等到饿。许可上，Qwen-Image-2.1 用的是 Qwen Research License，个人研究和玩没问题，商用要先读条款。至于 Open WebUI 本身，0.11.4 版本新建对话时生成标题会报一个 KeyError，对话只是没有自动标题，其他功能都正常，等上游修就好。

它不会比云端服务快，也不会比云端的旗舰模型聪明。但写故事、改文章、画张配图这类日常活，它都能在鬼哥的桌上完成：数据不出门，不按次计费，断网也能用。深夜想到一个画面，不用先去看 API 余额，这一点比预想的更让人舒服。何况这台机器是用早餐钱换的，每多画一张图，那几个月的蛋就吃得更值一点。

回到那个元夕故事。那天夜里，书生在灯海里寻了那个姑娘千百回，最后在一盏快燃尽的旧灯下找到了她。这台 Mac mini 上的两个大模型，比那两个人好安排：一个写完提示词就退场，一个画完图也退场，同一时刻，内存里只留一个。

32G 统一内存能同时装下的大模型，其实只有一个。它能当私人 AI 工作站，靠的是让两个模型轮流用这块内存。

这篇文章的封面，也是这台 Mac mini 上的 Qwen-Image-2.1 画的：1344×768，大约 8 分钟。

附：关键配置速查

Open WebUI 图像设置（管理员面板 → 设置 → 图像）

设置项	值
引擎	ComfyUI
Base URL	`http://127.0.0.1:8188`
默认模型	`qwen_image_2.1_int8_convrot.safetensors`
尺寸 / 步数	`1024x1024` / `25`
节点映射	prompt → 文本编码节点的 `prompt`；width/height → EmptyLatentImage；steps/seed → KSampler；model → UNETLoader 的 `unet_name`

模型文件（来自 Comfy-Org/Qwen-Image-2.1）

1
2
3


models/diffusion_models/qwen_image_2.1_int8_convrot.safetensors 7.3 GB
models/text_encoders/qwen3vl_8b_int8_convrot.safetensors 9.4 GB
models/vae/qwen_image_2.1_vae_bf16.safetensors 0.7 GB

让两个模型轮流用内存的核心逻辑（ComfyUI 起停脚本里的后台循环）

1
2
3
4
5
6
7
8


# 队列从空闲变成有任务：卸载 Ollama 里所有已加载的模型
for name in $(curl -s localhost:11434/api/ps | grep -o '"name":"[^"]*"' | cut -d'"' -f4); do
 curl -s localhost:11434/api/generate -d "{\"model\": \"$name\", \"keep_alive\": 0}" >/dev/null
done

# 队列空闲 5 秒：卸载 ComfyUI 的模型并清掉缓存（Mac 上两个参数缺一不可）
curl -s localhost:8188/free -H 'Content-Type: application/json' \
 -d '{"unload_models": true, "free_memory": true}'

参考资料

桌面 AI Studio 怎么选：DGX Spark、Ryzen AI Halo 和 M4 Max Mac Studio

Mon, 15 Jun 2026 00:00:00 +0000

买桌面 AI 机器，最容易被一个数字骗：TOPS、TFLOPS、PFLOPS，听起来都像能把模型原地起飞。现实是，AI 开发者真正卡住的往往不是峰值算力，而是 内存够不够、软件栈顺不顺、模型能不能跑、跑起来以后能不能折腾。

鬼哥最近就被这个问题挠得有点坐不住。

我桌上现在已经有三台风格完全不同的本地 AI 设备：一台 M4 Max Mac Studio/Mac mini 形态的 Apple Silicon 小主机，平时负责写代码、跑轻量本地模型、剪音视频、做各种 AI 开发实验；一台自己组的 GeForce RTX 4090 台式机，专门拿来折腾 Ollama、本地模型推理、Agent 接入和性能测试；还有一块 Raspberry Pi 5 小卡，更多是拿来提醒自己：边缘 AI 不是 PPT，它最后真的要落到这些又小又抠门的设备上。

4090 那台机器我之前专门写过一篇实测：《一张 4090 跑 Gemma4 26B：用 Ollama 搭本地 AI 开发环境实测》。结果挺有意思：Gemma4 26B 在那台机器上持续输出大约 160 tokens/s，模型加载后显存占用约 24.5GB，长输出功耗能到 260W+。这已经不是“本地模型能不能跑”的问题，而是“本地模型怎么接进真实开发工作流”的问题。

Mac 这边则完全是另一种体验：它不一定是大模型推理冠军，但它安静、稳定、顺手。写博客、跑 Claude/Codex、剪视频、处理图片、做前端 demo、顺手跑个 llama.cpp 或 MLX 模型，整个工作流几乎没有摩擦。缺点也很诚实：一碰到大模型、CUDA-only 项目、训练脚本复现，它就会提醒你“这里不是我的主场”。

树莓派更像一个现实锚点。它告诉我：AI 硬件不是只有“越大越好”这一条路。很多时候你真正想要的是低功耗、常开、便宜、可部署，而不是一个会把房间变暖的模型发动机。

所以，当 NVIDIA DGX Spark 和 AMD Ryzen AI Halo 相继把“桌面级个人 AI 工作站”摆上台面时，我第一反应不是“哇，又来了两台神机”，而是：它们到底能不能补上我现有三台设备各自的短板？

更麻烦的是，Apple 这边我还在翘首以盼，眼泪汪汪地等 M5 Mac mini/Mac Studio 更新。于是这篇文章就变成了一次很现实的调研：不是纯参数表，也不是厂商发布会复读，而是从一个极客的桌面出发，看看 DGX Spark、Ryzen AI Halo 和 M4 Max Mac Studio 到底分别适合谁。

NVIDIA DGX Spark、AMD Ryzen AI Halo、M4 Max Mac Studio，表面上都叫桌面级 AI Studio。其实它们不是三台同类机器，而是三种路线：

NVIDIA：把数据中心 AI 栈压到桌面，核心卖点是 CUDA 生态和 DGX 软件体验。
AMD：用 x86 APU + ROCm + Windows/Linux 抢本地 AI 开发者，核心卖点是开放 PC 工作流和 128GB 统一内存。
Apple：把成熟创作工作站顺手变成 AI 开发机，核心卖点是安静、省心、macOS 体验，但不是大模型怪兽。

先看规格，但别被规格牵着走

为了避免玄学，先把官方能确认的硬指标摆出来。这里的重点不是谁的数字最大，而是这些数字分别服务什么场景。

机器	核心芯片	统一内存	内存带宽	AI/图形算力口径	系统	典型定位
NVIDIA DGX Spark	GB10 Grace Blackwell	128GB LPDDR5x	273GB/s	最高 1 PFLOP FP4	DGX OS	本地 Agent、LLM 推理、CUDA 原型
AMD Ryzen AI Halo	Ryzen AI Max+ 395	128GB LPDDR5x	官方页面未列	60 FP16 TFLOPS GPU + 50 TOPS NPU	Windows 或 Linux	ROCm、本地 LLM、ComfyUI、PC AI 开发
M4 Max Mac Studio	M4 Max	36GB，最高 64GB	410GB/s，最高 546GB/s	40 核 GPU + 16 核 Neural Engine	macOS	开发主机、创作工作流、中小模型实验

如果只看表格，你可能会得出一个很粗暴的结论：DGX Spark 和 Ryzen AI Halo 是本地大模型机器，M4 Max Mac Studio 是“顺便跑 AI”的工作站。

这个结论大体没错，但还不够精确。

更准确的说法是：

DGX Spark 买的是 NVIDIA AI 栈，Ryzen AI Halo 买的是大内存 PC 路线，M4 Max Mac Studio 买的是低摩擦开发体验。

这三句话比任何 TOPS 数字都重要。

第一层分水岭：本地大模型先看内存

本地 LLM 的第一堵墙不是算力，是内存。

一个 70B 模型即使用 4-bit 量化，权重也常常要三四十 GB，再加上 KV cache、上下文、运行时开销、并发请求，很快就会把 64GB 机器逼到墙角。到了 120B、200B 这种级别，128GB 统一内存才开始有“能把东西装进去”的讨论资格。

这就是 DGX Spark 和 Ryzen AI Halo 的共同点：它们都把 128GB 统一内存 放到了桌面小机器里。

NVIDIA 官方给 DGX Spark 的定位很明确：128GB coherent unified system memory，可以在桌面运行最高 200B 参数模型的开发和测试工作，也可以微调最高 70B 参数模型。这个说法要谨慎理解：它不是承诺任何 200B 模型都能满血高吞吐跑，而是在告诉你，内存容量已经足够让这类模型进入本地实验范围。

AMD 的路线更像“PC 阵营的反击”。Ryzen AI Halo 开发平台同样是 128GB LPDDR5x 统一内存，并且官方强调 Windows 或 Linux 双系统、完整 ROCm 支持。对很多极客来说，这比 DGX OS 更有吸引力：你可以把它当本地 AI 服务器，也可以把它当一台能跑 Windows 软件的高端小主机。

M4 Max Mac Studio 的问题就在这里。M4 Max 版本最高 64GB 统一内存，带宽最高 546GB/s，带宽很漂亮，但容量不在一个级别。对于 7B、14B、32B 量化模型，它可以玩得很舒服；但如果你的目标是长期折腾 70B 以上模型，64GB 会让你不停做取舍。

一个极客版判断：

场景	64GB Mac Studio	128GB DGX Spark / Ryzen AI Halo
7B/14B 本地助手	很舒服	轻松
32B 量化模型	可用，需控制上下文	更从容
70B 量化推理	能折腾，但容易受限	进入主战场
70B 微调/LoRA	不适合作为主力	DGX Spark 更对口
120B/200B 实验	基本不是甜点区	有实验价值

所以，如果你关心的是“我能不能在桌面上把更大的模型塞进去”，答案很直接：128GB 机器先赢一半。

这也是我看 DGX Spark 和 Ryzen AI Halo 会心痒的原因。4090 台式机的推理速度很香，但显存墙是真实存在的；Mac 的统一内存体验很顺，但 M4 Max 的上限又不够“放肆”。128GB 统一内存的吸引力，不是参数洁癖，而是它允许你少做很多“这个模型能不能塞进去”的心算。

第二层分水岭：软件栈决定你折腾多久

AI 硬件最残酷的地方在于：跑分截图很好看，环境配置很难看。

同样是本地 AI Studio，三家的软件体验差异非常大。

DGX Spark：CUDA 是护城河，也是笼子

DGX Spark 最大的优势不是 1 PFLOP FP4，而是 NVIDIA AI 软件栈默认站在你这边。

CUDA、TensorRT、NIM、NVIDIA AI Enterprise、DGX OS、开发者论坛、官方 playbook，这些东西加起来，意味着你遇到问题时更容易找到“前人已经踩过的坑”。如果你的工作流最后要上 NVIDIA 数据中心或云 GPU，DGX Spark 的意义就更明显：它是一台桌面上的原型机。

我在 4090 上折腾 Ollama、Codex、Claude Code 和 Hermes 时，最大的感受就是：模型速度只是第一层，工具链稳定性才是第二层。同一个本地模型，Claude Code 能顺利读文件，Codex 在某些 Linux sandbox 环境里会被权限卡住。这个体验会让人更理解 DGX Spark 的价值：它卖的不是“我也有一颗 GPU”，而是尽量把硬件、驱动、框架、playbook 和支持路径绑成一套。

它的限制也同样清楚：DGX Spark 官方规格写的是 DGX OS。你不是在买一台泛用 PC，而是在买一台 NVIDIA 定义好的 AI appliance。对于研究者和企业开发者，这是省心；对于喜欢乱装系统、乱插外设、乱改内核的极客，这可能会有点憋。

Ryzen AI Halo：ROCm 的机会，也是变量

AMD 的牌面是：Windows/Linux + ROCm + 128GB 内存 + x86。

这很诱人。你可以在 Linux 上跑模型，在 Windows 上跑创作和开发工具，还能享受普通 PC 生态的弹性。AMD 页面还直接把自己和 DGX Spark 对比，脚注里写到：测试使用预生产 Ryzen AI Halo、128GB LPDDR5x、Linux OS，对比 DGX Spark，并列出 AMD Ryzen AI Halo $3999、DGX Spark $4699 的零售价。

但 ROCm 仍然是变量。它比前几年成熟太多，很多 PyTorch 和推理框架已经能跑，但 AI 生态的默认答案依然常常是 CUDA。你要有心理准备：同一个模型，同一个项目，NVIDIA 用户可能 pip install 后直接跑，AMD 用户可能要查 issue、换 wheel、等适配。

这不是说 AMD 不值得买，而是它更适合 愿意换性能/价格/开放性，但能接受折腾成本的人。

Mac Studio：最舒服，但不是最开放

Apple 的 AI 开发体验很奇特：它不是最强的，但往往是最顺的。

如果你的日常是写代码、跑中小模型、做 demo、剪视频、处理图片、调 UI、用 MLX 或 llama.cpp 跑本地模型，Mac Studio 会非常舒服。它安静、省电、系统稳定、开发工具成熟，而且 M4 Max 的 CPU/GPU/媒体引擎组合对创作者非常友好。

这也是我现在离不开 Mac 的原因。很多 AI 项目不是一天 24 小时都在跑模型，大量时间其实是在写胶水代码、改提示词、整理素材、剪一段 demo 视频、处理博客图片、部署网页、调试工具链。这个阶段 Mac 的低摩擦体验非常强：你不会因为驱动、风噪、电源、桌面空间这些小事分心。

问题是，一旦你进入主流深度学习训练、CUDA-only 项目、复杂推理优化、企业级 GPU 部署对齐，macOS 就会露出边界。Metal、MLX、Core ML 都很好，但它们不是 AI 研究社区的默认地面。

如果用一句话概括：

软件栈	最舒服的用户	最痛的地方
CUDA / DGX OS	想和 NVIDIA 生产环境对齐的人	泛用 PC 自由度低
ROCm / Windows / Linux	喜欢开放硬件和 PC 工作流的人	生态适配仍需耐心
MLX / Metal / macOS	需要一台安静全能开发主机的人	大模型和训练生态不是主场

第三层分水岭：你到底要跑什么

“AI 开发者”这个词太宽了。写 RAG 应用、做模型微调、玩 ComfyUI、跑机器人仿真、做科研复现实验，根本不是一类需求。

下面按真实工作流拆。

1. 本地 LLM 推理和 Agent 开发

如果你要做的是本地 Agent、RAG、长上下文代码助手、私有知识库问答，DGX Spark 和 Ryzen AI Halo 明显更像主力机器。

DGX Spark 的优势是 NVIDIA 官方已经把“本地自主 Agent”写进产品定位。它有 128GB 内存、NVIDIA 软件栈和面向 Agentic workload 的 playbook。你想做的是“本地先跑，未来迁到 NVIDIA 云或数据中心”，DGX Spark 的路径更直。

Ryzen AI Halo 的优势是自由度和价格。AMD 官方把它定位成 AI developer platform，而且支持 Windows/Linux。你可以把它放在桌上当小服务器，也可以 SSH 进去跑服务，还可以接普通 PC 工作流。对独立开发者和极客来说，这种弹性很香。

Mac Studio 不是不能做 Agent。相反，很多开发者会更喜欢在 macOS 上写代码、调工具、跑本地小模型。只是当 Agent 需要更大模型、更长上下文、更高并发时，M4 Max 的 64GB 上限会让它更像“开发控制台”，而不是“模型发动机”。

我的实际分工大概是这样：Mac 负责“人机交互”和日常开发，4090 负责“重推理”和性能测试。如果本地模型要长期作为服务跑，我更愿意让它待在一台可以 SSH、可以监控、可以随时重启的盒子里，而不是占着我的主力开发桌面。按这个逻辑，Ryzen AI Halo 这种 128GB 小盒子会非常诱人；DGX Spark 则更像“如果我要认真走 NVIDIA Agent 路线，就别自己东拼西凑了”。

2. 微调、LoRA 和科研复现

这一类需求更偏向 DGX Spark。

NVIDIA 官方直接写了 Fine-Tuning：用 128GB 统一内存微调最高 70B 参数模型。这里最关键的不是一句营销文案，而是它背后的现实：大量训练、微调、量化、推理优化工具默认优先支持 CUDA。

Ryzen AI Halo 也能做一部分微调和实验，尤其是 ROCm 支持越来越完整之后。但如果你是研究者，目标是快速复现论文、跑开源训练脚本、少改代码，CUDA 仍然是阻力最小的路线。

Mac Studio 适合做算法原型、数据处理、小模型实验、MLX 生态尝鲜，但不适合作为“我要复现各种 GitHub 训练项目”的唯一主机。你当然可以折腾，但很多时候不是硬件不行，是生态把你绕远了。

3. ComfyUI、图像生成和多模态玩法

这个场景 AMD 反而很有看点。

AMD 页面把 ComfyUI、Visual Studio Code、Python 等预装/同步工具放进 Ryzen AI Halo 的开发者体验里，并且官方测试脚注覆盖了 Stable Diffusion XL、Flux、Qwen Image、Wan 等图像和视频相关工作负载。这里要注意：厂商自测不能当第三方基准，但至少说明 AMD 非常清楚它要争夺哪类用户。

NVIDIA 当然也强，尤其是各种 CUDA 优化的图像生成工具链仍然更成熟。DGX Spark 的问题不是能力，而是“值不值”：如果你的主要玩法是 ComfyUI 和图片生成，买 DGX Spark 可能有点像为了煎蛋买实验室设备。

Mac Studio 的优势在创作闭环：图片、视频、剪辑、设计、开发都在一台安静机器上完成。它不一定是生成速度冠军，但它可能是最不打断创作流的机器。

我自己的感受是：音视频和内容生产这类任务，峰值性能不是唯一指标，工作流连续性更重要。一段视频从素材整理、脚本、配音、剪辑、封面、发布，中间会不断在浏览器、编辑器、终端、设计工具之间切换。Mac 在这里很舒服。4090 更像一个加速器：当你明确知道要批量生成、批量推理、批量转码时，把任务扔给它；但日常创作的主控台，我还是更愿意放在 Mac 上。

4. 机器人、边缘 AI 和硬件项目

这类场景 DGX Spark 的 NVIDIA 生态优势最明显。

NVIDIA 官方明确提到 Isaac、Metropolis、Holoscan 等边缘应用框架。你如果做机器人、视觉检测、边缘推理、智能摄像头原型，NVIDIA 从桌面到 Jetson 到数据中心的生态连贯性很强。

AMD Ryzen AI Halo 也能做边缘 AI 原型，但它更像“高性能 PC 盒子”。Mac Studio 则适合作为开发主机和可视化工作站，而不是硬件生态中心。

树莓派 5 在这里给我的提醒很直接：边缘设备上最稀缺的不是“能不能跑一个模型 demo”，而是功耗、散热、常开稳定性、部署维护和成本。桌面 AI Studio 如果只是跑分强，未必能帮助你真正理解边缘场景；但如果它能让你快速训练、量化、测试，再把结果下放到小设备，那才是完整链路。

价格可以看，但别只看价格

按 AMD 官方脚注，2026 年 5 月测试口径里，Ryzen AI Halo 零售价为 $3999，DGX Spark 零售价为 $4699。Apple 的 M4 Max Mac Studio 官方规格页能确认配置，但价格会随芯片、内存、存储和地区变化，实际应以 Apple 配置页为准。

但这篇文章不建议把价格当第一决策因子。

原因很简单：对 AI 开发者来说，真正贵的不是多花几百美元，而是 买回来以后三个月都在和驱动、依赖、模型格式、内存限制较劲。

更合理的价格问题应该这样问：

你真正购买的是	应该问的问题
DGX Spark	我是否需要 CUDA/DGX/NVIDIA 生产环境一致性？
Ryzen AI Halo	我是否愿意用折腾成本换 128GB、x86 和 Windows/Linux 弹性？
M4 Max Mac Studio	我是否更需要一台舒服的主力开发/创作机，而不是最大模型机器？

如果答案是“我要少踩坑，跟 NVIDIA 生产栈对齐”，DGX Spark 的溢价有意义。

如果答案是“我要一台能跑大模型、能装 Windows/Linux、还能当 PC 用的极客盒子”，Ryzen AI Halo 更有吸引力。

如果答案是“我每天要写代码、剪视频、做产品 demo，偶尔跑本地模型”，Mac Studio 可能才是最理性的选择。

三类人怎么选

AI 应用开发者

你关心的是 RAG、Agent、私有知识库、本地 API、开发效率。

我的排序：

Ryzen AI Halo：如果你愿意折腾 ROCm，它的 128GB 内存和 Windows/Linux 弹性很适合做本地 AI 服务盒子。
DGX Spark：如果你的应用未来要上 NVIDIA GPU，或者你需要 CUDA/NIM/DGX playbook，优先选它。
M4 Max Mac Studio：适合作为开发主机，不适合作为大模型主力推理服务器。

鬼哥经验：如果你的开发工作流已经像我一样被 Mac 绑住，不一定要把“主力开发机”和“本地模型服务器”合并成一台。更舒服的架构反而是：Mac 负责写代码和调产品，旁边放一台 128GB AI 小盒子长期跑模型服务。

研究者和实验室

你关心的是论文复现、微调、训练脚本兼容、长期维护。

我的排序：

DGX Spark：CUDA 生态仍然是研究代码的默认路径，少改代码就是生产力。
Ryzen AI Halo：适合预算敏感、愿意参与 ROCm 生态、需要 Windows/Linux 弹性的团队。
M4 Max Mac Studio：适合数据处理、写作、可视化、小模型原型，不建议作为唯一 AI 计算节点。

AI 极客

你关心的是可玩性、模型规模、系统自由度、折腾空间。

我的排序反而会变：

Ryzen AI Halo：x86、128GB、Windows/Linux、ROCm，能折腾的面最大。
DGX Spark：如果你想玩 NVIDIA 最新桌面 AI appliance，它很酷，但自由度不一定最高。
M4 Max Mac Studio：体验最好，折腾空间相对最小；适合“我要做东西”，不适合“我要拆机器边界”。

这里我会额外加一句：如果你已经有 4090 台式机，Ryzen AI Halo 和 DGX Spark 不一定是“性能升级”，更可能是“形态升级”。它们吸引人的地方是小、安静、统一内存、可常开，而不是一定能在所有任务里打爆一张高端独显。

我的最终判断

如果你把这三台机器都叫“桌面 AI Studio”，会看花眼；如果你把它们看成三条路线，选择就清楚了。

DGX Spark 是桌面版 NVIDIA AI 路线。 它适合研究者、企业开发者、Agent 原型团队，以及任何未来要迁移到 NVIDIA 云或数据中心的人。它不是最自由的机器，但它最像一条铺好的路。

Ryzen AI Halo 是 PC 阵营的本地 AI 路线。 它适合极客、独立开发者、小团队和愿意赌 ROCm 继续成熟的人。它的吸引力不只是便宜几百美元，而是 128GB 统一内存加 Windows/Linux 弹性。

M4 Max Mac Studio 是创作和开发主机路线。 它适合已经在 Apple 生态里、重视安静稳定、需要代码/视频/图像/产品 demo 一体化的人。它可以跑 AI，但不要把它想象成 DGX Spark 或 Ryzen AI Halo 的同类竞品。

至于我自己，如果现在必须下单，我大概率不会把 Mac 替换掉。Mac 仍然是我的主力创作和开发桌面；4090 台式机会继续承担重推理和测试；树莓派继续做边缘实验。真正让我心痒的是：能不能在这三者之外，再加一台 128GB、低功耗、可常开的本地模型盒子。DGX Spark 和 Ryzen AI Halo 的竞争，正好打在这个空位上。

但我也会继续等 Apple 的 M5 Mac mini/Mac Studio。不是因为我相信 Apple 会突然变成 CUDA 平替，而是因为 Apple 如果把统一内存容量、NPU/Metal/MLX 生态和桌面小主机形态继续往前推，它仍然可能成为最舒服的“AI 开发主控台”。

一句话版：

如果你最在意	选
CUDA、微调、科研复现、NVIDIA 生产环境对齐	DGX Spark
128GB、大模型、本地服务、Windows/Linux、极客可玩性	Ryzen AI Halo
macOS、安静稳定、开发创作一体、中小模型实验	M4 Max Mac Studio

本地 AI 的下一阶段，拼的不是谁喊出更大的 TOPS，而是谁能让开发者在桌面上更快完成一个闭环：模型能装进去，工具能跑起来，结果能用出去。

如果只买一台，我会先问自己一个很土但很有效的问题：

这台机器买回来以后，我是每天用它做东西，还是每天用它证明它能跑东西？

前者买工作流，后者买玩具。两者都没错，但别买错。

参考资料

NVIDIA DGX Spark 官方页面
AMD Ryzen AI Halo 官方页面
Apple Mac Studio 技术规格
Apple Mac Studio 购买配置页
鬼哥：一张 4090 跑 Gemma4 26B：用 Ollama 搭本地 AI 开发环境实测
图片来源：NVIDIA DGX Spark 官方页面、AMD Ryzen AI Halo 官方页面

一张 4090 跑 Gemma4 26B：用 Ollama 搭本地 AI 开发环境实测

Mon, 04 May 2026 00:00:00 +0000

以前本地大模型像玩具：能聊天，但一进开发工作流就露怯。现在一张 4090 已经能把 Gemma4 26B 跑起来，还能接 Codex、Claude Code、Hermes Agent。问题只剩一个：它到底是生产力，还是昂贵的电子暖手宝？

这篇文章不讲玄学，直接上手：用 Ollama 部署本地模型、用 API 对话、接入开发工具，再看 RTX 4090 上的真实推理数据。

先看结论

我这台机器的实测环境：

项目	数据
GPU	NVIDIA GeForce RTX 4090
`nvidia-smi` 显存	49140 MiB
NVIDIA Driver	570.158.01
CUDA	12.8
Ollama	0.23.0
模型	`gemma4:26b`
模型文件大小	17 GB
Ollama 加载后显存	约 24.5 GB
持续输出速度	约 160-166 tokens/s
长输出功耗	约 260-265W
长输出温度	54-60C

先打补丁：我这张 4090 在 nvidia-smi 里显示约 48GB 显存，不是常见 24GB 版本。普通 24GB 4090 也可以参考这篇文章的方法，但长上下文、并发和 Agent 场景要更保守。

我的结论是：

本地 26B 模型已经能做日常开发副驾，但还不能无脑替代云端顶级模型。

它适合解释私有代码、写脚本、生成小模块、做初步 code review；但复杂重构、跨仓库规划、长链路 Agent，仍然会被模型能力、上下文和工具链沙盒卡住。

Ollama 解决了什么

Ollama 的价值不是让模型变聪明，而是把本地部署降到几条命令：

1
2


ollama pull gemma4:26b
ollama run gemma4:26b

没有 Ollama，你要处理权重格式、量化版本、CUDA、服务启动、API 适配。用 Ollama 之后，它更像一个本地模型网关：

1
2
3
4
5
6
7


开发工具 / 脚本 / Agent
 |
 v
http://localhost:11434
 |
 v
本地 Gemma4 26B

查看模型：

1

ollama list

我本机输出里有：

1
2
3
4
5
6


NAME SIZE
gemma4:26b 17 GB
gemma4:e2b 7.2 GB
gemma4:latest 9.6 GB
gpt-oss:20b 13 GB
gpt-oss:120b 65 GB

查看运行状态：

1

ollama ps

实测加载后：

1
2


NAME SIZE PROCESSOR CONTEXT
gemma4:26b 25 GB 100% GPU 262144

这行信息很关键：100% GPU 说明没有明显落到 CPU，262144 说明上下文窗口很大，但不代表每次都应该塞满。

先直接对话

命令行对话：

1

ollama run gemma4:26b

然后直接问：

1

用三句话解释 Ollama 是什么。

如果要从程序里调用，用 Ollama 原生 API：

1
2
3
4
5
6
7
8


curl http://localhost:11434/api/chat \
 -d '{
 "model": "gemma4:26b",
 "messages": [
 {"role": "user", "content": "用三句话解释 Ollama 是什么。"}
 ],
 "stream": false
 }'

Ollama 返回的 JSON 里有性能字段：

字段	含义
`load_duration`	模型加载耗时
`prompt_eval_count`	输入 token 数
`prompt_eval_duration`	输入处理耗时
`eval_count`	输出 token 数
`eval_duration`	输出生成耗时

核心公式：

1

输出速度 = eval_count / eval_duration_seconds

这比手动掐秒表靠谱。

接入 Codex：默认沙盒失败，授权后跑通

Codex CLI 版本：

1

codex-cli 0.128.0

启动方式：

1

codex --oss --local-provider ollama -m gemma4:26b

我先跑了一个只读任务：

1
2
3
4
5
6
7


codex exec \
 --oss \
 --local-provider ollama \
 -m gemma4:26b \
 -s read-only \
 --ephemeral \
 "请阅读当前目录的 benchmark.sh，简要说明它会如何测试 Ollama 本地模型性能，不要修改任何文件。"

Codex 成功识别了 Ollama provider：

1
2
3


model: gemma4:26b
provider: ollama
sandbox: read-only

但默认 read-only sandbox 下，内部执行读文件命令时失败：

1

bwrap: loopback: Failed RTM_NEWADDR: Operation not permitted

这个结果很有价值：本地模型速度够，不代表 Agent 工具链一定顺。 这次不是模型不行，而是当前 Linux 环境下 bubblewrap sandbox 权限受限。

随后我显式授权绕过 Codex 内部 sandbox，仍然使用同一个只读任务：

1
2
3
4
5
6
7


codex exec \
 --oss \
 --local-provider ollama \
 -m gemma4:26b \
 --dangerously-bypass-approvals-and-sandbox \
 --ephemeral \
 "请阅读当前目录的 benchmark.sh，简要说明它会如何测试 Ollama 本地模型性能，不要修改任何文件。"

这次跑通了。Codex 成功执行：

1

cat benchmark.sh

并总结出脚本会调用本地 Ollama /api/chat，保存原始 JSON，再用 jq 计算 load_s、prompt_tokens_per_s、output_tokens_per_s 等指标。换句话说，Codex + Ollama + Gemma4 26B 是可用的，但在这台机器上需要绕过 Codex sandbox 才能读文件。

遇到类似问题，优先检查：

是否在受限容器、远程桌面、特殊 sandbox 里运行
系统是否允许 user namespace
Codex sandbox 模式是否过严
是否需要换普通终端或调整权限策略

接入 Claude Code：真实可用

Claude Code 版本：

1

2.1.126 (Claude Code)

Ollama 提供了 Anthropic-compatible API，所以可以这样接：

1
2
3
4
5


export ANTHROPIC_AUTH_TOKEN=ollama
export ANTHROPIC_API_KEY=""
export ANTHROPIC_BASE_URL=http://localhost:11434

claude --model gemma4:26b

我用完整路径跑了一个非交互只读任务：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


env ANTHROPIC_AUTH_TOKEN=ollama \
 ANTHROPIC_BASE_URL=http://localhost:11434 \
 ANTHROPIC_API_KEY= \
 /home/luoli/.local/bin/claude \
 -p \
 --model gemma4:26b \
 --no-session-persistence \
 --permission-mode dontAsk \
 --tools Read \
 --output-format json \
 "请阅读当前目录的 benchmark.sh，简要说明它如何测试 Ollama 本地模型性能。不要修改任何文件。"

结果成功：

指标	数据
状态	success
总耗时	7889 ms
API 耗时	7824 ms
轮数	2
输入 token	16319
输出 token	713
permission denials	0

Claude Code 正确读取了 benchmark.sh，并总结出脚本会用 5 个 case 调用 Ollama /api/chat，保存原始 JSON，再用 jq 提取 total_s、load_s、prompt_tokens_per_s、output_tokens_per_s 等指标。

这就是一个正面案例：同样是 Gemma4 26B，本地模型不只会聊天，也能通过 Claude Code 的 Read 工具进入真实开发上下文。

接入 Hermes Agent

Hermes Agent 版本：

1

Hermes Agent v0.12.0 (2026.4.30)

快速启动：

1

ollama launch hermes

也可以 oneshot 测试：

1
2
3


hermes --provider ollama \
 -m gemma4:26b \
 -z "请用三句话说明你当前是否在通过 Ollama 本地模型运行，并给一个开发建议。"

我本机能跑通。再用：

1

hermes status

看到：

1
2


Model: gemma4
Provider: ollama-launch

这里有个细节：模型回答里可能说自己是 custom provider，但工具状态显示 ollama-launch。所以验证 Agent 是否真的接入本地模型，不要只看模型自述，要看工具的 status 或配置。

4090 + Gemma4 26B 实测

我写了一个 benchmark 脚本：

1

content/post/ollama-local-dev/benchmark.sh

它测试 5 类任务：

Case	目的
Short chat	短对话
Long Chinese output	长中文输出
Code generation	代码生成
Code review	代码审查
Agent planning	Agent 规划

实测结果：

Case	总耗时	输出 tokens	输出速度
短对话	4.790s	697	165.93 tokens/s
长中文输出	18.728s	2785	160.84 tokens/s
代码生成	13.337s	1985	161.66 tokens/s
代码审查	14.430s	2143	161.16 tokens/s
Agent 规划	13.631s	2028	161.48 tokens/s
长输出监控	24.020s	3554	159.79 tokens/s

结论很稳定：

1

Gemma4 26B 在这台机器上的持续输出速度约 160 tokens/s

显存、功耗和温度

模型加载后：

1
2
3
4


GPU Memory: 24527MiB / 49140MiB
Power: 72W
Temp: 51C
Process: /usr/local/bin/ollama

长输出期间用：

1

nvidia-smi dmon -s pucvmet -c 20

观察到：

指标	数据
功耗	260-265W
温度	54-60C
SM 利用率	82-87%
显存占用	约 24529MB
显存利用率	50-55%
显存频率	10501 MHz
核心频率	2670-2685 MHz

这说明推理确实主要在 GPU 上跑，而且负载不低。长时间跑 Agent 时，真正要关注的不只是 tokens/s，还有散热、风噪、电费和显存被其他任务抢占。

一个容易误判的点：thinking 也算 token

第一次烟测里，我只是问：

1

用三句话解释 Ollama 是什么。

但 API 返回里的 eval_count 到了 887，因为模型生成了不少 thinking 内容。

所以做 benchmark 时不要只看“用户看到多少字”。对推理耗时来说，模型实际生成的 token 才是成本，包括 thinking。

适合怎么用

我建议这样分工：

场景	本地 Gemma4 26B 是否适合
私有代码解释	很适合
写脚本 / 小工具	很适合
生成测试样例	适合
初步 code review	适合
大型重构	谨慎
跨仓库复杂任务	不建议只靠本地
高风险生产改动	必须人工复核

最舒服的用法不是“让本地模型全自动开发完整系统”，而是：

1
2


本地模型负责高频、低风险、隐私敏感任务；
云端强模型负责低频、高难度、强推理任务。

Takeaway

回顾一下，搭一个能用于开发的本地 AI 环境，只需要四步：

用 Ollama 拉取模型：ollama pull gemma4:26b
用 API 或 CLI 确认模型能稳定对话
把 Codex、Claude Code、Hermes 接到 localhost:11434
用 tokens/s、显存、功耗、温度和 Agent 成功率一起评估体验

这次实测最重要的结论不是“4090 很快”，而是：

本地模型的下限已经很高，但上限取决于工具链。

Claude Code 能顺利读取文件，Codex 在同一环境里被 sandbox 卡住，Hermes 能跑通但 provider 映射要核验。这才是真实的本地 AI 开发体验：模型只是发动机，方向盘、刹车和路况一样重要。