Parlor：在一台 M3 Pro 上跑实时多模态 AI，这事儿真成了
昨天 HN 首页有个 Show HN 冲到 264 分：Parlor — 作者 Fikri 把 Gemma 3n E2B 塞进一台 M3 Pro，跑出了一个实时的音频+视频输入、语音输出的本地多模态 agent。不是云端 API 串起来的 demo，是真正 on-device 的闭环。
我看到这条的时候第一反应是：哦，本地实时多模态从”PPT 概念”正式变成”你现在就能 clone 下来跑”的东西了。
Parlor：在 M3 Pro 上实现音频/视频输入 + 语音输出的本地实时 AI
这东西为什么有意思
过去一年聊”本地 LLM”的时候，大部分讨论还停留在文本：llama.cpp 跑个 7B、Ollama 拉一个模型、用它写写邮件。但凡涉及到语音输入、视频理解、低延迟语音合成这几个维度，基本就得回到云端 — OpenAI Realtime API、Gemini Live，都是厂商把整条流水线在他们的 GPU 上编排好。
Parlor 做的事是把这条流水线完全搬到本地：
- 视觉/音频输入：摄像头和麦克风流直接喂给 Gemma 3n E2B（这是 Google 今年推的 on-device 多模态小模型，E2B 是 effective 2B 参数版本）
- 推理：MLX 框架，吃 Apple Silicon 的统一内存架构
- 输出：本地 TTS，实时语音回应
一台 M3 Pro，不联网，延迟做到了可交互的程度。这在两年前是完全不可想象的。
Gemma 3n E2B 是关键
这个项目能成，一半要归功于 Google 去年开源的 Gemma 3n 系列。E2B 这个”有效 2B 参数”的设计很有意思 — 实际参数量更大，但通过 per-layer embedding 和选择性激活，运行时的内存占用和计算量接近 2B 模型。换句话说：9B 的能力，2B 的成本。
对 on-device 场景这是决定性的。iPhone、MacBook、甚至未来的眼镜，都不会给你 16GB 显存去跑模型，但能腾出 2-3GB 给一个”足够聪明”的多模态模型，这个预算是现实的。
本地化的真正意义
我一直觉得本地 AI 最被低估的价值不是”省 API 费”，而是交互范式的解放：
- 延迟：云端 realtime API 再快，RTT 也在 200-500ms，本地可以做到 50ms 以内，这个差距在语音对话里是”机器”和”人”的区别
- 隐私：你的摄像头画面和麦克风音频不用离开设备，这对家庭、医疗、儿童场景是刚需
- 离线：飞机上、地下室、信号差的户外，AI 助手不会突然变砖
- 成本曲线：边际成本接近零，适合高频、长时长的使用场景
Parlor 证明了前三点在 2026 年的消费级硬件上已经可行。不是未来，是现在。
开发者视角的几点观察
作为一个每天在不同 AI 模型之间切换的开发者，我看这类项目的时候习惯问三个问题：
1. 它是 demo 还是 infra？ Parlor 目前是 demo，代码不到一千行，但架构清晰，是可以被拿去当 scaffold 的。接下来会有人把它封装成 SDK。
2. 它能跑在多便宜的硬件上？ M3 Pro 不便宜，但 M4 Air、未来的 A18 Pro 都会继承这条路径。Apple Silicon 的统一内存是 on-device AI 的结构性优势，Intel/AMD 短期追不上。
3. 它替代了什么云端服务？ 目前看，它会先蚕食”轻量级实时交互”场景 — 不是替代 GPT-4o 的全部能力，而是在延迟敏感、隐私敏感、使用频次高的子集里形成差异化。
云端与本地不是二选一
说到这儿必须强调：本地不等于反云端。真实的应用架构会是分层的 — 简单的实时交互本地处理，复杂推理 fallback 到云端大模型，两边数据打通。这也是为什么一个能一个账号聚合多个模型的平台对开发者很有价值：本地模型做前端响应，云端 Claude/GPT/Gemini 做深度推理，中间层不需要重复写集成。
如果你也在折腾多模型切换，推荐试试 OfoxAI（ofox.ai）— 一个账号搞定 Claude、GPT、Gemini、Kimi 等主流模型，API 统一，省掉在多个账号和 key 之间切换的心智成本。
写在最后
Parlor 只有 264 分，不算 HN 顶流，但在我眼里比很多千分帖更值得关注。因为它不是又一个”用 GPT API 包一层”的产品，而是一个真正在硬件边界上做工程的项目。
on-device 多模态是未来五年最重要的技术曲线之一。今天看起来粗糙的 demo，两年后就是 iPhone 上你每天用的 Siri。
记住这个时间点：2026 年 4 月，一台 M3 Pro 在本地跑起了实时多模态 agent。以后会越来越便宜，越来越小，越来越好。