Prefill y decode: por qué un LLM tiene dos velocidades
El mismo modelo procesa mil tokens de golpe y luego sufre para escupir uno a uno. Entender por qué cambia cómo lo sirves.
Pensamientos, tutoriales y experiencias sobre desarrollo web, arquitectura e ingeniería.
El mismo modelo procesa mil tokens de golpe y luego sufre para escupir uno a uno. Entender por qué cambia cómo lo sirves.
Por qué los modelos modernos hacen que varias cabezas de atención compartan memoria, y qué ganas tú en latencia cuando entiendes el porqué.
Un modelo anuncia cientos de miles de millones de parámetros y activa una fracción por token. No es marketing: es cómo separa capacidad de coste.
Si tu motor de inferencia agrupa peticiones por lotes fijos, estás pagando GPU que se queda mirando. El batching continuo llena esos huecos.
Si entiendes por qué la primera palabra cuesta y el resto es gratis, dejas de pelearte con la latencia de tu LLM.
La mitad de tus peticiones no necesitan el modelo caro. El truco está en saber cuáles antes de gastar.
Una alucinación no es un fallo que parchear: es el comportamiento por defecto de un modelo entrenado para continuar, no para saber.
Meter más tokens en el prompt parece gratis y suele salir caro: el modelo se distrae justo donde no mira.
Congelas el modelo, entrenas un parche diminuto de rango bajo y obtienes casi el mismo resultado por una fracción del coste.
Un modelo pequeño arriesga varios tokens de golpe y el grande solo verifica: misma salida, menos espera.
El modelo no ejecuta nada; solo rellena un formulario y te pide que lo hagas tú. Notas de campo sobre por qué esa distinción lo cambia todo.
La búsqueda semántica entiende el sentido pero se pierde con un código de error o un nombre propio. Notas de campo sobre juntar BM25 y vectores sin montar un frankenstein.
El mismo prompt da respuestas distintas cada vez. No es magia: son tres perillas que casi nadie toca con criterio.
Un modelo de 70B no cabe en tu tarjeta. Cuantizarlo lo mete dentro casi sin que se note. Casi.
El descuento más fácil de tu factura de LLM está en dejar de reenviar el mismo contexto una y otra vez.
El modelo no lee letras ni palabras: lee trozos. Y ese detalle explica la mitad de sus rarezas.
No compiten por el mismo trabajo. Uno cambia lo que el modelo sabe; el otro, cómo se comporta. Confundirlos sale caro.
No es un bug que se parchea con más instrucciones. Es la consecuencia de mezclar datos e instrucciones en el mismo canal.
Una ventana de contexto grande no es memoria. Distinguirlas es la diferencia entre un agente y un chat con amnesia.
El vector te trae diez candidatos, pero el orden en que llegan casi nunca es el bueno. Notas de campo sobre añadir un reranker sin arruinar la latencia.
Casi todos los fallos de recuperación no son culpa del embedding, sino de cómo troceaste el texto. Notas de campo para partir documentos sin romper el sentido.
Sacar datos de un LLM con expresiones regulares es una bomba de relojería. Notas de campo para obtener JSON que valida a la primera y no te revienta en producción.
Un panel que nadie abre no es neutro: cuesta tiempo, atención y credibilidad. Notas de campo para construir dashboards que cambian una decisión.
El mismo contexto, viajando una y otra vez. Ahí está tu factura, y ahí está la palanca.
La retro no es un ritual de quejas ni una terapia de grupo: es la única reunión que existe para cambiar algo.
El modelo tarda lo mismo, pero la espera se siente la mitad. Ese es todo el truco.
No compiten por el mismo puesto: uno lee registros en la planta, el otro los lleva a la nube.
No necesitas una plataforma de despliegue para un proyecto de una persona. Necesitas veinte líneas que corran los tests y suban el build sin que tú mires.
La respuesta honesta casi nunca es 'ya'. Aquí está la línea que sí la cruza.
No son decoración ni burocracia: son el contrato que convierte errores de producción en errores de tu editor.
Partir el monolito no es gratis: pagas en latencia, deuda operativa y reuniones. Cuándo merece la pena y cuándo te estás complicando la vida.
Boris Cherny dice que ya no hace prompts, sino bucles que los hacen por él. Qué significa eso en la práctica y por qué diseñar el bucle es más difícil, no más fácil.
Cinco principios pensados como heurísticas, no como mandamientos. Aplicarlos a ciegas también es deuda técnica.
Tu modelo funciona en el notebook. El problema empieza cuando lo llaman mil personas a la vez.
Sin un conjunto de evaluación, cada cambio de prompt es una apuesta a ciegas.
Un prompt que funciona en tu pantalla no es un sistema. Es un accidente que aún no se ha roto.
Lo que me llevé del harness de Anthropic y cómo lo aterricé en mi propio pipeline.
Si entiendes esto, entiendes por qué tu buscador semántico acierta o falla.
El problema casi nunca es el modelo. Es lo que le das de comer.
Por qué si no duele, probablemente no lo estés haciendo bien
En este post hago una exploración sobre la comunicación industrial, específicamente sobre Modbus.
Este post describe las librerías más utilizadas para la visualización de datos en tiempo real
Este post introduce al desarrollo con Stimulus.js
Este post introduce al desarrollo con Python
En este post voy a explicar la arquitectura de software y los principios SOLID.