按输入模态挑后端：纯文本、带图与带 PDF 的提示词在一把 key 上该各派给谁

为什么按输入模态做第一层筛选

聚合站的一个 API key 背后挂着多个模型，每个模型对输入模态的支持并不一致。如果你把带图片或 PDF 的请求发给了纯文本模型，轻则报错，重则返回无意义的结果。因此，在考虑价格、上下文长度、推理能力之前，先用「这条提示词必须携带什么模态」做一次硬性过滤，能避免大部分无效调用，也能让成本花在刀刃上。

三个模态档位与常见后端能力

不同厂商的模型对输入模态的支持各有侧重，下面是一个概括性的分类，具体以各模型官方文档为准。

• 纯文本：所有后端都支持。DeepSeek、Qwen、GLM、Kimi 在纯文本任务上通常有较好的成本优势，适合大规模文本处理。
• 图片输入：需要模型具备视觉理解能力。Claude 和 GPT 系列的多模态模型通常支持图片输入；部分国内模型也在逐步支持。如果你的提示词必须带图，优先从明确支持视觉的后端里选。
• PDF 输入：PDF 的处理方式有两种——一种是把 PDF 当作文件直接上传（原生支持文档输入），另一种是先转成图片或文本再喂给模型。原生支持 PDF 的后端能省去预处理步骤，但可用模型较少；多数情况下，将 PDF 转为图片或提取文本后再调用视觉或文本模型是更通用的做法。

决策流程：从模态到后端

你可以按以下顺序收敛：

1. 列出模态需求：这条提示词是纯文本、带图，还是带 PDF？
2. 过滤后端：去掉不支持该模态的模型。例如带图时，排除仅支持文本的模型；带 PDF 时，确认该后端是否原生支持文档输入，否则准备转换方案。
3. 在剩余后端中比成本：聚合站按官方价 ×1.3 扣费，不同模型的官方价差异很大。纯文本任务可以优先考虑单价较低的模型；多模态任务则在支持视觉的模型里选性价比合适的。
4. 考虑任务复杂度：如果任务需要强推理或长上下文，即使单价稍高，也可能因为一次通过而更划算。

实操建议：用一把 key 管理多模态路由

在代码里，你可以根据输入类型动态选择模型名称，而不需要维护多套密钥。例如：

• 纯文本批处理 → 选成本较低的文本模型；
• 带图片的问答 → 选支持视觉的模型；
• 带 PDF 的文档分析 → 若后端原生支持 PDF 则直接调用，否则先用工具将 PDF 转为图片或文本，再走对应模态的模型。

这样，同一把 API key 就能覆盖多种输入场景，计费统一按 USDC 结算，方便做成本核算。

成本视角：×1.3 与 ×1.1 的取舍

作为使用者，你按官方价 ×1.3 支付 USDC。如果你同时也贡献 key，贡献部分按官方价 ×1.1（优质 ×1.2）获得 USDC 返利。这意味着：

• 对于高频、对成本敏感的纯文本任务，选择单价低的模型能明显降低 ×1.3 后的绝对支出；
• 对于必须带图或 PDF 的任务，由于可选的视觉模型有限，成本优化空间较小，此时应优先保证模态支持正确，避免因选错模型导致重试浪费；
• 如果你有闲置的 key 可以贡献，返利能部分抵消使用成本，但不要将其误解为净成本大幅下降——实际支付仍是官方价 ×1.3。

常见陷阱

• 把图片发给纯文本模型：请求可能直接失败，或模型忽略图片只处理文字，导致结果不符合预期。
• 假设所有模型都支持 PDF 原生输入：多数模型需要你先做转换，提前规划转换流程能减少调试时间。
• 只看单价忽略模态限制：最便宜的模型如果不支持你需要的模态，再便宜也无法使用。

小结

按输入模态做第一层筛选，是使用多模型聚合站时最稳妥的起点。先确保后端支持你的模态，再在支持范围内比较 USDC 成本和任务需求，最后用一把 key 统一调用。这样既能避免无效请求，也能让每一笔 ×1.3 的支出都花在能真正处理你输入的后端上。