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.

¿Abandonar MCP? Por qué CLI se está convirtiendo en la capa de herramientas predeterminada para agentes

Fri, 10 Apr 2026 21:55:12 +0800

Durante el último año, el debate sobre las cadenas de herramientas para agentes se ha concentrado cada vez más en una pregunta:

¿MCP (Model Context Protocol) simplifica las llamadas a herramientas, o vuelve más complejas tareas que antes eran simples?

Para la mayoría de tareas cotidianas de ingeniería, CLI se está convirtiendo en la opción predeterminada más práctica.

La diferencia de coste no es un problema de UX, sino de orden de magnitud

La mayor presión práctica de MCP es el gasto de tokens.

En escenarios comunes, MCP suele tener que cargar grandes esquemas de herramientas antes de ejecutar la tarea real. Tomando como ejemplo un GitHub MCP Server, solo la inicialización puede consumir decenas de miles de tokens. En tareas largas, esto reduce directamente el presupuesto de contexto.

Las pruebas de la comunidad apuntan una y otra vez a la misma conclusión:

una llamada MCP suele costar varias veces, o incluso decenas de veces, más que CLI
la recuperación tras fallos también es más cara, porque hay que reconectar y recargar contexto

Esto no es simplemente “un poco más lento”. Escala hasta convertirse en problemas de coste de API, latencia y estabilidad.

Por qué los modelos son naturalmente mejores usando CLI

Un hecho que se pasa por alto con frecuencia es la distribución de entrenamiento.

Los LLM han visto enormes cantidades de texto de terminal durante el entrenamiento: comandos, salidas, errores, scripts y man pages. En otras palabras, la interacción por CLI ya está cerca del patrón de entrada nativo del modelo.

En cambio, el estilo JSON-RPC y los tool schemas de MCP solo se popularizaron a gran escala en los últimos años. Los modelos pueden aprenderlo, por supuesto, pero la familiaridad y la eficiencia de compresión suelen ser peores que en patrones CLI con décadas de corpus histórico.

Esto también explica por qué muchas veces:

para el mismo objetivo, los comandos CLI son más cortos
la salida es más fácil de usar para seguir razonando
las rutas de recuperación de errores son más estables

Seguridad y aislamiento: MCP aún tiene tarea pendiente

MCP no es incapaz de ser seguro, pero su ecosistema todavía está en una etapa temprana.

Las preocupaciones habituales incluyen:

Tool Poisoning en descripciones
deriva de comportamiento del servicio, o Rug Pull
sobrescritura por herramientas con el mismo nombre, o Shadowing

CLI también tiene riesgos de seguridad, como inyección, abuso de privilegios y riesgos de rutas. Pero su modelo de procesos, límites de permisos y cadena de auditoría han sido validados durante décadas de práctica de ingeniería. En producción, esa previsibilidad importa.

Esto no significa que MCP no tenga valor

No creo que MCP deba abandonarse.

Una posición más razonable es:

CLI se encarga de la capa de ejecución: local, baja latencia y llamadas frecuentes
MCP se encarga de la capa de conexión: descubrimiento de servicios remotos, autenticación unificada, auditoría y multitenencia

Es la arquitectura híbrida que suele resumirse como CLI + MCP Gateway.

Cuando hay que integrar muchos sistemas remotos y aplicar gobierno de permisos y auditoría de cumplimiento, MCP sigue teniendo un valor claro. Pero para “ayudar a un Agent a completar tareas de desarrollo rápidamente”, CLI-first suele encajar mejor con los límites actuales de capacidad de los modelos.

En la realidad de ingeniería actual, CLI se parece más al idioma de trabajo nativo de un Agent; MCP encaja mejor como protocolo de conexión que como único protocolo de ejecución.

Token Efficiency on KnightLi Blog