# 多模态向量：把文本、图片与视频放进同一个向量空间

> 有些向量模型不只接受文本，还接受图片与视频，而它们在标准 embeddings 端点上会被拒绝。本文给出应发送的结构、用量如何计数，以及它能替代什么。

_发布 2026-09-12 · 更新 2026-09-29 · [KeepRouter Editorial](https://keeprouter.com/editorial-policy#editorial-team) · 4 分钟阅读_

![三种带类型输入（文本、图片、视频）汇聚成一个向量块](https://keeprouter.com/editorial/blog/multimodal-embeddings-guide.png)

_带类型的文字与媒体输入形成向量表示；建立检索索引前，应先明确一条记录的边界。_

**先给结论：**向量就是一组数，而多模态向量模型能用同一个空间里的文本、图片与视频生成这组数。这个特性正是使用它的理由：一张图片与描述它的一句话会靠得很近，于是跨两者的检索变成对同一个索引的一次查询，而不是「先转写、再描述、再对描述做向量化」的流水线。

## 端点不同，而且这不是小毛病

有些上游把这些模型放在与普通文本向量不同的操作上。把这类模型发到标准 embeddings 端点，会得到明确错误，提示该模型不支持这个 API。这就是本站把它们放在独立模态下、并在模型页指向 `POST /v1/embeddings/multimodal` 而不是文本端点的原因。

发布错误端点比不发布更糟：客户端会照着模型页抄一个看起来能用的示例，然后被拒绝。本站遵循的规则是，模型页上的端点就是真正能服务该模型的端点。

## 请求结构

输入是带类型的部件数组，而不是一个裸字符串，因此纯文本请求仍然可用，但需要显式声明：

```bash
curl https://keeprouter.com/v1/embeddings/multimodal \
  -H "Authorization: Bearer $KEEPROUTER_KEY" -H "Content-Type: application/json" \
  -d '{"model":"doubao-embedding-vision-251215","input":[
        {"type":"text","text":"桌上的一架纸飞机"},
        {"type":"image_url","image_url":{"url":"https://keeprouter.com/logo-512.png"}}
      ]}'
```

网关会把响应归一化成 OpenAI 的列表形式，因此即使上游返回单个对象，读取 `data[0].embedding` 的既有代码仍可工作。它也接受纯字符串或字符串数组并自动包装成部件，所以纯文本调用不需要另写一条代码路径。

## 用量如何计数

响应里的用量会把媒体与文本分开。一次带一张小图与一句短文本的请求返回 362 个 prompt token，其中 334 个是图片 token，28 个是文本 token。这份明细是看清成本来源的诚实方式，也解释了为什么一个看起来很小的请求仍可能被计到几百。

上游对图片 token 的收费高于文本 token。本站的价格表每个模型只有一个输入费率，因此公布的是文本费率，媒体 token 也按它计费。实际效果是运营方吸收了折扣，而不是多收；在这样的费率下，全部差异也就是每次调用几分之一美分。如果将来图片流量变得重要，正确的做法是增加第二个输入费率，而不是提高文本费率。

## 什么时候该用它

当你手里的查询与语料属于不同种类，而你想要一次覆盖两者的排序时，用多模态向量模型：

- **商品目录里的视觉搜索**：买家的一句话要匹配到一张照片。
- **去重**：面对截图、视频帧与文字笔记混杂的档案。
- **多模态助手的检索**：让一个问题直接取回相关画面，而不必在前面加一步图片描述。

当任务需要的是文字而不是相似度时，请换别的工具。如果你必须读出图片里的文字，那是 OCR；如果你必须用句子描述图片内容，那是视觉模型。向量模型返回的是数字，它的职责是让相似的东西靠近，而不是解释它们。

## 生成向量前先定义一个目录条目

在商品搜索原型中，一张商品图及其说明可以描述一个条目，无关图片应保持为独立条目。索引和查询使用一致的表示方法，再用已知图片与文本配对检查检索。[KeepRouter API 参考](https://keeprouter.com/api/docs)定义该路由；[豆包检索教程](/zh/blog/doubao-multimodal-embedding-retrieval)补充有限向量检查与评估方法。向量请求成功并不能证明搜索结果有用。

## 实践要点

**维度由模型固定。** 本站该模型返回 2048 维向量。把这个宽度写进你的表结构并固定下来，因为以后换模型意味着重新向量化整个语料，而不是改一个查询。

**上下文很大但并非无限。** 公布的上下文窗口是 131,072 token，对文档与视频抽帧来说很宽裕，但它仍然是有限值。长输入会按上游实现被截断或拒绝，因此请有意识地分块。

**一次向量化，多次复用。** 向量的价值来自语料只嵌入一次、却被查询很多次。把向量库当作持久产物，把嵌入调用当作构建步骤，而不是在请求处理函数里顺手做的事。

[多模态模型 API 说明](/zh/features/multimodal-models)解释了每种模态各自端点的规则，[模型目录](/models)列出当前费率与每个模型的确切端点，[视频任务指南](/zh/blog/async-video-generation-api)则覆盖了本站另一条异步路径。


## 常见问题

### 为什么不能直接在 /v1/embeddings 上加一个图片字段？

因为提供该能力的上游把它实现成了独立操作。这类模型在标准 embeddings 端点上会被明确拒绝，若在那里发布就等于宣传一个无法服务的端点。网关为它们单独设置模态，并在模型页指向多模态路径。

### 图片和文本的费率一样吗？

上游对图片 token 的收费高于文本 token，但价格表只有一个输入费率，因此公布的是文本费率，媒体 token 也按文本计费。这是运营方吸收的折扣，而不会多收；在这样的费率下，每次调用差异只有几分之一美分。

### 接受哪些输入？

文本、图片与视频，以带类型的部件放在同一个请求里。本站该模型返回 2048 维向量，上下文窗口为 131,072 token，其用量明细会把图片 token 与文本 token 分开，便于你核对请求是如何计数的。

## 参考的一手资料

_本文最近复核 2026-09-29_

1. [Google Gemini API embeddings documentation (multimodal input, per-type limits)](https://ai.google.dev/gemini-api/docs/embeddings)
2. [OpenAI embeddings guide (request and response shape)](https://developers.openai.com/api/docs/guides/embeddings)
3. [KeepRouter API reference](https://keeprouter.com/api/docs)

## 继续阅读

- [多模态模型 API](https://keeprouter.com/zh/features/multimodal-models.md)
- [异步视频生成 API：任务 ID、轮询与按秒计费](https://keeprouter.com/zh/blog/async-video-generation-api.md)
- [models](https://keeprouter.com/models.md)
- [errors](https://keeprouter.com/docs/errors.md)
- [doubao embedding vision 251215](https://keeprouter.com/models/doubao-embedding-vision-251215.md)

## 查看这个型号的价格与 API

查看本文型号的当前用户费率、支持端点与接入示例。

[查看型号与价格](https://keeprouter.com/models/doubao-embedding-vision-251215)

[创建 Key，测试免费模型](https://keeprouter.com/login?returnTo=%2Fconsole%2Fkeys%3Fmodel%3Dfree)

免费测试使用 free 模型；其他付费型号需要足够预付额度。

[全部文章](https://keeprouter.com/zh/blog.md) · [模型与价格](https://keeprouter.com/models.md)