Hi3D V1.0 : six commits dans le dépôt, « validé en production » en conditions réelles

Le 23 octobre 2026, Hi3D V1.0 est apparu sur GitHub avec six commits, un seul tag et huit fichiers de poids. En l’espace d’une journée, la même version circulait dans les agences de presse avec un titre qui la présentait comme « le premier modèle 3D d’IA open source validé en production ». Les deux affirmations sont vraies. Une seule est vérifiable, et l’écart entre les deux est ce qu’un utilisateur potentiel a le plus intérêt à comprendre au sujet de cette version.

Le dépôt mérite d’être considéré pour ce qu’il est. Hi3D V1.0 est la continuation open source de Sparc3D, les travaux NeurIPS 2025 sur la représentation 3D à grille éparse. Ce n’est pas un générateur text-to-3D. Vous lui fournissez une image de référence et un maillage grossier qui existe déjà, et il renvoie un maillage plus dense. Cette distinction détermine si la publication vous est utile ou non, il vaut donc la peine de la préciser avant tous les chiffres de qualité : si vous cherchiez quelque chose qui transforme une phrase en objet, ce n’est pas le bon artefact.

Qu'y a-t-il réellement dans le dépôt ?

Cette version est dédiée à l’inférence uniquement. Le code échantillonne des latents épars, les décode via un VAE épars à élagage automatique et extrait un maillage ; la gamme de modèles effectue trois passes sur des grilles structurelles nominales de 64³, 128³ et 192³, produisant des grilles d’extraction éparses étiquetées 512³, 1024³ et 1536³. Une exécution en 512³ utilise une passe, 1024³ en utilise deux et 1536³ en utilise trois, avec 25 mises à jour du planificateur par passe. La sortie est de la géométrie et rien d’autre : pas de textures, pas de matériaux, pas de couleurs de sommets, taille de lot un, et le résultat est recentré et normalisé à un rayon unitaire, ce qui supprime l’échelle absolue.

Ce qui est absent compte autant que ce qui est présent. Il n’y a pas de code d’entraînement, pas de harnais d’évaluation, pas de partitions de benchmark ni de maillages de comparaison. Le package Python conserve l’ancien nom — sparc3d, avec un point d’entrée Sparc3DPipeline — ce qui rappelle utilement qu’il s’agit de la base de code de recherche avec une nouvelle étiquette, et non d’un nouveau build. L’adaptateur de démonstration facultatif est construit sur Hunyuan3D-2 mini de Tencent et possède sa propre licence, distincte de celle de Hi3D.

La liste des dépendances est courte et intransigeante : Linux, Python 3.10, un GPU NVIDIA avec une capacité de calcul 8.0 ou supérieure, CUDA 12.0–12.5 correspondant à la version de PyTorch utilisée, et flash-attn sans solution de repli. Il n’y a pas d’inférence sur CPU. La configuration sur laquelle Hi3D a effectué ses mesures était un seul H20 de 96 Go, et le dépôt indique que 1536³ n’a été validé que sur ce GPU. DINOv2-large et CLIP-ViT-L/14 sont téléchargés séparément au moment de l’exécution.

« Validé en production » est une formule, pas une mesure.

Le communiqué ne définit pas le terme. La base annoncée est que l’équipe « l’a testé dans des flux de production réels afin d’en améliorer l’utilisabilité pratique » avant de le publier en open source. C’est la description d’un dogfooding interne, ce qui est une chose raisonnable pour une entreprise, mais un argument faible à mettre en titre. Aucun client n’est nommé, aucun nombre de déploiements n’est indiqué, aucune donnée sur le taux d’échec n’est fournie et aucun tiers n’est impliqué. Le communiqué ne cite par ailleurs personne : il nomme un contact presse et n’attribue aucune déclaration à quiconque.

Ce n’est pas un scandale. C’est ainsi que fonctionnent les communiqués des fournisseurs, et Hi3D est loin d’être le pire contrevenant. Mais l’expression joue ici un rôle précis. « Validé en production » invite le lecteur à supposer qu’un usage indépendant en production a été observé et mesuré. Ce que le communiqué étaye est plus étroit : le fournisseur a utilisé son propre modèle dans ses propres flux de travail. Ce sont des affirmations différentes, et seule la seconde est attestée.

La même retenue devrait s’appliquer aux chiffres de qualité. La communication en anglais indique que le modèle a obtenu « les meilleurs scores de fidélité multi-vues et de richesse des détails dans l’évaluation rapportée », sans publier les scores. Les articles en chinois consacrés au même lancement les fournissent : fidélité multi-vues 0,75 ; richesse des détails 0,841 ; un score de préférence humaine de 85,9 % ; et un taux de réussite du découpage revendiqué d’environ 90 %, contre 7 à 17 % pour des modèles grand public non précisés à 1536³. Chacun de ces chiffres est déclaré par le fournisseur. Aucun n’a fait l’objet d’une réplication indépendante, et le dépôt ne peut pas les reproduire, car le harnais d’évaluation n’a pas été livré.

Le chiffre de 90 % pour le découpage est celui à prendre avec des pincettes. Il ne précise pas de slicer, ne fournit pas de maillages de test, ne définit pas ce qui compte comme un échec, et aucun modèle de référence n’est nommé dans la version anglaise de l’annonce. Il est peut-être tout à fait exact. Pour l’instant, ce n’est pas une preuve sur laquelle un acheteur puisse s’appuyer pour agir.

Le nombre qui, lui, a changé : de 500 000 à 2 000 000

Sous les affirmations sur la qualité se cache l’assertion la plus concrète de cette annonce. Hi3D affirme que les données d’entraînement sont passées d’environ 500 000 actifs 3D sélectionnés à environ deux millions. Cela représente une multiplication par quatre par rapport à la base de référence Sparc3D et, contrairement aux scores de préférence, il s’agit d’une affirmation dont le référent est clair : un décompte d’actifs que l’équipe dit avoir sélectionnés.

Il reste non auditable. Le dépôt ne fournit ni manifeste de données, ni ventilation par catégorie, ni liste de provenance des licences, ni aucun outil d’échantillonnage. Vous ne pouvez pas vérifier ce qu’étaient les 1,5 million d’éléments supplémentaires, d’où ils venaient, ni s’ils chevauchent le jeu d’évaluation. L’affirmation est vérifiable en principe et non vérifiée en pratique, ce qui est la description honnête de la plupart des divulgations de données d’entraînement dans les versions ouvertes.

Ce que quatre fois plus de données permettent vraisemblablement d’obtenir, c’est précisément le point faible des modèles de raffinement : la généralisation à des catégories d’objets que le maillage grossier gère mal. Une étape de raffinement qui a vu davantage la longue traîne devrait être moins susceptible d’halluciner des détails plausibles mais erronés lorsque l’entrée est inhabituelle. C’est une hypothèse sur le comportement, pas une garantie, et la façon de la tester est sur vos propres ressources plutôt que sur un graphique de fournisseur.

Comment le vérifier vous-même à moindre coût

Cette publication est inhabituellement facile à falsifier pour un modèle dépourvu de benchmark. Comme l'entrée est un maillage grossier accompagné d'une photo, vous pouvez constituer en un après-midi un petit jeu de test honnête :

• Prenez vingt objets que vous possédez déjà sous forme de maillages scannés ou modélisés. Dégradez chacun d’eux en une version délibérément grossière — décimez, lissez ou faites-le passer par le générateur que vous utilisez déjà.

• Générez une image de référence propre par objet à partir d’une caméra connue, et conservez une seconde vue que vous ne montrez jamais au modèle.

• Affinez à 1024³ et 1536³, puis comparez la vue de validation à l’original. Vous mesurez si le détail supplémentaire est réel, et non s’il paraît net.

• Évaluez l’étanchéité, le caractère manifold et le nombre de triangles avant qu’un slicer ne s’en occupe. Si vous imprimez, faites le slicing avec le profil exact que vous utiliserez pour imprimer, et consignez les échecs plutôt que les réussites — c’est dans les cas d’échec que le chiffre du fournisseur ne fournit aucune réponse.

• Attention à la perte d’échelle. La normalisation à rayon unitaire signifie que le modèle ne préservera pas les dimensions réelles de votre saisie ; tout pipeline d’impression nécessite donc une étape de remise à l’échelle dont vous avez la responsabilité.

Vingt objets ne produiront pas un benchmark. Cela vous dira si ce modèle vaut cent, et c’est la décision qui attend la plupart des équipes cette semaine.

La licence est ouverte de la même manière qu’un essai est gratuit.

Les poids et le code propre à Hi3D relèvent du Hi3D Open License Agreement 1.0, qui n’est pas une licence approuvée par l’OSI et ne doit pas être décrit comme open source sans ce qualificatif. L’utilisation commerciale est autorisée. Deux conditions s’appliquent. Une intégration doit afficher « Powered by Hi3D 1.0 », et un produit qui dépasse 200 000 utilisateurs actifs mensuels ou 1 000 000 $ de revenus mensuels doit informer Hi3D et négocier une licence distincte dans un délai de 60 jours.

Pour un groupe de recherche ou un outil interne, aucune des deux clauses ne s'applique. Pour quiconque construit un service 3D commercial sur ces poids, les seuils sont suffisamment bas pour être anticipés plutôt que découverts. Les portions sous-jacentes de Sparc3D conservent leurs conditions d'origine Apache-2.0 et MIT, si bien que la licence est un assemblage hétérogène : certains fichiers sont réellement permissifs, d'autres non. Lisez les mentions au niveau des fichiers avant de redistribuer.

Le produit commercial est quelque chose de tout à fait différent. Hi3D vend la v3.0, décrite comme une géométrie 2048³ avec des textures allant jusqu’à 8K. La V1.0 est l’ancien modèle ouvert, uniquement géométrique. Personne ne devrait interpréter cette publication comme le fait que l’entreprise offre gratuitement son produit actuel ; elle offre gratuitement l’étape de perfectionnement de la génération précédente.

Où un routeur convient, et où, honnêtement, il ne convient pas

OrcaRouter ne fournit pas de modèles de géométrie 3D. Rien dans cet article ne doit être interprété comme une offre d’exécuter Hi3D V1.0 via notre API, car nous ne le pouvons pas. Le pipeline ci-dessus s’exécute sur votre GPU, ou il ne s’exécute pas.

La partie d’un workflow 3D qui est multimodale, en revanche, c’est la boucle de révision. Comparer un maillage affiné à sa photo de référence, vérifier si un rendu correspond au brief, consigner les défauts repérés sur une vue rotative — c’est du travail de modèle de vision, et c’est la partie que les équipes ont tendance à improviser en dernier. Une seule clé pour plus de 200 modèles de langage, de vision et d’audio signifie que la passe de contrôle qualité n’a pas besoin de son propre processus d’approvisionnement, et que le basculement automatique maintient une tâche de révision en cours lorsqu’un seul fournisseur connaît une dégradation. Si vous testez trois réglages d’affinage sur vingt objets, la partie coûteuse est le jugement, pas l’échantillonnage.

Qu’est-ce qui changerait cette évaluation ?

Trois choses, par ordre décroissant d’utilité. Un harnais d’évaluation publié avec les maillages de test et les réglages du slicer transformerait les 90 % en un nombre que quelqu’un d’autre peut reproduire. Un manifeste de données rendrait vérifiable l’affirmation des deux millions d’actifs. Une exécution par une tierce partie sur du matériel autre qu’un H20 de 96 Go établirait si 1536³ est un véritable point de fonctionnement ou une anecdote liée à un seul GPU.

D’ici là, la bonne posture est celle que le dépôt lui-même invite à adopter : le télécharger, l’exécuter sur des objets que vous comprenez, et traiter chaque pourcentage mis en avant comme une hypothèse. Hi3D V1.0 est un véritable modèle d’affinage téléchargeable, dédié à l’inférence, avec un seuil matériel exigeant et une licence qui cesse d’être gratuite à grande échelle. C’est une sortie utile. Elle n’est pas encore validée, quoi qu’en disent les dépêches.