Capítulo 5: MTP, DFlash y draft: módulos separados. En este capítulo aprenderás a distinguir tres rutas de aceleración especulativa sin confundir soporte técnico con validación local.

La decodificación especulativa parte de una idea sencilla. Un componente barato propone varios tokens y el modelo principal los verifica. Si la propuesta coincide con lo que el modelo principal habría producido bajo el protocolo de aceptación, se ahorra trabajo. Si no coincide, se corrige. Esa idea común no vuelve intercambiables a MTP, un draft externo y DFlash. Cada ruta usa un predictor distinto, carga artefactos diferentes y plantea preguntas propias de memoria, compatibilidad y aceptación.

MTP está integrado en la arquitectura del checkpoint. La configuración pública de Ornith declara una capa de predicción multitoken. Eso confirma estructura, no rendimiento. Para usarla, el runtime debe reconocer esa familia, conservar los tensores necesarios y manejar correctamente el estado de la arquitectura híbrida. El soporte existe en versiones recientes de runtimes relevantes, pero el MTP de Ornith no ha sido evaluado funcionalmente en el entorno local. No conocemos todavía su tasa de aceptación, su costo de memoria ni su efecto sobre latencia y throughput.

Un draft externo clásico es otro modelo, normalmente más pequeño, que genera propuestas antes de la verificación del target. Puede resultar útil si comparte un contrato compatible de tokenizer, vocabulario y rollback. Su tamaño por sí solo no predice una mejora. Si propone mal, el target rechaza más tokens y el costo adicional puede cancelar el beneficio. El inventario de posibles drafts indica opciones para investigar; no prueba que alguna funcione bien con Ornith.

DFlash también es un artefacto auxiliar, pero no es un pequeño modelo autoregresivo convencional. Propone bloques mediante un mecanismo de difusión y se acopla a características del target. Por eso necesita un drafter preparado para la combinación concreta, además del soporte correspondiente en el runtime. Que exista soporte upstream para la técnica no demuestra que el archivo disponible en ia-lab sea correcto, rápido o útil con el servidor actual.

El estado operativo debe mantenerse separado de esas posibilidades. Hoy llama.cpp está activo con Ornith Q4_K_L, KV Q4, tres slots y sin mmproj externo. Esa configuración es el baseline. El archivo DFlash está presente, pero permanece apagado y no validado. Tampoco hay una evaluación funcional de MTP. Las antiguas cifras de velocidad, latencia o multicontexto siguen pendientes de trazabilidad y no deben mezclarse con este baseline.

Conviene aclarar la procedencia. Fuente A documenta el estado local: el target activo, la prueba aislada de AWQ cercana a 261K y el archivo DFlash sin ejecutar. Fuente B aporta detalle histórico sobre perfiles y mediciones, aunque sin el paquete completo que permitiría repetirlas. Consenso significa que ambas investigaciones coinciden en separar MTP, draft y DFlash, y en exigir pruebas controladas. No significa que la coincidencia aumente por sí sola el nivel de evidencia. El audio no vuelve una fuente evidencia local; la evidencia local nace de ejecuciones registradas, no de la forma en que se narra.

La primera comparación segura debe cambiar una sola variable. Se conserva el target, el quant, el KV, los prompts, el muestreo, el contexto y la concurrencia. Después se prueba MTP en un perfil separado, con una versión fijada del runtime. En otra corrida se prueba DFlash, también por separado. Un draft clásico ocuparía una tercera rama. Mezclar dos técnicas en el mismo arranque impediría saber qué produjo un cambio.

Cada rama debe guardar hashes de pesos y draft, commit del runtime, comando completo, hardware, prompt set y salidas. Las métricas mínimas son tokens propuestos y aceptados, tasa de aceptación, tiempo al primer token, tiempo por token, throughput agregado, VRAM y errores. Hay que separar arranque frío de estado estable y repetir. La calidad también entra en el gate: JSON válido, llamadas de herramientas correctas, código ejecutable, español e inglés, contexto largo y comportamiento seguro.

La comparación con AWQ requiere la misma prudencia. AWQ W4A16 procesó una solicitud cercana a 261K con KV INT4, pero esa observación no demuestra concurrencia triple ni calidad equivalente frente a llama.cpp. Sirve como una celda del mapa experimental, no como veredicto sobre el mejor motor. Para comparar, hay que igualar tarea y criterios, y declarar las diferencias inevitables del backend.

Si una ruta acelera un prompt corto pero degrada herramientas, corrompe JSON o falla bajo contexto largo, no supera el gate. Si el promedio mejora y el percentil noventa y cinco empeora mucho, tampoco hay una victoria automática. La aceleración útil debe sostener el servicio completo, no una cifra aislada.

Confirmado hoy… llama.cpp sirve Ornith Q4_K_L con KV Q4, tres slots y sin mmproj externo; el archivo DFlash existe, está apagado y no ha sido validado localmente.

Falta demostrar… el funcionamiento de MTP, la compatibilidad y utilidad de DFlash, el desempeño de cualquier draft externo y la trazabilidad de las métricas históricas.

Siguiente capítulo… veremos LoRA y QLoRA como rutas de especialización que deben partir del checkpoint adecuado y someterse a la misma disciplina de evaluación.