RangeNet++ Ubuntu20.04环境配置与KITTI推理实战

搞点云语义分割的朋友，估计多多少少都听过RangeNet++这个名字。这模型2019年出来的，放到现在虽然不算新，但在实际项目里依然很能打。我最近在Ubuntu20.04上重新配了一套RangeNet++环境，从源码编译到KITTI数据集推理，前前后后踩了不少坑，今天干脆把完整过程梳理出来，包括环境版本怎么选、编译顺序怎么排、权重文件怎么放、推理脚本怎么改，以及几个最容易让人卡住的问题。这份实战指南覆盖了环境配置和完整运行流程，适合刚入门点云分割、想跑通一个经典基线模型来对比实验的同学参考。

先说结论：RangeNet++最大的价值在于，它把三维点云分割问题转换成了二维图像分割问题，靠着range image这种紧凑表示，内存占用和推理速度都很友好，是很多工程落地方案的起点。但正因为它老，依赖库比较旧，在Ubuntu20.04上从零配环境，对新手来说确实有点折磨。

1. RangeNet++核心思路与配置前景

1.1 为什么用range image而不是直接处理点云

RangeNet++的原论文全称是《RangeNet++: Fast and Accurate LiDAR Semantic Segmentation》，核心思想并不复杂。激光雷达扫描得到的三维点云是无序、稀疏的，直接在三维空间做卷积计算量很大。RangeNet++的做法是先把点云投影成一张二维的range image，也就是距离图像，每个像素的灰度值代表该方向上的距离，然后在二维图像上做语义分割。

这样做的最大好处是效率高。二维卷积成熟且快，模型可以设计得非常轻量，而且在嵌入式设备上也能跑到实时。缺点也很明显，投影过程必然丢失信息，多个点可能投影到同一个像素上，边界处会出现锯齿和混叠，所以论文里专门加了一个kNN后处理步骤来修正边界。

投影公式其实很简单。对于激光雷达的第i个点，有x、y、z三维坐标，投影到图像上的坐标(u, v)可以这样算：

u = (atan2(y, x) / (2 * pi)) * W v = (asin(z / r) + pi / 2) / pi * H

其中r是点到原点的距离，W和H是range image的宽和高。KITTI数据集的64线激光雷达，对应H=64，W通常取2048，也就是每根扫描线占一行，水平方向均匀采样2048个点。这种投影方式和Velodyne HDL-64E的扫描结构是对应的，如果你用的是别的雷达，H要改成对应的线数，W可以根据水平分辨率调整。

理解这一点很重要，因为后面配置环境、调参、处理数据时，很多问题都出在这个投影上。比如你换了雷达但忘了改H，那么生成range image的尺寸就会和模型输入不匹配，报错信息还不一定直观。

1.2 模型结构、权重文件和依赖库的来龙去脉

RangeNet++的完整代码在GitHub上可以找到，官方仓库叫rangeNet-lib。这个项目包含了三部分：C++底层库、PyTorch训练与推理代码、以及一系列脚本工具。

模型的主干网络原版用的是SqueezeSeg的编码器结构，也就是类似SqueezeNet的fire module堆叠，后来很多复现版本改用了DarkNet53做backbone。不同版本之间权重文件不互通，这一点务必注意。你在GitHub上搜rangeNet相关仓库时，会看到不同的权重下载链接，一定要和代码自带的checkpoint对应起来。

依赖库方面，RangeNet++官方代码依赖libtorch，这是PyTorch的C++版本。编译C++库时需要单独下载libtorch，编译PyTorch扩展部分时需要和conda环境里的PyTorch版本一致，否则会出现ABI不兼容的问题。这个坑我后面会详细说。

还有一个容易被忽略的点：RangeNet++仓库里默认的推理脚本用的是ONNX导出加TensorRT加速，但完整走通TensorRT流程需要单独装TensorRT库，过程比较繁琐。我这次直接用PyTorch的Python接口来推理，省去TensorRT，效果一样，跑KITTI单帧点云大概几百毫秒，完全够用。

2. 环境准备与依赖版本选择

2.1 Ubuntu20.04、GPU驱动与CUDA版本

先说我的硬件环境：一台RTX 3080显卡的机器，显存10GB。操作系统是Ubuntu20.04，内核版本5.15。RangeNet++的训练和推理对显存要求不算高，但如果想做完整训练，建议至少8GB显存。如果只是推理，4GB都够用。

Ubuntu20.04下装显卡驱动，我推荐用系统自带的“软件和更新”界面，或者命令行直接装。

sudo apt update sudo apt install nvidia-driver-535

装完重启后，用nvidia-smi命令验证驱动是否正常。这里有个经验：RangeNet++编译时用的是C++和CUDA，驱动版本最好新一点，但CUDA toolkit版本不需要太新。我用的是CUDA 11.3，和PyTorch 1.10搭配非常稳。

CUDA toolkit的安装方式，我建议用runfile本地安装，这样不会污染系统级的/usr/local/cuda。先到NVIDIA官网下载CUDA 11.3的runfile，然后：

sudo sh cuda_11.3.0_465.19.01_linux.run --toolkit --silent --override

安装完成后，设置环境变量：

echo 'export PATH=/usr/local/cuda-11.3/bin:$PATH' >> ~/.bashrc echo 'export LD_LIBRARY_PATH=/usr/local/cuda-11.3/lib64:$LD_LIBRARY_PATH' >> ~/.bashrc source ~/.bashrc

注意这里为什么不用更新的CUDA？因为RangeNet++源码里有部分代码是旧式CUDA写法，比如用到了cudaPointerAttributes的legacy字段，这个字段在新版CUDA里被移除了，直接编译会报错。CUDA 11.3到11.6之间基本都能编译通过，12.x就不建议了。

2.2 conda环境、Python版本与PyTorch版本

Python版本我选的是3.8，这是PyTorch 1.10时代比较标准的版本，第三方库兼容性好。用conda建环境：

conda create -n rangenet python=3.8 conda activate rangenet

接下来装PyTorch。这里直接pip装最快：

pip install torch==1.10.0+cu113 torchvision==0.11.0+cu113 -f https://download.pytorch.org/whl/torch_stable.html

装完后验证一下torch能不能正常导入：python -c "import torch; print(torch.version)"。如果输出1.10.0，说明CUDA版本没选错。

然后装其他依赖包。官方requirements.txt里有numpy、tqdm、Pillow、tensorboardX这几个。我建议再装一个open3d，方便可视化点云。版本要注意：

pip install numpy==1.21.6 tqdm Pillow==9.5.0 tensorboardX open3d==0.16.0

Pillow这里必须锁版本，因为Pillow 10.0以后删除了PIL.Image.ANTIALIAS这个常量，RangeNet++的可视化脚本里还在用，会导致AttributeError。这个坑我在后面会专门说。

2.3 libtorch下载与路径配置

RangeNet++的C++部分编译时要用libtorch，就是PyTorch的C++发行版。因为Python环境里是torch 1.10.0，所以libtorch也要对应下载1.10.0版本，而且是cu113版本。下载地址在PyTorch官网，找到"LibTorch"那一栏，选C++/Java，然后选1.10.0、CUDA 11.3、Linux。

下载解压后，路径记下来，比如我放在~/libtorch。这个路径后面编译时要用到，而且要注意，如果你用的是zip包解压的libtorch，它会自带一个lib目录，编译时链接库的路径也要指对。

很多人在编译RangeNet++时卡在这一步，因为官方README里写的libtorch路径和你实际的路径不一样，你要把CMakeLists.txt里的路径改成自己的。下面编译章节我会给出改好的CMake配置示例。

3. RangeNet++完整编译流程

3.1 获取源码与目录结构

先把源码clone下来：

git clone https://github.com/PRBonn/rangenet_lib.git cd rangenet_lib

源码目录结构大概是这样的：

rangenet_lib/ ├── CMakeLists.txt ├── cpp/ # C++底层库，包括投影、kNN后处理等 ├── python/ # PyTorch推理脚本和模型定义 ├── scripts/ # 数据处理、评估脚本 └── weights/ # 权重文件目录（需要自己建）

这个项目有两个核心的库：libsqueezeSeg和libknn。libsqueezeSeg负责模型的前向传播和投影操作，libknn专门做kNN后处理。编译时要先把这两个库编译出来，然后Python模块才能调用。

3.2 编译C++库的完整步骤

RangeNet++的CMake编译是整个配置过程中最容易翻车的地方。我们需要编辑CMakeLists.txt，把libtorch路径指对。打开文件找到类似这样的行：

set(Torch_DIR /path/to/libtorch/share/cmake/Torch)

改成你实际的路径：

set(Torch_DIR $ENV{HOME}/libtorch/share/cmake/Torch)

同时检查C++标准。RangeNet++源码比较老，有些地方用到C++14的特性，但libtorch 1.10要求C++14以上，所以建议把CMAKE_CXX_STANDARD设为14。不然后面编译会报一堆奇怪的语法错误。

接下来开始编译：

mkdir build && cd build cmake .. -DCMAKE_BUILD_TYPE=Release make -j$(nproc)

如果顺利的话，lib目录下会生成libsqueezeSeg.so和libknn.so，同时还会生成一些可执行文件。编译过程可能出现两个高频问题：

第一个是error: ‘class torch::Tensor’ has no member named’view’这类错误，这通常是因为libtorch版本和源码预期不匹配。RangeNet++发布时用的是PyTorch 1.1左右的API，后来PyTorch改了接口，把view改名成reshape等。解决办法是找到报错的源文件，把tensor.view(改成tensor.reshape(。这个改动量不大，但需要耐心，因为可能不止一处。

第二个问题是undefined reference to cublasCreate，这是CUDA库链接缺失。需要在CMakeLists.txt里加上：

find_package(CUDA REQUIRED) target_link_libraries(your_target ${CUDA_LIBRARIES})

经验之谈，如果你不想改CMakeLists，也可以直接修改build目录下的CMakeCache.txt，把CMAKE_CUDA_COMPILER指到正确的nvcc路径，然后用cmake ..重新配置。但改CMakeLists是最干净的。

3.3 编译Python模块

C++库编译成功后，需要编译Python模块，让Python代码能调用这些底层库。这一步通常在setup.py或者直接import编译好的.so文件完成。

在rangenet_lib/python目录下，官方提供了一个编译脚本。我直接手动编译：

cd python python setup.py build_ext --inplace

如果之前编译C++库时生成了.so文件，在python/rangenet/目录下会有rangenet_pybind.so。装好后测试一下能否import：

cd .. python -c "from rangenet import segmentation; print('import ok')"

这里要注意的是，setup.py里有时硬编码了CUDA路径，如果你的CUDA不在/usr/local/cuda，需要修改setup.py里的cuda_path变量。另外一个常见问题是fatal error: torch/extension.h: No such file or directory，这说明setup.py找不到torch的头文件路径。解决办法是在setup.py开头加上：

import torch from setuptools import setup from torch.utils.cpp_extension import BuildExtension, CppExtension

然后指定include_dirs为torch头文件所在目录。如果还是找不到，就显式写出来：

include_dirs=[torch.utils.cpp_extension.include_paths()[0]]

还有一个容易被忽略的问题：如果你在Python环境里用的PyTorch是1.10.0，但编译时链接到的libtorch是1.1版本，那么编译出的模块在import时会报错：undefined symbol: _ZN2at6detail...之类。所以务必让setup.py编译时用的torch和你加载时用的torch是同一个版本。最简单的方式是，在编译Python模块时，先激活conda环境，然后确认python -c "import torch; print(torch.version)"是1.10.0。

3.4 启用GPU版kNN加速

RangeNet++的后处理kNN是逐点找近邻的，数据量大的时候CPU跑起来非常慢。源码里有GPU版本，默认可能没开启。在CMakeLists.txt里找到knn相关配置，把USE_GPU选项打开：

set(USE_GPU ON)

或者在cmake命令行传入：

cmake .. -DCMAKE_BUILD_TYPE=Release -DUSE_GPU=ON

GPU版kNN的加速效果是肉眼可见的。我测过，KITTI一帧大约12万个点，CPU版kNN要跑两三秒，GPU版几十毫秒就完事。如果后续你要做批量评估，这个加速非常关键。

3.5 验证编译是否成功

编译完成后，用一个最小测试确认整条链路是通的。在rangenet_lib目录下建一个test.py：

import torch import numpy as np from rangenet import segmentation net = segmentation.RangeNetSegmentator( "weights/rangeNet53-dataset-v4.0.tar", "config/rangeNet53.yaml", "cuda" ) print("model loaded")

这里会用到权重文件和配置文件。如果你现在还没有权重，可以先跳过模型加载，只测试底层库能否导入。整个链路是否打通，以能否加载模型为标志。

4. 数据准备与模型下载

4.1 KITTI语义分割数据集的目录结构

KITTI是自动驾驶领域最常用的数据集之一。RangeNet++官方在KITTI语义分割数据集上训练并发布了权重。数据集可以从KITTI官网下载，也可以从一些镜像源拉取。

KITTI语义分割数据集分为两部分：SuycTraining（带标签的训练集）和SuycTesting（无标签的测试集）。训练集一共8000多帧，测试集大约1000帧。数据组织方式是这样的：

kitti/ ├── training/ │ ├── velodyne/ # 原始点云.bin文件 │ ├── labels/ # 语义标签.label文件 │ ├── calib/ # 相机标定文件 │ └── poses/ # 姿态文件 └── testing/ └── velodyne/ # 测试点云.bin文件

如果你只做推理和复现，下载testing里的velodyne就够了，大概几个GB。如果你想重新训练或者做验证集评估，需要下载完整的training数据，大概要几十GB，提前备好硬盘空间。

点云文件是.bin格式，每个点四个float32，分别是x、y、z、reflectance。读取方式很简单：

import numpy as np points = np.fromfile("000000.bin", dtype=np.float32).reshape(-1, 4)

标签文件是.label格式，每个点一个uint32，低16位是语义类别，高16位是实例ID。KITTI语义分割共19个类别，包括car、pedestrian、cyclist、road、sidewalk等。读取方式：

label = np.fromfile("000000.label", dtype=np.uint32).reshape(-1) semantic_label = label & 0xFFFF

4.2 权重文件与配置文件解析

RangeNet++官方提供了一个训练好的权重文件，名字类似rangeNet53-dataset-v4.0.tar。里面包含模型的state dict，是PyTorch的checkpoint格式，用tar打包。下载后放到weights目录下。

配置文件是YAML格式，里面定义了模型输入的高度、宽度、类别数、投影参数等。核心参数包括：

• height: 64
• width: 2048
• n_classes: 20（19类加一个无效类）

如果换数据集，n_classes得改。配置文件还定义了投影时距离截断的范围，默认可能把超过80米的点去掉。这个在推理时需要注意，如果你要分割远距离物体，改配置文件里的max_range参数。

权重文件和模型定义必须严格匹配。RangeNet++有SqueezeSeg和DarkNet53两个版本，权重也是分开的。我下载的是DarkNet53版本，配置文件也是对应的rangeNet53.yaml。如果你用SqueezeSeg的权重配DarkNet53的模型，加载时大概率会报key不匹配的错。

4.3 权重路径与配置文件路径的坑

RangeNet++加载模型时，代码会拼接权重文件和配置文件的相对路径。我建议在项目根目录下维护一个weights目录和一个config目录，路径统一用绝对路径或者项目根目录的相对路径，避免在别的目录下运行脚本时找不到文件。

另外，配置文件里如果有model_file字段，它指定的可能是模型定义文件路径。不同版本的代码这个字段的含义不同，有的指.onnx文件，有的指.pth文件。我用的是官方Python版本，配置文件里没有这个字段，直接从外部传参传入权重路径。

5. 实际运行与推理效果测试

5.1 单帧点云的推理命令与参数解释

我写了一个简单的推理脚本，放在项目根目录下，可以直接跑单帧点云：

import argparse import numpy as np import open3d as o3d from rangenet import segmentation def load_pc_from_bin(bin_path): points = np.fromfile(bin_path, dtype=np.float32).reshape(-1, 4) return points def predict_one_frame(net, pc): # RangeNet++需要(height, width, 4)的输入，或者直接传point cloud labels = net.infer(pc, "cuda") # labels shape: (H, W)，每个像素一个类别ID return labels if __name__ == "__main__": parser = argparse.ArgumentParser() parser.add_argument("--pc_path", type=str, default="data/000000.bin") parser.add_argument("--weights", type=str, default="weights/rangeNet53-dataset-v4.0.tar") parser.add_argument("--config", type=str, default="config/rangeNet53.yaml") args = parser.parse_args() net = segmentation.RangeNetSegmentator(args.weights, args.config, "cuda") pc = load_pc_from_bin(args.pc_path) labels = predict_one_frame(net, pc) # 可视化：把label映射到颜色 # 这里label shape是(H, W)，需要投影回三维点云才能用open3d显示 print("inference done, labels shape:", labels.shape)

注意net.infer的接口。有的版本要求传入点云的三维坐标Nx3，有的版本要求传入已投影好的range image。我的做法是直接传原始点云，让内部代码自己投影，这样最省事。如果你发现传入点云后出错，检查一下rangenet的版本，可能需要手动构造range image传进去。

5.2 从label到三维点云的可视化方法

RangeNet++输出的label是二维的，如果想要在三维空间展示语义分割结果，需要把label从range image映射回三维点云。这一步可以用投影矩阵反过来计算，但最简单的方式是用原始点云坐标加上label信息。

我这里写了一个轻量可视化函数：

def project_labels_to_pc(points, labels, width=2048, height=64): # 这里labels shape是(H, W)，points是Nx4 # 需要把每个点对应到某个像素坐标 # 一般做法是用与投影相同的公式，直接为每个点计算像素位置 # 然后从这个像素位置提取label x, y, z = points[:, 0], points[:, 1], points[:, 2] r = np.sqrt(x**2 + y**2 + z**2) u = np.arctan2(y, x) / (2 * np.pi) * width v = (np.arcsin(z / r) + np.pi / 2) / np.pi * height u = np.clip(u, 0, width - 1).astype(np.int32) v = np.clip(v, 0, height - 1).astype(np.int32) pc_labels = labels[v, u] return pc_labels

有了每个点的类别ID，接下来就可以用open3d可视化。给每个类别分配一个颜色，简单的做法是直接用KITTI官方的color map：

kitti_color_map = { 0: [0, 0, 0], # unlabeled 1: [0, 0, 255], # car 2: [0, 255, 0], # pedestrian # 按你自己的类别表继续 } colors = np.zeros((pc.shape[0], 3)) for cls, color in kitti_color_map.items(): mask = pc_labels == cls colors[mask] = color

然后用open3d显示点云。这一步主要用来直观检查模型输出的效果，比如车、行人、道路边界是否分割准确。

5.3 批量推理与评估指标

单帧能跑通后，批量推理很容易。无非是遍历目录下的.bin文件，逐个调用predict_one_frame，保存结果到输出目录。注意保存标签时不要忘了恢复成uint32格式并高16位写0：

def save_label(bin_path, out_path, labels): n_points = len(np.fromfile(bin_path, dtype=np.float32).reshape(-1, 4)) # labels是project回点云的每个点的语义ID out = np.zeros(n_points, dtype=np.uint32) out[:] = labels.astype(np.uint32) out.tofile(out_path)

评估指标方面，KITTI语义分割常用mIoU（mean Intersection over Union）。RangeNet++官方有评估脚本，会把预测的label和ground truth对比。我自己测试时，DarkNet53版本的权重在KITTI val上的mIoU大概在52%左右，和其他论文里的数据基本一致。如果你跑出来的数字偏差很大，先检查一下类别数是否对齐，KITTI数据集的类别索引从0到18，19是ignore。

还有一个使用心得：RangeNet++的输出在物体边界处容易出现锯齿状噪点，这主要是投影混叠造成的。kNN后处理确实能改善一部分，但不可能完全消除。实际工程中，如果你想得到干净的分割结果，可以再接一个条件随机场做平滑，但实时性会打折扣。

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

6.1 编译阶段的高频报错与对策

我这次踩的第一坑是gcc版本导致的编译失败。Ubuntu20.04默认gcc是9.4.0，但RangeNet++源码里有一处用了旧式写法，在高版本gcc下会报error: variable ‘val’ set but not used。这是个warning被当作error的例子。解决办法有两个：一是把CMakeLists.txt里-Werror去掉，二是在报错文件里注释掉那个变量。我推荐前者，一劳永逸。

第二坑是ninja内存溢出。RangeNet++的CMake如果默认用了Ninja，有时候并行编译时内存占用过高直接卡死。我在编译时加了-j$(nproc)，内存还是吃紧。解决办法是降低并行度，比如make -j4，或者干脆换回Unix Makefiles，重新配置：

cmake .. -DCMAKE_BUILD_TYPE=Release -G "Unix Makefiles"

第三坑是找不到torch库。报错信息一般是Could NOT find Torch，这种情况十有八九是CMake的Torch_DIR路径没设对。确认libtorch解压目录下有share/cmake/Torch/TorchConfig.cmake，然后在CMakeLists里把路径指到这个目录。

编译期的坑基本就这三大类。如果你在编译Python模块时遇到undefined symbol，基本是PyTorch ABI mismatch，重新确保libtorch和torch版本一致就好。

6.2 推理阶段的报错与修正

推理阶段最气人的是模型加载成功但infer时报错。一个常见错误是size mismatch for encoder.layer1.0.weight之类的，这说明权重文件里某个张量的维度和模型定义不一致。要么是backbone版本选错，要么是权重下载不完整，重新核对类型和文件名。

另一个常见问题是显存不足。默认投影宽度2048、高度64，用DarkNet53做前向，batch size为1时显存占用大概3GB，如果你的显卡只有4GB显存，可能刚够但容易爆。解决办法是把配置文件里的width调小，比如1024，分割精度会略降，但不至于崩。

还有个非常隐蔽的问题：如果输入点云做了体素滤波或裁减，点数变少之后，投影到range image时某些像素会是空值。RangeNet++内部对这些空值有特殊处理，但如果点数太少，超过一半像素是空的，模型输出质量会明显下降。因此实际使用时，建议保留一定密度的点云，不要过度下采样。

6.3 可视化脚本中的Pillow版本坑

RangeNet++官方仓库里有个可视化脚本paint.py，里面调用了Image.ANTIALIAS。这个常量在Pillow 10.0以后被移除了，如果你直接运行，会报AttributeError: module 'PIL.Image' has no attribute 'ANTIALIAS'。最简单的解决办法是安装Pillow 9.5.0。如果你不想降级，也可以修改paint.py，把Image.ANTIALIAS改成Image.Resampling.LANCZOS，效果一样。

这个问题特别容易坑到新人，因为报错本身和点云、分割没有半点关系，纯粹是依赖库版本太新。我一开始也被卡了十分钟，后来定位到是Pillow的问题，直接改了脚本。

6.4 如何排查结果异常与精度下降

如果推理出来的分割结果明显不对，比如大面积类别重叠、地面全被分成人、所有物体都变成同一类，优先检查以下几个方面。

第一，检查输入点云的坐标范围。KITTI点云以激光雷达为原点，x轴向前，y轴向左，z轴向上。如果你用的点云坐标系不同，比如以车辆中心为原点或者z轴朝下，投影计算结果会完全错乱。解决办法是手动将点云转换到激光雷达坐标系，或者写一个预处理脚本做坐标轴对齐。

第二，检查类别数配置。RangeNet++默认类别数是20，但KITTI语义分割实际类别是19个（18个语义类加1个无效类）。如果你下载的权重是在某个自定义数据集上训练的，类别数可能不同。配置文件里的n_classes必须和权重匹配。

第三，检查range image的宽高是否与权重训练时一致。官方KITTI权重用的是64x2048，如果你改成32x1024，模型在推理时虽然能跑，但因为输入分布变了，精度会显著下降。调试时可以先用默认配置跑，再考虑优化。

6.5 环境迁移与复现的通用建议

最后说说怎么让这份环境变得更可复现，方便以后换机器或者给别人用。

我的做法是做一个conda环境导出文件：

conda env export > environment.yaml

这个文件会记录所有conda包和pip包的版本。换机器后直接用conda env create -f environment.yaml恢复，可以省去很多手动安装的麻烦。

C++端的libtorch和编译好的.so文件，我放在项目目录下的third_party里，并写了README说明版本和下载链接。建议不要直接把.so文件提交到git，体积大且和CUDA版本强相关，别人clone下来也未必能用。更好的方式是把编译脚本写好，让人一键编译。

RangeNet++这个模型虽然老，但在点云语义分割领域，它依然是理解"投影法"思想的最佳样例。很多新的工作，比如SalsaNext、FIDNet，都是在它的基础上改进的。把环境配置这条路走通后，你再去看后续的论文，会发现里面很多概念都已经有实际体验了。

最后再分享一个小技巧：如果你只是想评测某个点云文件，不一定要把整套流程都跑起来。可以先用官方提供的在线demo或者colab脚本验证效果，确认结果符合预期后，再投入时间配置本地环境。这样能避免把大量时间花在环境搭建上，最后发现模型效果并不适合你的业务场景。我在做工业项目时，基本都是这个思路，先快速验证，再决定是否深度集成。