Point-E 的论文全名是《Point-E: A System for Generating 3D Point Clouds from Complex Prompts》，作者是 Alex Nichol、Heewoo Jun、Prafulla Dhariwal、Pamela Mishkin 和 Mark Chen，2022 年 12 月 16 日挂上 arXiv，代码在 github.com/openai/point-e，MIT 协议。它走的是两段式：先用一个文生图扩散模型画出一张合成视角的图，再用第二个扩散模型把这张图变成点云。基础模型出 1024 个点，每个点 6 个通道（XYZ 坐标加 RGB 颜色），再交给一个 40M 的上采样模型补到 4096 个点。整条链路在单张 V100 上约 1.5 分钟，而同期的 DreamFusion 需要约 12 个 V100 小时——这一到两个数量级的差距，就是这篇论文当年的全部意义。
得先把落差说清楚。仓库主分支停在 2022 年 12 月 20 日，一共四次提交，之后再没更新，64 个开放 issue 基本没人回。论文里效果最好的那条文生 3D 链路依赖一个在 3D 渲染图上微调过的 GLIDE 文生图模型，这份权重 OpenAI 从来没放出来（issue #115 至今开着且没有回复），你能直接跑的纯文本模型是 base40M-textvec，README 自己承认它「能力有限，只认得简单的类别和颜色」。COCO CLIP R-Precision 上 Point-E 1B 是 41.1%／46.8%（ViT-B/32 与 ViT-L/14 两种打分器），DreamFusion 是 75.1%／79.7%。连官方那个 Hugging Face Space 现在都是 runtime error 状态。
那它今天还值得跑吗？三个理由：一是它大概是唯一能在 3GB 显存里跑完整条文本到 3D 链路的开源模型，做点云扩散、SDF 重建、3D 生成评测的人还在拿它当基线——P-FID 和 P-IS 这两个指标本身就出自这篇论文；二是它输出的是带颜色的显式点云而不是隐式场，拿来做几何先验、初始化、数据增广都很顺手；三是 diffusers 至今只收了 Shap-E，没收 Point-E，所以你没有 from_pretrained 一行搞定的捷径，必须自己起一台机器、克隆原始仓库来跑。NexGPU 上 Tesla V100 32GB 是 $0.188/卡·时，正好是论文那张测速卡；从 1,175 个可租节点、2,000 多个预置镜像里挑一个 PyTorch 的，SSH 上去十分钟就能出第一朵点云。
01 —
九个官方 checkpoint，到底哪个是哪个
文件大小取自 openaipublic.azureedge.net 上的实际 Content-Length，全部是 fp32 的 .pt
| 版本 | 参数量 | 显存 | 上下文 | 说明 |
|---|---|---|---|---|
| base40M-textvec | 40M（width 512／12 层／8 头） | fp32 权重 154MB ／ 整链路 < 3GB | 1024 点 × 6 通道 | 唯一直接吃文本 prompt 的权重，text2pointcloud 笔记本的默认选择。CLIP ViT-L/14 只给它一个文本向量做条件，所以它认得「a red motorcycle」这种简单类别加颜色，复杂描述基本失效。 |
| base40M ／ base40M-imagevec ／ base40M-uncond | 各 40M（width 512／12 层／8 头） | fp32 权重 各 152–155MB | 1024 点 × 6 通道 | 图像条件三兄弟。base40M 用 CLIP ViT-L/14 的 16×16＝256 个 grid token 做条件，是 image2pointcloud 的默认加载项；imagevec 只用单个图像向量；uncond 是无条件基线，做 P-FID 对照用。 |
| base300M | 300M（width 1024／24 层／16 头） | fp32 权重 1.16GB ／ 整链路 ≈ 4GB | 1024 点 × 6 通道 | 质量与速度的折中档，COCO CLIP R-Precision 40.3%／45.6%。在 24GB 卡上能开很大的 batch，是批量刷点云数据集时性价比最高的一档。 |
| base1B | 标称 1B（按 4.64GB fp32 权重反推约 1.24B，width 2048／24 层／32 头） | fp32 权重 4.64GB ／ 整链路 8GB 起 | 1024 点 × 6 通道 | 论文里最强的一档，41.1%／46.8%。单文件 4,977,344,725 字节，V100 上单次采样 28.67 秒。要复现论文里那些 banner 图，就是它加上一张外部生成的合成视角图。 |
| upsample | 40M（width 512／12 层／8 头） | fp32 权重 154MB | n_ctx 3072 ＋ cond_ctx 1024 ＝ 4096 点 | 把基础模型的 1024 点补到 4096 点。默认不加 classifier-free guidance——PointCloudSampler 会把第二段的 guidance_scale 自动压到 1.0，文本笔记本里干脆写成 0.0。V100 上 12.58 秒。 |
| sdf（附带 pointnet） | sdf 约 9.5M ／ pointnet 约 17M | 36MB ＋ 67MB，显存几乎不占 | marching cubes grid 32 或 128 | sdf 做点云到网格的符号距离回归再导出 PLY，训练时用了 240 万个 manifold mesh。pointnet 是算 P-FID／P-IS 的评测特征提取器，只跑生成的话下不下都行。 |
02 —
按场景选卡：Point-E 的瓶颈是 fp32 算力，不是显存
仓库全程 fp32、没有 fp16／bf16 路径（issue #103 还开着），所以 FP32 峰值算力比显存容量更值得看
跑 base40M-textvec 批量刷文生点云，或者对齐论文的延迟数字
Tesla V100 32GB$0.188/卡·时
论文里那 28.67 秒和 12.58 秒就是在 V100 上测的，用同一张卡对齐数字最省事，而且它是全站最便宜的一档，32GB 显存对这个模型属于奢侈。
base1B 图生点云 ＋ 上采样，想开大 batch 批量出货
RTX 4090 24GB$0.540/卡·时
4.64GB 权重加 CLIP ViT-L/14 只占掉 24GB 的四分之一，剩下全喂 batch；FP32 峰值约 82 TFLOPS，是 V100 那一档的五倍级，纯 fp32 的 Karras 采样能直接吃满。
只做 SDF 网格重建、grid_size=128 的 marching cubes 和 Blender 渲染
RTX 3090 24GB$0.193/卡·时
sdf 权重才 36MB，128³ 共 209 万个查询点按 4096 一批喂进去，显存压力接近零；这一步要的是便宜，加上 24GB 足够把渲染管线一起放进来。
拿 Point-E 当基线，同机横评 TRELLIS 与 Hunyuan3D 2.1
RTX A6000 48GB$0.817/卡·时
TRELLIS 官方要求至少 16GB，Hunyuan3D 2.1 形状 10GB、贴图 21GB、合起来 29GB；48GB 一张卡把 2022 到今天这几代模型放在一起跑，不用来回换机器重下权重。
03 —
四步在租来的卡上把 Point-E 跑起来
从 PyTorch 预置镜像开机到导出第一个 PLY 网格，路上的坑都标出来了
- 01
开机装环境，绕开 CLIP 那个同名包陷阱
在 NexGPU 控制台挑一个 PyTorch 预置镜像开机，SSH 或 Jupyter 进去克隆仓库。setup.py 里写的依赖是 clip @ git+https://github.com/openai/CLIP.git，装的是 OpenAI 的 CLIP；如果你手滑执行 pip install clip，装到的是 PyPI 上另一个完全无关的同名包，运行时报 module 'clip' has no attribute 'load'——仓库 issue #105 就是这个，挂了几年没人回。另外镜像里必须有 git，否则这条 git+ 依赖根本拉不下来。
git clone https://github.com/openai/point-e.git && cd point-e && pip install -e . && pip install git+https://github.com/openai/CLIP.git - 02
把权重缓存钉死在持久盘上
download.py 里的 default_cache_dir() 返回的是 os.path.join(os.path.abspath(os.getcwd()), 'point_e_model_cache')——当前工作目录，不是 ~/.cache。你在哪个目录起 Python，几个 GB 的权重就落到哪。base1B 单文件 4,977,344,725 字节，实例重建一次就得重下一次。固定 cd 到挂载的持久卷再执行，一次把要用的都拉全；九个 checkpoint 加上 CLIP ViT-L/14 大约 8GB。
cd /workspace && python -c "import torch; from point_e.models.download import load_checkpoint; [load_checkpoint(n, torch.device('cpu')) for n in ['base40M-textvec','base1B','upsample','sdf']]" - 03
两段式采样：base 出骨架，upsample 补密度
PointCloudSampler 把两个模型串成一条链，第一段生成 1024 个点，结果作为 low_res 条件喂给第二段补到 4096 个点。默认 karras_steps 是 (64, 64)，sigma_max 是 (120, 160)，s_churn 是 (3, 0)，guidance 只加在第一段。文生点云传 model_kwargs_key_filter=('texts', '')，图生点云改成 ('images', '') 并在 model_kwargs 里传 PIL 图像。想提速就先砍第一段的 karras_steps，画质掉得比想象中慢。
sampler = PointCloudSampler(device=device, models=[base_model, upsampler_model], diffusions=[base_diffusion, upsampler_diffusion], num_points=[1024, 4096 - 1024], aux_channels=['R', 'G', 'B'], guidance_scale=[3.0, 0.0], model_kwargs_key_filter=('texts', '')) - 04
点云转网格，导出 PLY
pointcloud2mesh 笔记本里 grid_size 默认只有 32，出来是个只能看轮廓的团子，官方自己注明评测时用 128。128³ 是 209 万个查询点，按 batch_size=4096 一批一批过 sdf 模型，显存吃不满但要等一会儿。导出格式是 PLY，颜色挂在顶点上；进 Blender 或 MeshLab 之前一般还要补一次法线并做简化。
from point_e.util.pc_to_mesh import marching_cubes_mesh mesh = marching_cubes_mesh(pc=pc, model=sdf_model, batch_size=4096, grid_size=128, progress=True) with open('mesh.ply', 'wb') as f: mesh.write_ply(f)
算笔账：一千朵点云到底多少钱
按论文在 V100 上拆出来的分段耗时，base1B 一次采样 28.67 秒、上采样 12.58 秒，合计 41.25 秒（论文里那 46.28 秒的 GLIDE 段权重没开源，你跑不到）。NexGPU 的 Tesla V100 32GB 是 $0.188/卡·时，折合每秒 $0.0000522，于是一朵 4096 点的彩色点云成本是 41.25 × 0.0000522 ≈ $0.00215，两毛美分不到。要 1,000 朵：41,250 秒 ＝ 11.46 小时，11.46 × 0.188 ＝ $2.15。换 RTX 4090 24GB 的 $0.540/卡·时，FP32 峰值约 82 TFLOPS 对 V100 那一档的 15 TFLOPS 级，保守只按三倍折算也就 3.8 小时，3.8 × 0.540 ＝ $2.06——花的钱几乎一样，时间省掉三分之二，还能把 batch 开大到填满 24GB。存储那边，九个 checkpoint 加 CLIP 大约 8GB，按 $0.414/GB·月 中位价是 $3.31/月；算力在实例停机那一刻就停止计费，存储会一直算到你 destroy 为止，所以跑完记得清。全程按秒计费、没有最低消费、没有起租量、不用提配额申请。
04 —