Ollama v0.40.12 把 Liquid AI 的 LFM3 家族接了进来。这是 Liquid AI 面向本地 Agent、工具调用和结构化输出做的一批小模型，走的是它家新的 tri-hybrid 架构。对小内存、跑在笔记本上的 Agent 场景，这批模型值得看，但先搞清楚各档的区别再决定用哪个。
家族四档
LFM3 家族按模态分了四档，主打档 lfm3 是 1.7B 的文本模型，带 256K 的上下文窗口：
| 型号 | 能力 |
|---|---|
| lfm3 | 1.7B 文本模型，256K 上下文窗口 |
| lfm3-vl | 加图像理解 |
| lfm3-audio | 18 种语言的语音识别、翻译、TTS |
| lfm3-omni | 文本、图像、语音一体 |
1.7B 意味着它在消费级笔记本上能顺畅跑，256K 上下文则适合把大段文档、长会话塞进去做本地 Agent。lfm3-vl 加图像理解，lfm3-audio 管 18 种语言的语音，lfm3-omni 三模态合一。
同一批还带了 d1 的 2B 版本，同样基于 LFM3。d1 的定位是"决策模型"——对文本和图像做判断，比如判断一条客服消息是不是账单问题，d1-omni 再加音频。
上手
跑起来就是一条命令：
ollama run lfm3
d1 的用法也简单，问题加一个判断式的 --ask：
ollama run d1:2b "I was charged twice for order 4417." --ask "Is this a billing issue?"
一个关键限制
这批模型目前只在 Apple 硬件上受支持，Linux 和 Windows 的支持官方说"coming soon"。也就是说，现在想跑 lfm3 和 d1 2B，得有台 Mac；Linux 服务器和 Windows 机器暂时别急着切。
除了新模型，这个版本还带了几项顺手的改进：Apple 芯片上 Gemma 4、Flint、Laguna 的提示词处理变快了；MLX 上的投机解码支持 DFlash2 草稿模型；Gemma 4 在小图上保留更多细节；ollama launch 兼容 OpenCode v2；还修了 Kimi CLI 的纯工具回合。
场景拆解
把这四档放进真实的本地 Agent 场景里，各自该接的活不一样：
- 长文档问答、把几十页资料塞进上下文做问答，用 lfm3 的 256K 窗口最合适，1.7B 的体量在 Mac 上跑起来不卡。
- 要识别截图、扫描件里的信息，用 lfm3-vl。
- 做语音输入、通话摘要、多语言语音交互，用 lfm3-audio，18 种语言的覆盖面对出海产品有点用。
- 三模态都要、又不想装三个模型，用 lfm3-omni。
- 只想做一个"是或不是"的判断——这条消息是不是账单问题、这封邮件要不要人工回——用 d1:2b，决策模型比生成模型更省、更聚焦。
一个容易混淆的点：d1 和 lfm3 定位不同。lfm3 是生成模型，负责把话说出来；d1 是决策模型，负责在选项之间做判断。别拿 d1 去写长文，也别拿 lfm3 去做二分类。
选型建议
值得上的场景：手头有 Mac、想在本地跑一个不吃资源、上下文够长的 Agent 底座，或者需要本地做语音识别、结构化输出的判断。1.7B 的体量和 256K 上下文，对"读一堆文档然后回答"这类活是合适的。
不该碰的场景：Linux/Windows 环境（现在还不支持）、需要强推理能力的重活——1.7B 撑不起复杂多步推理，这类还是交给大模型。d1 是决策模型不是生成模型，别指望它写长文。
整体看，LFM3 是给"本地 Agent"补的一批专用小模型，而不是一个全能选手。选它的理由应该是"我要在 Mac 上跑一个上下文够长、能吃多模态的轻量 Agent"，而不是"我要一个最强的本地模型"。
还有一层判断值得说：小模型的优势从来不在"回答得多好"，而在"跑得快、不联网、数据不出本机"。所以拿它和云端大模型比生成质量，本身就比错了对象。LFM3 该被拿来比的，是同样能本地跑的轻量模型——它真正的卖点是 256K 的上下文和工具调用、结构化输出这些 Agent 向的能力，而不是单轮问答的惊艳程度。