Novedades en la ingeniería de inferencia — Philip Kiely, Baseten
AAI Engineer
Computing/SoftwareInternet Technology
Transcript
00:00:00Estoy aquí para hablar de lo nuevo en ingeniería de inferencia. Hola, soy Philip y estoy aquí porque
00:00:19escribí un libro. Este es mi tercer año en la AI Engineer World's Fair. Esta es mi
00:00:24conferencia favorita de todo el mundo, es lo mejor del calendario cada año. Realmente
00:00:29empecé como ponente e ingeniero aquí en 2024, volví en 2025 e hice un montón de cosas,
00:00:36y aquí estoy de nuevo. Me encanta estar aquí y agradezco a los organizadores por recibirme siempre. Escribí este
00:00:44libro llamado "Ingeniería de inferencia", lo publicamos hace tres o cuatro meses y me ha
00:00:49abrumado la respuesta. Lo publiqué el 23 de febrero y, hasta la fecha,
00:00:57llevamos más de 11 000 copias en papel, estamos cerca de 30 000 copias digitales y 24 millones
00:01:04de personas en todo el mundo, o 24 millones de cuentas de Twitter (ya veremos cuántas personas son
00:01:09en realidad), han visto algo sobre ingeniería de inferencia. Y con toda esta gran acogida,
00:01:17ha habido una pregunta que la gente me ha estado haciendo: ¿por qué demonios harías esto? Es decir, ¿por qué
00:01:23escribirías un libro sobre algo que cambia tan rápido? Bueno, creo que muchos de los
00:01:29principios de la ingeniería de inferencia a estas alturas están bastante consolidados y hay mucho que
00:01:34podemos aprender y repetir generación tras generación de modelos. Pero hoy estoy aquí para hablar de
00:01:42lo nuevo en ingeniería de inferencia. Este es el primer anexo público con toda la información nueva desde que
00:01:48salió el libro. Vamos a repasar un poco los principios de la ingeniería de inferencia y luego hablaremos
00:01:54de todo lo que ha pasado en el mundo de la inferencia desde el 23 de febrero de 2026. Hablaremos
00:02:00de lo que pasó con TurboQuant, un poco sobre la compactación de KV, le dedicaremos bastante
00:02:05tiempo a D-Flash y a otras novedades interesantes en la decodificación especulativa, y luego haré un
00:02:12poco de pronóstico, unas cuantas predicciones sobre lo que creo que va a pasar en
00:02:17inferencia en el futuro cercano y sobre lo que me entusiasma poder hablarles la próxima vez
00:02:23que me vean por aquí. Genial, así que empecemos. Algo que he estado identificando ahora a partir
00:02:30de muchísimas conversaciones con gente sobre la inferencia es un puñado de principios compartidos, y uno
00:02:38de los más importantes... El otro día estuve en un pódcast con Sarah hablando de inferencia y,
00:02:44saben, hay dos tipos de ingeniería de inferencia que han surgido: está la inferencia
00:02:48local, donde la estrategia principal es simplemente hacer que funcione en el hardware que tengas comprimiendo
00:02:56el modelo mediante cuantización, destilación o poda, como puedas, distribuyéndolo entre las
00:03:02GPU que tengas en casa. Primero logras que funcione y luego lo haces menos tonto: eliminas los
00:03:09problemas catastróficos que haya creado toda esta compresión del modelo e intentas
00:03:15hacerlo volver a esa inteligencia base ejecutándolo con un tamaño de lote de uno. Y luego está mi
00:03:20mundo, que es el de los centros de datos y tamaños de lote grandes, donde el objetivo es lograr que funcione desde el primer día,
00:03:27levantar la compilación de vLLM, hacer que funcione y luego hacerlo menos lento, aplicando cosas como enrutamiento consciente de KV, especulación,
00:03:33desagregación... Y dentro de estos dos mundos, creo que tenemos mucho que aprender el uno del otro.
00:03:40En esta charla me voy a centrar en los avances de la ingeniería de inferencia orientada a centros de datos porque
00:03:46es lo que conozco, pero también están pasando cosas geniales en el mundo local.
00:03:52En el libro de ingeniería de inferencia, por lo general asumo que los pesos son un producto terminado y
00:03:58considero que el traspaso del entrenamiento a la inferencia es algo importante a tener en cuenta y una buena
00:04:03manera de delimitar el espacio. Sin embargo, lo que he descubierto cada vez más últimamente es que muchas
00:04:10optimizaciones para la inferencia provienen de un proceso de entrenamiento dedicado, por lo que las fronteras entre entrenamiento
00:04:17e inferencia son cada vez más difusas, y eso es algo interesante a tener en cuenta.
00:04:22Estamos viendo este ciclo en el que obtienes una inferencia más rápida, lo que te da más datos, que usas para entrenar un
00:04:28modelo mejor, lo que te da una inferencia más rápida, que te da más datos, y sigues haciendo eso
00:04:33hasta que te vuelves súper rico. Con el entrenamiento enfocado en la inferencia, tenemos un puñado de
00:04:39nuevas técnicas de las que hablar dentro de lo que me gusta llamar "los tres grandes". Vamos a hablar sobre
00:04:45novedades en cuantización, en almacenamiento en caché (específicamente el mecanismo de caché KV) y en
00:04:52especulación, porque aunque hay muchas otras cosas en el mundo de la inferencia
00:04:57(incluyendo algunos temas de los que hablaré al final), cuando se trata del día a día práctico sobre
00:05:02cómo hacer que cierto modelo sea más rápido, generalmente estas son las tres técnicas a las que la gente recurre.
00:05:09Primero, publico el libro en febrero y me siento de maravilla. Pienso: "Guau,
00:05:16todo lo que necesitas saber sobre inferencia en un solo lugar". Y luego tuvimos novedades en el
00:05:23mundo de la cuantización. Como repaso rápido, la cuantización es cuando usamos un formato numérico más pequeño y menos preciso
00:05:32para ahorrar ancho de banda y cómputo, mejorando el TTFT y las TPS. Suele ser
00:05:39específica del hardware, te ahorra costos pero puede degradar un poco la calidad del modelo.
00:05:45Por cierto, si quieren escuchar todo mi discurso sobre la cuantización, el mes pasado di una charla en AI Engineer
00:05:51Miami sobre cómo la cuantización no es necesariamente tan mala como suena y que hay
00:05:57muchas cosas que se pueden hacer para preservar la calidad en ese proceso. Así que me sentía bien con mi enfoque
00:06:04de la cuantización, y de repente 20 millones de personas vieron TurboQuant; de hecho, provocó una caída
00:06:12temporal en las acciones de memoria solo porque todos dijeron: "Oh, la memoria va a ser mucho más eficiente
00:06:16ahora, ya no necesitamos más memoria flash", lo cual era incorrecto, pero en fin. Era este nuevo
00:06:23enfoque de cuantización popularizado en marzo de este año que utiliza coordenadas polares para
00:06:29la cuantización y permite reducir la caché KV a cuatro bits. Fue la gran novedad y yo me quedé
00:06:36como: "Cielos, me dejé fuera todo esto. ¿Cómo se va a ver esto ahora?".
00:06:43Así que nuestro equipo investigó mucho al respecto. Si conocen al pasante de Waterloo en Twitter,
00:06:50Ali, de nuestro equipo de rendimiento de modelos (no estoy seguro de si todavía es pasante, la verdad,
00:06:57pero sí, es de Waterloo), escribió un artículo genial sobre las matemáticas detrás de TurboQuant.
00:07:04Básicamente, el beneficio que obtienes de TurboQuant es que puedes representar la caché KV con cuatro
00:07:09bits en lugar de ocho: ahorras la mitad del espacio, la mitad del ancho de banda y obtienes prácticamente el doble
00:07:14de ancho de banda al mover la caché KV en la memoria del sistema. Pero el inconveniente de TurboQuant
00:07:21es bastante grande: resulta que necesitas realizar cómputo adicional en la pasada hacia adelante
00:07:25para compensarlo durante la decodificación, y eso reduce las TPS a más de la mitad. Ese es un compromiso inaceptable
00:07:32para muchos casos de uso en producción. Así que analizamos bien TurboQuant, pero no lo estamos utilizando
00:07:38para ninguna de estas cargas de trabajo reales; seguimos con la cuantización tradicional NVFP4. Dicho
00:07:44esto, realmente es una gran técnica para los entusiastas de la inferencia local. Si estás ejecutando un modelo,
00:07:51especialmente un modelo de lenguaje con contexto largo en tu computadora local o en GPUs en tu sótano, tienes
00:07:58una cantidad de memoria muy limitada, que es el cuello de botella principal. Por eso, cualquier cosa que libere memoria
00:08:04de la caché KV y te permita cargar secuencias más largas va a ser muy valiosa,
00:08:09y el cómputo adicional en la pasada hacia adelante no resultará un inconveniente tan grande. Así que,
00:08:16aun así, TurboQuant es un artículo de investigación fantástico, una técnica genial que simplemente no resultó tan
00:08:22aplicable en la inferencia para centros de datos como pareció al principio. En su lugar, nos estamos
00:08:28centrando en NVFP4, priorizando la cuantización de los pesos frente a la caché KV, haciendo
00:08:36lo posible por pulir asperezas en los pesos cuantizados y asegurándonos de no aplanar las distribuciones
00:08:41de probabilidad para la propia caché KV. En su lugar, nos enfocamos en enrutamiento consciente de KV, descarga de KV, uso compartido de KV,
00:08:49usando NCCL, NVIDIA Dynamo y otras herramientas para mover la caché KV por el
00:08:55sistema y potencialmente descargarla a la memoria RAM ordinaria de la CPU, etc., en vez de intentar usar TurboQuant
00:09:04para comprimirla. También nos estamos centrando en la cuantización a través de distintas modalidades, pensando en
00:09:11cómo aplicar los beneficios de NVFP4 no solo a modelos de lenguaje, sino también a modelos de imagen y video.
00:09:17Ali también escribió cosas excelentes en Twitter sobre esto, así que deberían echarle un vistazo.
00:09:23Dicho esto, la caché KV sigue siendo muy importante y hablemos de ella; hablemos de la compactación de KV.
00:09:29Nuevamente, un repaso rápido: en la caché KV, si ingresas el mismo prompt con el mismo prefijo, puedes reutilizar los
00:09:35tokens que calculaste en la fase de pre-fill la última vez. Eso hace que todo tu sistema sea más rápido y eficiente.
00:09:42En términos generales, la caché KV es memoria sin pérdidas. Solo hay un par de fuentes de memoria sin pérdidas cuando pensamos
00:09:48en nuestro sistema de inferencia: tenemos el contenido del prompt, el contexto y la caché KV,
00:09:55y eso va a escalar linealmente con la cantidad de datos que le pases. Ahora bien, si piensas en
00:09:59longitudes de secuencia de un millón de tokens, eso se vuelve bastante significativo. Así que mucha gente se pregunta
00:10:05cómo comprimir la memoria o el contexto. Los entornos de agentes comprimen el contexto, la búsqueda RAG...
00:10:11Todas estas técnicas de las que hemos estado hablando durante años son una especie de compresión de un
00:10:17contexto más amplio en algo que puedas darle a un modelo o escribir en archivos. Todas estas cosas
00:10:22escalan de forma sublineal con la cantidad de datos que tienes. ¿Pero y si hubiera un punto medio? ¿Y si hubiera
00:10:28una forma de obtener bastante compresión en los datos que recuerdas con una retención de información casi sin pérdidas?
00:10:34Tenemos muchas formas distintas de pensar en qué conservar en la caché.
00:10:41Los métodos recientes de compactación han demostrado que podemos reemplazar la caché con una mucho más corta.
00:10:47shorter one. We've got papers like attention matching and cartridges that have given really promising outcomes
00:10:53here with high compression ratios, but both of these are run at inference time. Again, one of the techniques
00:11:00I want to talk about, or one of the themes I want to talk about, is training for inference. So in this case,
00:11:05I want to introduce something called STILL by the BaseTen research team, where the synthesis on top of
00:11:12the cache, where we're keeping a learned representation of the information rather than the information
00:11:17directly or a sort of deterministic subset of it, is amortized via training. So Charlie and Mudith from
00:11:25our post-training team did a fantastic chalk talk at CoSA Compile recently. It's up on YouTube, I would
00:11:31encourage you to take a look at it if you're interested in learning about KV compaction. I do not,
00:11:37unfortunately, have the time or the genius to explain everything up here, but the basic mechanism is
00:11:46that STILL is a Perceiver bottleneck that takes a fixed set of learned query vectors, cross-attends it
00:11:53against the full KV cache, and produces a set of compact keys and values in a single forward pass.
00:11:59This creates a fast, differentiable compressed memory that the LLM can attend to as if it was real context.
00:12:05So if you're interested in KV compaction, definitely check out Charlie and Mudith's work.
00:12:09It's been a really fantastic thing to learn about. So that's two of the techniques: we've talked about
00:12:16quantization, we've talked about caching. The final one is speculation, and there's been a lot of change
00:12:21here. As a review, in speculative decoding we're going to use draft tokens, we're going to verify them
00:12:29during the forward pass, and we're going to use that to generate more than one token per forward pass.
00:12:34It helps a lot with tokens per second, and it is a fully lossless optimization, which is great because
00:12:40we don't have to worry about quality at all. Now, in the history of speculation, we started with
00:12:46speculative decoding—all of these are in the book. You have SpecDec, where you use a small model from
00:12:52the same family to generate draft tokens. Turns out small models are not great draft token generators;
00:12:58they're just great small models. So as an industry, we invented a bunch of new methods like Medusa, where
00:13:04maybe you just add decoder heads to the model, and eventually Eagle 3, which was: "Hey, what if,
00:13:09instead of taking a tiny model from the same family, we actually train a 1B parameter model on the
00:13:15hidden states of the target model to generate draft tokens?" That actually worked really well. And so,
00:13:21you know, as of maybe February last year or February of this year, Eagle 3 was the best method in
00:13:27speculation. Now we've got dFlash. dFlash is even better, so it's diffusion for speculation. dFlash creates
00:13:36a sequence of draft tokens instead of a single token. So the model is a diffusion language model, which
00:13:43means it creates a whole sequence of tokens in the same way that a video or image generator creates a
00:13:49sequence of frames or pixels and iterates over it, rather than doing autoregressive token
00:13:55generation. dFlash models might be 2 or 4 times slower to run, but they're going to predict 8
00:14:01or 16 tokens at once in that window, while Eagle is only doing one at a time. So a single dFlash
00:14:08forward pass is faster than the entire Eagle draft phase and predicts more tokens. These tokens are able
00:14:14to cross-attend to each other and generally create a higher acceptance rate, because in speculation, acceptance
00:14:21rate is everything. So in the wild, we're seeing a more than 3x improvement from dFlash. This is measured with
00:14:30a single B200 Qwen 38B, and we can see that versus Eagle, it's a substantial improvement in tokens—both
00:14:40the token acceptance rate and the tokens per second. These dFlash models are trained with an attention mask for
00:14:47bidirectional drafting, so the target model is going to provide the context, and within each block
00:14:54we're going to have a subset of clean tokens that are sampled, and the attention mask is going to enforce
00:14:59causal consistency, but it is still going to allow for bidirectional attention, where, in a
00:15:06traditional autoregressive model, you're only looking at tokens in a single direction. So that's why we're able to
00:15:13take advantage of this diffusion-based architecture. And then, I thought I was
00:15:19done, and then a couple of days ago dSpark came out. Now, dFlash we do have up and running in production;
00:15:25dSpark is new research. So for this one, I can basically only say: "Hey, it exists, it's cool, we're
00:15:31looking at it." The difference versus dFlash: it still has that diffusion model, but it also pairs it with
00:15:38a sequential model. The idea is that we're going to improve acceptance rates by having these two
00:15:45models work together, rather than having just the iterative speculator, just the diffusion
00:15:51speculator, or just the autoregressive speculator. So dSpark is very exciting, but we don't have any
00:15:57production results with it yet to share. Hopefully, we'll have those for next time.
00:16:03What we do have production results on, though, is continuous speculator retraining. So this is... we're
00:16:09back to dFlash here, and this is the idea that speculative decoding is very dependent on the
00:16:15actual content of the prompts and responses that you're looking at in your system. And so if you are
00:16:21continuously retraining on those prompts and responses in your live system, you can see a 20% to even 2x
00:16:29improvement in your token acceptance rates. This is actually really hard to do: it takes a lot of
00:16:36storage, and you have to make sure that you have permission to use the data that you're processing in
00:16:40this way. It takes a ton of compute, and you have to move all of this information around. And if you
00:16:46change the underlying model, you also have to change the speculator model. But when I look forward into the
00:16:51future, I do think that continuous speculation for very, very large-scale systems is going to be a worthwhile
00:16:58optimization. So, what is next in inference? The following is personal opinion, speculation,
00:17:06and public information. And if I knew anything that was actually coming out, I wouldn't be able to
00:17:11talk about it. So this is just what I think is going to happen. You know, I've been through
00:17:17three hardware cycles: through the Ampere release, the Hopper release, the Blackwell release. And it always
00:17:23takes time from when these chips get shipped, to when they get installed in data centers, to when the
00:17:30entire software stack really is able to take advantage of their capabilities. But some things that I'm
00:17:36excited about are: with Rubin, it looks like the NVFP4 performance is going to be fantastic.
00:17:44So the more we can borrow techniques from local inference and get a lot of confidence running
00:17:49models in this NVFP4 data format, the more we're going to be able to take advantage of the awesome
00:17:54performance of the upcoming Rubin systems. I think disaggregation and system-wide
00:18:00communication is going to be increasingly important. We're seeing really excellent early gains from PD
00:18:05disaggregation, and the ability to move information like KV cache data around the system is
00:18:12going to be increasingly important. And then, like I said, the theme of training for inference is going to
00:18:17be something that continues to have a big impact in the industry moving forward. So thank you all so much
00:18:25for coming to the talk. I'm on Twitter, I'm on LinkedIn, and I'm giving out free books.
00:18:32You can download a PDF at the QR code, or come down with me to the BaseTen booth to get your free copy of
00:18:37Inference Engineering. We've got a bunch there, maybe enough for everyone; if not, we will have a courier
00:18:43bring some more from the office. So yeah, I'll be downstairs at the BaseTen booth. Thank you all so
00:18:48much and have a great day.
Community Posts
No posts yet. Be the first to write about this video!
Write about this video