Capítulo 1 de la serie Sprint DGX. Del pitch firmado a la primera semana operacional.
En abril de 2026 Quantum Howl accedimos a través de NVIDIA Innovation Lab a un grant de 60 días sobre un nodo 8×H100 SXM (640 GB VRAM) para entrenar dos modelos del producto dental-brain-agentic: un VLM multimodal dental y una capa de razonamiento clínico, ambos optimizados con el stack NVIDIA end-to-end para deploy en DGX Spark. Este capítulo cubre el pitch específico que se envió, qué cambia el día que arranca el cronómetro, y por qué la primera semana se dedicó a benchmarkar 4 candidatos VLM en lugar de empezar a entrenar el modelo prometido en el pitch original.
El programa
NVIDIA Innovation Lab es un programa para startups del NVIDIA Inception con acceso temporal a hardware DGX-class para validar una hipótesis técnica concreta. No es compute donado a granel; es un contrato implícito: prometes un entregable acotado, te dan el hardware durante una ventana definida, y reportas en mid-point y entrega final. La aplicación requiere un pitch específico, no «queremos investigar IA dental», sino qué modelos, qué stack, qué calendario, qué deliverable.
QuantumHowl entró al programa con producto en producción detrás: dental-brain-agentic lleva tiempo desplegado en una clínica real sobre una RTX 5070, con 13 contenedores Docker, 99,7% uptime, 5.241 pacientes acumulados y 252K imágenes DICOM procesadas. La hipótesis del pitch fue concreta: escalar la capa IA del producto entrenando dos modelos especializados sobre la infraestructura NVIDIA que será el target de deploy en clínicas (DGX Spark).
El pitch. Lo que se prometió
Dos modelos:
- VLM multimodal dental, escalando el LLaMA 3.2 11B Vision + dental LoRA que corre en producción, con QLoRA fine-tuning sobre 31+ datasets dentales (panorámicas, periapicales, intraorales, cefalometrías, CBCT, histopatología) más datos propios de la clínica.
- Capa de razonamiento clínico sobre Nemotron 3 Nano 8B para los 9 agentes LangGraph en producción (chat diagnóstico, predicción de no-shows, inventario, asistencia farmacéutica).
Stack NVIDIA end-to-end:
| Capa | Tecnología |
|---|---|
| Training | H100 vía DGX Innovation Labs |
| Data curation | NeMo Curator |
| Training framework | NeMo Framework |
| Inference | TensorRT-LLM (INT4 AWQ) |
| Serving | Triton Inference Server |
| Deploy target | DGX Spark |
Las desviaciones y sustituciones respecto a este stack se documentan en los capítulos 4 al 7.
Calendario 60 días:
- Días 1 a 15: Nemotron y benchmark VLM
- Días 16 a 45: pipeline 4-stage del VLM (DKI, DCA, SFT, RLT)
- Días 46 a 55: TensorRT-LLM y Triton
- Días 56 a 60: demo clínica end-to-end y case study
Lo que cambia cuando arranca el cronómetro
Cuando un grant científico arranca, el pitch deja de ser un documento de intenciones y pasa a ser el contrato implícito de entregables. La mid-point survey de Day 30 y el case study de Day 60 se evalúan contra el texto del pitch original, no contra lo que vas decidiendo sobre la marcha. Eso impone una disciplina específica al Day 1: releer el pitch separando compromisos por tipo de riesgo.
Compromisos verificables al firmar: el stack NVIDIA, el calendario por fases, el target DGX Spark, los modelos base candidatos. Auditados antes de enviar y cumplibles dentro del calendario.
Compromisos dependientes del hardware real: instance type, configuración del cluster, política de stop/start, paralelismo factible. No auditables hasta tener el nodo provisionado. El pitch dice «DGX Innovation Labs» porque eso es todo lo que se sabe antes del Day 0.
Compromisos sobre datos propios que requieren exports forenses: número de validaciones humanas reales, conteo del knowledge graph reproducible, estado de los pipelines de anotación. El conteo en producción es honesto según el schema conocido, pero la interpretación contractual de términos como «physician-validated» solo se cierra cuando los exports formales salen contra la base de datos de producción.
Esa tercera categoría es la que produce los matices que cualquier sponsor científico exigirá en mid-point. Entre el Day 3 y el Day 10, al ejecutar los exports formales contra PostgreSQL productivo, dos cifras del pitch necesitaron precisión:
- La tabla
diagnosescontenía 322 entradas, todas en estadopending. El conteo era honesto; lo que cambió fue precisar quependingno es physician-validated en el sentido contractual que un sponsor científico exigirá. La cifra correcta para mid-point: 0 diagnósticos formalmente validados y pipeline de validación clínica en curso para Day 60. - El knowledge graph reproducible Neo4j contenía 25.324 relaciones, no 49.484. La cifra mayor correspondía a una versión transitoria que existió durante un experimento y no era el grafo activo. La cifra correcta para mid-point: 25K+ relaciones SNOMED/ICD/MeSH reproducibles.
Ambos ajustes se documentaron para la mid-point survey sin esconderlos. Esa decisión, reportar las precisiones en lugar de mantener las cifras del pitch, es la que define cómo se cierra un grant científico con integridad.
Por qué la primera semana NO se dedicó a entrenar
El pitch firmaba LLaMA 3.2 11B Vision como modelo base del VLM. Era el que QuantumHowl tiene en producción, con dental LoRA ya entrenado. La decisión que se tomó el Day 1 fue no asumir que LLaMA 3.2 seguía siendo la mejor elección en abril de 2026. El panorama VLM se mueve trimestralmente, y arrancar 4 semanas de training sobre un modelo que un benchmark riguroso habría descartado es desperdiciar el grant.
La primera semana operacional (días 1 a 7) se dedicó a un benchmark multi-modelo sobre MMOral-Bench, un benchmark closed-ended y open-ended de razonamiento dental multimodal, con tres candidatos VLM:
- LLaMA 3.2 11B Vision (base original del pitch)
- Gemma 4 31B-IT (Google, Apache 2.0, dense)
- Qwen3-VL-8B (Alibaba, SOTA oct 2025)
Un cuarto modelo (Gemma 4 26B-A4B MoE) se descargó en disco como fallback pero no entró al benchmark formal. Se retuvo por si el constraint de framework cambiaba.
Los resultados, las decisiones estadísticas y el mail formal de pivot a NVIDIA son el contenido del Capítulo 2.
Estado al cerrar el Day 9
El nodo todavía no estaba operacional; el provisioning se resolvió el Day 11. El benchmark corría en local con un subset. Y la pregunta que definía todo lo que vendría después ya estaba encima de la mesa: si los datos confirmaban que LLaMA 3.2 no era el mejor modelo disponible para lo que habíamos prometido, ¿qué hacemos?
La respuesta llegó el Day 5. Es el Capítulo 2.
Próximo capítulo: el día 5, los datos del benchmark forzaron cambiar el modelo base del pitch. Gemma 4 31B-IT vs LLaMA 3.2 11B Vision, y el mail formal de pivot a NVIDIA el mismo día.
