VLM 还是 LLM——纯文本场景的真相

结论先抛：如果你的语料 100% 是纯文本，用普通 LLM 完全够，根本不需要 VLM。OpenViking 在配置里硬要叫"vlm"是个命名误导——它其实就是个 LLM 调用接口，只不过额外能接受图片输入而已。

01VLM 是 LLM 的超集，不是替代品

这是最关键的一点：VLM ⊃ LLM。

VLM = LLM + 视觉能力。所有现代 VLM（GPT-4o、豆包-vision、Gemini、Claude）
都是在 LLM 基础上"加了一只眼睛"——你不喂图片，它就退化成纯 LLM。

★ 核心洞察你把纯文本喂给 VLM，它的表现就是个 LLM。不会有任何额外开销、也不会有任何性能损失。换句话说："VLM 处理文本"和"LLM 处理文本"在能力上没区别。

02那为什么 OpenViking 默认叫 VLM？

三个工程层面的理由——都是"防御性设计"，不是技术必需。

REASON 01

不知道你会喂什么

OpenViking 设计成通用上下文库，开发者可能往里塞 PDF、截图、流程图、设计稿。默认就用 VLM，能兜底所有内容类型。

REASON 02

VLM 价格 ≈ LLM

现代多模态模型（豆包-vision、GPT-4o、Gemini）跟同档次纯文本模型价格基本一样。用 VLM 没有额外成本，没必要给用户两套配置。

REASON 03

命名是历史遗留

项目早期就把这个字段叫 vlm，沿用至今。改名会破坏向后兼容性。其实改叫 summarizer 或 llm 更准确。

REASON 04

"多模态原生"是卖点

项目方在宣传上强调"支持多模态"，叫 vlm 比叫 llm 显得高级。marketing 大于 engineering。

03实战 · 你可以把"vlm"指向纯文本模型

配置文件 ov.conf 里的 vlm 字段本质就是个 OpenAI 兼容的 API 端点。

OpenViking 的 vlm 配置只在乎"它能不能 OpenAI 风格 API 调用"，根本不检查模型是不是真支持视觉。你完全可以这么配：

{
  "vlm": {
    // 字段叫 vlm，但你指向纯文本模型也照样工作 ↓
    "provider": "volcengine",
    "api_key": "your-key",
    "model": "doubao-1-5-pro-32k"  // 纯文本豆包模型
    // 而不是 doubao-seed-2-0-pro-260215（默认的 VLM）
  }
}

这样跑起来：纯文本资料一切正常，L0/L1 摘要照常生成。唯一区别：哪天你往里塞图片，它会报错——因为模型看不到图。

★ 一个更省的玩法纯文本场景下你甚至可以用更便宜的小模型做摘要——比如豆包 Lite、DeepSeek-V3、Qwen-2.5 系列。L0/L1 是低难度任务，不需要 GPT-4 级别的能力。这个优化通常能让 token 费用再降一半以上。

04你应不应该换成 LLM？

按场景给建议。

✓

用 LLM（纯文本模型）就够

语料 100% 纯文本/代码/markdown 文档。建议：直接配豆包 Lite 或 DeepSeek-V3 之类的便宜模型省钱。

用 VLM 更稳妥

语料里偶尔有图片、PDF（带图）、截图、表格图。建议：保留 VLM 默认配置，反正成本差不多。

必须用 VLM

语料以图像为主（产品图、设计稿、扫描件、视频帧）。这种场景才是 VLM 真正发挥价值的地方。

⌘ 一句话纠正之前的说法

"必须用 VLM" 是误导，正确说法是这样的

OpenViking 在架构上必须接一个能调用 LLM 的 API来生成 L0/L1 摘要——这个角色 OpenViking 文档里叫它"VLM"，但你完全可以塞一个纯文本 LLM 进去，只要内容里没有图片。

所以更准确的说法是："OpenViking 必须连一个 能做文本摘要的 LLM API，外加一个 Embedding API"。VLM 是 OpenViking 对这个 LLM 角色的默认推荐，不是技术硬性要求。

对你那个多 Agent 平台——如果你的语料主要是群聊消息 + 文本任务，配个便宜的 DeepSeek 或豆包 Lite 当 "vlm" 就行，能省一大笔钱。