LFM3 把多模态模型带到本地

这次具体变化是什么

LFM3 值得开发者关注的变化，不是“又多了一个小模型”，而是 Liquid AI 在同一模型家族中发布文本、视觉、音频、全模态和决策等不同用途的开放权重模型，并将本地运行路径同时铺到 Hugging Face、Transformers、llama.cpp、MLX、vLLM、SGLang 等工具。Ollama 的 v0.40.12 先加入 LFM3 家族，支持范围当时限于 Apple 硬件；v0.40.13 随后把 LFM3 扩展到 Linux 和 Windows。开发者现在可以在不同桌面系统上试验同一家族的本地模型，但不能把“有多模态家族”误读成“每个变体都能处理所有模态”。

这篇内容聚焦可验证的能力边界与本地接入选择。Liquid AI 的发布说明发表于 2026 年 10 月 27 日，Ollama 的 v0.40.12 与 v0.40.13 发布说明分别记录了模型首次接入和跨平台支持变化。模型卡还明确写出音频变体的任务、上下文长度、语言范围，以及它不适合复杂多步推理或 Agent 编码等限制。下文只按这些原始资料说明，不把厂商自报的 benchmark 当成独立实测结论。

同一家族不等于同一能力

Liquid AI 将首批 LFM3 描述为共享基础架构上的多模态模型家族。开发者面对的实际选择包括文本、视觉、音频、Omni，以及面向结构化判断的 decision 变体。它们的输入输出并不相同：文本模型面向文字任务；视觉变体处理图像；音频变体接收音频或文字并返回文字、语音或交错的文字与语音；Omni 则将文字、视觉和音频组合在同一个模型中。决策模型把输入映射为指定类型的判断，不应仅因为名称带有同一家族标识，就假定它与通用聊天模型可以互换。

Ollama 的发布说明提供了适合快速识别的本地模型名：lfm3、lfm3-vl、lfm3-audio 和 lfm3-omni。其中 v0.40.12 的说明将 lfm3 标为 1.7B 文本模型，并列出视觉理解、语音识别与生成、以及文字图像音频组合等变体；同一说明也提醒那一版仅支持 Apple 硬件。到 v0.40.13，发布说明明确扩展 Linux 和 Windows 支持，并点名包含 lfm3-audio 与 lfm3-omni 的文字转语音能力。

对应用架构而言，这种拆分意味着模型路由应以任务能力为依据，而不是只写一个家族级别的 lfm3 配置。例如，纯文本分类先选择文本变体；图像问答需要视觉变体；语音识别、合成或语音驱动工具调用才考虑音频变体；只有确实需要同时看图、听音频并返回语音时，才评估 Omni。这样可以把“模型支持某模态”落实到具体请求路径，避免调用名正确、输入格式却与变体不匹配。

音频模型的实用边界

LFM3-Audio-2B 的模型卡把能力拆得较清楚：它可接收文字或音频，输出文字、24 kHz 语音或文字与语音交错内容；支持增量预填充和流式语音生成，也支持语音理解、转写、合成、翻译以及工具调用。音频编码器使用 16 kHz 输入，模型上下文长度为 32K token。对需要本地语音助手、语音输入转结构化动作或设备端音频处理的开发者，这些接口信息比“多模态”这个宽泛标签更能决定能否接入。

但语言和任务边界不能省略。模型卡列出 18 种语音语言或地区，包括中文；同时又明确指出，带有推理的流式语音聊天目前仅支持英语。也就是说，支持某种语言的语音转写、合成或翻译，不自动等于该语言下所有语音对话和推理模式都已支持。若产品需要中文语音对话，应分别验证目标路径究竟是转写、翻译、语音合成，还是“听完后进行多轮推理并口语回答”，不能仅凭语言列表做上线承诺。

模型卡还把 LFM3-Audio-2B 的适用范围限定在本地 Agent、工具调用、结构化输出和领域微调，并建议知识密集任务结合检索；它不建议用于 Agent 编码或复杂多步推理。这一点对开发者尤其重要：语音模型可以把口头请求转成工具调用，不等同于它适合承担长链路编码代理的大脑。需要代码修改、复杂规划或广泛知识问答时，应拆出相应模型或检索组件，而不是用“支持工具调用”推导出通用 Agent 能力。

用 Ollama 试验时先核对版本

若目标是通过 Ollama 快速验证本地模型，可先确认本机版本，再按发布说明中给出的文本模型命令启动：

ollama --version
ollama run lfm3

这里的命令只用于验证 lfm3 文本变体。对于视觉、音频和 Omni，不应想当然地把模型名替换后就视为接口测试完成；还要按相应模型能力准备图片或音频输入，检查该版本运行时暴露的调用接口，并确认客户端确实发送了该变体支持的数据结构。Ollama 发布说明说明了模型家族和平台范围，具体请求格式仍应以当前 Ollama 模型条目及应用接口文档为准。

版本是一个容易踩坑的细节：v0.40.12 的说明虽然已包含 LFM3，但当时支持范围明确是 Apple 硬件，Linux 和 Windows 被列为之后支持；v0.40.13 才写明跨平台支持。因此，在 Linux 或 Windows 上排错时，不能只看到模型已经出现在 Ollama library 页面就断定本地旧版本也能运行。应记录操作系统、Ollama 版本、具体变体和失败命令，再对照相应发行说明。若部署环境锁定旧版本，升级运行时属于必要的兼容性检查，而不是换模型名就能解决的问题。

此外，“能在操作系统上运行”并不等于所有硬件、量化格式和应用封装组合都已由这条发布说明逐一保证。模型卡将不同权重格式对应到不同推理框架：例如 GGUF 对应 llama.cpp，MLX 面向 Apple Silicon，ONNX Runtime 提供跨平台路径，BF16 则列出 vLLM、SGLang 与 Transformers。工程上应分别验证模型文件、后端、精度格式和硬件，而不要把 Ollama 的 Linux/Windows 支持外推成所有框架组合均可用。

从原型走向应用的检查项

本地原型可以先用少量样例验证四件事。第一，输入是否属于所选变体支持的模态；音频文件的采样率、图片内容和请求模板都应明确，而不是将原始数据随意塞进文本字段。第二，输出是否符合产品需要；音频模型可能返回文字、语音，或二者交错，应用需检查解析和播放链路。第三，工具调用是否包含可验证的结构化参数；将自然语言意图转成工具调用，并不代表工具副作用已经安全或正确。第四，失败与资源边界如何处理；模型卡公开了上下文和任务限制，应用需要据此约束输入长度、超时和降级路径。

如果团队依赖统一 API 层，不妨先把模型能力登记为字段，而不是只保存一个名字：例如支持的模态、输入采样率、输出类型、语言范围、工具调用能力、上下文上限、运行后端和版本。调用前校验请求与能力记录，部署时固定模型与运行时版本；遇到模型不识别、音频输出为空或跨系统行为不同，便能先判断是模型变体、数据结构、运行时版本还是硬件后端的问题。这些是从公开能力边界推导出的工程实践，不是官方对任一应用兼容性的保证。

若需要比较不同提供方公开列出的模型和运行方式，可从平台目录查看；寻找已登记的 API 站点时，可浏览站点目录。无论走本地推理还是远程 API，都应把输入输出模态、工具调用格式和数据处理位置作为验收项，而不是只凭模型家族名称判断兼容性。模型目录动态变化时，也可以参考模型目录核验的工程方法，把模型 ID、提供方和能力字段分开核对。

适合写进技术选型结论的说法

可以验证的结论是：LFM3 首批模型将文本、视觉、语音、Omni 和决策任务拆成不同变体；Ollama v0.40.13 把此前 v0.40.12 仅限 Apple 硬件的支持扩展到 Linux 和 Windows；音频变体还提供语音理解、生成与工具调用，但存在明确的语言和复杂推理边界。对开发者的直接影响，是本地多模态原型可以在更多桌面操作系统上试用，同时必须在应用层选择正确变体、确认运行时版本并验证具体请求格式。

不应从现有资料推出的结论包括：所有 LFM3 变体都在每种硬件与推理框架上同等可用、所有语言都有完整语音聊天推理、或音频模型适合替代编码代理。这些都超出已核对来源明确写出的范围。把模型拆分、运行时版本和语言/任务限制写入选型记录，才能让“本地多模态”成为可复现实验，而不是无法定位问题的宣传标签。