Quemé todos mis tokens investigando cómo ahorrar tokens

Los esfuerzos por reducir los costes de los modelos de lenguaje grandes (LLM) están revelando una incómoda disyuntiva: muchos trucos para “ahorrar tokens” añaden complejidad, rompen la caché de contexto o simplemente desplazan el desperdicio en lugar de eliminarlo. Los comentaristas comparan estrategias como tuberías multimodelo, prompts fijos frente a dinámicos y despliegues locales frente a la nube, y algunos sostienen que las API en la nube siguen siendo más baratas y capaces que la mayoría de las configuraciones locales, salvo cuando la privacidad o la escala justifican invertir en hardware. Bajo los detalles técnicos subyace una tensión más amplia sobre si el código y los productos asistidos por LLM son realmente valiosos o solo “slop” imposible de publicar, y sobre cómo medir ganancias reales de productividad más allá de afirmaciones anecdóticas.

Estrategias para ahorrar tokens y flujos de trabajo de investigación

  • Muchos describen experiencias similares a las del artículo: los LLM no son “ignorantes”, sino que carecen de disciplina, quemando tokens en callejones sin salida repetidos. El objetivo pasa a ser reducir los callejones sin salida repetidos, no la exploración en sí.
  • Flujo sugerido: empezar con modelos más baratos/pequeños para generar hipótesis y hacer exploración amplia, y luego pasar los resultados destilados a modelos más potentes. Varias hipótesis de bajo costo en paralelo pueden superar a una sola llamada cara.
  • Se proponen precios por lote y trabajos “overnight” para reducir costes cuando la latencia es aceptable.
  • Algunos sugieren mezclar modelos de múltiples proveedores en las primeras etapas para aportar diversidad.

Contexto, caché y diseño de prompts

  • Varios informan que los trucos ingeniosos para ahorrar tokens a menudo rompen la caché del prefijo de contexto, haciendo que todo sea más caro en conjunto.
  • Prefijos fijos, ligeramente más grandes, junto con una síntesis ocasional, pueden superar a los esquemas dinámicos de recuperación y poda.
  • Dejar que el modelo gestione la compactación (por ejemplo, mediante integraciones con el editor) funciona sorprendentemente bien para algunos; a menudo se puede simplemente dejar que el contexto se llene y luego resumirlo.
  • Se comenta el enrutamiento adaptativo de modelos según la dificultad; los problemas incluyen reproducir historiales completos al cambiar de modelo e incompatibilidad de las cachés de atención entre modelos.

Modelos locales frente a la nube y economía

  • Hay una opinión fuerte de que, para la mayoría de las personas, los modelos en la nube son más baratos y mejores que los locales, salvo que ya se disponga de hardware considerable o existan necesidades estrictas de privacidad.
  • Otros sostienen que los modelos locales tienen sentido para organizaciones con muchos usuarios intensivos o con computación ya existente, o como cobertura frente al bloqueo por proveedor y a restricciones cambiantes.
  • Se propone un patrón “90% local / 10% frontier”, pero identificar cuándo cambiar se considera no trivial.

Herramientas, agentes y evitar trabajo repetido

  • Se mencionan varias herramientas: MCP de memoria/caché, archivos de habilidades, y flujos que actualizan periódicamente “rules/skills” basados en chats pasados para dejar de rehacer los mismos pasos.
  • Se plantea la preocupación de que muchos agentes y productos siguen resolviendo los mismos problemas; se proponen bases de conocimiento compartidas para agentes, de modo que converjan en soluciones reutilizables.

Publicar, “slop” y valor en el mundo real

  • Debate encendido sobre si los proyectos asistidos por IA son realmente útiles o solo “slop”.
  • Algunos informan haber publicado herramientas internas, migraciones, juegos y hardware más rápido con LLMs.
  • Otros cuestionan el valor de publicar cosas que ahora los usuarios podrían construir por sí mismos y critican proyectos de IA con documentación escrita por bots.
  • Se disputan las definiciones de “publicado” (usuarios de pago vs herramientas personales vs OSS).

Alucinaciones y fiabilidad

  • Escepticismo sobre que las alucinaciones puedan eliminarse mediante reglas o flujos; se consideran intrínsecas a los modelos actuales.
  • Las afirmaciones de “sin alucinaciones” se cuestionan por exageradas.