把 UnifoLM-OminiA-0.3 的图文语音接进来，容易卡住的地方通常不在模型本身，而在两段之间的接口：输入那一侧，图像和语音是否真的进到了请求体里；输出那一侧，模型给回来的东西是否被整理成下游能直接读的固定字段。这两段要分开验证，不要一边调输入一边改输出解析，否则出错时无法判断是哪一段的问题。建议先用纯文本跑通一次请求，确认链路、鉴权和模型标识可用，再分别只加图像、只加语音，最后才把两路输入合在一起，并把输出按固定字段落盘。

判断方向：先证明图像通道和语音通道各自能让模型“看见/听见”，再谈输出格式统一。操作上分三次请求验证（纯文本基线、文本+图、文本+音频），每次只改一个变量，并用日志里的请求体大小、错误码和返回文本是否体现输入内容作为验证依据。边界：具体字段名、是否支持音频直读、是否有前置转写，都需要结合接入环境的接口文档与实际返回确认，不要照搬骨架里的字段。

先单独验证图像输入能进到请求里

图像通道要验证的是“请求体里有没有图、模型有没有用上这张图”，而不是“接口返回 200”。下面是一个通用骨架，字段名只是为了说明结构，实际以你接入的接口为准；有的服务把图片放在 content 数组里，有的用顶层 image 字段，也有只接受 URL 不接受 base64 的。

POST {你的接口路径}
Content-Type: application/json

{
  "model": "unifolm-ominia-0.3",
  "messages": [
    {
      "role": "user",
      "content": [
        {"type": "text", "text": "描述这张图里的主要物体"},
        {"type": "image_url", "image_url": {"url": "data:image/jpeg;base64,<BASE64>"}}
      ]
    }
  ]
}

返回里建议先看三类信息：一是错误体，区分鉴权失败、字段不支持（unsupported modality / invalid content type）、图片过大被网关拒绝；二是用量字段，如果返回里有输入计数或图片计数，能侧面说明图像被计入了本次请求；三是文本本身，把提示词换成只有看图才能答对的问题（例如图中数量、图中文字），如果回答与图片无关，多半是图片没进请求或被降级成纯文本处理。base64 体积过大时常被前置网关截断，可以先压缩或改用 URL 形式，并记录请求体字节数做对比。

再单独验证语音输入能进到请求里

语音比图像多一层歧义：有些接入是模型侧直读音频片段，有些是前置 ASR 先转写成文本再送进 messages。这两种情况下，“语音进了请求”的表现完全不同，验证前要先确认自己走的是哪条路。通用结构示例：

{
  "model": "unifolm-ominia-0.3",
  "messages": [
    {
      "role": "user",
      "content": [
        {"type": "text", "text": "转写这段语音并用一句话概括"},
        {"type": "input_audio", "input_audio": {"format": "wav", "data": "<BASE64>"}}
      ]
    }
  ]
}

与图像输入相比，语音的差异点主要在：格式和采样率限制更严格，时长往往有上限，单声道/双声道处理不一致，且失败时更容易表现为“返回了一段和音频无关的通用回答”而不是报错。需要记录的字段建议固定为：音频格式、采样率、声道数、时长、base64 长度、是否触发前置转写、转写文本（若有）、返回中的错误码。如果走前置转写，验证重点就变成转写文本是否合理；如果走模型直读，验证重点是播放/引用音频里才有的信息（例如某个数字、某个人名）看回答能否对上。

把模型输出整理成固定字段的文本

下游要的是稳定字段，不是一段自由发挥的文本。建议在调用侧加一层轻量规整，把每次结果写成一个固定结构的对象，再交给业务使用。

{
  "request_id": "",
  "model": "unifolm-ominia-0.3",
  "input_modalities": ["text", "image"],
  "text": "",
  "summary": "",
  "missing": [],
  "raw": ""
}

缺失字段的填充规则要写死，不要依赖模型补：字段未返回时填空字符串或 null，并把字段名追加进 missing 数组；summary 为空时不要用 text 前几十个字顶替，宁可留空，让下游自己决定是否回退；raw 保留原始返回，便于事后对比。走样输出的识别可以从几条明显信号入手：回答里复述了提示词、出现字段名串位（该是摘要的位置放了原文）、结尾被截断且长度贴近上限、语言与输入语言不一致、同一段内容重复两遍。识别到这些情况，先按截断和提示词问题排查，不要直接改解析代码去“兼容”。

两段分别出问题时的隔离排查顺序

输入异常和输出异常必须分开定位。下面这个顺序的好处是每一步只引入一个变量，出问题时能立刻知道是通道问题还是规整问题。

无法复现时的记录项建议固定下来：request_id、发生时间、输入模态组合、请求体字节数、音频时长与格式、图片分辨率、模型标识、是否流式、原始返回全文、规整后的字段对象。把这些一起存下来，下次出现同类现象时可以直接比对，而不需要凭印象重新构造请求。需要提醒的是，不同环境的网关对请求体积和超时的限制不一样，组合输入偶尔失败时，先确认是不是被前置层拦掉，再怀疑模型侧。