Hi3D v1.0 es de código abierto: qué exige realmente la afirmación sobre impresión 3D

Hi3D v1.0 se publicó en GitHub y Hugging Face el 23 de octubre de 2026 con un número adjunto: 90% de éxito de laminado. Ese número es la razón entera por la que un taller de impresión 3D debería interesarse por el lanzamiento, y también es el único número que el repositorio no puede reproducir. No hay ningún laminador en él, ni mallas de prueba, ni línea base, ni una definición de qué cuenta como fallo. Lo que sí hay en el repositorio es sustancial: código de inferencia, ocho archivos de pesos y un pipeline que toma una fotografía de referencia junto con una malla aproximada y devuelve una mucho más densa, hasta una rejilla de extracción dispersa efectiva de 1536³. Así que la pregunta útil no es si Hi3D v1.0 funciona. Es qué tiene que ser cierto a su alrededor antes de que salga una pieza imprimible por el otro extremo.

Qué se lanzó, exactamente

El lanzamiento consiste en la publicación como código abierto de Sparc3D —el paquete de Python y la API pública aún conservan los nombres sparc3d y Sparc3DPipeline por compatibilidad, y el artículo subyacente data de mayo de 2025—. El repositorio de GitHub se abrió con seis commits y una sola etiqueta; la tarjeta de Hugging Face indica que el modelo se publicó el 23 de octubre de 2026 y, en el mismo panel, que «no está desplegado por ningún proveedor de inferencia». No hay ningún endpoint alojado para v1.0. El producto comercial es un v3.0 separado y propietario, con geometría de 2048³ y texturas de hasta 8K.

• Qué contiene el repositorio — código de inferencia, una demo, Docker y restricciones de dependencias, y documentación. Faltan el código de entrenamiento, el arnés de evaluación del artículo, las particiones de benchmark y las mallas de comparación que respaldan la tabla principal, y el README lo dice claramente.

• Qué son los pesos — ocho archivos de tiempo de ejecución: un índice de modelo, una configuración de scheduler, una configuración de VAE y safetensors, y dos configuraciones de transformer y safetensors. Los codificadores de imagen, facebook/dinov2-large y openai/clip-vit-large-patch14, se cargan por separado en el primer uso y no forman parte del directorio del modelo.

• Cómo lo instalas — Python 3.10, PyTorch 2.5.0 con CUDA 12.4, flash-attn==2.7.4.post1, spconv-cu120==2.3.6, instalado desde el código fuente. No hay rueda de PyPI ni versión precompilada.

• Qué licencia se aplica — el Acuerdo de Licencia Abierta Hi3D 1.0. No es una licencia OSI. Se permite el uso comercial, pero un producto o servicio que supere los 200.000 usuarios activos mensuales o los 1.000.000 USD de ingresos mensuales debe notificar a Hi3D y solicitar una licencia por escrito independiente en un plazo de 60 días, y las integraciones deben mostrar «Powered by Hi3D 1.0» con un enlace cuando el medio lo admita.

El enfoque que se da en la cobertura del lanzamiento es que se trata de un modelo de imagen a 3D de «grado de producción industrial». La propia página de anuncio del proveedor sí afirma que ha sido «validado en flujos de trabajo de producción reales» y que la evaluación abarcó la apariencia multivista, el detalle local y la usabilidad geométrica. No menciona ni un solo cliente, flujo de trabajo o resultado medido. Eso es una afirmación sobre la producción, no una prueba de ella.

El reclamo de impresión, desglosado en cuatro requisitos

Una pieza que sale de una impresora tiene que cumplir cuatro cosas que no tienen nada que ver con lo impresionante que se vea un render. Hi3D v1.0 aborda bien una de ellas, otra de forma parcial y dos en absoluto.

• Escala — desaparece por diseño. La salida se vuelve a centrar y se normaliza a un radio máximo unitario. El tamaño absoluto y las coordenadas del mundo no se conservan, así que cada modelo debe reescalarse a milímetros antes de que signifique algo. Si tu foto de referencia proviene de un objeto real y necesitabas sus dimensiones verdaderas, Hi3D no las transmite. El repositorio lo dice explícitamente en lugar de callarlo, lo cual es digno de crédito, pero significa que la escala es un paso del que tú te encargas.

• Topología — heredada de la entrada, no reparada. Hi3D toma una malla gruesa y le añade detalle. Si esa malla gruesa tiene aristas no manifold, autointersecciones o normales invertidas, el refinamiento las hace más finas, no las corrige. La propia sección de limitaciones del README dice que «la estructura gruesa importa» y que los errores graves de la malla gruesa pueden persistir. Un slicer seguirá atascándose con los mismos defectos, solo que a mayor resolución. Esta es la frase más importante del lanzamiento para cualquiera que lo apunte a una impresora.

• Superficie — ausente. La salida es un trimesh.Trimesh solo de geometría: sin texturas, sin materiales, sin colores de vértices. Para impresión de un solo material, en gran medida no supone un problema, porque se imprime material en lugar de mapas UV. Para cualquier cosa que necesite un resultado pintado o multicolor, o para una vista previa del cliente que tenga que parecerse al producto, resulta descalificador y te empuja a la v3.0.

• Imprimibilidad — sin evaluar. Nada en el repositorio mide el grosor de pared, el tamaño mínimo de las características, los voladizos ni si la malla es estanca después del refinamiento. La cifra del 90 % de laminado está en la nota de prensa, no en el código, y no se nombra ningún laminador. Además, un archivo laminado no es una pieza impresa: el éxito del laminado no te dice si la impresión se adherirá, resistirá los soportes o mantendrá la tolerancia.

Los números, ordenados por lo que realmente los respalda

El comunicado mezcla afirmaciones con niveles de sustento muy distintos. Meterlas todas en el mismo saco es lo que hace que una cifra del proveedor se convierta en un hecho en una decisión de compra.

• Alrededor de dos millones de recursos 3D curados — así se indica en la nota de prensa y en la tarjeta del modelo, y es coherente con el linaje de Sparc3D, que el artículo anterior describía con aproximadamente 500.000 recursos. No se puede auditar la curaduría desde el repositorio, porque ni el conjunto de datos ni el código de entrenamiento se distribuyen. Trátalo como una cifra creíble del proveedor, no como una cifra verificada.

• resolución efectiva de 1536³ — esta sí es real como configuración. El pipeline ejecuta una pasada para 512³, dos para 1024³ y tres para 1536³, con 25 actualizaciones del planificador por pasada de forma predeterminada. La palabra «efectiva» importa: estas son rejillas nominales dispersas de coordenadas y de extracción, no un tensor latente denso de 1536³. El README también señala que la configuración de 1536³ solo se ha validado en una H20 de 96 GB y que la viabilidad y la memoria máxima en tarjetas más pequeñas no se especifican.

• 90% de éxito en el corte — reportado por el proveedor, no reproducido y sin metodología. Ningún laminador, ninguna definición de fallo, ninguna línea base, ningún conjunto de pruebas. Es la cifra más citable del lanzamiento y la menos verificable.

• Máxima fidelidad multivista y riqueza de detalles — presentado como el resultado de «la evaluación reportada», que no está en el repositorio. No hay tabla comparativa, ni lista de competidores, ni desglose por categoría.

• "Validado en flujos de trabajo de producción reales" — una frase en la página del anuncio, sin ningún socio nombrado, sin caso práctico y sin flujo de trabajo descrito. Bien puede ser cierto. Todavía no es una prueba.

La barrera del hardware

El stack medido es una NVIDIA H20 de 96 GB, y el repositorio reconoce honestamente que esta es la máquina en la que se validó la configuración máxima. Los requisitos asociados son igualmente específicos: Linux, capacidad de cómputo 8.0 o superior, CUDA 12.0 a 12.5 y ninguna ruta de inferencia por CPU. flash-attn no tiene una implementación de atención de reserva, por lo que un fallo de compilación allí es fatal en lugar de degradarse. El tamaño de lote es uno.

La descarga secuencial a CPU está soportada y reduce la residencia en GPU, pero el README se cuida de señalar que no establece un requisito mínimo de memoria de GPU y no elimina el coste de las características decodificadas. En la práctica, eso significa que la ruta de una sola pasada de 512³ podría caber en una tarjeta de 24 GB, pero nadie ha publicado una tabla de memoria, y el proveedor no lo ha afirmado. Si tu plan depende de una 4090, estás ejecutando una configuración no verificada y deberías medirla y cronometrarla tú mismo antes de comprometerte.

Así se ve un flujo de impresión que funciona

Hi3D v1.0 es una sola etapa. El repositorio incluye un adaptador opcional que usa Hunyuan3D-2 mini de Tencent para producir la malla gruesa a partir de una sola imagen; Hunyuan es de terceros y no es una dependencia de la biblioteca principal, pero sin algo como eso no tienes ninguna entrada.

Así que la secuencia real es: generar u obtener una malla gruesa, refinarla con Hi3D a 512³, 1024³ o 1536³, exportar la geometría, reescalarla a dimensiones reales, reparar toda la topología que la etapa gruesa dejó mal, verificar la estanqueidad y, por último, laminar. Tres de esos pasos —reparación, estanqueidad y laminado— no tienen equivalente en ninguna parte de la versión, y es en el primero donde realmente se producirán la mayoría de los fallos.

OrcaRouter no aloja Hi3D v1.0 ni ningún otro modelo 3D, y no va a devolver una malla imprimible a partir de una llamada a la API. Lo que sí aloja es el trabajo de texto y visión en torno al pipeline: redactar el brief del objeto, generar el pie de foto de la imagen de referencia y evaluar los renders multivista en busca de defectos antes de que gastes tiempo de GPU en una pasada de 1536³. Eso es un endpoint para más de 200 modelos con failover automático, lo cual resulta útil cuando las comprobaciones circundantes son la parte que no quieres construir tú mismo. El paso 3D se queda en tu propio hardware.

¿Quién debería descargarlo esta semana?

Si ya tienes en producción un generador de mallas de baja resolución —Hunyuan3D-2 mini, TripoSR o una etapa interna— y tu cuello de botella es que las mallas se ven blandas, Hi3D v1.0 merece un día de tiempo de GPU. La ruta de 512³ es el punto de partida; la ruta de 1536³ requiere la tarjeta de clase H20 que usó el proveedor.

Si tu requisito es «una fotografía entra, una pieza imprimible sale», esta versión no hace eso, y el marketing que la rodea tampoco. Sigues necesitando la primera etapa, la etapa de reparación y el laminador, y la cifra del 90 % no se traslada a tus objetos, tu material ni tu impresora.

Si necesitas texturas, color o un render para el cliente, espera a la v3.0 o usa otra opción. Trabajar solo con geometría es un límite estricto, no una carencia temporal.

Lo que cambiaría el veredicto es acotado y concreto: un laminador identificado, un conjunto de pruebas publicado, una taxonomía de fallos y una línea base —idealmente, la malla gruesa sin refinar, para que el lector pueda ver qué aportó realmente el refinamiento. Una tabla de memoria y latencia para las tres resoluciones en más de una GPU resolvería la cuestión del hardware. Hasta que exista alguno de esos elementos, la descripción honesta de Hi3D v1.0 es la de un refinador de geometría potente y genuinamente abierto, con una afirmación de producción añadida antes de la evidencia que la respalde.