Hi3D v1.0はオープンソース：3Dプリンティングの主張が実際に何を必要とするか

Hi3D v1.0は2026年10月23日にGitHubとHugging Faceで公開され、1つの数字が添えられていました：90%のスライシング成功率。その数字こそ、3Dプリントショップがこのリリースに注目すべき最大の理由であり、同時にリポジトリが再現できない唯一の数字でもあります。そこにはスライサーも、テスト用メッシュも、ベースラインも、何をもって失敗とするかの定義もありません。実際にリポジトリに入っているものはかなり充実しています。推論コード、8つの重みファイル、そして参照写真と粗いメッシュを受け取り、はるかに高密度なメッシュを返すパイプラインで、実効スパース抽出グリッドは最大1536³に達します。したがって、有用な問いはHi3D v1.0が機能するかどうかではありません。最終的に印刷可能な部品が得られるまでに、その周辺で何が成り立っていなければならないかです。

正確には、何がリリースされましたか

今回のリリースはSparc3Dのオープンソース化です。Pythonパッケージと公開APIは互換性のため、依然としてsparc3dおよびSparc3DPipelineという名前を保持しています。基盤となる論文は2025年5月にさかのぼります。GitHubリポジトリは6つのコミットと単一のタグで公開されました。Hugging Faceのカードには、モデルが2026年10月23日にリリースされたと記され、同じパネル内で「いずれのInference Providerによってもデプロイされていません」とあります。v1.0にはホストされたエンドポイントがありません。商用製品は別個のプロプライエタリなv3.0で、2048³のジオメトリと最大8Kのテクスチャを備えています。

• リポジトリに含まれるもの — 推論コード、デモ、Dockerと依存関係の制約、およびドキュメント。学習コード、論文の評価ハーネス、ベンチマークの分割、そして主要な表の背後にある比較用メッシュはすべて含まれておらず、READMEにもそのことが明記されています。

• 重みの内容 — ランタイムファイルは8つです。モデルインデックス、スケジューラ設定、VAE設定とsafetensors、および2つのtransformer設定とsafetensorsです。画像エンコーダーのfacebook/dinov2-largeとopenai/clip-vit-large-patch14は、初回使用時に別途読み込まれ、モデルディレクトリには含まれません。

• インストール方法 — Python 3.10、CUDA 12.4 対応の PyTorch 2.5.0、flash-attn==2.7.4.post1、spconv-cu120==2.3.6 をソースからインストールします。PyPI の wheel も事前ビルド済みリリースもありません。

• 適用されるライセンス — Hi3D Open License Agreement 1.0 です。これは OSI ライセンスではありません。商用利用は許可されていますが、月間アクティブユーザー数 200,000 人または月間収益 1,000,000 米ドルを超える製品やサービスは、Hi3D に通知し、60 日以内に別途書面によるライセンスを申請する必要があります。また、統合製品では、媒体がリンクをサポートしている場合はリンク付きで「Powered by Hi3D 1.0」を表示する必要があります。

リリース報道の論調は、これが「産業生産グレード」のimage-to-3Dモデルだというものだ。ベンダー自身の発表ページも、実際の生産ワークフローで検証済みであり、評価は多視点の見た目、局所的なディテール、幾何学的な使用可能性を対象にしたと主張している。しかし、顧客名、ワークフロー、測定された出力は一つも挙げていない。それは生産性に関する主張であって、その証拠ではない。

印刷クレームを4つの要件に分解したもの

プリンターから出てくる部品は、レンダーがどれほど印象的に見えるかとは無関係な4つの条件を満たさなければならない。Hi3D v1.0 はそのうち1つには十分対応しているが、1つには部分的にしか対応しておらず、2つにはまったく対応していない。

• スケール — 仕様により失われます。出力は再中心化され、最大半径が1になるよう正規化されます。絶対的なサイズやワールド座標は保持されないため、どのモデルも意味を持つ前にミリメートル単位へ再スケーリングする必要があります。参照写真が実物の物体から撮影されたもので、その実際の寸法が必要な場合、Hi3D はそれを引き継ぎません。リポジトリはこの点について沈黙せず明示しており、評価に値しますが、スケールは自分で担う工程になるということです。

• トポロジー — 入力から継承されたものであり、修復されるものではありません。Hi3Dは粗いメッシュを受け取り、そこに詳細を追加します。その粗いメッシュに非多様体エッジ、自己交差、反転法線がある場合、細分化はそれらをより細かくするだけで、修正はしません。README自体の制限事項セクションには「粗い構造が重要」とあり、深刻な粗メッシュのエラーは残る可能性があると述べています。スライサーは同じ欠陥で依然としてつまずくでしょう。違うのは、より高い解像度でそれが起きるという点だけです。プリンターで使おうとする人にとって、これはこのリリースで最も重要な一文です。

• Surface — なし。出力はジオメトリのみの trimesh.Trimesh です。テクスチャ、マテリアル、頂点カラーは一切ありません。単一マテリアルでの印刷では、UVマップではなくマテリアルを印刷するため、ほとんど問題になりません。しかし、塗装やマルチカラーの結果が必要な場合、あるいは製品らしく見えるクライアント向けプレビューが必要な場合は致命的であり、v3.0 へ移行せざるを得ません。

• 印刷適性 — 未評価。リポジトリ内には、壁厚、最小フィーチャサイズ、オーバーハング、またはリファインメント後にメッシュが水密かどうかを測定するものは何もない。90%スライスという数値はコードではなくプレスリリースにあり、スライサー名も明記されていない。スライスされたファイルは印刷済み部品でもない。スライスが成功しても、印刷が密着するか、サポートを外しても耐えられるか、公差を維持できるかは分からない。

数字を、実際に何が裏付けているかで並べ替えたもの

そのリリースは、裏付けの度合いが大きく異なる主張を混ぜ合わせている。それらを一括りにしてしまうことこそ、ベンダーが出した数字が購買判断における「事実」へと変わってしまうからくりだ。

• 約200万点のキュレーション済み3Dアセット — プレスリリースとモデルカードに記載されており、以前の論文が約50万点と述べていたSparc3Dの系譜とも整合する。データセットもトレーニングコードも提供されていないため、リポジトリからキュレーションを監査することはできない。これは検証済みの数値ではなく、信頼できるベンダー公称値として扱うべきだ。

• 1536³ の実効解像度 — これは設定としては実在します。パイプラインは512³で1パス、1024³で2パス、1536³で3パスを実行し、既定では1パスあたり25回のスケジューラ更新を行います。「実効」という言葉が重要です。これらは名目上のスパース座標グリッドおよび抽出グリッドであり、密な1536³の潜在テンソルではありません。READMEはまた、1536³設定が96 GBのH20でのみ検証済みであり、より小さいカードでの実現可能性とピークメモリについては明記されていないと述べています。

• 90%のスライス成功率 — ベンダー報告によるもので、再現されておらず、手法も定義されていない。スライサー、失敗の定義、ベースライン、テストセットのいずれもない。これはリリース中で最も引用しやすい数値でありながら、最も検証しにくい。

• マルチビューの忠実度と細部の豊かさが最高 — 「報告された評価」の結果として提示されているが、その評価はリポジトリに存在しない。比較表も競合他社の一覧も、カテゴリ別の内訳もない。

• 「実際の本番ワークフローで検証済み」 — 発表ページにある一文だが、提携先の名も、事例研究も、具体的なワークフローの説明もない。真実である可能性は十分ある。しかし、まだ証拠ではない。

ハードウェアの壁

実測済みのスタックは96 GBのNVIDIA H20であり、このリポジトリは、最高設定の検証が行われたマシンがこれであることを正直に示しています。周辺要件も同様に具体的です。Linux、コンピュートケイパビリティ8.0以降、CUDA 12.0～12.5、そしてCPU推論パスは一切ありません。flash-attnにはフォールバックのアテンション実装がないため、そこでのビルド失敗は縮退ではなく致命的です。バッチサイズは1です。

シーケンシャルCPUオフロードはサポートされており、GPU常駐量を削減しますが、READMEでは、それが最小GPUメモリ要件を確立するものではなく、デコードされた特徴量のコストを取り除くものでもないと慎重に述べています。実際には、512³のワンパス経路は24 GBカードに収まる可能性がありますが、メモリ表を公開した人はおらず、ベンダーもそれを主張していません。計画が4090に依存しているなら、未検証の構成で実行していることになるため、コミットする前に自分で時間を計測し測定するべきです。

実際に機能するプリントパイプラインとはどのようなものか

Hi3D v1.0は単一のステージです。リポジトリには、TencentのHunyuan3D-2 miniを使用して1枚の画像から粗いメッシュを生成するオプションのアダプターが同梱されています。Hunyuanはサードパーティ製であり、コアライブラリの依存関係ではありませんが、それに類するものがなければ入力が得られません。

つまり実際の手順は、粗いメッシュを生成または取得し、Hi3D で 512³、1024³、1536³ のいずれかを使ってリファインし、ジオメトリをエクスポートし、実寸法に再スケールし、粗い段階で誤ってしまったトポロジーを修復し、水密性を検証してからスライスする、という流れです。これらのステップのうち3つ——修復、水密性、スライス——には、このリリースのどこにも相当する機能がなく、しかも実際にほとんどの失敗が起きるのは最初のステップです。

OrcaRouterはHi3D v1.0やその他の3Dモデルをホストしておらず、API呼び出しから3Dプリント可能なメッシュを返すこともありません。OrcaRouterがホストするのは、パイプライン周辺のテキスト処理とビジョン処理です。具体的には、オブジェクトブリーフの作成、参照写真へのキャプション付け、1536³パスにGPU時間を費やす前にマルチビューレンダリングの欠陥を判定する作業です。それは200以上のモデルに対応する1つのエンドポイントであり、自動フェイルオーバーを備えており、周囲のチェックを自分で構築したくない場合に役立ちます。3Dステップはご自身のハードウェア上で実行されます。

今週は誰がそれをダウンロードすべきですか？

本番環境ですでに粗メッシュ生成器——Hunyuan3D-2 mini、TripoSR、または自社開発のステージ——を使っていて、メッシュが柔らかく見えることがボトルネックになっているなら、Hi3D v1.0 はGPUを1日使う価値があります。まずは512³のパスから始めるのがよいでしょう。1536³のパスには、ベンダーが使用したH20クラスのカードが必要です。

もしあなたの要件が「写真を1枚入れると印刷可能な部品が出てくる」ことなら、このリリースはそれを実現しておらず、それを取り巻くマーケティングも同様です。依然として最初の段階、修復段階、そしてスライサーが必要であり、その90%という数字はあなたのオブジェクト、材料、プリンターには当てはまりません。

テクスチャ、カラー、クライアント向けレンダリングが必要な場合は、v3.0 を待つか、別のものを使用してください。ジオメトリのみというのは一時的な不足ではなく、厳格な境界です。

判定を変えるものは、狭く具体的だ。名前の明示されたスライサー、公開されたテストセット、失敗分類、そしてベースライン——理想的には未精製の粗いメッシュで、読者が精製によって実際に何が得られたかを確認できるものだ。3つすべての解像度について、複数のGPUで測ったメモリとレイテンシの表があれば、ハードウェアに関する疑問は決着する。これらのいずれかが存在するまでは、Hi3D v1.0を正直に説明するなら、強力で真にオープンなジオメトリ精製ツールではあるが、その証拠に先んじて生産向けの主張が付け加えられたものだ。