Hi3D v1.0 é código aberto: o que a alegação sobre impressão 3D realmente exige

Hi3D v1.0 foi publicado no GitHub e no Hugging Face em 23 de outubro de 2026 com um número atrelado a ele: 90% de sucesso no fatiamento. Esse número é o motivo inteiro pelo qual uma loja de impressão 3D deveria se importar com o lançamento, e também é o único número que o repositório não consegue reproduzir. Não há slicer nele, nem malhas de teste, nem linha de base, e nenhuma definição do que conta como falha. O que realmente está no repositório é substancial: código de inferência, oito arquivos de pesos e um pipeline que recebe uma fotografia de referência mais uma malha aproximada e retorna uma bem mais densa, até uma grade efetiva de extração esparsa de 1536³. Portanto, a pergunta útil não é se o Hi3D v1.0 funciona. É o que precisa ser verdade ao redor dele para que uma peça imprimível saia do outro lado.

O que foi lançado, precisamente

O lançamento consiste na abertura do código-fonte do Sparc3D — o pacote Python e a API pública ainda mantêm os nomes sparc3d e Sparc3DPipeline por compatibilidade, e o artigo subjacente data de maio de 2025. O repositório no GitHub foi aberto com seis commits e uma única tag; o cartão de modelo do Hugging Face afirma que o modelo foi lançado em 23 de outubro de 2026 e, no mesmo painel, que ele "não é disponibilizado por nenhum Provedor de Inferência". Não há endpoint hospedado para a v1.0. O produto comercial é um v3.0 separado e proprietário, com geometria 2048³ e texturas de até 8K.

• O que o repositório contém — código de inferência, uma demo, Docker, restrições de dependências e documentação. Código de treinamento, a estrutura de avaliação do artigo, divisões de benchmark e as malhas de comparação por trás da tabela principal estão todos ausentes, e o README diz isso claramente.

• O que são os pesos — oito arquivos de runtime: um índice de modelo, uma configuração de scheduler, uma configuração de VAE e safetensors, e duas configurações de transformer e safetensors. Os codificadores de imagem, facebook/dinov2-large e openai/clip-vit-large-patch14, são carregados separadamente no primeiro uso e não fazem parte do diretório do modelo.

• Como instalá-lo — Python 3.10, PyTorch 2.5.0 com CUDA 12.4, flash-attn==2.7.4.post1, spconv-cu120==2.3.6, instalado a partir do código-fonte. Não há wheel no PyPI nem versão pré-compilada.

• Qual licença se aplica — o Hi3D Open License Agreement 1.0. Não é uma licença OSI. O uso comercial é permitido, mas um produto ou serviço que ultrapasse 200.000 usuários ativos mensais ou USD 1.000.000 de receita mensal deve notificar a Hi3D e solicitar uma licença escrita separada em até 60 dias, e as integrações devem exibir "Powered by Hi3D 1.0" com um link onde o meio suportar.

O enquadramento na cobertura do lançamento é de que se trata de um modelo image-to-3D "de nível de produção industrial". A própria página de anúncio do fornecedor afirma que ele foi "validado em fluxos de trabalho de produção reais" e que a avaliação abrangeu aparência em múltiplas vistas, detalhe local e usabilidade geométrica. Ela não nomeia um único cliente, fluxo de trabalho ou resultado medido. Isso é uma alegação sobre produção, não uma evidência dela.

A reivindicação de impressão, dividida em quatro requisitos

Uma peça que sai de uma impressora precisa satisfazer quatro coisas que não têm nada a ver com o quão impressionante uma renderização parece. O Hi3D v1.0 aborda uma delas bem, uma parcialmente e duas de modo algum.

• Escala — ausente por design. A saída é recentralizada e normalizada para um raio máximo unitário. O tamanho absoluto e as coordenadas de mundo não são preservados, então todo modelo precisa ser reescalado para milímetros antes de significar qualquer coisa. Se sua foto de referência veio de um objeto real e você precisava das dimensões verdadeiras, o Hi3D não as leva adiante. O repositório é explícito sobre isso em vez de ficar em silêncio, o que merece crédito, mas significa que a escala é uma etapa sua.

• Topologia — herdada da entrada, não reparada. O Hi3D pega uma malha grosseira e adiciona detalhe a ela. Se essa malha grosseira tiver arestas não manifold, autointerseções ou normais invertidas, o refinamento as torna mais finas, não as corrige. A própria seção de limitações do README diz que "a estrutura grosseira importa" e que erros graves na malha grosseira podem persistir. Um fatiador ainda vai engasgar com os mesmos defeitos, apenas em resolução mais alta. Esta é a frase mais importante do lançamento para quem for apontá-lo para uma impressora.

• Superfície — ausente. A saída é um trimesh.Trimesh apenas de geometria: sem texturas, sem materiais, sem cores de vértice. Para impressão de material único isso é em grande parte irrelevante, porque você imprime material, não mapas UV. Para qualquer coisa que precise de um resultado pintado ou multicor, ou para uma prévia de cliente que tenha de parecer o produto, é eliminatório e leva você para a v3.0.

• Imprimibilidade — não avaliada. Nada no repositório mede espessura de parede, tamanho mínimo de recurso, saliências ou se a malha é estanque após o refinamento. O número de 90% de fatiamento está no comunicado de imprensa, não no código, e nenhum fatiador é nomeado. Um arquivo fatiado também não é uma peça impressa: o sucesso do fatiamento não diz que a impressão vai aderir, sobreviver aos suportes ou manter a tolerância.

Os números, ordenados pelo que realmente os sustenta

O comunicado mistura alegações com níveis de fundamento muito diferentes. Metê-las todas no mesmo saco é como um número de fornecedor se torna um facto numa decisão de compra.

• Cerca de dois milhões de ativos 3D curados — declarado no comunicado à imprensa e no model card, e consistente com a linhagem Sparc3D, que o artigo anterior descrevia com aproximadamente 500.000 ativos. Não é possível auditar a curadoria a partir do repositório, porque nem o conjunto de dados nem o código de treinamento são disponibilizados. Trate-o como um número credível do fornecedor, não como verificado.

• resolução efetiva de 1536³ — esta é real como configuração. O pipeline executa uma passagem para 512³, duas para 1024³ e três para 1536³, com 25 atualizações do agendador por passagem por padrão. A palavra “efetiva” importa: estas são grades nominais esparsas de coordenadas e de extração, não um tensor latente denso de 1536³. O README também observa que a configuração de 1536³ foi validada apenas em um H20 de 96 GB e que a viabilidade e o pico de memória em placas menores não são declarados.

• 90% de sucesso no fatiamento — relatado pelo fornecedor, não reproduzido e sem metodologia. Nenhum fatiador, nenhuma definição de falha, nenhuma linha de base, nenhum conjunto de teste. É o número mais citável do lançamento e o menos verificável.

• Maior fidelidade e riqueza de detalhes em múltiplas vistas — apresentado como o resultado da “avaliação relatada”, que não está no repositório. Não há tabela comparativa, lista de concorrentes nem detalhamento por categoria.

• "Validado em fluxos de trabalho reais de produção" — uma frase na página de anúncio, sem parceiro nomeado, sem estudo de caso e sem fluxo de trabalho descrito. Pode muito bem ser verdade. Ainda não é evidência.

A barreira do hardware

A pilha medida é uma NVIDIA H20 de 96 GB, e o repositório é honesto ao afirmar que foi nessa máquina que a configuração máxima foi validada. Os requisitos circundantes são igualmente específicos: Linux, capacidade de computação 8.0 ou mais recente, CUDA 12.0 a 12.5 e nenhum caminho de inferência em CPU. O flash-attn não tem implementação de atenção alternativa, portanto uma falha de compilação ali é fatal em vez de degradada. O tamanho do lote é um.

O offload sequencial para CPU é suportado e reduz a residência na GPU, mas o README faz questão de dizer que isso não estabelece um requisito mínimo de memória da GPU e não elimina o custo das features decodificadas. Na prática, isso significa que o caminho de uma passada em 512³ pode caber em uma placa de 24 GB, mas ninguém publicou uma tabela de memória, e o fornecedor não reivindicou isso. Se o seu plano depende de uma 4090, você está executando uma configuração não verificada e deve cronometrar e medir você mesmo antes de se comprometer.

Como é um pipeline de impressão funcional

O Hi3D v1.0 é um único estágio. O repositório inclui um adaptador opcional que usa o Hunyuan3D-2 mini da Tencent para produzir a malha grosseira a partir de uma única imagem; o Hunyuan é de terceiros e não é uma dependência da biblioteca principal, mas sem algo do tipo você não tem entrada.

Então, a sequência real é: gerar ou obter uma malha grosseira, refiná-la com o Hi3D em 512³, 1024³ ou 1536³, exportar a geometria, redimensioná-la para as dimensões reais, reparar qualquer topologia que a etapa grosseira tenha errado, verificar a estanqueidade e, então, fatiar. Três dessas etapas — reparo, estanqueidade, fatiamento — não têm equivalente em nenhum lugar da versão, e é na primeira que a maioria das falhas realmente ocorrerá.

O OrcaRouter não hospeda o Hi3D v1.0 nem qualquer outro modelo 3D, e não vai retornar uma malha imprimível a partir de uma chamada de API. O que ele hospeda é o trabalho de texto e visão em torno do pipeline: escrever o briefing do objeto, descrever a foto de referência e avaliar renders de múltiplas vistas em busca de defeitos antes de você gastar tempo de GPU em uma passada de 1536³. Isso é um endpoint para mais de 200 modelos com failover automático, o que é útil quando as verificações ao redor são a parte que você não quer construir por conta própria. A etapa 3D fica no seu próprio hardware.

Quem deveria baixá-lo esta semana

Se você já tem um gerador de malha grosseira em produção — Hunyuan3D-2 mini, TripoSR ou uma etapa interna — e seu gargalo é que as malhas parecem pouco nítidas, o Hi3D v1.0 vale um dia de tempo de GPU. O caminho 512³ é por onde começar; o caminho 1536³ exige a placa da classe H20 que o fornecedor usou.

Se o seu requisito é “entra uma fotografia, sai uma peça imprimível”, esta versão não faz isso, e o marketing em torno dela também não. Você ainda precisa do primeiro estágio, do estágio de reparo e do fatiador, e o número de 90% não se transfere para os seus objetos, o seu material ou a sua impressora.

Se você precisar de textura, cor ou um render para apresentar ao cliente, aguarde a v3.0 ou use outra solução. Apenas geometria é um limite rígido, não uma lacuna temporária.

O que mudaria o veredito é estreito e específico: um fatiador nomeado, um conjunto de testes publicado, uma taxonomia de falhas e uma linha de base — idealmente a malha grossa não refinada, para que o leitor possa ver o que o refinamento realmente trouxe. Uma tabela de memória e latência nas três resoluções em mais de uma GPU resolveria a questão de hardware. Até que uma dessas coisas exista, a descrição honesta do Hi3D v1.0 é um refinador de geometria forte e genuinamente aberto, com uma alegação de produção anexada antes de suas evidências.