Hi3D v1.0 是開源：3D 列印的主張實際上需要什麼

Hi3D v1.0 已於 2026 年 10 月 23 日在 GitHub 和 Hugging Face 上發布，並附上一個數字：90% 切片成功率。這個數字正是 3D 列印店家應該關心此版本發布的全部原因，也是該儲存庫無法重現的唯一數字。裡面沒有切片軟體、沒有測試網格、沒有基準線，也沒有定義什麼情況算失敗。儲存庫裡實際有的內容相當可觀：推論程式碼、八個權重檔案，以及一條流程，能接收一張參考照片加上一個粗略網格，並回傳一個密度高得多的網格，有效稀疏擷取網格最高可達 1536³。所以，有用的問題不是 Hi3D v1.0 是否有效，而是：在另一端產出可列印零件之前，周圍必須有哪些條件成立。

具體來說，發布了什麼

本次發布是 Sparc3D 的開源；Python 套件與公開 API 仍保留 sparc3d 和 Sparc3DPipeline 名稱以維持相容性，而基礎論文可追溯至 2025 年 5 月。GitHub 儲存庫最初以六個提交與單一標籤開啟；Hugging Face 模型卡指出該模型於 2026 年 10 月 23 日發布，並在同一面板中表示其「未由任何 Inference Provider 部署」。v1.0 沒有託管端點。商業產品則是獨立、專有的 v3.0，具備 2048³ 幾何與最高 8K 紋理。

• 儲存庫包含什麼——推論程式碼、一個示範、Docker 與相依性限制，以及文件。訓練程式碼、論文的評估測試框架、基準資料集切分，以及頭條表格背後的比較網格，全部付之闕如，而 README 也直言不諱地表明了這一點。

• 權重包含哪些內容 — 八個執行階段檔案：一個模型索引、一個排程器設定、一個 VAE 設定與 safetensors，以及兩個 transformer 設定與 safetensors。影像編碼器 facebook/dinov2-large 和 openai/clip-vit-large-patch14 會在首次使用時另行載入，不屬於模型目錄的一部分。

• 如何安裝 — Python 3.10、PyTorch 2.5.0（搭配 CUDA 12.4）、flash-attn==2.7.4.post1、spconv-cu120==2.3.6，從原始碼安裝。沒有 PyPI wheel，也沒有預先建置的版本。

• 適用哪種授權——Hi3D 開放授權協議 1.0。它並非 OSI 授權。允許商業使用，但若產品或服務的每月活躍使用者達到 200,000 人或每月營收達到 1,000,000 美元，必須在 60 天內通知 Hi3D 並申請另行簽署的書面授權；且整合項目必須顯示「Powered by Hi3D 1.0」，並在媒介支援連結時附上連結。

這則發布報導的定調是，這是一個「工業生產級」的圖像轉 3D 模型。供應商自家的公告頁面確實聲稱，它已「在真實生產工作流程中獲得驗證」，且評估涵蓋多視角外觀、局部細節與幾何可用性。但它沒有點名任何一家客戶、任何一個工作流程，或任何經測量的輸出成果。那是關於生產的斷言，不是生產的證據。

印刷聲明，拆解為四項要求

從印表機取下來的零件必須滿足四件事，而這四件事與渲染畫面看起來多麼出色毫無關係。Hi3D v1.0 妥善處理了其中一項，部分處理了另一項，還有兩項完全沒有處理。

• 比例 — 這是設計上刻意不保留的。輸出會重新置中，並正規化到單位最大半徑。絕對尺寸與世界座標都不會保留，因此每個模型都必須重新縮放到毫米，才有意義。如果你的參考照片來自真實物體，而你需要它真實的尺寸，Hi3D 並不會保留這些資訊。儲存庫對此有明確說明，而不是默默略過，這點值得肯定，但這也意味著比例是你自己必須處理的步驟。

• 拓撲 — 繼承自輸入，未經修復。Hi3D 會接收粗糙網格並為其添加細節。如果該粗糙網格具有非流形邊、自相交或法線反轉，細化只會讓這些問題變得更精細，而不會修正它們。README 本身的限制章節寫道「粗糙結構很重要」，且嚴重的粗糙網格錯誤可能會持續存在。切片器仍會在同一批缺陷上卡住，只是解析度更高。對任何要把它用於印表機的人來說，這是本次發布中最重要的一句話。

• 表面 — 不存在。輸出是僅含幾何的 trimesh.Trimesh：沒有紋理、沒有材質、沒有頂點顏色。對於單一材料列印，這大多不成問題，因為你列印的是材料，而不是 UV 貼圖。對於任何需要上色或多色結果，或用於必須看起來像產品的客戶預覽，這會使其不合格，並把你推向 v3.0。

• 可列印性 — 未評估。儲存庫中沒有任何內容會量測壁厚、最小特徵尺寸、懸垂，或細化後網格是否為水密。90% 切片數字存在於新聞稿中，而非程式碼裡，且未指名任何切片軟體。切片檔案也不是列印成品：切片成功並不代表列印會附著、能撐過支撐材，或能保持公差。

這些數字，依其實際依據排序

這份新聞稿混合了支持程度天差地遠的各種說法。把它們混為一談，正是供應商的一個數字在採購決策中變成鐵錚錚事實的緣由。

• 約兩百萬個精選 3D 資產——新聞稿與模型卡上如此陳述，且與 Sparc3D 系列一致；較早的論文將該系列描述為約 50 萬個資產。你無法從儲存庫稽核其精選過程，因為資料集與訓練程式碼均未發布。請將其視為可信的廠商數字，而非已驗證的數字。

• 1536³ 有效解析度——這項作為配置是真實存在的。管線對 512³ 執行一趟、對 1024³ 執行兩趟、對 1536³ 執行三趟，預設每趟有 25 次排程器更新。「有效」這個詞很重要：這些是名義上的稀疏座標與擷取網格，而不是密集的 1536³ 潛在張量。README 也註明，1536³ 設定僅在 96 GB H20 上驗證過，且較小顯示卡上的可行性與峰值記憶體並未說明。

• 90% 切片成功率 — 廠商回報、無法重現，且未說明方法。未指明切片軟體、未定義失敗、沒有基準、沒有測試集。這是本次發布中最適合引用的數字，卻也是最難以查證的。

• 最高的多視角保真度與細節豐富度——以「所報告的評估」結果呈現，但該評估並不在儲存庫中。沒有比較表、沒有競爭對手清單，也沒有按類別的分項細分。

• 「已在真實生產工作流程中驗證」——公告頁面上的一句話，沒有具名合作夥伴、沒有案例研究，也沒有描述任何工作流程。它很可能是真的。但這還不是證據。

硬體高牆

實測的技術堆疊是一張 96 GB 的 NVIDIA H20，而該儲存庫也如實說明，這正是最高設定經過驗證的機器。周邊需求同樣明確：Linux、運算能力 8.0 或更新版本、CUDA 12.0 到 12.5，而且完全沒有 CPU 推論路徑。flash-attn 沒有備援的注意力實作，因此該處建置失敗是致命問題，而非降級。批次大小為一。

支援循序 CPU 卸載，可降低 GPU 佔用，但 README 特別說明，這並不代表建立了最低 GPU 記憶體需求，也不會消除解碼特徵的成本。實務上，這表示 512³ 單趟路徑或許能在 24 GB 顯示卡上運作，但沒有人公布記憶體表，廠商也未如此宣稱。如果你的計畫取決於 4090，你就是在執行未經驗證的配置，應在投入前自行計時與測量。

一個可運作的列印管線是什麼樣子

Hi3D v1.0 是單一階段。此儲存庫附帶一個選用配接器，使用騰訊的 Hunyuan3D-2 mini 從單張影像產生粗略網格；Hunyuan 屬於第三方，並非核心函式庫的相依項目，但若沒有類似它的東西，你就沒有輸入。

所以真正的流程是：產生或取得粗略網格，用 Hi3D 以 512³、1024³ 或 1536³ 對其進行細化，匯出幾何，將其重新縮放到實際尺寸，修復粗略階段弄錯的拓撲，驗證水密性，然後切片。其中有三個步驟——修復、水密性驗證、切片——在整個發行版本中都沒有任何對應功能，而第一個步驟正是大多數失敗實際會發生的地方。

OrcaRouter 不託管 Hi3D v1.0 或任何其他 3D 模型，也不會透過 API 呼叫回傳可列印的網格。它託管的是圍繞此流程的文字與視覺工作：撰寫物件簡報、為參考照片加上說明，以及在您花費 GPU 時間進行 1536³ 運算之前，判斷多視角渲染是否有瑕疵。這就是一個端點支援超過 200 個模型，並具備自動容錯移轉，當周邊檢查正是您不想自行打造的部分時，這會很有用。3D 步驟仍留在您自己的硬體上。

本週誰應該下載它？

如果你在生產環境中已經有粗網格生成器——Hunyuan3D-2 mini、TripoSR，或自研環節——而瓶頸在於網格看起來偏軟，那麼 Hi3D v1.0 值得花一天 GPU 時間。建議從 512³ 路徑開始；1536³ 路徑則需要廠商所用的 H20 等級顯示卡。

如果你的需求是「丟一張照片進去，印出可列印的零件」，這個版本做不到，圍繞它的行銷宣傳也一樣做不到。你仍然需要第一階段、修復階段和切片軟體，而那個 90% 的數字並不會套用到你的物件、你的材料或你的印表機上。

如果你需要貼圖、色彩，或給客戶看的算圖，請等 v3.0，或改用其他方案。僅限幾何是硬性界限，不是暫時的缺口。

真正能改變結論的東西既窄又具體：一個指名道姓的切片器、一份公開的測試集、一套失敗分類法，以及一個基準——理想上是未經細化的粗略網格，讓讀者能看出細化究竟帶來了什麼效益。一張涵蓋全部三種解析度、且在不止一張 GPU 上的記憶體與延遲表，將能解決硬體方面的疑問。在這些東西出現任何一項之前，對 Hi3D v1.0 最誠實的描述是：一個強大且真正開放的幾何細化器，但被硬加上一項跑在其證據之前的量產宣稱。