Todos los vídeos Inferencia de LLMs 2:15

Prefix caching vs speculative decoding

La continuación todavía debe generarse. Un hit de prefijo no recupera una respuesta completa.

Los enlaces con ?t= abren el vídeo en un segundo concreto.

Resumen del vídeo

Las ideas que debes retener

01

El presupuesto de latencia vuelve a ser el punto de partida

Para una petición servida de forma autoregresiva podemos mantener la descomposición del capítulo 4.1:

02

Prefix caching reutiliza estado de un prefijo ya calculado

En un Transformer autoregresivo, el prefill produce K/V para los tokens de entrada. Si una petición posterior empieza con exactamente el mismo prefijo —según el contrato de identidad del…

03

Un hit sólo existe para la parte realmente reutilizable

Sea una petición con Lin tokens de entrada y Lhit tokens cubiertos por estado KV reutilizable. Definamos una tasa de reutilización por tokens:

Momentos clave

Ve directamente a una sección

  1. Reutilizar sólo el prefijo
  2. La identidad decide el hit
  3. Proponer no es confirmar
  4. Aceptar mucho no basta
  5. La rama rechazada se retira
  6. Intercalar trabajo
Leer transcripción revisada

Vídeo sin narración. Esta transcripción reproduce el texto visual del vídeo; no atribuye una voz inexistente.

Reutilizar sólo el prefijo

Dos peticiones comparten cuatro tokens iniciales y tienen sufijos distintos.

El segundo prefill puede reutilizar el estado de esos cuatro tokens, si el cache es compatible.

La continuación todavía debe generarse. Un hit de prefijo no recupera una respuesta completa.

La identidad decide el hit

El texto parece igual, pero los tokens o la revisión del modelo pueden haber cambiado.

La clave debe reflejar las dependencias reales y el aislamiento de acceso exigido.

Una coincidencia incompleta no autoriza reutilizar KV. La corrección precede al porcentaje de hits.

Proponer no es confirmar

El proposer adelanta tres tokens candidatos: A, B y C.

El target acepta A y B, rechaza C y produce D con el procedimiento correcto.

La secuencia confirmada es A, B, D. Los candidatos no verificados no deben llegar como salida definitiva.

Aceptar mucho no basta

Tres tokens normales cuestan doce unidades de tiempo en este ejemplo.

Proponer y verificar cuesta nueve en un caso, pero dieciocho en otro con igual salida confirmada.

Sólo el primero ahorra tiempo. Acceptance rate sin coste de propuesta y verificación es incompleta.

La rama rechazada se retira

Los candidatos especulativos también pueden reservar estado KV provisional.

Al rechazar C, su estado no puede tratarse como parte del prefijo confirmado.

El rollback conserva A y B y descarta la rama inválida. Mide también el coste del estado temporal.

Intercalar trabajo

Un prefill grande puede ocupar un intervalo durante el que otras peticiones esperan decode.

Dividirlo en chunks permite al scheduler intercalar pasos de generación.

La política cambia interferencia y eficiencia. Hay que medir ambas; fragmentar no acelera necesariamente cualquier carga.