Capítulo 14 de la serie Sprint DGX (desde el Capítulo 1). Cómo se conecta el VLM entrenado en H100s al PMS dental que ya estaba en producción.
QuantumHowl no parte de cero. El producto, un PMS dental con capa de IA, lleva tiempo desplegado en una clínica real, atendiendo pacientes cada día. No es una demo ni un roadmap en PowerPoint: es software en producción. Lo que el sprint DGX construye no es «el producto», sino la pieza más difícil de todas: el cerebro de visión, entrenado sobre infraestructura de clase DGX, listo para encajar en el sistema que ya existe. Este capítulo cuenta cómo se conecta esa nueva capa al producto sin tocar nada de lo que ya funciona, qué gana el dentista cuando entre y por qué la integración es casi un cambio de cable: el mismo contrato de siempre, mejor inteligencia por debajo.
El producto que ya existía
El producto es un PMS dental con capa de IA en producción. Vive en su propio repositorio, independiente de este sprint, y lleva tiempo desplegado en una clínica dental partner. Sus componentes operacionales:
| Capa | Tecnología | Estado |
|---|---|---|
| Frontend | React + Tauri (app de escritorio + web) | producción |
| Backend API | FastAPI + PostgreSQL + MinIO + Neo4j | producción, uptime alto |
| Capa agentic | una decena de agentes orquestados + system prompts | producción |
| VLM dental | modelo de visión y lenguaje con afinado dental | producción on-prem |
| Grafo de conocimiento | del orden de doce mil nodos y veinticinco mil relaciones SNOMED/ICD/MeSH | producción Neo4j |
| Datos | ~5.000 pacientes, cientos de miles de imágenes DICOM | producción |
| Contenedorización | una decena de contenedores Docker orquestados | producción |
| Anonimización | stripping de tags DICOM + filtro de PII | conforme a RGPD |
Hace cosas concretas en clínica: chat diagnóstico, programación de citas, predicción de no-shows, recordatorios a pacientes, asistencia farmacéutica con verificación de alergias / embarazo / anticoagulantes, gestión de inventario, facturación. El sistema corre 24/7 sobre hardware on-prem en la clínica. El uptime acumulado es alto y sin incidencias relevantes.
El producto ya existe. El sprint no compite con eso ni lo reemplaza. Entrena una capa específica, la del VLM dental especializado, sobre una infraestructura de clase DGX, y la deja lista para encajar en el sistema que ya está en producción.
La capa que el sprint entrena
El VLM dental especializado que el sprint produce (Gemma 4 31B-IT con las etapas 1+2+3 entrenadas, el checkpoint canónico v0bis-2) aporta tres propiedades que elevan de forma sustancial la calidad de la capa de inteligencia:
- Modelo base más grande y capaz (31B): más capacidad de razonamiento clínico, especialmente en casos ambiguos donde los modelos más pequeños se quedan cortos.
- VLM multimodal real: panorámicas, intraorales y periapicales procesadas con visión integrada, no con descripción textual de imágenes generada por fuera.
- Bilingüe nativo ES/EN: paridad estadística verificada en los probes propios, no asumida.
Estas propiedades requieren hardware con holgura de memoria, y ahí entra el target del sprint: una NVIDIA DGX Spark de 128 GB de memoria unificada, donde el modelo completo en BF16 cabe cómodo, sin recortar precisión. Es la pieza que la infraestructura on-prem podrá servir cuando llegue a la clínica.
Cómo se integra
El path de integración no requiere refactorizar el producto. El cliente del PMS ya habla chat completions compatible con OpenAI de forma nativa. Servimos el VLM con vLLM sobre REST compatible con OpenAI, exponiendo exactamente el mismo contrato que ya consumía la capa de inferencia anterior.
La arquitectura del deploy primario, descrita en prosa: en la clínica, on-prem, la app de escritorio Tauri (React) habla con el orquestador FastAPI que ya está en producción. Ese orquestador es la pieza que no cambia de forma: lo único que cambia es la URL del endpoint del VLM, que pasa a apuntar a un vLLM local sirviendo Gemma 4 31B-IT en BF16 sobre memoria unificada. El routing agentic sigue por su lado, con su modelo base y sus system prompts. El hardware target es una DGX Spark de 128 GB de memoria unificada.
┌─────────────────────────────────────────────────────────────┐
│ Clínica on-prem (cliente final) │
│ │
│ ┌──────────────────┐ ┌────────────────────────────────┐ │
│ │ App escritorio │ │ Orquestador FastAPI │ │
│ │ Tauri (React) │◄──►│ (el PMS que ya está en prod) │ │
│ └──────────────────┘ │ │ │
│ │ - Envuelve el endpoint vLLM │ │
│ │ - Routing agentic │ │
│ └─────────────┬──────────────────┘ │
│ │ │
│ ┌────────────────────────────────┴────────────┐ │
│ │ │ │
│ ┌────▼──────────────┐ ┌───────────▼─────┐ │
│ │ vLLM serve │ │ Capa agentic │ │
│ │ Gemma 4 31B-IT │ │ (modelo base │ │
│ │ BF16, mem unif. │ │ + system │ │
│ │ REST OpenAI-compat│ │ prompts + │ │
│ │ /v1/chat/ │ │ safety a nivel │ │
│ │ completions │ │ de registry) │ │
│ └───────────────────┘ └─────────────────┘ │
│ │
│ Hardware: NVIDIA DGX Spark 128 GB de memoria unificada │
└─────────────────────────────────────────────────────────────┘Características del deploy:
- Los datos del paciente nunca salen del edificio: deploy 100 % on-prem, sin llamadas a la nube para inferencia.
- Mismo contrato OpenAI-compatible: el orquestador FastAPI que ya está en producción solo cambia la URL del endpoint del VLM.
- Mismo modelo agentic: el routing sigue funcionando con su modelo base, sus system prompts y sus chequeos de seguridad a nivel de registry. Lo que mejora es la calidad de la inferencia por debajo.
Lo que el producto recibe del sprint
Del sprint entran al producto cuatro activos:
- El VLM canónico v0bis-2 (Gemma 4 31B-IT tras las etapas 1+2+3): un upgrade de inferencia. Las mismas funcionalidades del producto (chat diagnóstico, lectura de panorámicas, etc.) con mejor calidad clínica. Métricas verificables: +6,72 pp en MMOral closed en inglés (p=0,0027), +7,13 pp en español bilingüe (p=0,0001), cero olvido catastrófico.
- El pipeline RGPD-clean del DICOM: anonimización y cadena de custodia operacionales. El producto puede onboardear nuevos pacientes y procesar imágenes con garantías formales documentables.
- Los probes panorámico e intraoral bilingües: una batería de tests propia que se integra al CI del producto para regression testing de futuros updates del modelo.
- El script de anonimización de DICOM: un pipeline reusable de onboarding de datos para futuras clínicas, que toma las imágenes crudas y deja una versión sin PII residual.
Lo que cambia para el cliente final
Del lado de la UX, prácticamente nada. El médico abre la misma app Tauri, ve la misma interfaz, chatea con el mismo agente. El cambio está por debajo:
- Mejor calidad de respuesta clínica en queries complejas.
- Multimodalidad real sobre panorámicas e intraorales: las respuestas pueden referirse a regiones específicas de la imagen, no a una descripción genérica.
- Paridad bilingüe: las queries en español tienen una accuracy verificada equivalente a las de inglés, sin fallback interno a inglés.
- Latencia consistente: el clínico no espera de forma arbitraria.
Lo que NO cambia:
- El mismo workflow del médico.
- El mismo pipeline de ingestión de DICOM.
- La misma UI Tauri.
- El mismo deploy on-prem.
- Las mismas garantías de seguridad (modelo agentic base + system prompts + chequeos de registry).
El producto sigue siendo el producto
El sprint produce activos, no producto. El producto existía antes del día 1 y existirá después del día 60. Lo que se entrega al cierre del sprint es:
- Una capa de IA mejorada lista para integrar (el checkpoint canónico v0bis-2).
- Un pipeline de integración REST OpenAI-compatible validado, que encaja en el orquestador sin refactor.
- Una documentación reproducible de cómo se entrenó y por qué se tomaron las decisiones que se tomaron (esta serie de capítulos).
- Un plan de deploy on-prem sobre DGX Spark respaldado por benchmarks BF16 y análisis de encaje de memoria.
El cliente final compra el producto, no el sprint. El sprint hace que el producto sea mejor. Esa es la relación correcta.
Estado al cerrar el sprint
- El VLM canónico v0bis-2 fusionado y listo para desplegar sobre DGX Spark.
- El pipeline de integración REST OpenAI-compatible validado.
- El PMS operacional, ahora con una capa de IA actualizable.
- El producto sigue produciendo valor en clínica desde el día 1, sin downtime durante el sprint.
- Roadmap post-sprint: despliegue de la nueva capa de visión sobre DGX Spark en la clínica, y extensión a nuevas clínicas a medida que se incorporan.
Preguntas frecuentes
¿El dentista tiene que cambiar algo en su día a día? No. Abre la misma app, ve la misma pantalla y chatea con el mismo agente. La nueva capa de visión mejora la calidad de las respuestas por debajo, sobre todo en casos complejos y multimodales, sin pedirle que cambie su flujo de trabajo.
¿Por qué corre on-premise y no en la nube? Porque ni una sola imagen del paciente sale del edificio. El modelo completo cabe en una NVIDIA DGX Spark de 128 GB de memoria unificada dentro de la propia clínica, así que no hay datos sanitarios viajando a un servidor de terceros ni dependencia de la conexión. En un sector donde el dato es especialmente sensible, «se queda en casa» es una ventaja de partida.
¿Qué aporta esta capa frente a la versión anterior? Un modelo base más grande y capaz, visión multimodal real sobre radiografías y paridad bilingüe ES/EN verificada con pruebas propias: +6,72 pp en inglés (p=0,0027) y +7,13 pp en español (p=0,0001) en un examen público de conocimiento dental, con cero olvido catastrófico. Mejor inteligencia clínica, mismo contrato de integración.
Próximo capítulo: día 60, lo que queda construido tras 60 días. Un modelo que ve la radiografía, razona en dos idiomas y vive on-premise, listo para llevar a más clínicas.
