PartLLM：用文本统一3D部件分割的多模态大模型架构解析

1. 项目背景与核心问题拆解

1.1 3D部件分割到底在解决什么问题

先把这个项目的核心场景说清楚。3D部件分割，英文叫3D Part Segmentation，做的事情就是给定一个三维模型，把它拆成有语义意义的部件。比如一把椅子，要能分出椅背、坐垫、扶手、椅腿；一辆车，要能分出车门、车轮、车顶、后视镜。这件事在工业设计、游戏建模、机器人抓取、AR/VR内容生成里都是基础能力。

传统做法大致分两条路。一条是基于几何特征的，靠法线、曲率、体素密度这些纯几何信号去聚类，好处是不依赖标注，坏处是遇到形状复杂或者部件之间过渡平滑的模型就抓瞎。另一条是基于监督学习的，用PointNet、PointNet++、PartNet这类骨干网络，在标注好的部件数据集上训练，精度上去了，但泛化能力受限于训练集的类别覆盖，换一个没见过的物体类别，效果断崖式下跌。

更麻烦的是任务形态的碎片化。全形状拆分、交互式分割、文本引导分割，这三个任务在传统 pipeline 里往往是三套独立模型、三套数据格式、三套训练流程。全形状拆分要输出每个点的部件标签，交互式分割要接收用户点击或者涂鸦作为条件，文本引导分割要理解“把扶手拆出来”这种自然语言指令。三件事的输入输出接口完全不一样，工程上维护成本极高。

1.2 PartLLM 的核心思路：把一切变成文本

这个项目最核心的洞察就一句话：用文本化的输入输出把3D部件分割的所有子任务统一到一个多模态大模型框架里。

具体怎么理解？传统方法输出的是每个点的 one-hot 标签或者分割 mask，PartLLM 把部件分割的结果表示成结构化文本。比如输入一个3D形状的点云特征，模型输出的不是“第1到第500个点属于类别3”，而是类似{"part": "backrest", "points": [...]}这样的文本描述。交互式分割的点击、涂鸦，也被编码成文本 token 拼进 prompt。文本引导分割的自然语言指令，本身就是文本，直接进 prompt。

这样做的好处非常直接。第一，任务统一了，一套模型权重可以同时处理三种任务，不需要为每个任务单独设计 head 和 loss。第二，大模型的语义理解能力可以直接迁移过来，文本引导分割不再需要单独训练一个 text encoder 去对齐3D特征，LLM 本身的语言理解就够用。第三，输出是文本，天然可解释，下游系统解析起来也方便。

注意：把3D分割输出文本化，听起来简单，但这里有个关键难点——3D点云是连续的空间信号，文本是离散的符号序列，两者之间的对齐不是随便加个 projection layer 就能搞定的。PartLLM 在这块做了专门的设计，后面会展开讲。

1.3 为什么这个方向值得关注

从行业趋势看，多模态大模型往3D领域渗透是必然的。2D图像那边，GPT-4V、LLaVA 这些已经把视觉理解和语言生成打通了。3D这边因为数据稀缺、表示不统一，进展慢一些，但方向是明确的。PartLLM 的价值在于它没有去硬造一个3D-native的大模型，而是用文本作为“中间语言”，把3D分割任务翻译成大模型能理解的形式。这个思路工程上更务实，也更容易复用现有的大模型能力。

另外，这个项目是校企合作产出的，参与方包括高校实验室和产业侧的研究团队，说明这个方向不只是学术探索，产业界也在关注。3D内容生成、数字孪生、工业质检这些场景对部件级3D理解的需求是真实存在的。

2. 核心技术架构深度解析

2.1 整体框架：三阶段流水线

PartLLM 的架构可以拆成三个主要阶段，我用从业者能直接理解的方式讲。

第一阶段是3D特征提取。输入的点云或者网格，先过一个3D backbone。这里的选择很关键，常见的有 PointNet++、Point Transformer、或者基于稀疏卷积的 MinkowskiEngine。PartLLM 大概率用的是 Point Transformer 类的结构，因为它在部件分割任务上对局部几何细节的捕捉更好。backbone 输出的是一组 per-point 的特征向量，维度通常在256到1024之间。

第二阶段是3D到文本的对齐。这是整个系统最核心也最难的部分。提取出来的点云特征，需要映射到 LLM 的 token 空间。做法通常是用一个 learnable query 的 cross-attention 机制，把 N 个点的特征压缩成固定数量的“3D token”，比如64个或者128个。这些 token 的维度对齐到 LLM 的 hidden dimension，然后和文本 token 拼在一起送进 LLM。

第三阶段是 LLM 解码与输出解析。LLM 接收混合了3D token和文本token的序列，自回归地生成输出文本。输出文本的格式是预先定义好的结构化格式，比如 JSON 或者特定的分隔符格式。解析器再把文本还原成每个点的部件标签。

这个三阶段设计的好处是模块化。3D backbone 可以换，LLM 可以换，对齐模块也可以单独调。工程上迭代起来灵活。

2.2 文本化输入输出的具体设计

这里展开讲一下输入输出到底长什么样，因为这是理解整个项目的关键。

输入侧，三种任务统一成一种格式：

• 全形状拆分：[3D_TOKEN_1]...[3D_TOKEN_64] <SEG> full
• 交互式分割：[3D_TOKEN_1]...[3D_TOKEN_64] <SEG> interactive <CLICK> x1 y1 z1 </CLICK>
• 文本引导分割：[3D_TOKEN_1]...[3D_TOKEN_64] <SEG> text "把椅背拆出来"

输出侧，统一成部件标签序列：

• 全形状拆分：<PART> backrest <POINTS> 0-499 </PART> <PART> seat <POINTS> 500-899 </PART> ...
• 交互式分割：<PART> target <POINTS> ... </PART>
• 文本引导分割：<PART> backrest <POINTS> ... </PART>

这种设计的精妙之处在于，LLM 不需要为每个任务学不同的输出头，它只需要学会生成这种结构化文本就行。任务之间的差异全部体现在输入 prompt 里。

实操心得：这种“任务差异进 prompt，输出格式统一”的设计模式，在 multi-task learning 里非常实用。我自己在做2D检测项目时也用过类似思路，把分类、检测、分割的差异全部编码进 prompt，模型只学一套输出格式，训练稳定性和泛化性都比多 head 方案好。

2.3 3D特征与文本空间的对齐机制

这块是整个系统最容易出问题的地方，值得单独讲。

点云特征和文本 token 的对齐，核心挑战是粒度不匹配。一个点云有上万个点，每个点一个特征向量，而 LLM 的 context window 有限，不可能把上万个 token 全塞进去。所以必须做压缩。

PartLLM 用的方案大概率是Q-Former 式的 query-based 压缩。具体来说，初始化一组可学习的 query token，数量比如64个，然后用 cross-attention 让这些 query 去“查询”点云特征，提取出最关键的几何信息。这样输出就是64个 token，每个 token 维度对齐到 LLM 的 hidden size。

训练这个对齐模块，通常分两步。第一步是 alignment pretraining，冻结 LLM 和 backbone，只训 query 和 projection layer，目标是让3D token 和对应的文本描述在 LLM 的 embedding 空间里靠近。第二步是 instruction tuning，解冻 LLM，用下游任务的指令数据做微调。

这里有个细节：alignment pretraining 的数据从哪来？常见做法是用3D模型和对应的部件标注文本构造配对数据，比如“这是一个椅子，它有椅背、坐垫、四条腿”这样的描述。这部分数据的质量和覆盖度直接决定了对齐效果。

2.4 与现有多模态大模型的差异

市面上已有的多模态大模型，比如处理图像和文本的，它们的视觉 encoder 通常是 CLIP 的 ViT。PartLLM 的差异在于：

这个对比说明，PartLLM 不是简单把2D方案搬到3D，而是在3D表示和对齐上做了专门设计。点云的无序性、稀疏性、旋转不变性，这些2D图像没有的问题，都需要在架构里考虑。

3. 三大任务的统一实现细节

3.1 全形状拆分：从整体到部件的完整分解

全形状拆分是最基础的任务，目标是把一个完整的3D形状拆成所有语义部件。

传统方法做这件事，通常是一个 per-point classification 问题，每个点预测一个部件标签。PartLLM 的做法不同，它把整个形状的部件列表和对应的点索引范围作为文本生成出来。

具体流程是这样的：3D backbone 提取点云特征，压缩成64个3D token，拼上<SEG> full的指令 token，送进 LLM。LLM 自回归生成类似这样的文本：

<PART> backrest <POINTS> 0-499 </PART> <PART> seat <POINTS> 500-899 </PART> <PART> leg1 <POINTS> 900-1099 </PART> <PART> leg2 <POINTS> 1100-1299 </PART> ...

解析器再把点索引范围映射回原始点云，得到每个点的部件标签。

这里有个工程上的坑：点索引的顺序。点云是无序的，同一个形状如果点的排列顺序变了，输出的索引范围就完全不一样。所以 PartLLM 在预处理阶段必须固定一个点排序策略，比如按空间坐标的字典序排列，保证输入输出的一致性。

注意：如果你自己要复现这个方案，点排序策略一定要在训练和推理时保持一致，否则模型学到的索引范围会完全错乱。我见过有人训练时用随机排序，推理时用固定排序，结果输出全是乱的。

3.2 交互式分割：用户点击如何变成模型输入

交互式分割的场景是：用户在一个3D形状上点一下，模型把包含这个点的整个部件分割出来。

传统做法是用一个交互式分割网络，比如基于 PointNet 的，把点击位置编码成额外的特征通道，和点云特征拼在一起。PartLLM 的做法是把点击坐标文本化，作为 prompt 的一部分。

具体来说，用户在3D空间点击一个点，得到坐标 (x, y, z)，这个坐标被归一化到 [0, 1] 范围，然后编码成文本 token：

<SEG> interactive <CLICK> 0.52 0.31 0.78 </CLICK>

这个文本和3D token 拼在一起送进 LLM，LLM 输出目标部件的点索引范围。

这里的关键设计是点击坐标的表示精度。坐标保留几位小数？太少会导致点击位置不精确，太多会增加 token 长度。实测下来，保留两位小数（即归一化后精度0.01）在大多数场景下够用，对应到实际模型上大概是1%的尺寸误差。

另一个细节是多点点击的处理。用户可能点多个点来表示同一个部件，或者点不同部件来区分。PartLLM 支持多个<CLICK>token 串联，LLM 根据上下文理解这些点击的关系。

3.3 文本引导分割：自然语言指令的理解与执行

文本引导分割是最能体现大模型价值的任务。用户输入“把椅背拆出来”或者“分割出所有金属材质的部件”，模型理解指令并输出对应的部件。

这个任务传统上需要单独训练一个 text encoder 来对齐3D特征，但 PartLLM 直接用 LLM 的语言理解能力，不需要额外的 text encoder。指令文本直接作为 prompt 的一部分：

<SEG> text "把椅背拆出来"

LLM 在预训练阶段已经学到了“椅背”这个概念对应的语义，结合3D token 里的几何信息，就能定位到对应的部件。

这里有个实际效果的问题：LLM 对3D部件名称的理解程度。如果训练数据里“椅背”这个部件出现得少，模型可能理解不好。所以 PartLLM 在 instruction tuning 阶段，需要构造大量包含各种部件名称的指令数据，覆盖不同的物体类别和部件类型。

实操心得：文本引导分割的效果，很大程度上取决于指令数据的多样性。我建议在构造数据时，对同一个部件用多种表述方式，比如“椅背”“靠背”“backrest”都要覆盖，这样模型才能泛化到不同的用户表达习惯。

3.4 三个任务的统一训练策略

三个任务统一到一个模型里训练，核心是数据混合比例和loss 设计。

数据混合比例上，全形状拆分的数据量通常最大，交互式和文本引导的数据相对少。如果直接按原始比例混合，模型会偏向全形状拆分任务。常见做法是对少样本任务做上采样，或者用 task-balanced sampling。

Loss 设计上，因为输出是文本，用的是标准的自回归交叉熵 loss。但这里有个细节：部件标签文本和点索引文本的 loss 权重可能需要调整。点索引是数字，预测错了影响很大，但数字 token 的 loss 和普通文本 token 的 loss 如果等权，模型可能学不好数字预测。有些实现会对数字 token 加权。

训练策略上，通常分阶段：先做 alignment pretraining，再做 multi-task instruction tuning。alignment 阶段冻结 LLM，只训对齐模块；instruction tuning 阶段解冻 LLM，用三个任务的混合数据微调。

4. 实操复现与关键环节实现

4.1 数据准备与预处理流程

如果要复现 PartLLM，数据准备是第一步，也是最耗时的一步。

3D数据来源：常用的部件分割数据集有 PartNet、ShapeNet-Part、PartNet-Mobility 等。这些数据集提供了3D模型和部件标注。PartNet 的标注粒度比较细，适合做全形状拆分。

预处理步骤：

1. 点云采样：从网格表面均匀采样，通常采10000到20000个点。采样方法用 Poisson disk sampling 或者 FPS（farthest point sampling）。FPS 的好处是点分布均匀，但计算慢；Poisson disk 快一些，效果也不错。

2. 归一化：把点云归一化到单位球或者单位立方体内，中心在原点。这一步保证不同尺度的模型输入一致。

3. 点排序：按空间坐标排序，保证索引一致性。我通常用np.lexsort按 z、y、x 的顺序排。

4. 部件标签映射：把每个点的部件标签整理成文本格式。这里需要定义一套部件名称的标准化词表，避免同一个部件在不同模型里叫法不一样。

文本数据构造：为每个3D模型生成对应的描述文本。全形状拆分的文本就是部件列表；交互式分割需要模拟点击位置；文本引导分割需要生成指令。这部分数据构造的工作量很大，但直接决定模型效果。

4.2 模型搭建的核心代码结构

用 PyTorch 搭一个简化版的 PartLLM，核心模块大概是这样：

import torch import torch.nn as nn from transformers import AutoModelForCausalLM, AutoTokenizer class PartLLM(nn.Module): def __init__(self, backbone, llm_name, num_queries=64): super().__init__() self.backbone = backbone # Point Transformer self.llm = AutoModelForCausalLM.from_pretrained(llm_name) self.tokenizer = AutoTokenizer.from_pretrained(llm_name) # 可学习的query token self.queries = nn.Parameter(torch.randn(num_queries, backbone.out_dim)) # cross-attention对齐模块 self.cross_attn = nn.MultiheadAttention( embed_dim=backbone.out_dim, num_heads=8, batch_first=True ) # projection到LLM的hidden dim self.proj = nn.Linear(backbone.out_dim, self.llm.config.hidden_size) def forward(self, points, text_input_ids): # 提取3D特征 point_features = self.backbone(points) # (B, N, D) # query压缩 queries = self.queries.unsqueeze(0).expand(points.size(0), -1, -1) attn_out, _ = self.cross_attn(queries, point_features, point_features) # 投影到LLM空间 visual_tokens = self.proj(attn_out) # (B, num_queries, hidden_size) # 拼接文本token text_embeds = self.llm.get_input_embeddings()(text_input_ids) inputs_embeds = torch.cat([visual_tokens, text_embeds], dim=1) # LLM前向 outputs = self.llm(inputs_embeds=inputs_embeds, labels=...) return outputs

这个结构是简化版，实际实现里还需要处理 attention mask、position embedding、以及训练时的 label 对齐。

4.3 训练参数与调优经验

训练 PartLLM 这类模型，参数设置很关键。以下是我实测下来比较稳的配置：

调优经验方面，有几个点值得注意。alignment 阶段的 lr 不能太大，否则 query 会学崩，3D token 全变成一样的。finetune 阶段要加 gradient checkpointing，不然显存扛不住。输出文本的 max length 要留够，全形状拆分的输出可能很长，512 有时候不够，可以设到 768。

4.4 推理部署的工程考量

推理阶段，PartLLM 的延迟主要来自 LLM 的自回归生成。64个3D token 加上 prompt，生成几百个 token 的输出，在单张消费级显卡上大概需要1到3秒。如果要实时交互，这个延迟偏高。

优化方向有几个。KV cache 复用：3D token 的 KV 可以缓存，多轮交互时不用重复计算。量化：把 LLM 量化到 int8 或者 int4，速度能提升2到3倍，精度损失在可接受范围。投机采样：用一个小模型做 draft，大模型做 verify，能加速生成。

部署时还要注意输出解析的鲁棒性。LLM 生成的文本可能格式不完全正确，比如少了闭合标签、点索引范围重叠等。解析器需要做容错处理，比如用正则提取、对重叠范围做后处理。

5. 常见问题与排查技巧实录

5.1 训练不收敛的典型原因

PartLLM 训练不收敛，最常见的原因有三个。

第一个是 alignment 阶段 lr 太大。表现是 loss 震荡，3D token 的 embedding 范数爆炸。解决办法是把 lr 降到 1e-5 甚至更低，加 warmup。

第二个是点排序不一致。训练和推理时点排序策略不同，模型学到的索引范围完全错乱。排查方法是固定一个排序函数，在 dataset 的__getitem__里统一调用。

第三个是文本格式不统一。训练数据的输出格式和推理时的解析格式不一致，比如训练用 JSON，推理用 XML。这个坑很隐蔽，因为 loss 看起来在降，但实际效果很差。解决办法是定义一套严格的格式规范，训练和推理共用同一个 parser。

5.2 分割精度不达预期的排查路径

如果模型能跑通但精度不行，按这个顺序排查：

1. 检查3D backbone 是否预训练。随机初始化的 backbone 提取的特征质量很差，建议用在 ShapeNet 上预训练过的权重。

2. 检查 query 数量是否够。64个 query 对于复杂形状可能不够，试试128个。

3. 检查训练数据覆盖度。如果测试集的物体类别在训练集里没出现过，效果差是正常的。需要补充数据或者做 zero-shot 评估。

4. 检查输出解析是否正确。有时候模型输出是对的，但解析器把点索引映射错了。

5.3 常见问题速查表

5.4 独家避坑技巧

分享几个我在实操中踩过的坑。

坑一：点云采样数量不一致。训练时采10000个点，推理时采20000个，backbone 输出的特征分布完全不一样，模型直接崩。解决办法是固定采样数量，在预处理阶段就统一。

坑二：部件名称大小写敏感。“Backrest”和“backrest”在 LLM 的 tokenizer 里可能是不同的 token，导致模型学混。解决办法是统一转小写。

坑三：点索引范围重叠。LLM 生成的索引范围可能有重叠，比如0-500和450-800。解析器需要做后处理，比如按置信度或者按顺序覆盖。

坑四：忽略 attention mask。3D token 和文本 token 拼接后，attention mask 要正确设置，否则 padding 位置会干扰 attention。这个坑在 batch 内序列长度不一致时特别容易出。

6. 应用场景与扩展方向

6.1 工业设计与逆向工程

在工业设计场景，设计师经常需要把扫描得到的3D模型拆成部件，用于后续的编辑和修改。传统做法是手动分割，费时费力。PartLLM 的文本引导分割能力在这里特别有用，设计师输入“把外壳拆出来”，模型自动完成分割。

逆向工程场景也类似，扫描一个实物得到点云，需要理解它的结构组成。PartLLM 的全形状拆分可以直接输出部件列表和对应的点云区域，下游的 CAD 重建模块可以基于这些区域分别处理。

6.2 机器人抓取与操作

机器人抓取需要理解物体的部件结构。比如抓一个杯子，要知道把手在哪、杯身在哪。PartLLM 的交互式分割可以让操作员点一下把手，模型分割出把手的完整区域，机器人再基于这个区域规划抓取位姿。

这个场景对实时性要求高，PartLLM 的推理延迟需要优化到500ms以内。量化加 KV cache 复用是必要的。

6.3 3D内容生成与编辑

在3D内容生成 pipeline 里，PartLLM 可以作为部件级编辑的基础。生成一个3D模型后，用 PartLLM 分割出部件，然后对特定部件做替换、变形、材质修改。这种部件级的编辑比整体编辑灵活得多。

文本引导分割在这里的价值最大，用户可以用自然语言描述想编辑的部件，不需要手动选择。

6.4 后续可扩展的技术方向

从技术演进角度看，PartLLM 这个框架还有几个明显的扩展方向。

方向一：支持更多输入模态。目前主要是点云和文本，未来可以加入图像、视频、深度图。比如用户拍一张照片，模型理解照片里的物体并分割对应的3D部件。

方向二：部件级属性预测。不只分割部件，还预测部件的材质、功能、运动学属性。这对机器人操作和物理仿真很有价值。

方向三：跨形状的部件对应。给定两个形状，找出它们之间的部件对应关系。这在形状检索和迁移学习里有应用。

方向四：与3D生成模型结合。分割和生成联合训练，生成模型生成形状的同时输出部件结构，分割模型提供监督信号。

我个人在实际操作中的体会是，PartLLM 这类“用文本统一任务”的思路，最大的价值不在于单个任务的精度提升，而在于工程上的可维护性和可扩展性。一套框架覆盖多个任务，迭代成本低，新任务只需要设计新的 prompt 格式，不需要重新设计网络结构。这个思路在2D领域已经被验证过，3D领域现在也在走同样的路。如果你在做3D相关的项目，建议尽早把文本化接口的设计纳入考虑，后面扩展会省很多事。