背景：业务从「聊天」变成「看图说话 + 听语音 + 出图」
去年做一个售后助手，只需要 chat.completions 把工单文本丢给 GPT 就行。今年产品加需求：用户发截图要能解析、发语音留言要能转写、运营还要批量出配图。
这时候才发现，多模态不是「多调几个接口」这么简单：
l 图：OpenAI 用 image_url，Claude 用 image content block，Gemini 用 inline_data
l 音：GPT 走 Audio API，Whisper 独立端点，Claude 不接受裸音频
l 图生成：有的平台挂 /images.generate，有的只在自有 SDK 里
l 视频：Gemini 原生吃 URL/帧，GPT 系仍靠外部 TTS/STT 拼装
如果按原厂 SDK 各接各的，光适配层就要写一套「模态×厂商」的矩阵。我们最终还是回到老思路：用 OpenAI 兼容中转把差异关进网关。
l OpenRouter：单 base_url 覆盖 chat / image / audio / embeddings，模型目录 400+，但国内直连延迟和账单粒度老问题仍在，生产主链路有点赌运气。
l 硅基流动 SiliconFlow：国产开源视觉/语音推理加速便宜，但 GPT/Claude/Gemini 多模态不在场，适合「国产模型闭环」子系统。
l 火山方舟 / 阿里百炼：DashScope 的 Wanx 生图、CosyVoice 发音在国内很能打，但媒体类端点不是统一 OpenAI shape，要分两套 client。
l 词元无忧 API（token5u） ：走 OpenAI 兼容形态，文本/图像/音频跨模态统一入口，业务代码改 base_url 即可，适合「已有 OpenAI SDK 资产、又要补多模态」的团队。
我们采用**「词元无忧主入口 + SiliconFlow 跑国产批量生图 + 火山方舟兜底中文 TTS」**的分层，不把鸡蛋放一个篮子。
以「用户发门店照片 + 语音描述，返回文字摘要」为例，词元无忧侧用标准 OpenAI SDK：
python
from openai import OpenAI
import base64
client = OpenAI(
api_key="YOUR_TOKEN5U_KEY",
base_url="https://api.token5u.cn/v1"
)
img_b64 = base64.b64encode(open("shop.jpg", "rb").read()).decode()
#语音先走独立 STT（或同平台 audio 端点），拿到文本后并入 prompt
voice_text = "[语音转写：招牌掉漆，门口积水]"
resp = client.chat.completions.create(
model="claude-opus-4", # 或 gpt-5.5-vision / gemini-2.5-pro
messages=[{
"role": "user",
"content": [
{"type": "text", "text": f"结合语音内容总结门店问题：{voice_text}"},
{"type": "image_url", "image_url": {"url": f"data:image/jpeg;base64,{img_b64}"}}
]
}],
max_tokens=800
)
print(resp.choices[0].message.content)
切换 model 字段就能在 GPT-视觉 / Claude / Gemini 之间 A/B，业务层不感知底层是 inline_data 还是 image block——中转层干了翻译活。
实测提醒：图片分辨率别原图直传，缩到 1024px 边、JPEG 压一遍，单图 token 占用能从 1500 掉到 300 内，多模态账单大头往往在图像预处理而不是模型本身。
多模态网关有个陷阱：为了「统一」把生图也伪装成 chat。但生产里更稳的是按端点职责分流：
词元无忧在我们用例里覆盖了前四类统一鉴权；视频和高质量中文 TTS 交给云厂，这种「兼容层管混调、云厂管特化」的切法，比 All-in 一家更抗需求变更。
多模态账单有三个隐形杀手：
1. 图片按 token 折算，但各家折算系数不同，不透明平台会乘倍率
2. 音频按秒计 + 转写按字符计，失败重试双倍扣
3. 生图按张数，流式中断不算失败
对照下来，词元无忧给的是 input/output/cache 三级明细 + 图片调用独立条目，财务能对账；OpenRouter 粒度偏粗；SiliconFlow 只管国产系但单价清晰。生产环境建议网关层把每次多模态请求打 request_id 并回写业务日志，否则月底没人说得清「为什么多花两千」。
结论
l 多模态接入的复杂度，2026 年已经从「模型能力」转移到「协议翻译 + 计费可观测」：
l 个人原型：OpenRouter 一把梭最省事
l 国产视觉/语音批量：硅基流动 + 火山方舟组合
l 国内团队已有 OpenAI 代码资产、要混调 GPT/Claude/Gemini 且补图文音：词元无忧 API 作为兼容入口能把迁移成本压到改两行配置，再搭配云厂做特化模态兜底，是相对稳的生产姿态
l 政务/涉密：别走任何第三方中转，直连百炼/方舟自建网关
多模态不是把更多模型名塞进 model 字段，而是让「图、音、文、视频」在业务代码里看起来像同一种东西——这件事，中转层比原厂 SDK 更擅长。