GLM-4-32B-0414 es la edición fija de texto de la clase 32B de la serie GLM-4-0414 de Z.ai. Su base se preentrenó con 15 billones de tokens, incluido material de razonamiento sintético. El entrenamiento posterior combina alineación de preferencias de diálogo, muestreo por rechazo y aprendizaje por refuerzo para desarrollar seguimiento de instrucciones, código de ingeniería y llamadas a funciones. Su trabajo declarado incluye tareas de software, artefactos de texto, preguntas basadas en búsquedas e informes. La entrada y la salida son texto; el código generado se convierte en un artefacto ejecutable o renderizado cuando la aplicación lo guarda y ejecuta.
GLM-Z1-32B-0414, centrado en razonamiento, y el modelo Rumination, orientado a investigación, son ediciones con nombres separados. Esta entrada sigue las demostraciones más amplias de código y herramientas del propio modelo GLM-4 en lugar de sustituirlas por las reglas de razonamiento de otra versión.
El fabricante muestra cómo programar una pelota que se mueve dentro de un hexágono giratorio. El ejemplo de GLM-4-32B-0414 usa HTML y describe el movimiento, las colisiones y los supuestos físicos. Es código para una simulación, no un modo de generación de video. Para preparar una tarea similar, proporciona la escena, las reglas de movimiento, el comportamiento de colisión y el entorno de ejecución previsto; después pide una implementación autocontenida y una explicación de los supuestos. La aplicación ejecuta ese código para inspeccionar el resultado.
Los ejemplos incluyen una interfaz de dibujo para gráficas de funciones personalizadas, con opciones para agregar y eliminar funciones y asignar colores. Otro ejemplo construye una interfaz móvil de aprendizaje automático con tareas de entrenamiento, administración de almacenamiento y estadísticas personales, incluidas gráficas, organizadas en una página HTML. Son tareas concretas de frontend con controles y estados especificados.
Para obtener una salida útil, describe las acciones que debe admitir cada control y los datos que debe mostrar la vista. Una solicitud de interfaz puede pedir el código de la página junto con la relación entre la entrada, el estado mostrado y el resultado. Un turno posterior puede proporcionar el renderizado observado y pedir un cambio específico que conserve el comportamiento enumerado.
El fabricante también muestra ilustraciones SVG, incluidos un paisaje y una explicación del proceso de entrenamiento de un modelo de lenguaje. SVG es texto estructurado, así que la aplicación puede guardarlo como un artefacto vectorial editable. Proporciona el tema, las etiquetas, la disposición y las relaciones visuales requeridas. Pide el marcado SVG como un entregable separado en lugar de mezclar el código de la ilustración con una explicación larga sin relación.
Para escritura de investigación, la tarjeta proporciona resultados de búsqueda como observaciones y pide al modelo que los organice e interprete en vez de copiarlos. Sus instrucciones distinguen los resultados pertinentes de los irrelevantes, favorecen los detalles significativos cuando la evidencia lo permite, usan una estructura legible y responden en el idioma del usuario. El ejemplo produce un informe analítico sobre literatura infantil que abarca métodos narrativos, temas y sus efectos.
Una tarea práctica puede proporcionar fragmentos identificados y pedir un informe organizado en torno a preguntas explícitas, con cada conclusión vinculada al material que la respalda. La búsqueda y la recuperación ocurren en la aplicación que lo integra; los pasajes devueltos se convierten en la evidencia del modelo. Esto también resulta útil para comparar documentos o preparar una explicación a partir de una colección de investigación proporcionada.
GLM-4-32B-0414 admite llamadas a herramientas externas con argumentos JSON. El modelo identifica una función y sus argumentos, la aplicación la ejecuta y el resultado se devuelve como una observación. La demostración del fabricante repite ese ciclo hasta producir una respuesta final. Describe el propósito y los campos requeridos de cada herramienta y distingue su observación de la instrucción del usuario. Así, una consulta puede proporcionar datos para una comparación posterior sin fingir que el modelo obtuvo información en vivo por su cuenta.
La configuración publicada establece max_position_embeddings en 32,768 y no incluye una entrada rope_scaling. Los ejemplos desarrollados del fabricante usan longitudes de generación específicas de cada solicitud; la tarjeta no indica un máximo estricto universal de salida. Mantén el código pertinente, los pasajes recuperados y el diálogo dentro del contexto activo, e indica si el resultado final debe ser HTML, SVG, un fragmento de código, argumentos JSON o un informe. Son representaciones de texto producidas para la tarea descrita; la ejecución, la creación de archivos y el acceso a datos externos siguen siendo acciones de la aplicación.
", "aboutText": "### Introducción\n\nGLM-4-32B-0414 es la edición fija de texto de la clase 32B de la serie GLM-4-0414 de Z.ai. Su base se preentrenó con 15 billones de tokens, incluido material de razonamiento sintético. El entrenamiento posterior combina alineación de preferencias de diálogo, muestreo por rechazo y aprendizaje por refuerzo para desarrollar seguimiento de instrucciones, código de ingeniería y llamadas a funciones. Su trabajo declarado incluye tareas de software, artefactos de texto, preguntas basadas en búsquedas e informes. La entrada y la salida son texto; el código generado se convierte en un artefacto ejecutable o renderizado cuando la aplicación lo guarda y ejecuta.\n\nGLM-Z1-32B-0414, centrado en razonamiento, y el modelo Rumination, orientado a investigación, son ediciones con nombres separados. Esta entrada sigue las demostraciones más amplias de código y herramientas del propio modelo GLM-4 en lugar de sustituirlas por las reglas de razonamiento de otra versión.\n\n### Demostración: generación de animaciones\n\nEl fabricante muestra cómo programar una pelota que se mueve dentro de un hexágono giratorio. El ejemplo de GLM-4-32B-0414 usa HTML y describe el movimiento, las colisiones y los supuestos físicos. Es código para una simulación, no un modo de generación de video. Para preparar una tarea similar, proporciona la escena, las reglas de movimiento, el comportamiento de colisión y el entorno de ejecución previsto; después pide una implementación autocontenida y una explicación de los supuestos. La aplicación ejecuta ese código para inspeccionar el resultado.\n\n### Demostración: diseño web\n\nLos ejemplos incluyen una interfaz de dibujo para gráficas de funciones personalizadas, con opciones para agregar y eliminar funciones y asignar colores. Otro ejemplo construye una interfaz móvil de aprendizaje automático con tareas de entrenamiento, administración de almacenamiento y estadísticas personales, incluidas gráficas, organizadas en una página HTML. Son tareas concretas de frontend con controles y estados especificados.\n\nPara obtener una salida útil, describe las acciones que debe admitir cada control y los datos que debe mostrar la vista. Una solicitud de interfaz puede pedir el código de la página junto con la relación entre la entrada, el estado mostrado y el resultado. Un turno posterior puede proporcionar el renderizado observado y pedir un cambio específico que conserve el comportamiento enumerado.\n\n### Demostración: generación de SVG\n\nEl fabricante también muestra ilustraciones SVG, incluidos un paisaje y una explicación del proceso de entrenamiento de un modelo de lenguaje. SVG es texto estructurado, así que la aplicación puede guardarlo como un artefacto vectorial editable. Proporciona el tema, las etiquetas, la disposición y las relaciones visuales requeridas. Pide el marcado SVG como un entregable separado en lugar de mezclar el código de la ilustración con una explicación larga sin relación.\n\n### Escritura basada en búsquedas\n\nPara escritura de investigación, la tarjeta proporciona resultados de búsqueda como observaciones y pide al modelo que los organice e interprete en vez de copiarlos. Sus instrucciones distinguen los resultados pertinentes de los irrelevantes, favorecen los detalles significativos cuando la evidencia lo permite, usan una estructura legible y responden en el idioma del usuario. El ejemplo produce un informe analítico sobre literatura infantil que abarca métodos narrativos, temas y sus efectos.\n\nUna tarea práctica puede proporcionar fragmentos identificados y pedir un informe organizado en torno a preguntas explícitas, con cada conclusión vinculada al material que la respalda. La búsqueda y la recuperación ocurren en la aplicación que lo integra; los pasajes devueltos se convierten en la evidencia del modelo. Esto también resulta útil para comparar documentos o preparar una explicación a partir de una colección de investigación proporcionada.\n\n### Llamadas a funciones\n\nGLM-4-32B-0414 admite llamadas a herramientas externas con argumentos JSON. El modelo identifica una función y sus argumentos, la aplicación la ejecuta y el resultado se devuelve como una observación. La demostración del fabricante repite ese ciclo hasta producir una respuesta final. Describe el propósito y los campos requeridos de cada herramienta y distingue su observación de la instrucción del usuario. Así, una consulta puede proporcionar datos para una comparación posterior sin fingir que el modelo obtuvo información en vivo por su cuenta.\n\n### Planificación del contexto y del resultado\n\nLa configuración publicada establece max_position_embeddings en 32,768 y no incluye una entrada rope_scaling. Los ejemplos desarrollados del fabricante usan longitudes de generación específicas de cada solicitud; la tarjeta no indica un máximo estricto universal de salida. Mantén el código pertinente, los pasajes recuperados y el diálogo dentro del contexto activo, e indica si el resultado final debe ser HTML, SVG, un fragmento de código, argumentos JSON o un informe. Son representaciones de texto producidas para la tarea descrita; la ejecución, la creación de archivos y el acceso a datos externos siguen siendo acciones de la aplicación.", "editorialOverlay": { "copy_fields": { "practical_html": "Ejemplo técnico en inglés
Generate an editable process diagram\n\nCreate self-contained SVG markup for a left-to-right process: Receive -> Validate -> Store. Use three labelled rectangles and two arrows; all labels must remain readable in a 720 by 180 viewBox. Use no scripts, external fonts or external images. Return SVG code and a brief explanation of how the arrows encode the required order.A standalone editable SVG code block with three named nodes and two directional arrows, followed by a short order explanation.Render the SVG locally and check the exact labels, arrow direction and absence of clipped text or external dependencies.THUDM/GLM-4-32B-0414GLM-4-32B-0414 es la edición fija de texto de Z.ai para código de ingeniería, artefactos interactivos HTML/SVG, informes basados en búsquedas y llamadas a funciones JSON. Su tarjeta de modelo muestra flujos concretos de desarrollo y un ciclo de herramientas controlado por la aplicación.
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.
GLM-4-32B-0414 es la edición fija de texto de la clase 32B de la serie GLM-4-0414 de Z.ai. Su base se preentrenó con 15 billones de tokens, incluido material de razonamiento sintético. El entrenamiento posterior combina alineación de preferencias de diálogo, muestreo por rechazo y aprendizaje por refuerzo para desarrollar seguimiento de instrucciones, código de ingeniería y llamadas a funciones. Su trabajo declarado incluye tareas de software, artefactos de texto, preguntas basadas en búsquedas e informes. La entrada y la salida son texto; el código generado se convierte en un artefacto ejecutable o renderizado cuando la aplicación lo guarda y ejecuta.
GLM-Z1-32B-0414, centrado en razonamiento, y el modelo Rumination, orientado a investigación, son ediciones con nombres separados. Esta entrada sigue las demostraciones más amplias de código y herramientas del propio modelo GLM-4 en lugar de sustituirlas por las reglas de razonamiento de otra versión.
El fabricante muestra cómo programar una pelota que se mueve dentro de un hexágono giratorio. El ejemplo de GLM-4-32B-0414 usa HTML y describe el movimiento, las colisiones y los supuestos físicos. Es código para una simulación, no un modo de generación de video. Para preparar una tarea similar, proporciona la escena, las reglas de movimiento, el comportamiento de colisión y el entorno de ejecución previsto; después pide una implementación autocontenida y una explicación de los supuestos. La aplicación ejecuta ese código para inspeccionar el resultado.
Los ejemplos incluyen una interfaz de dibujo para gráficas de funciones personalizadas, con opciones para agregar y eliminar funciones y asignar colores. Otro ejemplo construye una interfaz móvil de aprendizaje automático con tareas de entrenamiento, administración de almacenamiento y estadísticas personales, incluidas gráficas, organizadas en una página HTML. Son tareas concretas de frontend con controles y estados especificados.
Para obtener una salida útil, describe las acciones que debe admitir cada control y los datos que debe mostrar la vista. Una solicitud de interfaz puede pedir el código de la página junto con la relación entre la entrada, el estado mostrado y el resultado. Un turno posterior puede proporcionar el renderizado observado y pedir un cambio específico que conserve el comportamiento enumerado.
El fabricante también muestra ilustraciones SVG, incluidos un paisaje y una explicación del proceso de entrenamiento de un modelo de lenguaje. SVG es texto estructurado, así que la aplicación puede guardarlo como un artefacto vectorial editable. Proporciona el tema, las etiquetas, la disposición y las relaciones visuales requeridas. Pide el marcado SVG como un entregable separado en lugar de mezclar el código de la ilustración con una explicación larga sin relación.
Para escritura de investigación, la tarjeta proporciona resultados de búsqueda como observaciones y pide al modelo que los organice e interprete en vez de copiarlos. Sus instrucciones distinguen los resultados pertinentes de los irrelevantes, favorecen los detalles significativos cuando la evidencia lo permite, usan una estructura legible y responden en el idioma del usuario. El ejemplo produce un informe analítico sobre literatura infantil que abarca métodos narrativos, temas y sus efectos.
Una tarea práctica puede proporcionar fragmentos identificados y pedir un informe organizado en torno a preguntas explícitas, con cada conclusión vinculada al material que la respalda. La búsqueda y la recuperación ocurren en la aplicación que lo integra; los pasajes devueltos se convierten en la evidencia del modelo. Esto también resulta útil para comparar documentos o preparar una explicación a partir de una colección de investigación proporcionada.
GLM-4-32B-0414 admite llamadas a herramientas externas con argumentos JSON. El modelo identifica una función y sus argumentos, la aplicación la ejecuta y el resultado se devuelve como una observación. La demostración del fabricante repite ese ciclo hasta producir una respuesta final. Describe el propósito y los campos requeridos de cada herramienta y distingue su observación de la instrucción del usuario. Así, una consulta puede proporcionar datos para una comparación posterior sin fingir que el modelo obtuvo información en vivo por su cuenta.
La configuración publicada establece max_position_embeddings en 32,768 y no incluye una entrada rope_scaling. Los ejemplos desarrollados del fabricante usan longitudes de generación específicas de cada solicitud; la tarjeta no indica un máximo estricto universal de salida. Mantén el código pertinente, los pasajes recuperados y el diálogo dentro del contexto activo, e indica si el resultado final debe ser HTML, SVG, un fragmento de código, argumentos JSON o un informe. Son representaciones de texto producidas para la tarea descrita; la ejecución, la creación de archivos y el acceso a datos externos siguen siendo acciones de la aplicación.
POST /v1/chat/completionstexttext| Campo | Tipo | Requisito | Valores y límites | Predeterminado |
|---|---|---|---|---|
Campomodel | Tipostring | RequisitoObligatorio | Valores y límites THUDM/GLM-4-32B-0414 | 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.00014 / 1K tokens Salida · Tokens de salida $0.00014 / 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": "THUDM/GLM-4-32B-0414", "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='THUDM/GLM-4-32B-0414',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='THUDM/GLM-4-32B-0414',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 THUDM/GLM-4-32B-0414
Usa las rutas de método indicadas arriba.
THUDM/GLM-4-32B-0414GLM-4-32B-0414 es la edición fija de texto de Z.ai para código de ingeniería, artefactos interactivos HTML/SVG, informes basados en búsquedas y llamadas a funciones JSON. Su tarjeta de modelo muestra flujos concretos de desarrollo y un ciclo de herramientas controlado por la aplicación.
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.
GLM-4-32B-0414 es la edición fija de texto de la clase 32B de la serie GLM-4-0414 de Z.ai. Su base se preentrenó con 15 billones de tokens, incluido material de razonamiento sintético. El entrenamiento posterior combina alineación de preferencias de diálogo, muestreo por rechazo y aprendizaje por refuerzo para desarrollar seguimiento de instrucciones, código de ingeniería y llamadas a funciones. Su trabajo declarado incluye tareas de software, artefactos de texto, preguntas basadas en búsquedas e informes. La entrada y la salida son texto; el código generado se convierte en un artefacto ejecutable o renderizado cuando la aplicación lo guarda y ejecuta.
GLM-Z1-32B-0414, centrado en razonamiento, y el modelo Rumination, orientado a investigación, son ediciones con nombres separados. Esta entrada sigue las demostraciones más amplias de código y herramientas del propio modelo GLM-4 en lugar de sustituirlas por las reglas de razonamiento de otra versión.
El fabricante muestra cómo programar una pelota que se mueve dentro de un hexágono giratorio. El ejemplo de GLM-4-32B-0414 usa HTML y describe el movimiento, las colisiones y los supuestos físicos. Es código para una simulación, no un modo de generación de video. Para preparar una tarea similar, proporciona la escena, las reglas de movimiento, el comportamiento de colisión y el entorno de ejecución previsto; después pide una implementación autocontenida y una explicación de los supuestos. La aplicación ejecuta ese código para inspeccionar el resultado.
Los ejemplos incluyen una interfaz de dibujo para gráficas de funciones personalizadas, con opciones para agregar y eliminar funciones y asignar colores. Otro ejemplo construye una interfaz móvil de aprendizaje automático con tareas de entrenamiento, administración de almacenamiento y estadísticas personales, incluidas gráficas, organizadas en una página HTML. Son tareas concretas de frontend con controles y estados especificados.
Para obtener una salida útil, describe las acciones que debe admitir cada control y los datos que debe mostrar la vista. Una solicitud de interfaz puede pedir el código de la página junto con la relación entre la entrada, el estado mostrado y el resultado. Un turno posterior puede proporcionar el renderizado observado y pedir un cambio específico que conserve el comportamiento enumerado.
El fabricante también muestra ilustraciones SVG, incluidos un paisaje y una explicación del proceso de entrenamiento de un modelo de lenguaje. SVG es texto estructurado, así que la aplicación puede guardarlo como un artefacto vectorial editable. Proporciona el tema, las etiquetas, la disposición y las relaciones visuales requeridas. Pide el marcado SVG como un entregable separado en lugar de mezclar el código de la ilustración con una explicación larga sin relación.
Para escritura de investigación, la tarjeta proporciona resultados de búsqueda como observaciones y pide al modelo que los organice e interprete en vez de copiarlos. Sus instrucciones distinguen los resultados pertinentes de los irrelevantes, favorecen los detalles significativos cuando la evidencia lo permite, usan una estructura legible y responden en el idioma del usuario. El ejemplo produce un informe analítico sobre literatura infantil que abarca métodos narrativos, temas y sus efectos.
Una tarea práctica puede proporcionar fragmentos identificados y pedir un informe organizado en torno a preguntas explícitas, con cada conclusión vinculada al material que la respalda. La búsqueda y la recuperación ocurren en la aplicación que lo integra; los pasajes devueltos se convierten en la evidencia del modelo. Esto también resulta útil para comparar documentos o preparar una explicación a partir de una colección de investigación proporcionada.
GLM-4-32B-0414 admite llamadas a herramientas externas con argumentos JSON. El modelo identifica una función y sus argumentos, la aplicación la ejecuta y el resultado se devuelve como una observación. La demostración del fabricante repite ese ciclo hasta producir una respuesta final. Describe el propósito y los campos requeridos de cada herramienta y distingue su observación de la instrucción del usuario. Así, una consulta puede proporcionar datos para una comparación posterior sin fingir que el modelo obtuvo información en vivo por su cuenta.
La configuración publicada establece max_position_embeddings en 32,768 y no incluye una entrada rope_scaling. Los ejemplos desarrollados del fabricante usan longitudes de generación específicas de cada solicitud; la tarjeta no indica un máximo estricto universal de salida. Mantén el código pertinente, los pasajes recuperados y el diálogo dentro del contexto activo, e indica si el resultado final debe ser HTML, SVG, un fragmento de código, argumentos JSON o un informe. Son representaciones de texto producidas para la tarea descrita; la ejecución, la creación de archivos y el acceso a datos externos siguen siendo acciones de la aplicación.
POST /v1/messagestextjson, sse| Campo | Tipo | Requisito | Valores y límites | Predeterminado |
|---|---|---|---|---|
Campomodel | Tipostring | RequisitoObligatorio | Valores y límites THUDM/GLM-4-32B-0414 | 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.00014 / 1K tokens Salida · Tokens de salida $0.00014 / 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": "THUDM/GLM-4-32B-0414",\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': 'THUDM/GLM-4-32B-0414', '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': 'THUDM/GLM-4-32B-0414', '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 THUDM/GLM-4-32B-0414
Usa las rutas de método indicadas arriba.
Ejemplo técnico en inglés
Generate an editable process diagram\n\nCreate self-contained SVG markup for a left-to-right process: Receive -> Validate -> Store. Use three labelled rectangles and two arrows; all labels must remain readable in a 720 by 180 viewBox. Use no scripts, external fonts or external images. Return SVG code and a brief explanation of how the arrows encode the required order.A standalone editable SVG code block with three named nodes and two directional arrows, followed by a short order explanation.Render the SVG locally and check the exact labels, arrow direction and absence of clipped text or external dependencies.