► Stacking Optimizations: Combinaciones Ganadoras

► Decisión Framework por Prioridad

► Sizing Óptimo: 1.64%-5% del Target Model

La investigación académica muestra que los draft models efectivos suelen ser entre 1.64% y 5% del tamaño del target model en parámetros.

Regla práctica: Para modelos de 7B-70B, busca draft models de 100M-1B parámetros. Más grande que eso y pierdes velocidad. Más pequeño y el acceptance rate cae demasiado.

► Model Family Alignment: Usa la Misma Arquitectura

El draft model debe ser de la misma familia arquitectónica que el target model para maximizar alignment y acceptance rate.

Por qué importa: Modelos de la misma familia comparten tokenizer, embeddings, y arquitectura de atención. Esto significa que sus distribuciones de probabilidad tienen mayor overlap, resultando en acceptance rates más altos (típicamente 0.6-0.7 vs 0.3-0.4 con familias diferentes).

► Acceptance Rate Threshold: El KPI Crítico

El acceptance rate (tasa de aceptación) es el porcentaje de tokens especulativos que el target model acepta. Es el KPI más importante para medir si speculative decoding está funcionando.

Qué hacer si acceptance rate

• Cambiar a un draft model más grande (↑ parámetros hasta 3-5% del target)
• Usar draft model de la misma familia que el target
• Si el target está fine-tuneado, re-entrenar el draft con knowledge distillation
• Reducir num_speculative_tokens (generar menos tokens especulativos por iteración)
• Considerar técnicas alternativas (quantization, prompt caching, chunked prefill)

► Domain-Specific Adaptation: El Problema del Fine-Tuning

Un pain point crítico que pocos artículos cubren: cuando fine-tuneas tu target model para un dominio específico, el draft model generic deja de funcionar bien.

Solución: Re-entrenar el draft model usando knowledge distillation del target model fine-tuneado. Proceso:

1. Genera un dataset de outputs del target model fine-tuneado (10k-50k ejemplos)
2. Fine-tunea el draft model para imitar las distribuciones del target
3. Usa temperature scaling y soft labels para capturar probabilidades, no solo tokens
4. Benchmarkea acceptance rate post-distillation (debería recuperar 0.6+)

IBM Research documentó este proceso con Granite 20B Code, entrenando un draft model específico para código que logró acceptance rate de 0.70 vs 0.45 con draft generic.

► Kubernetes Deployment con vLLM

Configuración production-ready para desplegar vLLM con speculative decoding en Kubernetes:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: vllm-speculative-llama70b
  namespace: ml-inference
spec:
  replicas: 2
  selector:
    matchLabels:
      app: vllm-llama70b
  template:
    metadata:
      labels:
        app: vllm-llama70b
    spec:
      containers:
      - name: vllm-server
        image: vllm/vllm-openai:v0.6.3
        args:
        - --model
        - meta-llama/Meta-Llama-3.1-70B-Instruct
        - --speculative-model
        - meta-llama/Llama-3.2-1B
        - --num-speculative-tokens
        - "5"
        - --gpu-memory-utilization
        - "0.90"
        - --tensor-parallel-size
        - "4"
        - --dtype
        - bfloat16
        - --max-model-len
        - "8192"
        - --port
        - "8000"
        ports:
        - containerPort: 8000
          name: http
        resources:
          requests:
            nvidia.com/gpu: 4
          limits:
            nvidia.com/gpu: 4
        env:
        - name: HF_TOKEN
          valueFrom:
            secretKeyRef:
              name: huggingface-token
              key: token
        livenessProbe:
          httpGet:
            path: /health
            port: 8000
          initialDelaySeconds: 120
          periodSeconds: 30
        readinessProbe:
          httpGet:
            path: /health
            port: 8000
          initialDelaySeconds: 60
          periodSeconds: 10
---
apiVersion: v1
kind: Service
metadata:
  name: vllm-service
  namespace: ml-inference
spec:
  selector:
    app: vllm-llama70b
  ports:
  - protocol: TCP
    port: 80
    targetPort: 8000
  type: LoadBalancer

► Monitoring con Prometheus + Grafana

Métricas críticas para monitorear speculative decoding en producción:

Script Python para exponer acceptance rate a Prometheus:

import time
import requests
from prometheus_client import start_http_server, Gauge

# Métricas Prometheus
acceptance_rate_gauge = Gauge(
    'vllm_speculative_acceptance_rate', 
    'Acceptance rate de tokens especulativos'
)

latency_p50_gauge = Gauge(
    'vllm_latency_p50_seconds', 
    'Latencia P50 en segundos'
)

goodput_gauge = Gauge(
    'vllm_goodput_tokens_per_second', 
    'Tokens válidos generados por segundo'
)

def fetch_vllm_metrics():
    """
    vLLM expone métricas en /metrics endpoint (Prometheus format)
    pero acceptance rate requiere parsing custom de logs o stats API
    """
    try:
        # Workaround: vLLM no expone acceptance rate directamente
        # Necesitas enable stats logging y parsear
        response = requests.get('http://localhost:8000/stats')
        stats = response.json()
        
        # Calcular acceptance rate desde stats
        total_speculative = stats.get('total_speculative_tokens', 0)
        accepted = stats.get('accepted_speculative_tokens', 0)
        acceptance_rate = accepted / total_speculative if total_speculative > 0 else 0
        
        acceptance_rate_gauge.set(acceptance_rate)
        latency_p50_gauge.set(stats.get('latency_p50', 0))
        
        # Goodput = accepted tokens / time
        goodput = accepted / stats.get('total_time_seconds', 1)
        goodput_gauge.set(goodput)
        
    except Exception as e:
        print(f"Error fetching metrics: {e}")

if __name__ == '__main__':
    # Exponer métricas en puerto 9090 para Prometheus scraping
    start_http_server(9090)
    
    while True:
        fetch_vllm_metrics()
        time.sleep(10)  # Scrape cada 10 segundos
 

► Alerting Thresholds y Rollback Strategy

Define alertas para detectar degradación y rollback automático si es necesario:

► Las Dos Observaciones Clave de Google Research

La técnica fue desarrollada originalmente por Google Research en 2022 y publicada en el paper "Fast Inference from Transformers via Speculative Decoding". Se basa en dos observaciones críticas:

Combinando estas dos observaciones, Google desarrolló speculative decoding: usar un modelo pequeño y rápido (draft model) para generar varios tokens candidatos especulativos, y luego usar el modelo grande (target model) para verificarlos todos en un solo forward pass paralelo.

► Cómo Funciona: Draft + Verification en Paralelo

El algoritmo tiene cuatro pasos principales:

La magia está en el paso 2: verificar K tokens en paralelo es casi tan rápido como verificar 1 token, porque el cuello de botella es cargar los pesos del modelo en memoria, no hacer los cálculos. Si aceptas 3 de 4 tokens especulativos en promedio, has generado 3 tokens válidos con el coste de 1 forward pass del modelo grande + 4 forward passes del modelo pequeño (que es 20-50x más rápido).

► Matemáticamente Idéntico al Autoregressive Normal

Un aspecto crítico que diferencia speculative decoding de otras técnicas de optimización (como beam search truncado o sampling con temperature alto) es que produce exactamente la misma distribución de probabilidad que generación autoregresiva normal.

Esto fue validado por Google Research en sus benchmarks originales de traducción y summarization, donde lograron 2x-3x speedup sin degradación en métricas BLEU/ROUGE.

► El Problema: Fragmentación del Ecosistema

Antes de Speculators, cada framework de inferencia tenía formato propietario para draft models:

• vLLM: Custom format, no standardized metadata
• TensorRT-LLM: Engine files compiled específicos NVIDIA GPUs
• llama.cpp: GGUF format, no compatible cross-platform
• PyTorch: Custom implementations sin interoperabilidad

► La Solución: Hugging Face Format Standardization

Red Hat Speculators introduce tres innovaciones clave:

► Modelos Speculators Pre-Entrenados (Nov 2025)

Red Hat lanzó 7 speculators production-ready:

► Benchmarks Production: Llama-4-Maverick 4.9x Speedup

El benchmark más impresionante: Llama-4-Maverick speculator logra hasta 4.9x latency reduction en high-throughput regime, contradiciendo conventional wisdom de que speculative decoding degrada con batch sizes altos.

Esto marca un turning point: speculative decoding ya NO es solo para low-latency single-request scenarios. Ahora es viable para high-throughput production workloads.

► Costes de Implementación

► Beneficios Cuantificables

Ejemplo cálculo startup SaaS chatbot:

► Trade-Off: Latencia vs Throughput

El trade-off fundamental de speculative decoding: optimizas latencia individual a costa de throughput máximo (en algunos escenarios).

► Problema #1: Acceptance Rate Invisible en vLLM

Causa raíz: vLLM

► Problema #2: Slowdown Inesperado en A100 (llama.cpp)

Causa raíz: Bug llama.cpp GPU utilization. Weights offloaded a GPU pero GPU no se usa durante speculative decoding phase. CPU bottleneck.

Soluciones:

• Solución #1: Usar vLLM en lugar de llama.cpp para production deployments (no tiene este bug)
• Solución #2: Si debes usar llama.cpp, actualizar a versión más reciente (bug parcialmente resuelto en 2024)
• Solución #3: Para A100, verificar que draft model también esté offloaded a GPU con `-ngl` flag

► Problema #3: Resource Contention Draft + Target (TensorRT-LLM)

Causa raíz: TensorRT-LLM NO maneja resource contention automáticamente. Necesitas custom async execution loop sincronizado.

Solución Baseten (production-verified):

Alternativa: vLLM maneja esto automáticamente con PagedAttention scheduler. Si no tienes equipo con expertise CUDA/C++, usa vLLM.

► Problema #4: TTFT (Time-to-First-Token) Degradation

Causa raíz: Draft model debe hacer prefill también. Overhead inicial de cargar dos modelos en lugar de uno.

Mitigaciones:

• Prefill optimization: Usar chunked prefill (vLLM feature) para reducir TTFT
• EAGLE-3: Self-speculative elimina overhead draft model prefill separado
• Prompt caching: Combinar con speculative decoding para amortizar prefill cost
• Trade-off acceptable: +50ms TTFT pero -60% latency total (usuarios perciben mejora)