本地模型做提取任务这两年讨论最多的场景之一就是 building footprint extraction。简单说就是从遥感影像或航拍影像里把建筑轮廓自动提出来输出成可供 GIS 使用的矢量边界。和直接调云端 API 相比本地模型的核心优势是数据不出环境、后处理可以反复改、批量任务跑起来成本更可控。但“本地能跑”和“本地能稳定产出可用结果”是两回事很多人一开始只看到模型精度实际落地时却被数据切片、环境依赖、输出管理这些事拖住。这篇文章不打算堆功能列表而是从一次横向对比的视角拆清楚如果你要评估本地模型在提取任务上的表现应该先准备什么、怎么跑通、怎么判断结果、遇到问题按什么顺序排查。无论你是做地理信息、遥感解译还是单纯想把一套检测模型搬回本地跑批量下面的思路都可以直接套用。1. 先弄清楚“本地模型做提取”到底在对比什么1.1 提取任务的两条路线端到端分割和本地推理服务“head to head”按字面理解是模型之间正面对比。放到提取场景里我们通常比的是两条路线。一条是端到端的语义分割模型。输入影像瓦片输出每个像素的类别概率再通过后处理把建筑区域转成轮廓。这条路线最直接也是 building footprint extraction 最常见的做法。另一条是本地部署的推理服务。模型被封装成接口批量图片送进去拿回掩膜或边界。这类服务可能是通用分割模型也可能是针对建筑轮廓微调过的专用模型。它解决的问题是工程化接入让上游系统和下游系统之间不需要手工拷贝文件。这两条路线不冲突。很多落地流程是先用分割模型出掩膜再用后处理算法修正边界最后统一转矢量。对比时不要把“模型”和“工程流程”混在一起否则你很难说清楚精度差异到底是模型带来的还是后处理带来的。1.2 对比本地模型时不能只盯着平均精度很多人在对比本地模型时只看一个数字比如 IoU 或者 F1。这是最容易踩的坑。提取任务真正要看的输出质量维度至少有五个完整度建筑轮廓是否被完整识别有没有一半被切掉。边界精度轮廓线是否贴合真实房顶边缘有没有锯齿或内缩。拓扑正确性相邻建筑是否粘连洞口、天井有没有被错误填充。小目标表现小房子、密集自建房、临时建筑是否被漏检。泛化能力换一个城市、换一种拍摄角度或光影条件后精度下降多少。同一个模型在不同数据上的表现差异可能非常大。本地的优势恰恰在这里你可以用自己的数据反复试把指标和可视化结果都放在一起再做决定。只看平均精度选出来的模型很可能在你自己的数据上并不是最优解。2. 跑本地提取模型之前先把环境条件列出来2.1 显存、内存、磁盘和推理时间的基本判断本地模型能不能跑第一道门槛不是模型有多先进而是你的机器能装下什么。以常见的图像分割模型为例判断条件大致是这些检查项建议关注点显存单张推理时峰值占用批量推理时按 batch size 成倍上升内存大影像切片、数据加载和缓存都会占用内存磁盘模型权重、中间结果、瓦片缓存都需要空间CPU数据预处理、后处理、矢量化通常吃 CPU推理时间单张 512 或 1024 瓦片耗时多少批量吞吐多少这些数字没有一个固定的“够用标准”因为不同模型、不同输入尺寸差异很大。更稳妥的做法是先跑一个最小样例用监控工具记录峰值显存和峰值内存再决定要不要加 batch size。比如 Linux 下可以用 nvidia-smi 周期性记录显存也可以用系统监控工具看 CPU 和内存。跑完一个小批次后把峰值占用记下来再倒推合理的并发数。不要一上来就开满并发否则报的错很难判断是内存不足还是代码问题。2.2 数据准备影像、标签、范围、切片building footprint extraction 的输入通常是遥感影像或无人机影像输出是建筑轮廓。数据准备阶段要做四件事统一定义范围想清楚提取对象是永久建筑、临时板房还是含棚房这个定义直接影响标注和验收。统一数据格式影像的投影坐标系要一致波段顺序要一致尤其是多光谱数据。检查标签质量如果有现成的建筑轮廓标签先检查错位、漏标、边界粗糙的问题否则模型学到的就是错误边界。切片大影像一般切成 512 或 1024 的瓦片再送进模型切片时要注意重叠率避免建筑正好被切在边缘。切片重叠率通常建议 10% 到 25%。重叠太小边缘建筑容易被截断重叠太大推理成本翻倍。这个值没有绝对标准要看你目标建筑的平均尺寸。如果建筑普遍很大重叠率要适当提高如果建筑小而密可以适当降低。2.3 依赖工具链的选择本地跑这类任务常见依赖包括深度学习框架、图像处理库、矢量处理库。比较常见的组合是 PyTorch 加 OpenCV 加 shapely 或 geopandas。如果你的流程里还要做瓦片拼接和矢量化GDAL 和 rasterio 也几乎绕不开。这里给的是通用组合原始材料没有给出明确版本落地时一定要先确认依赖版本和你的 CUDA 环境是否匹配。我踩过不少次因为 PyTorch 和 CUDA 版本不匹配导致推理直接报错的坑。这类问题看起来像模型问题实际上和环境问题差不多。第一次搭建环境时建议把框架版本、CUDA 版本、显卡驱动版本都记录下来放到项目 README 里。换机器、换环境时这份记录能省很多时间。3. 单条样本验证先跑通再谈对比3.1 最小验证流程多模型对比之前先保证每个模型在同样的单条样本上能稳定跑通。我会这样拆准备一张裁剪好的影像瓦片尺寸固定在 512 或 1024。写出一个最简单的推理脚本输入这张瓦片输出掩膜。记录日志模型输入路径、模型权重路径、预处理方式、推理耗时、输出路径。检查输出不是空数组掩膜尺寸和输入一致类别数量正确。示意图如下# 单条样本验证脚本示意 model load_model(weights.pth) tile read_image(sample.tif) tile preprocess(tile) # 归一化、裁剪、通道调整 mask model.predict(tile) # 输出概率图或掩膜 save_mask(mask, output/mask.tif)先跑单条任务的意义在于把变量减到最少。如果这一步就挂了后面所有对比数据都不可信。不要拿一个还没验证过的脚本直接跑几十张图否则你可能花了很多时间最后发现是预处理写错了。3.2 输出结果怎么检查模型输出通常是概率图或二值掩膜。检查时不要只看有没有形状要看边界是否合理。我一般做三件事把掩膜叠加到原图上目视检查建筑边缘是否贴合。用连通域分析看是否有大量碎块。统计掩膜面积和标签面积的偏差如果系统性偏大或偏小说明模型有系统性偏移。这一步不需要很复杂的代码但很能说明问题。输出质量不是靠一个指标决定的可视化复查在提取任务里几乎是必需的。3.3 成功标准不是“跑出来”就结束单条样本的验收标准至少包括三部分不报错推理脚本从头到尾没有异常。输出完整掩膜尺寸、通道数、数据范围都正确。结果可用目视检查轮廓基本贴合没有大面积误检。如果这三条都满足再进入多模型对比。这里要额外提醒一句成功标准里要写清楚“什么是失败”。比如输出为空、输出错位、输出全是背景都算失败。把失败定义写清楚批量跑的时候你才知道哪些结果需要重新处理。4. 多模型横向对比要控制哪些变量4.1 统一数据、统一指标、统一后处理“head to head”最怕的就是变量控制不一致。对比至少要做到三个统一统一测试数据同一批影像、同一个切片方式、同一套标签。统一前后处理归一化方式、颜色通道顺序、是否反转、后处理阈值都要一致。统一设备环境同一台机器、同一个推理框架版本至少要记录清楚。如果 A 模型用了精细后处理B 模型直接用原始概率图做阈值那对比出来的是“后处理后的 A”和“后处理前的 B”不是模型本身的对比。这个道理很简单实际操作时却经常被忽略。具体执行时我建议先把后处理流程抽成独立函数所有模型共用。这样既保证公平也方便后面单独调后处理参数。后处理对提取结果的影响有时候比模型选择还大。4.2 指标怎么看IoU、F1、边界完整度、推理耗时提取任务常用指标可以分成两类质量指标和成本指标。指标看什么注意点IoU预测掩膜和真实标签的重叠程度对边界偏移敏感但无法反映拓扑错误F1精确率和召回率的平衡小目标多时单独看 F1 不够边界完整度轮廓是完整还是断成多段需要后处理统计光看 IoU 看不出推理耗时单张瓦片耗时和批量吞吐包含预处理和后处理才是真实耗时显存峰值单卡还是多卡、batch 多大影响你能跑多大的模型和并发建议不要只看一个指标。同样的 IoU一个模型可能是边界外扩另一个是漏检部分建筑这两个问题在业务上的影响完全不同。边界外扩的问题可能通过收缩后处理解决漏检却很难靠后处理补回来两者处理的优先级不一样。4.3 可视化对比和人工复核自动指标只能告诉你“差多少”不能告诉你“差在哪里”。我会把多个模型的结果并排输出成对比图按区域放大看三类问题密集建筑区是否粘连。阴影、树木遮挡区域是否漏检。大型建筑屋顶边缘是否被切碎。如果有条件找一位懂业务的人一起看结果。建筑提取的标准不完全由模型决定还取决于下游用途比如做城市管理、做变化检测、做三维重建对边界精度的要求都不一样。让业务方参与复核能避免你只盯着指标调模型最后交付的东西却不符合实际需求。5. 从单模型到批量提取落地5.1 切片推理与原图拼接单张瓦片跑通后批量提取的第一步是把大影像切成瓦片推理完成后把掩膜拼回原图坐标系。拼接时要注意每个瓦片要记录它在原图中的行列偏移否则拼回去会错位。重叠区域要决定融合策略常见做法是取中间区域或加权平均。拼接完成后要裁剪到原图范围避免边缘多出黑边。这个阶段最容易出的问题不是模型而是坐标偏移。我见过很多次结果看起来“好像还行”一叠加到原影像上就发现整体平移了几十个像素。排查时优先检查瓦片坐标记录和重采样方式而不是调模型。5.2 批量任务需要的队列、日志和失败重试批量推理不能只写一个 for 循环。至少要处理三件事任务队列把瓦片列表按顺序排队能暂停、能续跑。日志记录每张瓦片的输入、输出、耗时、是否成功都记录到文件。失败重试单张失败不能导致整个批次中断失败的要单独重试。还有输出命名。批量任务里输出文件命名是重灾区建议用“原图名加行列号”的方式生成唯一文件名避免覆盖和混淆。比如 tile_scene01_row012_col034_mask.tif一眼就能看出这张结果来自哪个位置。如果可能给每个批次生成一个批次 ID并把配置参数、模型权重路径、数据版本都写进日志。这样出了结果问题你能快速定位是哪一批、哪个参数、哪个模型版本。5.3 从栅格结果到矢量边界掩膜是栅格结果但 building footprint extraction 的业务交付通常是矢量边界。从栅格到矢量的常用流程是对掩膜做后处理去掉碎块、填补小洞。使用轮廓提取算法生成多边形。对多边形做简化去掉过多顶点。按最小面积阈值过滤噪声。这一步里两个参数很关键最小面积阈值和简化容差。最小面积太小会留下大量噪声碎片简化容差太大直角屋顶会被抹圆。建议先在小范围测试目视确认后再套用到全图。6. 常见问题排查和适用边界6.1 精度低、边界碎、漏检、卡死的排查顺序本地提取模型最常见的四类问题建议按固定顺序排查。精度低先看测试集和训练集是否同分布再看标签是否准确最后再看模型输入尺寸是不是太小。不要一上来就换模型很多精度问题出在数据而不是模型。边界碎先看后处理有没有做连通域合并和轮廓简化再看掩膜阈值是否合理。边界碎通常是后处理不足而不是模型能力问题。漏检先看切片重叠率再看小目标是否被下采样过滤掉。如果建筑尺寸远小于输入瓦片的一个像素漏检几乎是必然的。这时候要考虑提高输入分辨率或者分层处理不同尺寸的目标。卡死或无输出先看显存和内存占用再看日志有没有异常最后看输出目录权限和路径。任务卡住时先确认资源占用和输出目录不要盲目重启。6.2 参数边界不是分辨率越高越好不是并发越大越快提取任务里有两个很容易被夸大的直觉。第一个是“分辨率越高越好”。输入分辨率提高模型确实可能看得更细但推理时间、显存占用、后处理复杂度都会上升。而且如果训练数据的标签边界本身不精确高分辨率只会把标签错误放得更大。建议从模型训练时的原始分辨率开始测不要随意加码。第二个是“并发越大越快”。批量推理时并发增加会提升吞吐但到一定程度后GPU 显存和 CPU 预处理会成为瓶颈速度不再线性提升还可能因为显存溢出直接挂掉。建议先跑一个并发梯度测试比如 1、2、4、8找到拐点再确定生产并发数。6.3 什么时候不要迷信本地模型本地模型很好但不是所有场景都适合。如果你的数据量很小、只需要一次性提取或者对时效性要求极高云端 API 可能更合适因为本地部署和调试的成本摊薄不下来。反之如果你要长期批量处理、数据又不能出环境或者需要反复调后处理本地模型就是更合理的选择。还有一类情况要单独说模型选择不要只看“本地能跑”。能跑只是第一步批量稳定性、输出格式统一性、后处理可维护性才是真正决定这个方案能不能长期用的因素。很多项目不是死在推理精度而是死在输出管理混乱和失败重试缺失。踩过不少次之后我的判断是本地模型做提取真正该盯住的不是模型列表而是输入数据、资源占用和失败重试这三件事。先把单条样本跑稳再把对比变量控制住最后再考虑批量和接口。这个顺序看起来慢实际是最省时间的。如果你正在做 building footprint extraction 或者类似的本地提取任务按这个流程走一遍基本上能把 80% 的坑提前踩掉。