Hi3D V1.0 今日开源。这个仓库证明了什么，又没证明什么

2026年10月23日，一个名为 hi3d-official/Hi3Dv1.0 的 GitHub 仓库出现，包含六次提交、一个标签，以及一条发布说明：“发布 Hi3D v1.0 推理代码和文档。”同日，八个运行时文件上线 Hugging Face，而Hi3D V1.0——这个模型此前名为Sparc3D——变得可下载并可商业使用。这次公告，尽管形式如此，是以一则新闻通稿发布，标题为“Hi3D V1.0 开源：首个经生产验证的开源 AI 3D 模型”。没有发出去的是一张基准测试表。仓库里没有任何数字能告诉你，这个模型比它所细化的粗糙网格好多少，也还没有第三方发布过这样的数字。这个空白才是故事所在。

六个提交和八个文件

这个仓库小到可以在一个下午读完，而这是关于它的第一个有用事实。它包含推理代码、一个演示、Docker 约束、文档以及 sparc3d Python 包。它不包含训练代码、评估框架、基准划分，也不包含新闻稿图表背后的对比网格。作者在 README 中直接说明了这一点：这是一个推理发布版，而不是一个可复现包。

权重共有八个文件：一个模型索引、一个调度器配置、一个 VAE 配置以及 model.safetensors，再加上 transformer_512 和 transformer_1024 的配置与权重。加载器只读取 JSON 和 safetensors，不会执行模型仓库中的 Python，也不会对检查点进行 unpickle；这是更安全的模式，值得任何需要清理供应链的人注意。两个条件编码器—— facebook/dinov2-large 和 openai/clip-vit-large-patch14 ——是单独下载的，并带有各自的许可证。

没有公布参数数量。README 里没有,模型卡片上没有,新闻稿里也没有。如果你把文件下载下来,可以从文件大小推断规模,但厂商始终没有给出一个数字,本文也不会凭空编造一个。

处理流程会如何处理你的图像

Hi3D V1.0 并不是大多数人通常所说的图像到3D生成器。它是一个精修阶段。你给它一张物体的参考图像和同一物体的粗糙网格，它会返回一个更高分辨率的网格。图像对定义在取自粗糙网格的坐标上的稀疏流进行条件约束；该流程采样稀疏潜变量，通过自剪枝稀疏 VAE 解码，提取表面，然后对该表面重新体素化，以支持下一轮处理。

共有三轮，你请求的分辨率决定运行多少轮：

• 512³ — 单次遍历，64³ 结构网格，512³ 稀疏提取，transformer_512

• 1024³ — 两遍处理，添加 128³ 结构网格，1024³ 提取，transformer_1024

• 1536³ — 三遍处理，新增 192³ 结构网格、1536³ 提取，transformer_1024

每一轮默认运行 25 次调度器更新。README 对“1536³”的含义作了谨慎说明：它是一个名义上的稀疏坐标与提取网格，而不是一个稠密的 1536³ 潜变量张量，也不是固定的三角形数量。这一区分很重要，因为新闻稿中说的是“有效稀疏网格分辨率最高可达 1536³”，这一表述准确，但容易被理解得比实际情况更稠密。

输出是一个 trimesh.Trimesh，以及达到的分辨率。它会被重新居中并归一化到单位最大半径，因此原始世界坐标和绝对尺度都已丢失。批大小为 1。没有纹理、材质或顶点颜色。如果你的下一步需要真实世界尺寸——打印床、CAD 装配体、碰撞外壳——你就要手动重新缩放和重新定向。

90%这个数字没有分母

该新闻稿提出了四项量化说法。训练数据从约50万个精选3D资产增长到200万个。几何体可达到有效的1536³稀疏网格。该模型报告了90%的切片成功率。并且它声称“在所报告的评估中获得了最高的多视角保真度和细节丰富度得分”。

仓库中只能看到前两项。两百万这个数字作为项目报告中的说法出现在模型卡上；1536³ 这个数字在某种意义上确实是真实的，因为流水线会接受该请求，而且相关配置也存在。90% 的切片数字在仓库中完全找不到。没有说明切片的是什么、使用了哪个切片器、失败模式是什么，或者基线是什么。“最高多视图保真度”在公开材料中没有任何分数、对比集或方法论作为支撑。这些都是供应商报告的数字，而诚实的解读是它们尚未经过验证，而不是说它们是错的。

缺少评估框架正是这件事重要的原因。读者无法拿到仓库、运行所报告的比较并核验结果。独立复现将不得不从重建基准开始，而那是另一个项目。对于仅推理发布来说这并不罕见，但这确实意味着，对这个模型的第一次严肃评审将来自拥有打印农场或资产管线的人，而不是来自排行榜。

仓库比发布版本更诚实

读一下局限性部分，就能得到比标题所呈现的更有用的认识。以下是对供应商原话的转述：

• 仅几何体。无纹理、材质或顶点颜色，且批大小为 1。

• 必须使用粗糙网格。模型负责细化结构，而不是从图像中凭空创造初始表面。

• 粗网格误差会持续存在。如果输入的轮廓不正确，细化可能会使错误的形状变得更加锐利。

• 参考图中被遮挡的几何结构是以合理方式补全的，而非精确重建。这对主视觉资产来说没问题，但对测量来说很糟糕。

归一化步骤会丢弃绝对尺度和世界坐标。

• 种子并非网格哈希。GPU 稀疏卷积和注意力机制并非按位确定性的，因此相同的种子可能生成不同的网格。

• 完整的 1536³ 阶梯仅在 96 GB 的 NVIDIA H20 上经过验证。在较小显卡上的显存占用和可行性尚未明确确立。

• 没有 CPU 推理路径，并且 flash-attn 没有回退的注意力实现。

• 如果无法达到请求的分辨率，管线会抛出错误，而不是静默地返回较低的分辨率。

• README 指出，标称分辨率和几何细节并不能保证其适合下游应用。这是文档中最重要的一句话。

开源，并附有增长条款

该许可证名为 Hi3D Open License Agreement Version 1.0。它不是 MIT、Apache-2.0，也不是任何经 OSI 批准的许可证文本；官方页面根本没有标明许可证，因此代码仓库才是权威来源。商业使用是允许的。有意思的地方在于它的条件。

如果相关产品或服务的月活跃用户超过 200,000 或月收入超过 1,000,000 美元，被许可方必须在 60 天内通知 Hi3D 并申请单独的书面许可。商业集成必须展示“Powered by Hi3D 1.0”，并在支持的情况下链接到官方网站。不包含任何 Hi3D 材料或衍生作品的独立输出本身不会触发品牌标识、分发或规模化许可义务。现有的 Apache-2.0 和 MIT 条款对其涵盖的原始部分和第三方部分仍然有效，DINOv2、CLIP、Hunyuan 及其他组件保留其自身条款。

对于制作素材的爱好者或代理机构来说，这几乎等于不受限制。对于把精修能力放在某个端点后面的 SaaS 来说，这是一份在特定规模设有触发线的许可，外加一项署名要求。20 万 MAU 这条线对消费级设计工具而言并不算高。任何打算做这类工具的人，都应该在集成之前读协议，而不是等增长曲线起来之后才读。

运营需要什么

这是一个仅限 Linux 的源码安装版本。需要 Python 3.10、计算能力为 8.0 或更新的 NVIDIA GPU，以及与已安装的 PyTorch 匹配、版本在 12.0 到 12.5 之间的 CUDA 工具包。README 中的实测配置为 Python 3.10.12、PyTorch 2.5.0（CUDA 12.4）和 96 GB H20。安装会拉取 flash-attn 2.7.4.post1（禁用构建隔离）、spconv-cu120以及一个锁定版本的约束文件。没有 PyPI wheel，也没有预构建的项目包。

离线使用需要精炼权重、DINOv2 和 CLIP 的本地副本。用于生成粗略网格的可选演示适配器使用腾讯的 Hunyuan3D-2 mini，该模型必须单独获取，并保留其自身的许可证。核心精炼脚本不会导入 Hunyuan，并且可以接受你提供的任何粗略网格；对于已经拥有生成器的生产流水线而言，这是更有用的模式。

安装说明中包含两条实用警告。flash-attn 必须在 PyTorch 之后构建，而且一旦失败就没有回退方案。内存卸载可用，但不保证最低的 GPU 显存占用，并且不能与普通的.to("cuda") 结合使用。如果你希望在 24 GB 的工作站显卡上运行它，仓库并未声称你可以做到，而唯一经过测量的配置是它的四倍。

什么不在盒子里？

Hi3D V1.0 没有托管 API。Hugging Face 模型卡称该模型“未被任何 Inference Provider 部署”，而官网的下载按钮指向本地部署。厂商页面链接的免费演示 Space 只是试用，并不是带有价目表的端点。该公司的商业产品是另一个模型：Hi3D v3.0，官网将其描述为具备 2048³ 体素级几何结构、最高 8K 纹理，并可通过在线工作区访问。v1.0 是开源的那一个；v3.0 是公司售卖的那一个。

缺少托管端点并不是批评。这是一个部署层面的事实，它决定了这个月谁能用上这个模型：拥有 96 GB GPU 和 Linux 机器的团队可以；而想把图像发送到 API 的团队则不行，除非他们自己构建这项服务，或者等别人来做。

路由器适合用在哪里，又不适合用在哪里

OrcaRouter 不提供 Hi3D V1.0，也完全不提供 3D 模型。其目录涵盖文本、视觉、视频、嵌入和语音模型。本文中的任何内容都不应被解读为：你可以通过我们的端点调用网格生成器。

精修流水线外围的那一层则是另一回事。对于以图像为条件的网格，最直接的质量检查是视觉检查：从三四个角度渲染结果，然后让视觉模型判断轮廓、局部细节和多视图一致性是否与参考相符。这是一种典型的 LLM 式调用，而这类调用正适合在无需签三份合同的情况下尝试多个模型。OrcaRouter 将 200 多个模型置于同一个 API 之后，加价 0%，并在提供商服务退化时自动故障转移，其模型融合模式还能让一组模型共同完成同一项检查，而不是把 QA 关卡押在单一模型上。3D 部分的工作仍留在本地；围绕它的判断则不必量身定制。

什么会改变这一评估？

三件事，按有用程度排序。使用具名切片软件进行打印测试，并给出明确的失败判定标准和基线，能把“90%”这一说法变成一个买家可用的数字。一张在 512³、1024³ 和 1536³ 下、在不止一块 GPU 上测得的延迟与内存表，会告诉团队：96 GB 的要求究竟是验证产物，还是硬性下限。而与其起始粗网格进行独立对比，会回答细化模型唯一真正重要的问题：第二阶段实际增加了多少细节，又为此付出了多少伪影代价？

在此之前，站得住脚的总结有限但有用。Hi3D V1.0 是一个真实可下载、可商用的细化模型，它有异常坦诚的局限性说明、随业务规模调整的许可证，但除作者自述外没有任何已发表的证据。对于已经能生成粗糙网格并拥有 GPU 的团队来说，这足以在本周开展一次实验。对其他所有人来说，这是一个前景可期、但实证尚待公布的版本。