Qué es Token Efficiency: DeepSeek V4, planificación con modelos grandes y ejecución con modelos pequeños

Fri, 15 May 2026 08:59:33 +0800

La próxima métrica importante en AI Coding quizá no sea quién tiene el modelo más fuerte, sino quién completa más trabajo verificable con menos tokens, menor coste y un proceso más estable.

Ese es el valor de Token Efficiency.

Muchos lo entienden como modelos baratos, contexto largo o cache hits más económicos. Eso es solo la base. Lo que lo convierte en productividad es la división de trabajo entre modelos, la orquestación de tareas, el presupuesto de contexto y la evaluación.

Token Efficiency no es un truco para ahorrar dinero. Es un método de ingeniería para convertir tokens en producción.

DeepSeek V4: separar planificación y ejecución

DeepSeek V4 no es solo otro modelo más fuerte. Divide las dos capacidades necesarias para Token Efficiency en V4 Pro y V4 Flash: V4 Pro encaja mejor con planificación, razonamiento, juicio arquitectónico y revisión crítica; V4 Flash encaja con ejecución frecuente, reescritura en lote, completado de código, organización de información y nodos normales de un agente.

En AI Coding esto se traduce así:

V4 Pro: planner / consultant para requisitos, diseño técnico, bugs complejos, revisión de arquitectura y aceptación final.
V4 Flash: executor para escanear archivos, implementar cambios simples, completar tests, ordenar documentación, generar candidatos y repetir tareas.

La documentación API de DeepSeek indica que ambos soportan 1M de contexto, JSON Output, Tool Calls, Chat Prefix Completion y FIM Completion. La página de precios también separa input con cache hit y señala una bajada fuerte de ese precio.

La combinación es lo importante: 1M de contexto reduce compresión en tareas agent complejas; el cache hit barato reduce el coste de volver a cargar prompts, docs, código e historial; la separación Flash / Pro evita usar un modelo flagship para cada paso o depender solo de un modelo pequeño inestable.

Así, DeepSeek V4 ofrece una estructura de coste realista para el patrón “modelo consultor + modelo ejecutor + harness de orquestación”.

No hacer que el modelo más fuerte lo haga todo

Antes era común elegir el modelo más inteligente y dejarle requisitos, código, tests y resumen de punta a punta.

Es sencillo, pero no siempre eficiente. Muchas tareas no necesitan razonamiento de frontera. Los modelos caros deberían actuar como consultores, arquitectos o planificadores que intervienen en puntos clave.

Una estructura mejor:

Modelos grandes para descomponer problemas y tomar decisiones clave.
Modelos pequeños para ejecutar, procesar en lote y repetir cambios.
Herramientas y harness para proceso, estado, contexto y validación.
Personas para definir producto, aceptar resultados y decidir tradeoffs.

Así el razonamiento caro no se desperdicia en ejecución mecánica.

Más contexto no siempre es mejor

El contexto largo importa en coding agents porque código, documentos, historial, salida de tests y logs consumen ventana. Cuando se llena, aparecen compresión, olvido y errores de juicio.

Pero contexto largo no significa meterlo todo.

Token Efficiency exige que cada tarea quepa en una ventana clara y controlada: archivos necesarios, documentos relevantes para la decisión, estado actual, entradas y salidas claras, y resumen estructurado para el siguiente nodo.

Si el contexto es barato, la tentación es meter ruido. El ruido no hace al modelo más inteligente.

El harness importa más que un modelo aislado

Conectar Claude Code, Codex u otro agent a un modelo barato no basta. Los modelos pequeños se desvían en cadenas largas si no hay control de proceso.

Un harness decide cómo dividir tareas, correr nodos, escoger modelos, validar resultados, reintentar fallos y pasar contexto.

Sin esa capa, un modelo pequeño solo es barato. Con esa capa, puede convertirse en palanca.

Dividir tareas con DAG

Una tarea compleja puede convertirse en un DAG. Por ejemplo: aclarar requisitos, diseñar solución, dividir tareas, implementar, completar tests, hacer Code Review, corregir y enviar PR.

Cada nodo puede ser un agente independiente con rol, prompt, permisos de herramientas y formato de salida. Los nodos deberían intercambiar resultados estructurados, no conversaciones largas.

Esto hace cada nodo más corto, más fácil para modelos pequeños y más medible.

Ejecutar varias réplicas de una tarea

Cuando los tokens son suficientemente baratos, una tarea no tiene por qué ejecutarse una sola vez. Puedes correrla con distintos modelos, prompts u orquestaciones, luego elegir el mejor resultado o combinar partes útiles.

Sirve para diseños, copy, casos de prueba, hipótesis de bug, alternativas de refactor y Code Review. No sirve para tareas con efectos externos, estado compartido o criterios de aceptación borrosos.

El objetivo no es apostar, sino obtener muestras comparables para mejorar la orquestación y la elección de modelos.

Construir evaluación

Token Efficiency no se mide solo por precio. Un modelo barato con alta tasa de fallo consume tiempo humano y puede salir más caro.

Conviene registrar tasa de finalización, intervenciones humanas, fallos de tool calls, tests que pasan, hallazgos de review, coste por tarea, tiempo, retrabajo y diferencias entre combinaciones de modelos.

Con esos datos se sabe qué tareas van bien con modelos pequeños, cuáles requieren modelos grandes y cuáles deben quedarse en manos humanas.

Hacer atómicos los workflows

No todo el mundo tiene que construir un harness completo. Pero sí puede dividir sus procesos en nodos atómicos.

Producción de contenido: tema, investigación, esquema, borrador, fact-check, estilo, título SEO, traducción y revisión de publicación.

Desarrollo de software: requisitos, diseño técnico, estructura de datos, cambios de API, unit tests, implementación, migraciones, documentación y review.

Cada nodo debe tener entrada, salida, aceptación y contexto claros. Cuando maduren las herramientas de harness, esos procesos podrán conectarse directamente.

El hardware no es lo primero

Muchas conversaciones sobre Token Efficiency saltan a despliegue local y GPU. Para la mayoría, la API debería ser la primera opción.

Antes de validar el modelo económico, el hardware local es coste adelantado. Mejor: validar el workflow con API, medir coste y calidad, detectar nodos frecuentes y estables, y solo después estudiar qué merece localizar.

Resumen

Token Efficiency no consiste en sustituir modelos caros por baratos, sino en rediseñar el workflow de IA.

Modelos grandes juzgan, modelos pequeños ejecutan, el harness orquesta y valida, y las personas definen objetivos y aceptación. Solo juntas estas capas convierten tokens en productividad.

La diferencia futura quizá no esté en quién llama al modelo más fuerte, sino en quién convierte los mismos tokens en más resultados reales.

Small Models on KnightLi Blog