本地模型建筑足迹提取横向对比：YOLOv8与SAM实战指南

最近和做地理信息、遥感数据处理的朋友聊天，很多人的需求已经从“能不能调一个云端API”变成了“能不能在本地把提取任务跑起来”。特别是在 building footprint extraction 这类任务上，数据往往涉及内网资产、版权影像，传云端既不安全也不现实。这次我们从实际工程落地角度出发，把本地模型做信息提取的横向对比流程讲清楚：包括本地模型怎么选、显存和硬件门槛是什么、部署启动怎么做、批量任务怎么跑、接口怎么封装，以及最容易踩的坑。

先说结论：本地模型做提取，最关键的并不是某个模型“看起来多厉害”，而是它能不能在你的机器上稳定复现、批量处理、可量化评估。文章会围绕三种技术路线展开对比：一类是单阶段分割模型（YOLOv8-seg 这类），一类是提示分割模型（SAM/SAM2 这类），一类是本地多模态视觉语言模型（VLM）。三类模型的输出形式、资源占用、部署难度差异非常大，适合的工程场景也不一样。本文会演示一套可复用的对比评测流程，让你在自己机器上也能把“Local models head to head for extraction”这件事跑通。

1. 提取任务的核心能力速览

在进入具体部署之前，先把这次评测关注的能力维度整理成表。下面的参数来自常见本地部署实践，具体数字需要以你本机的模型版本和推理分辨率为准。

从表格可以看出，没有单一模型能在所有维度上做到最优。YOLO 类分割模型适合“给定标注数据后做高效批量提取”，SAM 系列适合“交互式修正和自动全图分割”，VLM 则适合“属性提取、结果复核、自然语言交互”。文章后面的对比评测会重点看四个维度：提取精度、单体资源占用、批量稳定性、接口集成难度。

2. 本地模型选型与对比维度

2.1 为什么需要本地模型做提取

在 building footprint extraction 这类任务中，遥感影像通常有版权和使用范围限制，直接把影像发送到外部 API 服务存在合规风险。本地模型意味着整个推理链路都在自己的机器上完成：影像读取、预处理、推理、后处理、矢量化、结果导出都不离开本机。这样既满足数据管控要求，又可以针对自己的数据集反复调参。

另外，本地模型在批量任务上有明显优势。云端 API 通常按调用次数计费，大批量推理成本高且受并发限制。本地部署一次后，批量推理只消耗电力和硬件资源，适合需要反复迭代的场景。

2.2 三条技术路线的本质区别

路线 A 是监督式分割模型。它需要一定量的标注数据做训练或微调，但训练完成后推理速度快，可以直接对整张影像输出建筑掩码。适合标注数据充足、任务域比较固定的项目。

路线 B 是提示分割模型。SAM 系列模型在零样本情况下也能分割任意对象，但它本身不是一个“找到所有建筑”的检测器。要在全图上自动提取建筑足迹，通常需要额外加一个目标检测器生成建议框，再交给 SAM 生成精细掩码。适合需要人工交互修正的场景。

路线 C 是本地 VLM 模型。这类模型的优势是能理解自然语言指令，可以直接问“这张图里有几栋建筑，分别是什么类型的屋顶”，但劣势是它输出的是文本而不是像素掩码。在建筑足迹提取任务中更适合做属性提取和结果复核，而不是直接生成轮廓矢量。

2.3 评测指标怎么定

做模型对比前，先统一评测指标，否则对比结果没有说服力。建筑足迹提取常用以下指标：

3. 适用场景与使用边界

本地模型做建筑足迹提取，适合以下项目：

• 自然资源调查，需要对辖区影像做建筑分布摸底，前提是有合法数据来源和授权。
• 城市规划辅助，批量识别建筑物轮廓，用于更新 GIS 图层。
• 工程测量预处理，在正式测绘前自动生成候选建筑范围，减少人工勾绘工作量。
• 数据不出内网的项目，影像数据无法上传外部服务，本地模型是唯一现实方案。

不适合的场景也要说清楚。如果项目对建筑轮廓精度要求达到厘米级、需要满足法定测绘成果标准，纯 AI 模型提取结果不能直接作为成果，只能作为辅助参考。另外，涉及敏感区域识别、未经审批的目标侦测，不能使用个人或企业内部模型替代法定流程。

合规边界是硬要求：使用遥感影像、地图数据、建筑标注数据时，必须确认数据来源合法、授权范围清晰。提取结果如果涉及个人隐私、建筑物所有人信息，也要按相关法律法规处理。本文所有示例只使用公开测试数据和合成数据验证流程。

4. 环境准备与前置条件

本地模型部署首先要有一台能跑的机器。建筑足迹提取通常处理的是高分辨率遥感影像，对内存、显存和磁盘速度的要求都不低。下面是通用环境检查清单，不需要严格照搬，但建议逐项确认。

4.1 硬件环境

• GPU：建议 NVIDIA 显卡，显存 8G 起步。如果你只是测试小尺寸影像，6G 也可以跑，但批量任务会比较吃力。
• CPU：支持 AVX 指令集即可，AMD 和 Intel 均能运行。
• 内存：建议 32G 以上。遥感影像切块处理时，内存占用往往比显存更早成为瓶颈。
• 磁盘：预留 50G 以上空间。模型文件、测试数据集、输出结果都需要空间。

4.2 软件环境

推荐使用 Python 3.9 到 3.11 的虚拟环境，避免不同模型依赖互相冲突。先创建独立环境：

python -m venv venv_extract source venv_extract/bin/activate # Windows 下使用 venv_extract\Scripts\activate

然后升级 pip 并安装基础依赖：

pip install --upgrade pip pip install torch torchvision --index-url https://download.pytorch.org/whl/cu121

这里需要注意：CUDA 版本必须和你的显卡驱动匹配。上面的命令指定了 cu121，如果你的驱动版本不同，需要到 PyTorch 官网重新选择对应的安装命令。装完之后，先验证 CUDA 是否可用：

python -c "import torch; print(torch.cuda.is_available()); print(torch.version.cuda)"

如果输出False，说明 CUDA 安装有问题，需要先解决驱动和 PyTorch 的版本匹配问题，再继续后面的部署。

5. 数据集与评测基准准备

模型对比不能只靠“看起来效果不错”的主观判断，需要一套固定的测试集。这里推荐使用公开的建筑物分割数据集做基准，例如 Massachusetts Buildings Dataset、Inria Aerial Image Labeling Dataset、Open Buildings 等。它们都提供影像和标注掩码，适合做横向对比。

5.1 测试集划分

从公开数据集中抽取固定数量的影像作为测试集，测试集不参与任何微调训练。建议至少准备 20 到 50 张覆盖不同场景的影像，包括：

• 高密度老城区，小建筑多、间距密。
• 低密度郊区，大建筑、空地多。
• 新开发区，建筑规整、边界清晰。

固定测试集保证三个模型看到完全相同的输入，指标的差异才能归因到模型本身。

5.2 标注格式处理

公开数据集的标注格式不一定统一。有些是单通道 PNG 掩码，有些是 GeoJSON 矢量。使用 GeoJSON 标注时，需要先矢栅转换：

import geopandas as gpd from PIL import Image import numpy as np # 读取 GeoJSON 标注 gdf = gpd.read_file("label.geojson") # 创建空掩码，尺寸与影像一致 height, width = 1024, 1024 mask = np.zeros((height, width), dtype=np.uint8) # 将矢量面转换为像素掩码，具体实现需按项目和依赖库调整 # 这里仅示意：遍历 gdf 多边形，用 rasterio 或 PIL 绘制 print("掩码尺寸:", mask.shape)

5.3 评测脚本模板

统一评测脚本是横向对比的核心。无论哪个模型，推理后输出对应的 PNG 掩码，再计算 IoU：

import numpy as np from sklearn.metrics import jaccard_score def compute_iou(pred_mask, gt_mask): pred = (pred_mask > 0).astype(np.uint8).flatten() gt = (gt_mask > 0).astype(np.uint8).flatten() return jaccard_score(gt, pred, average="binary")

mIoU 可以对每张测试图计算 IoU 后取平均。注意：如果模型输出的是概率图，要先做二值化，阈值通常取 0.5，但需要根据验证集调整。

6. 本地模型部署与启动

6.1 路线 A：YOLO 类分割模型部署

YOLO 系列是实例分割的高效选择。以 Ultralytics 提供的 YOLO 分割权重为例，安装方式：

pip install ultralytics

推理脚本非常简洁：

from ultralytics import YOLO # 加载模型，路径按实际下载位置调整 model = YOLO("yolov8n-seg.pt") # 推理并保存结果 results = model.predict( source="test_image.png", conf=0.25, save=True, save_txt=True, save_conf=True )

这里的yolov8n-seg.pt是示例权重名，实际路径取决于你下载的版本。如果想提升精度，可以换yolov8m-seg.pt或yolov8x-seg.pt，显存占用会同步上升。

启动后，程序会在runs/segment/predict下生成标注结果图和标签文件。你还可以通过results[0].masks.data拿到原始掩码张量，方便后续做矢量化处理。

6.2 路线 B：SAM 系列提示分割部署

SAM 系列是 Meta 开源的提示分割模型，亮点是零样本泛化能力。安装依赖：

pip install segment-anything

推理时需要下载对应的模型权重。这里以 SAM 为例给出一个通用调用框架：

from segment_anything import sam_model_registry, SamPredictor import cv2 # 权重路径按实际下载位置调整 sam = sam_model_registry["vit_b"](checkpoint="sam_vit_b_01ec64.pth") sam.to("cuda") predictor = SamPredictor(sam) image = cv2.imread("test_image.png") predictor.set_image(image) # 输入一个提示点，坐标是 (x, y) input_point = np.array([[500, 400]]) input_label = np.array([1]) mask, score, _ = predictor.predict( point_coords=input_point, point_labels=input_label, multimask_output=True )

运行后可以得到多个候选掩码，score表示每个掩码的置信度。你需要根据自己的业务场景选择使用哪个掩码。

要注意：SAM 系列本身不会自动找到所有建筑。如果你要做全图自动提取，建议先用一个轻量检测模型生成候选框，再对每个框执行 SAM 分割。这样既保留了 SAM 的精细边界能力，又解决了“自动找目标”的问题。

6.3 路线 C：本地 VLM 部署

本地多模态视觉语言模型的部署方式各不相同，这里给出基于 Transformers 的通用调用框架：

from transformers import pipeline # 模型名称按实际使用的 VLM 替换 pipe = pipeline( "image-to-text", model="local-vlm-model-path", device=0 ) result = pipe( "test_image.png", prompt="请提取这张图中建筑的数量和位置描述，输出 JSON。" ) print(result)

把local-vlm-model-path替换成你实际下载的 VLM 目录即可。这类模型输出的不是掩码，而是文本。工程上常见用法是：先用 YOLO 或 SAM 得到建筑掩码，再用 VLM 对每个掩码区域做属性提取，比如判断屋顶类型、楼层数等。两个模型组合使用，比单独依赖任何一个模型都更可靠。

7. 功能测试与效果验证

7.1 单图提取测试

测试目的：验证模型能否在单张影像上输出可用的建筑足迹掩码。

操作步骤：

1. 准备一张覆盖一定建筑密度的测试影像。
2. 分别运行三个模型的单图推理。
3. 将输出掩码叠加到原图上，目视检查边界质量。

判断标准：

• 建筑轮廓是否闭合，有没有明显断裂。
• 边界是平滑还是锯齿严重。
• 小建筑是否漏检。
• 道路、空地是否被误检为建筑。

常见失败：掩码空白、漏检严重、边界明显偏移。出现这些情况时，先检查输入影像分辨率是否被过度压缩，再检查后处理阈值和二值化逻辑。

7.2 批量提取测试

测试目的：验证模型能稳定处理多张影像，并输出结构化结果。

批量推理以 YOLO 为例：

from ultralytics import YOLO model = YOLO("yolov8n-seg.pt") results = model.predict( source="./test_images/", # 输入目录 conf=0.25, save=True, project="./outputs", name="batch_run" )

这里重点观察三个现象：

• 批量任务是否全部跑完，有没有中途报错。
• 输出结果是否和输入文件一一对应。
• 处理速度是否稳定，有没有越跑越慢。

对 SAM 类模型做批量全图提取时，要额外写循环逻辑，按“检测建议框 -> SAM 分割 -> 汇总掩码”的顺序处理。这一步最容易出问题的是显存没有释放，推荐每次处理完一张图后手动清空中间变量，并用torch.cuda.empty_cache()释放显存缓存。

7.3 定量精度评估

批量推理完成后，把每个模型的掩码输出和真实标注做对比，计算 IoU 和 F1：

这张表给出的是常见规律，具体数值必须以你自己的测试集为准。对比的意义在于找到当前数据下“性价比最高”的模型，而不是追求某一个指标的最高绝对数字。

8. 接口 API 与批量任务

8.1 FastAPI 接口封装

本地模型封装为 HTTP 服务后，可以非常方便地集成到 GIS 工具、在线地图项目或内部管理系统中。使用 FastAPI 的通用模板如下：

pip install fastapi uvicorn python-multipart

from fastapi import FastAPI, UploadFile, File from ultralytics import YOLO import tempfile import os app = FastAPI() model = YOLO("yolov8n-seg.pt") @app.post("/extract") async def extract_building(file: UploadFile = File(...)): # 保存上传文件到临时目录 with tempfile.NamedTemporaryFile(suffix=".png", delete=False) as tmp: tmp.write(await file.read()) tmp_path = tmp.name # 执行提取 results = model.predict(tmp_path, conf=0.25) mask_data = results[0].masks.data.cpu().numpy() if results[0].masks is not None else [] # 清理临时文件 os.unlink(tmp_path) return { "status": "ok", "mask_count": len(mask_data), "note": "实际项目中请保存掩码并返回文件路径" }

启动服务：

uvicorn main:app --host 127.0.0.1 --port 8000

启动后，可以用浏览器访问http://127.0.0.1:8000/docs查看 Swagger 文档，也能直接测试接口。

用 curl 做一次接口验证：

curl -X POST http://127.0.0.1:8000/extract \ -F "file=@test_image.png"

需要强调：上面的示例代码是通用模板，YOLO("yolov8n-seg.pt")等路径必须按实际项目替换。生产环境还需要加入鉴权、日志、错误处理和请求大小限制。

8.2 批量任务目录设计

接口服务适合“按需调用”的场景，但如果是成百上千张影像的批量提取，建议直接用命令行脚本遍历目录，而不是频繁调用 HTTP 接口，后者会引入不必要的网络开销。推荐目录结构：

project/ ├── inputs/ # 原始影像 ├── outputs/ # 提取结果 │ ├── masks/ # PNG 掩码 │ └── geojson/ # 矢量化结果 ├── logs/ # 运行日志 └── models/ # 本地模型权重

批量脚本要注意三点：

• 检查输出文件是否已存在。已经处理过的文件跳过，这样任务意外中断后可以从断点继续。
• 每处理 50 张或 100 张就输出一次进度日志。
• 对每张图做异常捕获，单张失败不能中断整个任务。

9. 资源占用与性能观察方法

本地模型部署中，显存和内存是限制批量任务规模的主要瓶颈。这里给出一套通用的观察方法，不需要额外安装工具。

显存占用使用nvidia-smi实时查看：

nvidia-smi -l 1

在另一个终端运行推理脚本，观察推理过程中显存峰值。如果显存不够，优先尝试以下方案：

• 降低输入分辨率。把 1024x1024 降为 512x512，显存占用会大幅下降，代价是边界精度下降。
• 使用半精度推理。PyTorch 中可以用torch.autocast(device_type="cuda", dtype=torch.float16)包住推理代码。
• 减小批量大小。批量数从 8 降到 4 或 2，是降低显存最直接的手段。
• 及时释放中间变量。推理完一张图后，大数组变量要手动删除。

对 CPU 推理，建议限制推理线程数：

torch.set_num_threads(4)

10. 常见问题与排查方法

本地模型部署最耗时间的往往不是模型本身，而是环境问题和批处理稳定性。下面这张表整理了高频问题，建议保留备查。

11. 最佳实践与使用建议

从工程角度看，本地模型做提取任务要稳定运行，建议配置一套标准流程。第一次跑通时先用小分辨率、小批量、单张图验证链路，确认输入输出正确后再上批量任务。

模型权重、输入影像、输出结果、日志文件要分目录管理，不要混放在一起。大批量任务必须记录执行日志，格式建议包含时间戳、文件名、耗时和状态，方便回溯。

在多人协作环境中，接口服务要加访问限制，不要直接暴露到公网。可以在本地监听127.0.0.1，或通过反向代理加鉴权。涉及遥感影像、人脸、声音等敏感数据时，必须确认数据来源合法、使用已获授权，提取结果也不能用于未经批准的用途。

效果比较稳定之后，可以把提取结果导出为 GeoJSON 或其他矢量格式，接入 GIS 系统。矢量化可以用 OpenCV 的轮廓提取配合shapely构建多边形，也可以使用rasterio.features.shapes做栅格转矢量。

12. 总结与下一步

本地模型做信息提取，核心价值不是追赶某个模型的指标上限，而是把数据留在自己手里，让提取任务变得可重复、可调参、可批量。对 building footprint extraction 这类任务，更稳妥的路径是先用 YOLO 类分割模型做第一轮自动提取，再用 SAM 类模型修正边界，最后用本地 VLM 复核输出属性信息。

文章开头提到的“head to head”对比，本质是一次思路沉淀：模型选型不是凭感觉，而是用同一套固定测试集、同一套质量指标、同一台机器，把三个模型的精度、显存占用、吞吐量、部署难度全部摆到桌面上比较。

最容易踩的坑集中在三个点：CUDA 环境版本不匹配、全图推理时显存溢出、批量任务缺少断点续跑。先解决这三个问题，再谈模型精度优化，工程节奏会顺畅很多。

后续可以继续扩展的方向：一是引入更多本地模型，横向对比更多基线；二是做自动超参搜索，找到每个模型在当前数据上的最优阈值；三是把提取结果接入 RAG 或 GIS 系统，形成完整的数据生产链路。