Descripción general: un modelo para varias modalidades de entrada
Qwen2.5-Omni-7B es el modelo multimodal de extremo a extremo de Qwen para texto, imágenes, audio y video. Puede comprender estas entradas en conjunto y generar texto con voz natural en un flujo de trabajo por streaming. Úsalo cuando una tarea dependa tanto de lo visible como de lo audible, o cuando el usuario dé la instrucción por voz en lugar de escribirla. Este es el checkpoint 7B exacto; el producto comercial Omni-Turbo y las versiones posteriores de Omni tienen sus propios contratos.
Funciones principales y arquitectura
El diseño Thinker-Talker combina comprensión y generación de voz. Thinker procesa la tarea multimodal y produce contenido textual, mientras que Talker participa en la formación de la respuesta hablada. TMRoPE, el esquema posicional multimodal del fabricante alineado en el tiempo, sincroniza las marcas de tiempo del video con el audio. La arquitectura está diseñada para entradas por fragmentos e interacción ágil por voz o video; este objetivo de diseño no es una garantía de tiempo de respuesta fijo para todas las interfaces.
La cobertura de tareas del fabricante incluye reconocimiento de voz, traducción del habla, comprensión de audio, razonamiento sobre imágenes, comprensión de video y generación de voz. Por lo tanto, las instrucciones habladas pueden participar directamente en una pregunta multimodal sin requerir siempre una transcripción escrita proporcionada por separado. Mantén clara la tarea objetivo: comprender un clip de audio, responder una pregunta hablada y generar una respuesta hablada son usos distintos, aunque el modelo admita todas sus formas de entrada o salida.
Preparación de una conversación multimodal
Proporciona los medios pertinentes e indica cómo debe relacionarlos la respuesta. Para una demostración narrada, pide al modelo que distinga los pasos visibles de la explicación del hablante e identifique dónde coinciden. Para una imagen acompañada de una pregunta en audio, identifica el papel de la imagen y solicita una respuesta concisa basada en el contenido visible. Para un fragmento solo de audio, indica si el objetivo es reconocer el habla, explicar sonidos o responder una pregunta sobre el contenido. Estas son aplicaciones propuestas de la cobertura de tareas documentada.
Los ejemplos del fabricante muestran conversaciones solo de texto, solo de audio, solo de video y con medios combinados. Conserva el orden y los tiempos originales de un video. Etiqueta los recursos separados para que el modelo pueda referirse a ellos sin tratar evidencia sin relación como un solo evento. El resultado puede ser únicamente texto o texto con voz; elige el artefacto útil antes de preparar la solicitud.
Preparación de la salida de voz
La receta del checkpoint de Qwen requiere su prompt de sistema documentado sobre capacidades de audio cuando se necesita salida de voz. El prompt identifica a Qwen y sus capacidades auditivas, visuales, textuales y de habla; un reemplazo sin relación puede impedir el comportamiento de audio esperado. Esta es una orientación para el flujo de trabajo del checkpoint del fabricante, no una afirmación de que todas las aplicaciones expongan controles de prompt de sistema o generación de audio.
El checkpoint exacto ofrece dos voces: Chelsie, una voz femenina cálida, y Ethan, una voz masculina animada. Chelsie es la predeterminada documentada cuando no se selecciona un hablante. Su ejemplo de generación escribe la voz con una frecuencia de muestreo de 24,000 Hz. Estas dos voces no deben sustituirse por la descripción de cuatro voces de un modelo comercial con otro nombre.
Uso del audio de un video
La pista de audio de un video puede ser pertinente para su significado, como instrucciones habladas o un sonido producido por una acción visible. Qwen expone use_audio_in_video en la preparación de medios, el procesamiento y la generación. El ajuste debe mantenerse coherente en las tres etapas y durante una conversación de varios turnos; los ajustes inconsistentes pueden producir resultados inesperados. Por lo tanto, una interpretación solo visual de un video es distinta de una interpretación audiovisual, aunque el archivo sea el mismo.
Salida solo de texto y procesamiento por lotes
El fabricante admite salida solo de texto mediante return_audio=False. También permite desactivar Talker después de la carga, lo que reduce la memoria de GPU aproximadamente 2 GB, pero deja la salida de audio sin disponibilidad en esa instancia. El ejemplo documentado de procesamiento por lotes con muestras mixtas requiere return_audio=False y combina solicitudes de texto, imágenes, audio y video. Ese ejemplo por lotes no debe convertirse en una afirmación de generación de voz por lotes.
Contexto y límites sustantivos
La configuración de la base textual del checkpoint establece las posiciones máximas en 32,768. El texto, los medios representados y las respuestas generadas consumen espacio de secuencia; este valor no define de manera independiente una duración universal de audio o video. Los ejemplos de recursos del fabricante muestran que un video más largo necesita mucha más memoria, por lo que un clip breve y pertinente suele ser más práctico que una grabación extensa sin relación. Sus ejemplos no publican un máximo estricto de longitud de respuesta independiente ni una duración de medios garantizada universalmente.
Verifica las citas textuales del audio y las conclusiones contra la fuente, conserva suficiente detalle visual para la pregunta y mantén un resultado textual cuando una persona revisora necesite inspeccionar la explicación hablada. El valor documentado del modelo es la comprensión conjunta y la respuesta en texto o voz, mientras que los controles exactos de voz, el procesamiento de medios y la entrega de la salida siguen siendo funciones de la interfaz elegida.
", "aboutText": "Descripción general: un modelo para varias modalidades de entrada\n\nQwen2.5-Omni-7B es el modelo multimodal de extremo a extremo de Qwen para texto, imágenes, audio y video. Puede comprender estas entradas en conjunto y generar texto con voz natural en un flujo de trabajo por streaming. Úsalo cuando una tarea dependa tanto de lo visible como de lo audible, o cuando el usuario dé la instrucción por voz en lugar de escribirla. Este es el checkpoint 7B exacto; el producto comercial Omni-Turbo y las versiones posteriores de Omni tienen sus propios contratos.\n\nFunciones principales y arquitectura\n\nEl diseño Thinker-Talker combina comprensión y generación de voz. Thinker procesa la tarea multimodal y produce contenido textual, mientras que Talker participa en la formación de la respuesta hablada. TMRoPE, el esquema posicional multimodal del fabricante alineado en el tiempo, sincroniza las marcas de tiempo del video con el audio. La arquitectura está diseñada para entradas por fragmentos e interacción ágil por voz o video; este objetivo de diseño no es una garantía de tiempo de respuesta fijo para todas las interfaces.\n\nLa cobertura de tareas del fabricante incluye reconocimiento de voz, traducción del habla, comprensión de audio, razonamiento sobre imágenes, comprensión de video y generación de voz. Por lo tanto, las instrucciones habladas pueden participar directamente en una pregunta multimodal sin requerir siempre una transcripción escrita proporcionada por separado. Mantén clara la tarea objetivo: comprender un clip de audio, responder una pregunta hablada y generar una respuesta hablada son usos distintos, aunque el modelo admita todas sus formas de entrada o salida.\n\nPreparación de una conversación multimodal\n\nProporciona los medios pertinentes e indica cómo debe relacionarlos la respuesta. Para una demostración narrada, pide al modelo que distinga los pasos visibles de la explicación del hablante e identifique dónde coinciden. Para una imagen acompañada de una pregunta en audio, identifica el papel de la imagen y solicita una respuesta concisa basada en el contenido visible. Para un fragmento solo de audio, indica si el objetivo es reconocer el habla, explicar sonidos o responder una pregunta sobre el contenido. Estas son aplicaciones propuestas de la cobertura de tareas documentada.\n\nLos ejemplos del fabricante muestran conversaciones solo de texto, solo de audio, solo de video y con medios combinados. Conserva el orden y los tiempos originales de un video. Etiqueta los recursos separados para que el modelo pueda referirse a ellos sin tratar evidencia sin relación como un solo evento. El resultado puede ser únicamente texto o texto con voz; elige el artefacto útil antes de preparar la solicitud.\n\nPreparación de la salida de voz\n\nLa receta del checkpoint de Qwen requiere su prompt de sistema documentado sobre capacidades de audio cuando se necesita salida de voz. El prompt identifica a Qwen y sus capacidades auditivas, visuales, textuales y de habla; un reemplazo sin relación puede impedir el comportamiento de audio esperado. Esta es una orientación para el flujo de trabajo del checkpoint del fabricante, no una afirmación de que todas las aplicaciones expongan controles de prompt de sistema o generación de audio.\n\nEl checkpoint exacto ofrece dos voces: Chelsie, una voz femenina cálida, y Ethan, una voz masculina animada. Chelsie es la predeterminada documentada cuando no se selecciona un hablante. Su ejemplo de generación escribe la voz con una frecuencia de muestreo de 24,000 Hz. Estas dos voces no deben sustituirse por la descripción de cuatro voces de un modelo comercial con otro nombre.\n\nUso del audio de un video\n\nLa pista de audio de un video puede ser pertinente para su significado, como instrucciones habladas o un sonido producido por una acción visible. Qwen expone use_audio_in_video en la preparación de medios, el procesamiento y la generación. El ajuste debe mantenerse coherente en las tres etapas y durante una conversación de varios turnos; los ajustes inconsistentes pueden producir resultados inesperados. Por lo tanto, una interpretación solo visual de un video es distinta de una interpretación audiovisual, aunque el archivo sea el mismo.\n\nSalida solo de texto y procesamiento por lotes\n\nEl fabricante admite salida solo de texto mediante return_audio=False. También permite desactivar Talker después de la carga, lo que reduce la memoria de GPU aproximadamente 2 GB, pero deja la salida de audio sin disponibilidad en esa instancia. El ejemplo documentado de procesamiento por lotes con muestras mixtas requiere return_audio=False y combina solicitudes de texto, imágenes, audio y video. Ese ejemplo por lotes no debe convertirse en una afirmación de generación de voz por lotes.\n\nContexto y límites sustantivos\n\nLa configuración de la base textual del checkpoint establece las posiciones máximas en 32,768. El texto, los medios representados y las respuestas generadas consumen espacio de secuencia; este valor no define de manera independiente una duración universal de audio o video. Los ejemplos de recursos del fabricante muestran que un video más largo necesita mucha más memoria, por lo que un clip breve y pertinente suele ser más práctico que una grabación extensa sin relación. Sus ejemplos no publican un máximo estricto de longitud de respuesta independiente ni una duración de medios garantizada universalmente.\n\nVerifica las citas textuales del audio y las conclusiones contra la fuente, conserva suficiente detalle visual para la pregunta y mantén un resultado textual cuando una persona revisora necesite inspeccionar la explicación hablada. El valor documentado del modelo es la comprensión conjunta y la respuesta en texto o voz, mientras que los controles exactos de voz, el procesamiento de medios y la entrega de la salida siguen siendo funciones de la interfaz elegida.", "editorialOverlay": { "copy_fields": { "practical_html": "Ejemplo técnico en inglés
Compare demonstration notes with narration\n\nCompare two text records of demonstration M2. Visual notes: 'Operator closes the lid, then presses Start.' Narration transcript: 'Press Start before closing the lid.' Identify the sequence disagreement and write one clarification question for the instructor. Use only these supplied records; do not claim to have watched or heard a clip.A source-linked sequence comparison and one targeted clarification question.The answer must preserve the opposing event order and avoid inventing a resolution.qwen2.5-omni-7bQwen2.5-Omni-7B combina comprensión de texto, imágenes, audio y video con salida de texto y voz natural. Su arquitectura Thinker-Talker alinea el audio con los tiempos del video, admite interacción por streaming y ofrece dos voces documentadas en este checkpoint abierto exacto.
Esta descripción cubre las capacidades del modelo. Las entradas, salidas y opciones disponibles en Ailoot se indican a continuación para el método seleccionado.
Descripción general: un modelo para varias modalidades de entrada
Qwen2.5-Omni-7B es el modelo multimodal de extremo a extremo de Qwen para texto, imágenes, audio y video. Puede comprender estas entradas en conjunto y generar texto con voz natural en un flujo de trabajo por streaming. Úsalo cuando una tarea dependa tanto de lo visible como de lo audible, o cuando el usuario dé la instrucción por voz en lugar de escribirla. Este es el checkpoint 7B exacto; el producto comercial Omni-Turbo y las versiones posteriores de Omni tienen sus propios contratos.
Funciones principales y arquitectura
El diseño Thinker-Talker combina comprensión y generación de voz. Thinker procesa la tarea multimodal y produce contenido textual, mientras que Talker participa en la formación de la respuesta hablada. TMRoPE, el esquema posicional multimodal del fabricante alineado en el tiempo, sincroniza las marcas de tiempo del video con el audio. La arquitectura está diseñada para entradas por fragmentos e interacción ágil por voz o video; este objetivo de diseño no es una garantía de tiempo de respuesta fijo para todas las interfaces.
La cobertura de tareas del fabricante incluye reconocimiento de voz, traducción del habla, comprensión de audio, razonamiento sobre imágenes, comprensión de video y generación de voz. Por lo tanto, las instrucciones habladas pueden participar directamente en una pregunta multimodal sin requerir siempre una transcripción escrita proporcionada por separado. Mantén clara la tarea objetivo: comprender un clip de audio, responder una pregunta hablada y generar una respuesta hablada son usos distintos, aunque el modelo admita todas sus formas de entrada o salida.
Preparación de una conversación multimodal
Proporciona los medios pertinentes e indica cómo debe relacionarlos la respuesta. Para una demostración narrada, pide al modelo que distinga los pasos visibles de la explicación del hablante e identifique dónde coinciden. Para una imagen acompañada de una pregunta en audio, identifica el papel de la imagen y solicita una respuesta concisa basada en el contenido visible. Para un fragmento solo de audio, indica si el objetivo es reconocer el habla, explicar sonidos o responder una pregunta sobre el contenido. Estas son aplicaciones propuestas de la cobertura de tareas documentada.
Los ejemplos del fabricante muestran conversaciones solo de texto, solo de audio, solo de video y con medios combinados. Conserva el orden y los tiempos originales de un video. Etiqueta los recursos separados para que el modelo pueda referirse a ellos sin tratar evidencia sin relación como un solo evento. El resultado puede ser únicamente texto o texto con voz; elige el artefacto útil antes de preparar la solicitud.
Preparación de la salida de voz
La receta del checkpoint de Qwen requiere su prompt de sistema documentado sobre capacidades de audio cuando se necesita salida de voz. El prompt identifica a Qwen y sus capacidades auditivas, visuales, textuales y de habla; un reemplazo sin relación puede impedir el comportamiento de audio esperado. Esta es una orientación para el flujo de trabajo del checkpoint del fabricante, no una afirmación de que todas las aplicaciones expongan controles de prompt de sistema o generación de audio.
El checkpoint exacto ofrece dos voces: Chelsie, una voz femenina cálida, y Ethan, una voz masculina animada. Chelsie es la predeterminada documentada cuando no se selecciona un hablante. Su ejemplo de generación escribe la voz con una frecuencia de muestreo de 24,000 Hz. Estas dos voces no deben sustituirse por la descripción de cuatro voces de un modelo comercial con otro nombre.
Uso del audio de un video
La pista de audio de un video puede ser pertinente para su significado, como instrucciones habladas o un sonido producido por una acción visible. Qwen expone use_audio_in_video en la preparación de medios, el procesamiento y la generación. El ajuste debe mantenerse coherente en las tres etapas y durante una conversación de varios turnos; los ajustes inconsistentes pueden producir resultados inesperados. Por lo tanto, una interpretación solo visual de un video es distinta de una interpretación audiovisual, aunque el archivo sea el mismo.
Salida solo de texto y procesamiento por lotes
El fabricante admite salida solo de texto mediante return_audio=False. También permite desactivar Talker después de la carga, lo que reduce la memoria de GPU aproximadamente 2 GB, pero deja la salida de audio sin disponibilidad en esa instancia. El ejemplo documentado de procesamiento por lotes con muestras mixtas requiere return_audio=False y combina solicitudes de texto, imágenes, audio y video. Ese ejemplo por lotes no debe convertirse en una afirmación de generación de voz por lotes.
Contexto y límites sustantivos
La configuración de la base textual del checkpoint establece las posiciones máximas en 32,768. El texto, los medios representados y las respuestas generadas consumen espacio de secuencia; este valor no define de manera independiente una duración universal de audio o video. Los ejemplos de recursos del fabricante muestran que un video más largo necesita mucha más memoria, por lo que un clip breve y pertinente suele ser más práctico que una grabación extensa sin relación. Sus ejemplos no publican un máximo estricto de longitud de respuesta independiente ni una duración de medios garantizada universalmente.
Verifica las citas textuales del audio y las conclusiones contra la fuente, conserva suficiente detalle visual para la pregunta y mantén un resultado textual cuando una persona revisora necesite inspeccionar la explicación hablada. El valor documentado del modelo es la comprensión conjunta y la respuesta en texto o voz, mientras que los controles exactos de voz, el procesamiento de medios y la entrega de la salida siguen siendo funciones de la interfaz elegida.
POST /v1/chat/completionstexttext| Campo | Tipo | Requisito | Valores y límites | Predeterminado |
|---|---|---|---|---|
Campomodel | Tipostring | RequisitoObligatorio | Valores y límites qwen2.5-omni-7b | Predeterminado— |
Campomessages | Tipomessage[] | RequisitoObligatorio | Valores y límites Número mínimo de elementos: 1 | Predeterminado— |
Campomessages[].role | Tipostring | RequisitoObligatorio | Valores y límites Ejemplos: system, user, assistant, tool, function Condiciones: Estos roles están representados explícitamente por los tipos de compatibilidad del código fuente; el conjunto exacto de roles depende del modelo. Depende del modelo | Predeterminado— |
Campomessages[].content | Tipostring|content_part[]|null | RequisitoOpcional | Valores y límites | Predeterminado— |
Campomessages[].tool_calls | Tipotool_call[] | RequisitoOpcional | Valores y límites | Predeterminado— |
Campomessages[].tool_call_id | Tipostring | RequisitoOpcional | Valores y límites Se aplica cuando: role=tool; utiliza el ID real devuelto | Predeterminado— |
Campomessages[].name | Tipostring | RequisitoOpcional | Valores y límites | Predeterminado— |
Campomessages[].reasoning_content | Tipostring | RequisitoOpcional | Valores y límites Se aplica cuando: Devuelve en los turnos siguientes el razonamiento realmente recibido cuando este modelo lo utilice | Predeterminado— |
Campomessages[].reasoning_details | Tipoobject|array | RequisitoOpcional | Valores y límites Depende del modelo | Predeterminado— |
Campomax_tokens | Tipointeger | RequisitoOpcional | Valores y límites Mínimo: 1 Depende del modelo | Predeterminado— |
Campomax_completion_tokens | Tipointeger | RequisitoOpcional | Valores y límites Mínimo: 1 Depende del modelo | Predeterminado— |
Campostream | Tipoboolean | RequisitoOpcional | Valores y límites | Predeterminadofalse |
Campostream_options.include_usage | Tipoboolean | RequisitoOpcional | Valores y límites Depende del modelo | Predeterminado— |
Campotemperature | Tiponumber | RequisitoOpcional | Valores y límites Depende del modelo | Predeterminado— |
Campotop_p | Tiponumber | RequisitoOpcional | Valores y límites Depende del modelo | Predeterminado— |
Campostop | Tipostring|string[] | RequisitoOpcional | Valores y límites Depende del modelo | Predeterminado— |
Campotools | Tipofunction_tool[] | RequisitoOpcional | Valores y límites Depende del modelo | Predeterminado— |
Campotools[].type | Tipostring | RequisitoOpcional | Valores y límites function Depende del modelo | Predeterminado— |
Campotools[].function.name | Tipostring | RequisitoObligatorio | Valores y límites Se aplica cuando: herramienta de función proporcionada | Predeterminado— |
Campotools[].function.description | Tipostring | RequisitoOpcional | Valores y límites | Predeterminado— |
Campotools[].function.parameters | TipoJSON_schema | RequisitoOpcional | Valores y límites | Predeterminado— |
Campotool_choice | Tipostring|object | RequisitoOpcional | Valores y límites Depende del modelo | Predeterminado— |
Campoparallel_tool_calls | Tipoboolean | RequisitoOpcional | Valores y límites Depende del modelo | Predeterminado— |
Camporesponse_format | Tipoobject | RequisitoOpcional | Valores y límites Depende del modelo | Predeterminado— |
Camporeasoning_effort | Tipostring | RequisitoOpcional | Valores y límites Depende del modelo | Predeterminado— |
Camporeasoning | Tipoobject | RequisitoOpcional | Valores y límites Depende del modelo | Predeterminado— |
Camposervice_tier | Tipostring | RequisitoOpcional | Valores y límites Depende del modelo | Predeterminado— |
Campoinstructions | Tipostring | RequisitoOpcional | Valores y límites Campo de compatibilidad | Predeterminado— |
Campofunctions | Tipofunction[] | RequisitoOpcional | Valores y límites Depende del modelo | Predeterminado— |
Campofunction_call | Tipostring|object | RequisitoOpcional | Valores y límites Depende del modelo | Predeterminado— |
Campoprompt_cache_options | Tipoobject | RequisitoOpcional | Valores y límites Depende del modelo | Predeterminado— |
Campomodalities | Tipostring[] | RequisitoOpcional | Valores y límites text | Predeterminado— |
Campoprovider | Tipoobject | RequisitoOpcional | Valores y límites Condiciones: provider.options se rechaza en esta ruta de texto Ultra | Predeterminado— |
Campocache_control.ttl | Tipostring | RequisitoOpcional | Valores y límites Condiciones: 1h se rechaza en los campos reales de caché de instrucciones | Predeterminado— |
Texto · Texto UTF8
messages[].content
| Parámetro | Contrato |
|---|---|
Parámetrocontent_type | Contratoapplication/json |
Parámetrorequired | Contratomodel, messages |
Parámetromaterial_types | Contratotext |
Parámetromessages | Contratomatriz de mensajes con estructura role/content |
Parámetrofile_material | Contratodocumento real en UTF-8 insertado como texto literal; no se deduce ningún ID de archivo |
Parámetrooptional_controls | Contratostream, temperature, top_p, stop, max_tokens, max_completion_tokens, reasoning, response_format, tools, tool_choice |
Parámetrocontrol_scope | Contratodepende del modelo; las herramientas de funciones del usuario difieren de las herramientas alojadas |
Parámetrooutput_modalities | Contratotext |
Parámetrohosted_operations | Contratofalse |
Parámetromultimodal_input_binding | Contratonull |
Ciclo de vida: synchronous_or_streamed
Envía el ID exacto del modelo junto con messages.
La longitud del contexto no es un límite máximo de salida.
Un archivo de texto puede aportar texto literal; las entradas de imagen, audio u objetos de archivo requieren una vinculación exacta.
Las referencias tarifarias no añaden opciones a la solicitud. Los parámetros admitidos se indican en el método seleccionado.
| Configuración | Tabla de tarifas | Cargo |
|---|---|---|
| ConfiguraciónTarifas base por token | Tabla de tarifasTarifa base | Cargo Entrada · Tokens de entrada $0.0046 / 1K tokens Salida · Tokens de salida $0.0138 / 1K tokens Entrada · Lectura de caché $0 / 1K tokens Entrada · Escritura en caché $0 / 1K tokens Entrada · Escritura en caché, 1 hora — / 1K tokens |
Ailoot reserva un monto estimado antes de la solicitud. Tras obtener el resultado, liquida el cargo definitivo según el uso medido. En las respuestas en flujo, la liquidación usa el registro de uso final. Cómo funcionan la reserva y la liquidación →
set -eu\n: "${AILOOT_API_KEY:?Set your Ailoot API key}"\npython3 - <<'PY_REQUEST'\nimport json,os\nfrom pathlib import Path\np=json.loads('{"model": "qwen2.5-omni-7b", "messages": [{"role": "user", "content": "Explain the difference between an observation and a hypothesis in three sentences."}]}')\n\nPath("request.json").write_text(json.dumps(p,ensure_ascii=False))\nPY_REQUEST\ncurl --fail-with-body --silent --show-error https://api.ailoot.ai/v1/chat/completions \\\n -H "Authorization: Bearer $AILOOT_API_KEY" -H 'Content-Type: application/json' \\\n --data-binary @request.json -D response-headers.txt -o result.json\npython3 - <<'PY_RESULT'\nimport json\nfrom pathlib import Path\nr=json.loads(Path("result.json").read_text())\nfor x in r.get("choices",[]):\n if x.get("message",{}).get("content"): print(x["message"]["content"])\nPY_RESULT\nfrom openai import OpenAI\nimport os\n\nif not os.environ.get("AILOOT_API_KEY", "").strip(): raise SystemExit("Set AILOOT_API_KEY before making a request")\nclient=OpenAI(base_url="https://api.ailoot.ai/v1",api_key=os.environ["AILOOT_API_KEY"],max_retries=0)\nresult=client.chat.completions.create(model='qwen2.5-omni-7b',messages=[{"role":"user","content":"Explain observations and hypotheses in three sentences."}])\nimport base64, json\nfrom pathlib import Path\n\ndef save_result(data, stem="result"):\n # Keep every field, including usage, IDs, reasoning and tool requests.\n Path(stem + ".json").write_text(json.dumps(data, ensure_ascii=False, indent=2), encoding="utf-8")\n print(json.dumps(data, ensure_ascii=False, indent=2))\n def save_blob(encoded, suffix, label):\n raw = base64.b64decode(encoded, altchars=b"-_", validate=True)\n ext = "png" if raw.startswith(b"\\x89PNG\\r\\n\\x1a\\n") else "jpg" if raw.startswith(b"\\xff\\xd8") else "webp" if raw[:4] == b"RIFF" and raw[8:12] == b"WEBP" else suffix\n file = Path(stem + "-" + label + "." + ext)\n file.write_bytes(raw)\n print("Saved", file)\n for index, block in enumerate(data.get("content") or []):\n print("Content", index, json.dumps(block, ensure_ascii=False))\n for choice in data.get("choices") or []:\n print("Choice", choice.get("index"), json.dumps(choice.get("message", choice.get("delta", {})), ensure_ascii=False))\n for index, item in enumerate(data.get("output") or []):\n print("Output", index, json.dumps(item, ensure_ascii=False))\n if item.get("type") == "image_generation_call" and item.get("result"):\n save_blob(item["result"], item.get("output_format") or "bin", "output-" + str(index))\n for ci, candidate in enumerate(data.get("candidates") or []):\n for pi, part in enumerate((candidate.get("content") or {}).get("parts") or []):\n print("Candidate/part", ci, pi, json.dumps(part, ensure_ascii=False))\n blob = part.get("inlineData") or part.get("inline_data")\n if blob and blob.get("data"):\n mime = blob.get("mimeType") or blob.get("mime_type")\n suffix = {"image/png":"png", "image/jpeg":"jpg", "image/webp":"webp", "audio/wav":"wav", "audio/mpeg":"mp3", "video/mp4":"mp4"}.get(mime, "bin")\n save_blob(blob["data"], suffix, "candidate-" + str(ci) + "-part-" + str(pi))\n\nsave_result(result.to_dict(mode="json"))\nfrom openai import OpenAI\nimport os\nfrom pathlib import Path\n\nif not os.environ.get("AILOOT_API_KEY", "").strip(): raise SystemExit("Set AILOOT_API_KEY before making a request")\nclient=OpenAI(base_url="https://api.ailoot.ai/v1",api_key=os.environ["AILOOT_API_KEY"],max_retries=0)\nimport base64, json\nfrom pathlib import Path\n\ndef save_result(data, stem="result"):\n # Keep every field, including usage, IDs, reasoning and tool requests.\n Path(stem + ".json").write_text(json.dumps(data, ensure_ascii=False, indent=2), encoding="utf-8")\n print(json.dumps(data, ensure_ascii=False, indent=2))\n def save_blob(encoded, suffix, label):\n raw = base64.b64decode(encoded, altchars=b"-_", validate=True)\n ext = "png" if raw.startswith(b"\\x89PNG\\r\\n\\x1a\\n") else "jpg" if raw.startswith(b"\\xff\\xd8") else "webp" if raw[:4] == b"RIFF" and raw[8:12] == b"WEBP" else suffix\n file = Path(stem + "-" + label + "." + ext)\n file.write_bytes(raw)\n print("Saved", file)\n for index, block in enumerate(data.get("content") or []):\n print("Content", index, json.dumps(block, ensure_ascii=False))\n for choice in data.get("choices") or []:\n print("Choice", choice.get("index"), json.dumps(choice.get("message", choice.get("delta", {})), ensure_ascii=False))\n for index, item in enumerate(data.get("output") or []):\n print("Output", index, json.dumps(item, ensure_ascii=False))\n if item.get("type") == "image_generation_call" and item.get("result"):\n save_blob(item["result"], item.get("output_format") or "bin", "output-" + str(index))\n for ci, candidate in enumerate(data.get("candidates") or []):\n for pi, part in enumerate((candidate.get("content") or {}).get("parts") or []):\n print("Candidate/part", ci, pi, json.dumps(part, ensure_ascii=False))\n blob = part.get("inlineData") or part.get("inline_data")\n if blob and blob.get("data"):\n mime = blob.get("mimeType") or blob.get("mime_type")\n suffix = {"image/png":"png", "image/jpeg":"jpg", "image/webp":"webp", "audio/wav":"wav", "audio/mpeg":"mp3", "video/mp4":"mp4"}.get(mime, "bin")\n save_blob(blob["data"], suffix, "candidate-" + str(ci) + "-part-" + str(pi))\n\nwith client.chat.completions.stream(model='qwen2.5-omni-7b',messages=[{"role":"user","content":"Explain observations and hypotheses in three sentences."}]) as stream:\n with Path("stream-events.jsonl").open("w",encoding="utf-8") as log:\n for event in stream:\n payload=event.to_dict(mode="json")\n log.write(json.dumps(payload,ensure_ascii=False)+"\\n"); log.flush()\n print(json.dumps(payload,ensure_ascii=False))\n final=stream.get_final_completion()\n save_result(final.to_dict(mode="json"),"stream-result")\njson o SSE
Conserva todas las respuestas, archivos y partes de contenido completos recibidos.
Conserva cada alternativa y su contenido, llamadas de herramientas y razonamiento. En SSE, ensambla los fragmentos incrementales por índice de alternativa/herramienta y conserva el motivo final de terminación y el uso.
Conserva los ID de solicitud y respuesta y los encabezados. No se proporciona una URL genérica para recuperar tareas de texto.
| Campo | Tipo |
|---|---|
Campochoices[].index | Tipointeger |
Campochoices[].message.content | Tipostring|null |
Campochoices[].message.tool_calls | Tipotool_call[] |
Campochoices[].message.reasoning_content | Tipostring |
Campochoices[].message.reasoning_details | Tipoobject|array |
Campochoices[].finish_reason | Tipostring|null |
Campousage | Tipoobject |
| Respuesta | Condición | Siguiente paso |
|---|---|---|
Respuesta400 · invalid_request_error | CondiciónCampos obligatorios, representación del material o valor del parámetro no válidos | Siguiente pasoCorrige los campos indicados antes de una nueva solicitud de creación. |
Ailoot Ultra qwen2.5-omni-7b
Usa las rutas de método indicadas arriba.
qwen2.5-omni-7bQwen2.5-Omni-7B combina comprensión de texto, imágenes, audio y video con salida de texto y voz natural. Su arquitectura Thinker-Talker alinea el audio con los tiempos del video, admite interacción por streaming y ofrece dos voces documentadas en este checkpoint abierto exacto.
Esta descripción cubre las capacidades del modelo. Las entradas, salidas y opciones disponibles en Ailoot se indican a continuación para el método seleccionado.
Descripción general: un modelo para varias modalidades de entrada
Qwen2.5-Omni-7B es el modelo multimodal de extremo a extremo de Qwen para texto, imágenes, audio y video. Puede comprender estas entradas en conjunto y generar texto con voz natural en un flujo de trabajo por streaming. Úsalo cuando una tarea dependa tanto de lo visible como de lo audible, o cuando el usuario dé la instrucción por voz en lugar de escribirla. Este es el checkpoint 7B exacto; el producto comercial Omni-Turbo y las versiones posteriores de Omni tienen sus propios contratos.
Funciones principales y arquitectura
El diseño Thinker-Talker combina comprensión y generación de voz. Thinker procesa la tarea multimodal y produce contenido textual, mientras que Talker participa en la formación de la respuesta hablada. TMRoPE, el esquema posicional multimodal del fabricante alineado en el tiempo, sincroniza las marcas de tiempo del video con el audio. La arquitectura está diseñada para entradas por fragmentos e interacción ágil por voz o video; este objetivo de diseño no es una garantía de tiempo de respuesta fijo para todas las interfaces.
La cobertura de tareas del fabricante incluye reconocimiento de voz, traducción del habla, comprensión de audio, razonamiento sobre imágenes, comprensión de video y generación de voz. Por lo tanto, las instrucciones habladas pueden participar directamente en una pregunta multimodal sin requerir siempre una transcripción escrita proporcionada por separado. Mantén clara la tarea objetivo: comprender un clip de audio, responder una pregunta hablada y generar una respuesta hablada son usos distintos, aunque el modelo admita todas sus formas de entrada o salida.
Preparación de una conversación multimodal
Proporciona los medios pertinentes e indica cómo debe relacionarlos la respuesta. Para una demostración narrada, pide al modelo que distinga los pasos visibles de la explicación del hablante e identifique dónde coinciden. Para una imagen acompañada de una pregunta en audio, identifica el papel de la imagen y solicita una respuesta concisa basada en el contenido visible. Para un fragmento solo de audio, indica si el objetivo es reconocer el habla, explicar sonidos o responder una pregunta sobre el contenido. Estas son aplicaciones propuestas de la cobertura de tareas documentada.
Los ejemplos del fabricante muestran conversaciones solo de texto, solo de audio, solo de video y con medios combinados. Conserva el orden y los tiempos originales de un video. Etiqueta los recursos separados para que el modelo pueda referirse a ellos sin tratar evidencia sin relación como un solo evento. El resultado puede ser únicamente texto o texto con voz; elige el artefacto útil antes de preparar la solicitud.
Preparación de la salida de voz
La receta del checkpoint de Qwen requiere su prompt de sistema documentado sobre capacidades de audio cuando se necesita salida de voz. El prompt identifica a Qwen y sus capacidades auditivas, visuales, textuales y de habla; un reemplazo sin relación puede impedir el comportamiento de audio esperado. Esta es una orientación para el flujo de trabajo del checkpoint del fabricante, no una afirmación de que todas las aplicaciones expongan controles de prompt de sistema o generación de audio.
El checkpoint exacto ofrece dos voces: Chelsie, una voz femenina cálida, y Ethan, una voz masculina animada. Chelsie es la predeterminada documentada cuando no se selecciona un hablante. Su ejemplo de generación escribe la voz con una frecuencia de muestreo de 24,000 Hz. Estas dos voces no deben sustituirse por la descripción de cuatro voces de un modelo comercial con otro nombre.
Uso del audio de un video
La pista de audio de un video puede ser pertinente para su significado, como instrucciones habladas o un sonido producido por una acción visible. Qwen expone use_audio_in_video en la preparación de medios, el procesamiento y la generación. El ajuste debe mantenerse coherente en las tres etapas y durante una conversación de varios turnos; los ajustes inconsistentes pueden producir resultados inesperados. Por lo tanto, una interpretación solo visual de un video es distinta de una interpretación audiovisual, aunque el archivo sea el mismo.
Salida solo de texto y procesamiento por lotes
El fabricante admite salida solo de texto mediante return_audio=False. También permite desactivar Talker después de la carga, lo que reduce la memoria de GPU aproximadamente 2 GB, pero deja la salida de audio sin disponibilidad en esa instancia. El ejemplo documentado de procesamiento por lotes con muestras mixtas requiere return_audio=False y combina solicitudes de texto, imágenes, audio y video. Ese ejemplo por lotes no debe convertirse en una afirmación de generación de voz por lotes.
Contexto y límites sustantivos
La configuración de la base textual del checkpoint establece las posiciones máximas en 32,768. El texto, los medios representados y las respuestas generadas consumen espacio de secuencia; este valor no define de manera independiente una duración universal de audio o video. Los ejemplos de recursos del fabricante muestran que un video más largo necesita mucha más memoria, por lo que un clip breve y pertinente suele ser más práctico que una grabación extensa sin relación. Sus ejemplos no publican un máximo estricto de longitud de respuesta independiente ni una duración de medios garantizada universalmente.
Verifica las citas textuales del audio y las conclusiones contra la fuente, conserva suficiente detalle visual para la pregunta y mantén un resultado textual cuando una persona revisora necesite inspeccionar la explicación hablada. El valor documentado del modelo es la comprensión conjunta y la respuesta en texto o voz, mientras que los controles exactos de voz, el procesamiento de medios y la entrega de la salida siguen siendo funciones de la interfaz elegida.
POST /v1/messagestextjson, sse| Campo | Tipo | Requisito | Valores y límites | Predeterminado |
|---|---|---|---|---|
Campomodel | Tipostring | RequisitoObligatorio | Valores y límites qwen2.5-omni-7b | Predeterminado— |
Campomessages | Tipomessage[] | RequisitoObligatorio | Valores y límites | Predeterminado— |
Campomessages[].role | Tipostring | RequisitoObligatorio | Valores y límites user, assistant | Predeterminado— |
Campomessages[].content | Tipostring | RequisitoObligatorio | Valores y límites | Predeterminado— |
Campomax_tokens | Tipointeger | RequisitoObligatorio | Valores y límites | Predeterminado— |
Campostream | Tipoboolean | RequisitoOpcional | Valores y límites | Predeterminadofalse |
Texto · Texto UTF-8
cadena messages[].content
| Parámetro | Contrato |
|---|---|
Parámetrocontent_type | Contratoapplication/json |
Parámetrorequired | Contratomodel, messages, max_tokens |
Parámetrooptional_controls | Contratostream |
Parámetromaterial_types | Contratotext |
Parámetrotext_file_material | ContratoLee el documento real en UTF-8 y coloca su texto en el campo input indicado o en la cadena de contenido del mensaje. |
Ciclo de vida: synchronous_or_streamed
Las referencias tarifarias no añaden opciones a la solicitud. Los parámetros admitidos se indican en el método seleccionado.
| Configuración | Tabla de tarifas | Cargo |
|---|---|---|
| ConfiguraciónTarifas base por token | Tabla de tarifasTarifa base | Cargo Entrada · Tokens de entrada $0.0046 / 1K tokens Salida · Tokens de salida $0.0138 / 1K tokens Entrada · Lectura de caché $0 / 1K tokens Entrada · Escritura en caché $0 / 1K tokens Entrada · Escritura en caché, 1 hora — / 1K tokens |
Ailoot reserva un monto estimado antes de la solicitud. Tras obtener el resultado, liquida el cargo definitivo según el uso medido. En las respuestas en flujo, la liquidación usa el registro de uso final. Cómo funcionan la reserva y la liquidación →
{\n "model": "qwen2.5-omni-7b",\n "max_tokens": 128,\n "messages": [\n {\n "role": "user",\n "content": "Summarize the incident report."\n }\n ],\n "stream": false\n}set -eu\n: "${AILOOT_API_KEY:?Set your Ailoot API key}"\n: "${AILOOT_TEXT_FILE:?Set your actual UTF-8 document}"\nexport AILOOT_TEXT_FILE\npython3 - <<'PY_REQUEST'\nimport json, os\nfrom pathlib import Path\n\nsource_file = Path(os.environ['AILOOT_TEXT_FILE'])\nif not source_file.is_file():\n raise SystemExit('Set AILOOT_TEXT_FILE to your actual UTF-8 document')\ntext = source_file.read_text(encoding='utf-8')\nif not text.strip():\n raise SystemExit('Choose a document containing text')\npayload = {'model': 'qwen2.5-omni-7b', 'max_tokens': 128, 'messages': [{'role': 'user', 'content': 'Summarize the incident report.'}]}\npayload['messages'][0]['content'] = 'Summarize this material and quote supporting source passages.\\n\\n' + text\nPath('request.json').write_text(json.dumps(payload, ensure_ascii=False), encoding='utf-8')\nPY_REQUEST\ncurl --fail-with-body --silent --show-error https://api.ailoot.ai/v1/messages \\\n -H "x-api-key: $AILOOT_API_KEY" -H 'anthropic-version: 2023-06-01' -H 'Content-Type: application/json' \\\n --data-binary @request.json -D response-headers.txt -o result.json\npython3 - <<'PY_RESULT'\nimport json\nfrom pathlib import Path\n\nresult = json.loads(Path('result.json').read_text(encoding='utf-8'))\nprint(json.dumps(result, ensure_ascii=False, indent=2))\nPY_RESULT\nimport json, os\nfrom pathlib import Path\n\nsource_file = Path(os.environ['AILOOT_TEXT_FILE'])\nif not source_file.is_file():\n raise SystemExit('Set AILOOT_TEXT_FILE to your actual UTF-8 document')\ntext = source_file.read_text(encoding='utf-8')\nif not text.strip():\n raise SystemExit('Choose a document containing text')\npayload = {'model': 'qwen2.5-omni-7b', 'max_tokens': 128, 'messages': [{'role': 'user', 'content': 'Summarize the incident report.'}]}\npayload['messages'][0]['content'] = 'Summarize this material and quote supporting source passages.\\n\\n' + text\nfrom urllib.request import Request, urlopen\nfrom urllib.error import HTTPError\n\napi_key = os.environ['AILOOT_API_KEY']\nif not api_key.strip():\n raise SystemExit('Set AILOOT_API_KEY before making a request')\nheaders = {'x-api-key': 'PLACEHOLDER_KEY', 'anthropic-version': '2023-06-01', 'Content-Type': 'application/json'}\nheaders['x-api-key'] = api_key\nrequest = Request('https://api.ailoot.ai/v1/messages', data=json.dumps(payload, ensure_ascii=False).encode('utf-8'), headers=headers, method='POST')\ntry:\n with urlopen(request, timeout=120) as response:\n raw = response.read()\n Path('response-headers.txt').write_text(str(response.headers), encoding='utf-8')\nexcept HTTPError as error:\n Path('result.json').write_bytes(error.read())\n Path('response-headers.txt').write_text(str(error.headers), encoding='utf-8')\n raise\nPath('result.json').write_bytes(raw)\nimport json\nfrom pathlib import Path\n\nresult = json.loads(Path('result.json').read_text(encoding='utf-8'))\nprint(json.dumps(result, ensure_ascii=False, indent=2))\nJSON o SSE
Conserva todas las respuestas, archivos y partes de contenido completos recibidos.
Conserva todos los bloques de contenido, las firmas de razonamiento y los ID reales de uso de herramientas. Ensambla todos los fragmentos incrementales de los bloques SSE; el primer bloque de texto no constituye la salida completa.
Conserva los ID de solicitud y respuesta y los encabezados. No se proporciona una URL genérica para recuperar tareas de texto.
| Campo | Tipo |
|---|---|
Campoid | Tipostring |
Campomodel | Tipostring |
Campocontent[] | Tipotext|thinking|tool_use|other content block |
Campostop_reason | Tipostring|null |
Campousage | Tipoobject |
| Respuesta | Condición | Siguiente paso |
|---|---|---|
Respuesta400 · invalid_request_error | CondiciónCampos obligatorios, representación del material o valor del parámetro no válidos | Siguiente pasoCorrige los campos indicados antes de una nueva solicitud de creación. |
Ailoot Ultra qwen2.5-omni-7b
Usa las rutas de método indicadas arriba.
Ejemplo técnico en inglés
Compare demonstration notes with narration\n\nCompare two text records of demonstration M2. Visual notes: 'Operator closes the lid, then presses Start.' Narration transcript: 'Press Start before closing the lid.' Identify the sequence disagreement and write one clarification question for the instructor. Use only these supplied records; do not claim to have watched or heard a clip.A source-linked sequence comparison and one targeted clarification question.The answer must preserve the opposing event order and avoid inventing a resolution.