Los primeros sistemas basados en LLM se diseñaron alrededor de una premisa sencilla: utilizar el modelo más capaz disponible y darle todo el contexto posible.
Ese enfoque funciona hasta que las tareas empiezan a parecerse a trabajo real y cogen cierto tamaño: repositorios completos, migraciones, investigación con múltiples fuentes o procesos que duran horas. Ahí es donde empiezas a pensar en varios modelos, cada uno con una tarea.
Y en ese momento aparece un problema distinto. La pregunta deja de ser qué modelo usar y pasa a ser qué responsabilidad tiene cada modelo.
Llevo toda esta semana trabajando con GLM 5.2 y DeepSeek V4 Flash 0731 y el combo me está funcionando bastante bien. Antes hacía algo parecido con DeepSeek V4 Flash y Qwen 3.6, pero el nivel ha subido bastante.
Lo importante: un sistema multi-modelo requiere algo más que encadenar llamadas. Necesita responsabilidades, interfaces y mecanismos de validación entre componentes. Un modelo que entiende el objetivo, diseña un plan y toma decisiones de alto nivel. Modelos especializados que ejecutan subtareas concretas con velocidad y bajo coste. Y una forma clara de transferir contexto y resultados entre ellos.
En este artículo uso GLM 5.2 como orquestador y DeepSeek V4 Flash 0731 como ejecutor para explorar esta arquitectura. La elección no es azar: tienen perfiles diferentes. GLM 5.2 está optimizado para tareas largas donde importa mantener una visión global. DeepSeek V4 Flash resulta especialmente interesante para ejecutar muchas tareas a gran velocidad y bajo coste.
La dificultad real aparece en el punto intermedio: el handoff. Me estaba pasando que GLM 5.2 daba demasiado contexto a DeepSeek y eso hacía que a veces se liara, y cuando terminaba la tarea, DeepSeek devolvía demasiado contexto a GLM 5.2, que procesaba muchos tokens de entrada y tardaba más.
Cuando un modelo delega trabajo a otro no puede copiar su conversación completa y esperar que funcione. Hay que decidir qué información es relevante, cómo se expresa la tarea y cómo vuelve el resultado. Y más con estos dos modelos, donde un contexto demasiado grande o demasiado pequeño marca la diferencia entre ejecutar bien la tarea y disparar los costes.
La arquitectura se basa en una idea sencilla: el orquestador no pasa todo el contexto, crea y pasa contratos de trabajo.
A partir de ahí vienen tres patrones básicos de implementación, cómo diseñar esos contratos, cómo controlar costes y cuándo esta arquitectura aporta valor frente a utilizar un único modelo.
GLM 5.2 vs DeepSeek V4 Flash 0731: dos perfiles para dos trabajos distintos
Una arquitectura multi-modelo empieza definiendo qué trabajo hace cada uno.
En este caso la división es sencilla. GLM 5.2 actúa como orquestador: entiende objetivos ambiguos, diseña planes, decide qué tareas delegar y revisa resultados. DeepSeek V4 Flash 0731 actúa como ejecutor: recibe tareas bien definidas y las resuelve con velocidad y bajo coste.
Los dos modelos pueden resolver problemas complejos, pero están optimizados (o yo los uso así) para distintos puntos del proceso.
GLM 5.2: el que mantiene la visión global
Los sistemas agénticos tienen que mantener una dirección constante durante muchos pasos. Son procesos largos. Por eso encaja un modelo con mucho contexto y especializado en tareas de horizonte largo.
Un orquestador necesita mantener el objetivo final durante toda la ejecución, dividir problemas grandes en subtareas, decidir qué información merece la pena conservar, detectar errores cuando aparecen y adaptar el plan conforme cambia el contexto.
Estas capacidades no implican que el modelo ejecute mejor cada tarea individual, sino que sea capaz de mantener coherencia entre muchas decisiones consecutivas.
Su coste es más alto, así que no tiene sentido utilizarlo para cada pequeña operación. Su valor está en que las decisiones sean correctas y no se pierda el objetivo.
DeepSeek V4 Flash 0731: el que ejecuta muchas veces
El ejecutor tiene un problema diferente.
No necesita entender toda la misión. Necesita recibir una tarea bien especificada y completarla: modificar un fichero, generar una prueba, analizar un documento, transformar datos o implementar una función concreta. Ahí importan otras propiedades: la velocidad de generación, el coste por operación y la capacidad de ejecutar muchas tareas en paralelo.
DeepSeek V4 Flash está orientado precisamente a este escenario: muchas llamadas, tareas concretas y alto volumen de ejecución.
Qué significa esto en la práctica
La idea es reservar la capacidad de razonamiento más cara para las decisiones que realmente la necesitan. Uno piensa y dirige muy bien, el otro ejecuta muy bien. De la otra manera, sobreutilizamos los modelos más potentes.
Bajando a una realidad que todos conocéis: en un equipo de ingeniería, un arquitecto de software no baja a escribir cada línea de código, y a un desarrollador junior no le pides decidir toda la arquitectura. Ambos roles son necesarios porque optimizan problemas diferentes.
Con los LLM ocurre algo parecido, y por eso la pregunta útil deja de ser cuál de los dos modelos es mejor y pasa a ser qué parte del proceso le toca a cada uno.
Patrones de arquitectura para orquestar varios modelos
La mayoría de sistemas útiles empiezan por una arquitectura bastante simple. Orquestar modelos consiste en introducir una capa de coordinación entre el objetivo del usuario y los modelos que ejecutan el trabajo. Antes de añadir frameworks, grafos de ejecución o mecanismos complejos de memoria, lo importante es entender qué información debe circular entre los modelos y dónde debe vivir el estado del sistema.
Tres patrones sencillos y habituales.
Patrón 1: planificación y ejecución separadas
Es el patrón más sencillo y, en muchos casos, el más efectivo.
El orquestador recibe el objetivo completo, analiza el contexto disponible y genera un plan formado por tareas independientes. Cada tarea incluye la información necesaria para ejecutarse, las restricciones que debe respetar y una forma de comprobar si el resultado es correcto.
Después, un modelo ejecutor recibe cada tarea y trabaja sobre ella. Cuando todas terminan, el orquestador revisa los resultados y decide si cumplen el objetivo inicial.
La ventaja principal es su simplicidad. El flujo es fácil de observar y depurar porque cada paso tiene una entrada y una salida claras. Además permite aprovechar la paralelización cuando las tareas son independientes.
Un ejemplo típico sería una migración de código. El orquestador analiza un repositorio completo, detecta los ficheros afectados y genera una serie de tareas de migración. Cada ejecutor trabaja sobre un fichero concreto siguiendo las convenciones globales del proyecto.
Este patrón funciona especialmente bien cuando el problema puede dividirse antes de empezar la ejecución. Procesamiento documental, generación de contenido, migraciones repetitivas o análisis por lotes son escenarios donde suele encajar.
Y esta es la configuración que utilizo por defecto, con una salvedad: al trabajar con OpenCode, el propio harness despliega la herramienta Task para asignar tareas al modelo ejecutor, lo que en realidad es el patrón 2.
Patrón 2: el ejecutor como herramienta del orquestador
En lugar de crear todo el plan al principio, el orquestador mantiene el control durante la ejecución y utiliza otros modelos como herramientas.
El flujo se parece más al funcionamiento de un agente tradicional. El modelo principal analiza la situación, decide qué información necesita, delega una tarea y utiliza el resultado para decidir el siguiente paso.
Por ejemplo, durante un proceso de debugging el orquestador puede pedir a un ejecutor que analice un módulo concreto, recibir una hipótesis sobre el fallo y utilizar esa información para decidir qué revisar después.
Este enfoque es más flexible porque permite adaptar el plan mientras aparecen datos nuevos. También aumenta la complejidad del sistema, ya que cada resultado del ejecutor debe transformarse en información útil para el siguiente ciclo de decisión.
El diseño del contrato entre modelos adquiere mucha importancia en este patrón. Si el ejecutor devuelve demasiada información irrelevante, el contexto del orquestador crece rápido y las siguientes decisiones empeoran.
Patrón 3: agentes con estado compartido
El tercer patrón aparece cuando las tareas dejan de ser simples intercambios de mensajes y empiezan a parecerse a un proyecto completo.
Aquí los agentes comparten un espacio de trabajo común. Puede ser un sistema de ficheros, una base de datos, un repositorio de código o cualquier otro mecanismo donde puedan dejar artefactos y consultar el trabajo de otros agentes.
Un ejemplo sería un sistema de desarrollo automático donde un agente analiza requisitos, otro implementa cambios, otro ejecuta pruebas y otro revisa el resultado final. Cada uno interactúa con el mismo repositorio y deja información para los siguientes pasos.
La ventaja es que evita transportar constantemente grandes cantidades de contexto entre modelos. El estado del proyecto vive fuera de la conversación y cada agente accede solo a la información que necesita. La dificultad está en diseñar qué información se considera estado compartido y quién tiene autoridad para modificarla.
La contrapartida es que el sistema empieza a tener problemas similares a cualquier arquitectura distribuida. Hay que gestionar versiones, conflictos, errores parciales y trazabilidad de cambios.
El handoff entre modelos: diseñar contratos de trabajo
Cuando un modelo delega una tarea a otro aparece una nueva frontera dentro del sistema, y la forma de comunicar esa transición determina en gran medida la calidad del resultado.
En una arquitectura basada en APIs, la comunicación entre modelos se hace mediante representaciones externas: texto, estructuras de datos o artefactos compartidos. Eso simplifica la integración técnica, porque cualquier modelo con una API compatible puede participar. El reto está en decidir qué información debe cruzar esa frontera.
Un error habitual, y el que estaba cometiendo yo, es pasar toda la conversación del orquestador al ejecutor. Parece una solución segura porque conserva todo el contexto disponible, pero introduce tres problemas.
El primero es la relevancia. El historial de un orquestador contiene decisiones descartadas, exploraciones previas y resultados de otras tareas sin relación con la nueva ejecución. El ejecutor tiene que separar la información útil del ruido antes de empezar a trabajar.
El segundo es el coste. Enviar información repetida aumenta el consumo de tokens y encarece cada llamada, especialmente en sistemas donde se ejecutan muchas subtareas.
El tercero aparece con los errores. Si una tarea falla y su contexto de entrada depende de una conversación completa, repetir la ejecución implica arrastrar también las decisiones y los errores acumulados durante esa conversación.
La solución es tratar cada delegación como un contrato de trabajo independiente. El orquestador transforma su contexto en una especificación que otro modelo puede ejecutar sin conocer la historia completa.
La especificación que he construido incluye cuatro elementos:
- Objetivo. Qué resultado debe existir al finalizar la tarea.
- Entradas. Los datos, ficheros o recursos necesarios para trabajar.
- Restricciones. Las reglas que no pueden romperse: convenciones del proyecto, límites técnicos o decisiones previas.
- Criterio de éxito. Cómo validar que el trabajo está terminado correctamente.
Un ejemplo sencillo con una tarea de migración de código:
objetivo:
Migrar test_pagos.py de unittest a pytest
entradas:
- tests/test_pagos.py
restricciones:
- Mantener nombres actuales de tests
- Usar fixtures compartidas desde conftest.py
criterio_de_exito:
- pytest tests/test_pagos.py ejecuta correctamente
- No quedan imports de unittestSi una tarea no puede expresarse con esta claridad, probablemente todavía no está suficientemente definida para delegarse.
La información que vuelve también forma parte del diseño
El flujo no termina cuando el ejecutor recibe una tarea. El resultado que vuelve al orquestador necesita el mismo nivel de diseño.
En mis primeras implementaciones el ejecutor devolvía toda la respuesta generada al modelo principal. Eso funciona con pocas tareas, pero escala mal cuando ejecutas decenas o cientos de subtareas. En mi caso veía cómo el contador de tokens de GLM 5.2 subía demasiado.
Una arquitectura más eficiente separa dos tipos de salida: el artefacto generado (código, documentos o datos transformados) y un resumen operativo que permita al orquestador tomar decisiones.
El orquestador no necesita leer cada línea modificada. Necesita saber qué se ha hecho, si ha terminado correctamente y si hay algún problema que requiera atención. El artefacto se queda en el espacio de trabajo compartido y solo se recupera cuando una revisión posterior lo necesita.
Este diseño tiene además una ventaja económica directa. Los mecanismos de prompt caching funcionan por prefijos: cuando el inicio del prompt es idéntico entre llamadas, el proveedor no vuelve a procesar esos tokens y los factura con descuento. En el caso de DeepSeek, los tokens de entrada que aciertan en caché se cobran con una reducción cercana al 98%, una de las políticas más agresivas del mercado.
De ahí sale una regla de ordenación: la información constante, como las instrucciones del ejecutor o las convenciones del proyecto, va al principio del contexto, y la información específica de cada tarea se añade al final. Cualquier variación en el prefijo invalida la caché de todo lo que viene detrás.
Hay un segundo detalle: la caché se construye cuando una llamada termina de procesarse. Si el sistema lanza veinte tareas en paralelo desde el primer momento, ninguna encuentra el prefijo en caché porque todas llegan a la vez. La solución es simple: una primera llamada en solitario que procese el prefijo completo, y el resto en paralelo detrás, ya con la caché caliente.
Ejemplo práctico: migrar una suite de tests con varios modelos
Para ver la arquitectura completa, apliquemos estos patrones a un caso habitual: migrar una suite de tests desde unittest a pytest.
Es un buen ejemplo porque combina las tres cosas que hacen interesante la orquestación: hay un objetivo claro, hay muchas tareas repetitivas que pueden ejecutarse en paralelo y el resultado puede validarse automáticamente.
El flujo sería el siguiente:
- GLM 5.2 analiza el repositorio y genera un plan de migración.
- Cada tarea se convierte en una especificación independiente.
- DeepSeek V4 Flash ejecuta las migraciones individuales.
- Las pruebas automáticas validan los cambios.
- GLM 5.2 revisa el resultado global y detecta problemas de consistencia.
La primera decisión importante es dónde poner la inteligencia cara. El análisis inicial del repositorio requiere entender relaciones entre ficheros, convenciones existentes y posibles dependencias compartidas: ahí tiene sentido el modelo orquestador. Durante la ejecución, en cambio, la mayoría de tareas tienen un contexto reducido. Migrar un fichero, actualizar imports o adaptar una fixture son operaciones repetitivas donde pesan más la velocidad y el coste.
La arquitectura resultante sería algo así:
El detalle importante es que los ejecutores no reciben la conversación completa del orquestador. Cada uno recibe una tarea autocontenida con la información necesaria para trabajar.
Un ejecutor no necesita saber que el repositorio se está migrando desde hace tres semanas. Necesita saber qué fichero debe modificar, qué convenciones debe respetar y cómo comprobar que su cambio es correcto.
Eso hace que las tareas sean independientes. Si una migración falla, se repite esa tarea concreta con el error que devolvieron las pruebas, sin reiniciar todo el proceso ni arrastrar el historial anterior.
Dónde aparece realmente el ahorro
La ventaja económica de esta arquitectura aparece cuando aumenta el volumen.
Con los precios de las APIs first-party a agosto de 2026, tomados como orden de magnitud porque varían según proveedor: GLM 5.2 cuesta 1,40 dólares por millón de tokens de entrada y 4,40 de salida. DeepSeek V4 Flash cuesta 0,14 y 0,28 respectivamente, unas 15 veces menos en salida, y genera a más de 100 tokens por segundo.
Aplicado a la migración del ejemplo, con 15 ficheros:
- Planificación y revisión final con GLM 5.2, las dos llamadas con contexto amplio: unos 15 céntimos de dólar.
- Las 15 ejecuciones con DeepSeek, con el prefijo común en caché y pagando a precio completo solo el contrato y el fichero de cada tarea: unos 5 céntimos.
- Total: alrededor de 20 céntimos.
El mismo proceso ejecutado íntegramente con GLM 5.2 se sitúa entre 50 y 70 céntimos según lo que se extienda cada generación. Aproximadamente el triple, y más lento en la fase paralelizable. A escala, utilizar el modelo más grande y caro para todo supone multiplicar tu factura por 3 como mínimo.
Y si el plan está bien hecho, el ahorro crece con el número de subtareas que se delegan: cuanto más trabajo cae en el ejecutor, mayor es la diferencia contra hacerlo todo con el modelo grande.
El punto de equilibrio depende de tres variables: la diferencia de coste entre modelos, el número de ejecuciones y el coste de coordinación. En una tarea puntual, la arquitectura puede incluso resultar más cara. En un pipeline que ejecuta este proceso cientos de veces al mes, o en tareas donde la fase de ejecución mueve millones de tokens, la diferencia se acumula rápido y es lo que hace viable ponerlo en producción.
La lógica de asignación es la misma a cualquier escala. GLM 5.2 participa en los momentos donde una decisión incorrecta tiene un coste alto: comprender el objetivo, diseñar la estrategia y revisar el resultado final. DeepSeek V4 Flash participa en las operaciones donde importa ejecutar muchas veces de forma eficiente.
El ahorro tampoco viene solo del precio por token. Viene también de reducir la cantidad de trabajo que hace cada modelo. El orquestador no procesa cada detalle operativo y los ejecutores no necesitan entender toda la historia del proyecto.
Otras cosas a tener en cuenta
El modelo ayuda a decidir y ejecutar, pero el sistema necesita mecanismos deterministas que confirmen que el resultado es correcto. En este caso, herramientas de siempre: ejecutar la suite de tests, revisar los cambios con control de versiones, comprobar reglas estáticas y validar los formatos esperados.
Además, una arquitectura multi-modelo necesita observabilidad igual que cualquier sistema distribuido. En producción conviene registrar qué versión de modelo ejecutó cada tarea, qué prompt y configuración utilizó, qué coste generó cada paso, qué resultado produjo y cuánto tardó. Esa información permite detectar degradaciones cuando cambia un modelo, comparar estrategias de orquestación y mejorar los contratos entre componentes.
Y no compensa añadir multi-modelo cuando las tareas son pequeñas, cuando el problema requiere contexto global, cuando la latencia es crítica o cuando tienes poco volumen de peticiones.
Esto lo puedes hacer con otros modelos
Nada de este patrón es exclusivo de GLM y DeepSeek. Antes de este combo trabajaba con Qwen 3.6 de ejecutor y DeepSeek V4 Flash u Opus de orquestador.
Un ejemplo diferente: Claude Opus 5 como orquestador y Qwen 3.6-35B-A3B como ejecutor. Opus 5 es de lo mejor que existe hoy en planificación y trabajo agéntico (aunque todos echamos de menos Opus 4.6). Cuesta bastante más que GLM 5.2, pero si ya tienes la suscripción quizás lo prefieras. Además permite configurar el nivel de esfuerzo por llamada, lo que encaja de forma natural con el rol: esfuerzo alto para el plan, medio para la revisión. Y Qwen 3.6 es el ejecutor perfecto: nosotros lo hemos usado como todoterreno en Helmcode para todo.
También podrías hacerlo con GPT 5.6 Sol y Qwen 3.6, o GPT 5.6 y DeepSeek, o la combinación que más te guste.
La idea principal es esta: el modelo caro y potente como orquestador, trabajando lo justo, y el modelo barato y rápido como ejecutor, haciendo la mayor parte del trabajo.
Quickstart: pruébalo en 5 minutos
Si quieres probar esta arquitectura sin escribir nada, he preparado un quickstart con OpenCode que la deja funcionando en dos comandos:
git clone https://github.com/helmcode/orchestrator-quickstart
bash orchestrator-quickstart/setup.shEl script es un instalador. Solo te hace una pregunta, qué pareja quieres (GLM 5.2 + DeepSeek V4 Flash, Opus 5 + Qwen 3.6, o la tuya propia), y configura el resto: el proveedor, los dos agentes con sus roles y permisos, y la plantilla de convenciones del proyecto. Tú pones tu API key y a delegar.
Los agentes son dos ficheros markdown que puedes leer y modificar. El orquestador tiene la escritura denegada a propósito, para que delegar sea su única vía (puedes cambiarlo si vas a una arquitectura como la del patrón 3). El ejecutor devuelve siempre un resumen de 3 líneas para no inflar el contexto de nadie, y no está capado, por lo que puede ejecutar cualquier cosa. Puedes caparlo para evitar que borre ficheros innecesarios.
Lo único que necesitas es una plataforma que sirva estos modelos con API compatible con OpenAI. Nosotros servimos los que mejor coste y throughput tienen , todos modelos abiertos, con tarifa plana y zero logs.
La ventaja está en diseñar el sistema, no en acumular modelos
La evolución de los modelos ha llevado a muchos equipos a buscar una solución basada en un único modelo generalista. En sistemas complejos, la arquitectura suele ser tan importante como la capacidad individual del modelo: asignar responsabilidades diferentes a componentes diferentes permite construir sistemas más controlables y eficientes.
En una arquitectura multi-modelo, el orquestador entiende el objetivo, mantiene la dirección del proceso y toma las decisiones de alto nivel. Los ejecutores resuelven tareas concretas con la velocidad y el coste adecuados.
La parte más importante del diseño está en la frontera entre ambos. Un modelo no mejora por recibir más contexto, sino por recibir la información correcta en el formato adecuado. El handoff funciona cuando existe un contrato claro: qué hay que hacer, con qué recursos, bajo qué restricciones y cómo se valida el resultado.
Después de recorrer todos estos patrones, la idea central sigue siendo la misma: el orquestador no pasa conversaciones, pasa contratos de trabajo.
He usado GLM 5.2 y DeepSeek V4 Flash como ejemplo porque son los dos modelos más nuevos que estamos sirviendo en Helmcode y NaN.builders, y porque combinan capacidades diferentes. Pero el principio es más amplio: los sistemas basados en LLM necesitan arquitectura, interfaces y mecanismos de validación igual que cualquier otro sistema complejo.
La orquestación es una forma de diseñar el sistema completo. Y los mejores sistemas no son los que utilizan más modelos, son los que asignan mejor las responsabilidades, van más rápido y cuestan menos.
