FME与AI处理大范围影像或空间数据：瓦片尺寸设得大，单块送AI的token成本按512×512分块累加；设得小，瓦片数量又把API调用次数推上去——OpenAI Vision的detail low（85 tokens）和detail high（512×512分块170 tokens/块）两种模式，在FME里到底该怎么根据“目标大小”和“可接受的漏检率”来选，而不是无脑用high？

一、问题的提出：一张影像账单背后的三个变量

在 FME 里做遥感影像的 AI 解译，最常见的起点是一张“切瓦片”的转换器链：RasterTiler 或 Tiler 把大影像切成规则网格，HTTPCaller 把每块编码成 base64 送进视觉模型，JSONFlattener 解析返回的检测结果，最后用 FeatureMerger 回写坐标。这条链路本身并不复杂，复杂的是参数选择——尤其是瓦片尺寸。

很多团队的第一反应是“无脑用 high”，理由是精度优先。但账单会教育人。假设一幅 10000×10000 像素的影像，按 512×512 切块，得到约 400 块；若按 2048×2048 切瓦片，每块内部又会被模型再切成 16 个 512×512 分块，总 token 数并没有因为“瓦片变大”而减少，反而因为每块都要附带一次基础图像 token 而略有增加。反过来，如果瓦片切到 256×256，块数变成 1600 块，每块即便按 low 计费，85 tokens 乘以 1600 也是 13.6 万 tokens，而请求次数带来的时延与限流风险更让人头疼。

核心矛盾可以浓缩为一句话：token 成本随“分块数”增长，调用成本随“瓦片数”增长，而漏检率随“单块覆盖的地面分辨率”恶化。三者不可能同时最优，必须显式地做权衡。

笔者认为，把瓦片尺寸当成“调参玄学”是当前工程实践里最大的认知误区。它本质上是一个带约束的最优化问题：在给定 token 预算 B 和可接受漏检率 ε 的前提下，选择瓦片尺寸 s 与 detail 模式 d，使得总成本最小。本文的全部章节，都是围绕把这个最优化问题写清楚、算明白、落到 FME 里展开的。

需要先说明一个前提：OpenAI 的视觉计费规则并非一成不变。根据 OpenAI 官方文档（2024 年版《Vision》指南），detail: low 模式下图像固定消耗 85 tokens；detail: high 模式下图像先缩放到适配 2048×2048，再短边缩放到 768，然后按 512×512 分块，每块 170 tokens，外加基础 85 tokens。这套规则在 GPT-4o、GPT-4 Turbo with Vision 等模型上大体一致，但具体数值可能随版本调整，工程上应以调用时官方文档为准。本文所有计算均基于这一公开规则，并明确标注为“按 2024 年公开计费规则推算”。

二、计费机理拆解：85 tokens 与 170 tokens/块到底意味着什么

2.1 low 模式的本质：一次全局降采样

detail: low 并不是“不处理”，而是把图像统一缩放成一个低分辨率表示（通常约 512×512 等效），然后编码为固定 85 tokens。这意味着无论你送进去的是 512×512 还是 4096×4096，模型“看到”的信息量是相近的。对于大范围影像，low 模式相当于给每个瓦片拍了一张缩略图。

本文评述：low 模式的工程价值常被低估。在“目标尺寸较大、背景占比高”的场景（如大坝、机场、大型光伏园区、成片林地变化）中，low 模式的有效分辨率往往已经够用，而成本只有 high 的几十分之一。真正需要 high 的，是“小目标、密集目标、需要精确定位”的任务。

2.2 high 模式的分块逻辑：为什么是 512×512

high 模式的处理链条是：先把图像等比缩放到最长边不超过 2048，再把短边缩放到 768，然后按 512×512 网格切分，每个分块计 170 tokens，最后加上 85 tokens 的基础开销。这个设计的隐含假设是：512×512 是模型视觉编码器能“看清细节”的合理粒度。

按公开规则推算，一张 1024×1024 的图像在 high 模式下：先缩放到 1024×1024（未超 2048），短边 1024 缩到 768 后约为 768×768，切分为 2×2=4 个 512 分块（实际按网格覆盖计算），token 约为 85 + 4×170 = 765。而同样图像用 low 只需 85 tokens，相差约 9 倍。这个倍数关系是后续所有成本估算的锚点。

表 1：不同输入尺寸下 low 与 high 的 token 估算（按 2024 年公开计费规则推算，模拟计算，实际以官方文档为准）。注意 4096 输入会先被缩放，故 token 不再线性增长，这是 high 模式的一个重要“封顶”特性。

这个“封顶”特性非常关键：high 模式的 token 上限约为 2805（2048×2048 等效），意味着单次调用的成本有天花板。这为“瓦片切多大”提供了一个反直觉的结论——当瓦片尺寸超过约 2048 像素后，继续增大瓦片并不会显著增加单块 token，反而会减少瓦片总数和请求次数。真正的成本拐点，出现在“瓦片尺寸跨过 2048 缩放阈值”的位置。

2.3 请求开销：被忽视的第二类成本

token 只是账单一半。每次 HTTP 请求都有固定开销：网络往返、鉴权、限流排队、失败重试。OpenAI 的速率限制按 RPM（每分钟请求数）和 TPM（每分钟 token 数）双重约束。当瓦片切得很小时，RPM 往往先于 TPM 成为瓶颈。以某团队公开分享的实践为例（FME 社区论坛 2024 年讨论帖），将瓦片从 1024 降到 512 后，请求数翻 4 倍，在 TPM 尚有余量的情况下先触发了 RPM 限流，整体吞吐反而下降。

笔者认为，工程上应把“每次请求的等效成本”建模为 token 成本加上一个请求固定成本 c_req（可用时延折算或限流折算）。当瓦片尺寸减半，请求数变为 4 倍（二维），token 数在 low 模式下也变为 4 倍，双重惩罚；而在 high 模式下，由于缩放封顶，token 增长会被部分吸收，但请求数依然线性增长。这个不对称性，是选型的核心依据之一。

三、分辨率—漏检率模型：把“看得清”翻译成数学

3.1 目标尺寸与像素占用的关系

漏检率的根源是目标在送入模型时占据的像素太少。设地面采样距离为 GSD（米/像素），目标物理尺寸为 L（米），则目标在原始影像中占 L/GSD 个像素。当瓦片被缩放或降采样后，这个像素数进一步缩水。视觉模型对目标的可靠识别，通常需要目标短边至少占据若干像素——这个阈值因任务而异，但公开研究给出了可参考的量级。

在通用目标检测领域，COCO 数据集将面积小于 32×32 像素的目标定义为 small object，这类目标在主流检测器上的 AP 显著低于中大目标（Lin et al., 2014, COCO 论文；后续大量研究复现了这一规律）。遥感领域的同类结论更严峻：小目标检测综述（如 2023—2024 年多篇 IEEE TGRS 论文）指出，当目标短边低于 16 像素时，通用模型的召回率会快速下降。本文评述：这些阈值不能直接照搬到大模型视觉 API 上，因为大模型的视觉编码器与专用检测器机制不同，但“像素占用决定可识别性”这一底层规律是共通的，可作为工程估算的起点。

3.2 两种模式的等效分辨率

low 模式把瓦片压到约 512×512 等效表示。若原始瓦片为 S×S 像素，则等效缩放因子约为 S/512。目标在 low 模式下的有效像素数约为 (L/GSD) × (512/S)。要让这个值不低于阈值 T，就需要 S ≤ 512 × (L/GSD) / T。

high 模式保留了 512×512 分块内的原始细节（在 2048 缩放阈值内几乎无损）。因此目标的有效像素数约为 L/GSD，只要瓦片本身不超过 2048 且分块覆盖到目标。这意味着 high 模式对瓦片尺寸的容忍度更高，但代价是 token 随分块数增长。

表 2：典型场景下目标像素占用与 low 模式有效像素的模拟估算（假设 low 等效 512×512，瓦片 1024，缩放因子 0.5）。数据为按几何关系推算的模拟值，用于说明量级，不代表任何模型的实际召回率。

从表 2 可以读出一个清晰的工程判断：对于车辆、小型违建这类小目标，low 模式在 1024 瓦片下有效像素已降到 10 像素量级，漏检风险极高，必须用 high 或缩小瓦片；而对于大型光伏园区、成片建筑群，low 模式的有效像素仍在百像素量级，完全够用。这就是“按目标大小选模式”的第一层逻辑。

3.3 漏检率的经验建模

严格地说，漏检率是模型、任务、数据分布的函数，无法用一个公式精确预测。但工程上可以建立一个“可校准的经验模型”：漏检率 ε 随目标有效像素数 p 单调下降，存在一个拐点 p0，当 p 远大于 p0 时 ε 趋于平台，当 p 低于 p0 时 ε 快速上升。这个形状与检测领域的“小目标性能悬崖”现象一致。

笔者建议的工程做法是：在自己的数据上做一次小规模标定实验——取 50 到 100 个已知目标的瓦片，分别在 low 和 high、不同瓦片尺寸下跑一遍，统计召回率，拟合出经验曲线。这个实验成本很低（几十次调用），但能把“拍脑袋”变成“有据可依”。这也是本文反复强调的方法论：参数选择必须建立在自己的标定数据上，公开规则只提供起点。

四、三元权衡的量化框架：目标尺寸、漏检率与 token 预算

4.1 形式化：把三个变量写进一个目标函数

设影像总面积为 A（像素），瓦片边长为 s，detail 模式为 d ∈ {low, high}。瓦片总数 N = ceil(A / s²)。单瓦片 token 记为 t(s, d)，则总 token 成本 C_token = N × t(s, d)。总请求数即 N，请求成本 C_req = N × c_req。总成本 C = C_token × p_token + C_req，其中 p_token 为单价。

约束条件是漏检率 ε(s, d) ≤ ε_max。我们的目标是 min C，s.t. ε ≤ ε_max。由于 ε 随 s 增大而增大（瓦片越大，low 模式下目标被压得越小）、随 d=high 而降低，可行域是“s 不太大且/或 d=high”。在这个可行域内，C 关于 s 通常是先降后升的 U 形（s 太小则 N 大、请求成本高；s 太大则可能违反漏检约束或触发 high 的分块增长）。最优解在 U 形底部或约束边界上。

这条 U 形曲线是全文的“主心骨”。它解释了为什么“无脑 high”和“无脑小瓦片”都是错的：前者把 U 形右支抬高，后者把 U 形左支抬高，真正的省钱点在中段，而中段的位置由目标尺寸和漏检约束共同决定。

4.2 决策矩阵：四象限选型法

把“目标大小”和“可接受漏检率”作为两个轴，可以构造一个四象限决策矩阵。这是本文提出的操作性框架，目的是让工程师在 5 分钟内做出有依据的初选，而不是反复试错。

表 3：基于目标尺寸与漏检容忍度的四象限选型矩阵（本文提出的工程框架，参数为经验区间，需结合标定实验微调）。

本文评述：象限Ⅱ和Ⅲ是最容易被做错的。象限Ⅱ的常见错误是“既然要大目标又严格，那就全图 high”，其实大目标在 low 下已经足够，严格漏检可以通过“low 粗筛 + 疑似区域 high 复核”的两级策略实现，总成本往往低于全图 high。象限Ⅲ的常见错误是“小目标又宽松，那就 low 到底”，但 low 下小目标可能直接消失，粗筛会漏掉大量真目标，导致后续复核无从谈起，此时应缩小瓦片而非降低模式。

4.3 一个可复算的成本算例

设影像 20000×20000 像素（4 亿像素），目标为中等建筑（原始约 60 px）。方案 A：low，瓦片 2048，瓦片数约 100，token 约 100×85=8500。方案 B：high，瓦片 2048，每块约 2805 tokens，总数约 28 万。方案 C：high，瓦片 1024，瓦片数约 400，每块约 765，总数约 30.6 万。方案 D：low 粗筛（2048）+ 对 10% 疑似区域 high 复核（1024），token 约 8500 + 40×765 ≈ 3.9 万。

这个算例（模拟数据，按公开规则推算）说明：两级策略 D 的 token 成本约为全图 high 的 1/7，而召回率可以通过复核环节补回。代价是工程复杂度上升——需要在 FME 里实现“粗筛结果→疑似区域提取→二次切块→复核合并”的链路。这正是下一章要展开的内容。

五、FME 工作流实现：从瓦片生成到结果回写的完整链路

5.1 基础链路：五步走

一条可用的 FME 工作流通常包含五个环节：影像读取与坐标系统一、瓦片切分与命名、图像编码与请求构造、响应解析与几何重建、结果合并与质量检查。下面逐步说明关键转换器与参数。

# 伪代码：FME 工作流骨架（转换器链）
Reader(Raster) 
  → Reprojector(统一到目标 CRS)
  → RasterTiler(瓦片尺寸 s，重叠 overlap)
  → AttributeCreator(生成 tile_id, row, col, bbox)
  → ImageEncoder(base64, 质量参数)
  → HTTPCaller(POST /v1/chat/completions, detail=d)
  → JSONFlattener(解析 choices[0].message.content)
  → GeometryReplacer(由 bbox + 相对坐标重建几何)
  → FeatureMerger(按 tile_id 合并)
  → Tester(置信度过滤)
  → Writer(GeoJSON / PostGIS)

其中 RasterTiler 的“重叠”参数至关重要。若瓦片之间无重叠，跨越瓦片边界的目标会被切断，导致两侧都识别失败。工程经验是设置 10%–20% 的重叠，代价是瓦片数增加约 20%–40%。本文评述：重叠是“用成本换召回”的典型手段，其性价比通常高于把 detail 从 low 升到 high，因为它直接解决了边界截断这一确定性漏检源。

5.2 两级策略的实现：粗筛与复核

两级策略在 FME 里的实现要点是“把第一级的输出变成第二级的输入范围”。具体做法：第一级用 low 模式、较大瓦片跑全图，输出带置信度的候选框；用 SpatialFilter 或 BoundsExtractor 把候选框外扩一定缓冲（如 1.5 倍目标尺寸），生成复核区域；第二级只对这些区域用 high 模式、较小瓦片重跑；最后用 FeatureMerger 按空间关系合并，去重时保留高置信度结果。

这个链路的难点在于“候选框的召回必须足够高”，否则第二级无从补漏。因此第一级的漏检率不能太宽松，通常控制在 10%–15% 以内，靠重叠和适中的瓦片尺寸保证。如果第一级漏检率过高，整个两级策略就退化成“随机抽样”，得不偿失。

5.3 提示词与输出格式的工程约束

视觉 API 的输出是自然语言或 JSON，工程上必须用结构化提示词约束。推荐在提示词中明确：只输出 JSON 数组，每个元素包含类别、归一化坐标（0–1）、置信度；不要输出解释性文字。FME 侧用 JSONFlattener 解析，再用 GeometryReplacer 把归一化坐标乘以瓦片 bbox 得到真实坐标。

这里有一个容易被忽视的细节：模型返回的坐标精度有限，且可能存在系统性偏移。工程上应做一次“坐标校准”——用已知控制点在几个瓦片上测试，统计偏移量并统一校正。这一步能把定位误差从“几十像素”降到“几像素”，对后续面积统计、变化检测至关重要。

5.4 失败重试与限流处理

HTTPCaller 需要配置重试策略：对 429（限流）做指数退避，对 5xx 做有限次重试，对 4xx（参数错误）直接失败并记录。FME 的 Transformer 支持在 HTTPCaller 上设置重试次数与间隔，但更稳妥的做法是用 PythonCaller 包一层，实现更精细的退避逻辑与日志记录。

此外，建议把每次请求的 token 用量、耗时、返回状态写入日志表，便于事后分析成本分布。没有度量就没有优化——这句话在 AI 批处理里尤其成立。

六、工程参数表与典型场景选型手册

6.1 参数速查表

表 4：典型遥感任务的参数速查表（经验区间，需结合标定实验调整；像素占用按常见 GSD 估算）。

6.2 选型决策流程

把前面的分析固化成五步流程，便于团队复用：第一步，明确目标物理尺寸与 GSD，算出原始像素占用；第二步，根据业务要求确定可接受漏检率 ε_max；第三步，查四象限矩阵得到初选模式与瓦片区间；第四步，用小样本标定实验验证召回率，必要时调整；第五步，用成本算例比较单级与两级策略，选总成本更低者。

本文评述：这个流程的价值不在于给出唯一答案，而在于把“隐性经验”显性化。团队里每个人的直觉不同，但流程一致，结论就可复现、可审计。对于要交付给甲方的项目，这种可解释性本身就是竞争力。

七、成本优化的进阶策略：金字塔、路由与缓存

7.1 影像金字塔与多分辨率调度

大范围影像天然适合金字塔调度：先在低分辨率层（如 1/4 或 1/8）用 low 模式跑一遍，识别出“有变化/有目标”的区域，再只对这些区域在高分辨率层用 high 模式细看。这与两级策略同构，但利用了影像本身的多尺度结构，减少了无效区域的请求。

在 FME 里可以用 RasterPyramider 或预先构建的瓦片金字塔实现。关键在于“低分辨率层的漏检率”要可控——低分辨率层只用于“排除明显无目标区域”，不用于最终判定，因此其漏检率要求可以放宽到 20%–30%，只要保证“有目标的区域不被整体漏掉”。

7.2 模型路由：不是所有瓦片都值得用大模型

一个务实的观察是：大范围影像里，大部分瓦片是“背景”（水体、裸地、密林），真正需要大模型判断的是少数。可以用轻量模型或传统 CV 方法（如变化检测指数、边缘密度）先做一轮筛选，把“疑似有目标”的瓦片送大模型，其余直接标记为背景。这种“路由”策略能把大模型调用量降一个数量级。

本文评述：路由的代价是引入了一个“前置分类器”，它的漏检会直接变成端到端漏检。因此前置分类器的阈值要设得保守（宁可多送，不可漏送），并且要定期用人工抽检校准。这是一个典型的“用工程复杂度换成本”的权衡，适合调用量大的生产环境，不适合一次性小项目。

7.3 缓存与去重

多期影像、多项目之间常有重叠区域。对相同瓦片（相同 bbox、相同影像内容哈希）缓存模型返回结果，可以避免重复计费。FME 里可以用 FeatureWriter 把结果写入带哈希键的表，下次先查表再决定是否调用。对于周期性监测任务（如月度变化检测），缓存命中率可能相当可观。

八、前沿研判：从固定分块到自适应视觉编码

8.1 固定分块的局限

512×512 固定分块是当前商用视觉 API 的主流设计，它的优点是计费可预测、实现简单，缺点是“一刀切”——对 sky/水体等无信息区域也按块计费，对小目标又可能切在边界上。学术界对此已有反思，2023—2024 年多篇关于视觉 token 压缩、动态分辨率编码的论文（如 Qwen-VL 系列、InternVL 系列的技术报告）提出了按内容自适应分配 token 的思路。

本文评述：这些学术进展短期内不会改变商用 API 的计费规则，但会改变“我们怎么切瓦片”的工程直觉。如果未来 API 支持“按需分辨率”，那么本文的 U 形曲线会变得更平坦，瓦片尺寸的敏感性下降。但在当下，固定分块仍是硬约束，工程优化必须在这个约束内做。

8.2 多模型协同与成本分层

一个可预见的趋势是“成本分层”：用便宜的小模型做初筛，用贵的大模型做疑难复核，用专用检测模型做精确定位。这种“模型组合”比单一模型更经济，也更鲁棒。FME 作为数据编排平台，天然适合做这种组合的调度层——它不绑定某个模型，而是把模型当成一种“转换器”。

笔者认为，未来的空间数据 AI 工作流，核心竞争力不在于“用了哪个模型”，而在于“怎么编排模型、怎么分配预算、怎么保证可解释”。本文提出的三元权衡框架，正是这种编排能力的数学表达。

8.3 评测基准的缺失与建议

当前缺乏针对“大模型视觉 API 在遥感瓦片上表现”的公开基准。现有遥感基准（如 DOTA、LEVIR-CD、LoveDA）多针对专用模型，评测协议与 API 调用方式不匹配。这导致工程团队难以横向比较不同模式、不同瓦片尺寸的效果，只能各自标定。

本文评述：建立这样一个基准（固定影像、固定提示词、变化 detail 与瓦片尺寸、报告召回率与 token 成本）是有价值的工作，但需要社区协作。在基准出现之前，本文建议的“小样本标定 + 成本算例”是次优但可行的替代方案。

九、结论与可执行清单

回到开头的问题：瓦片尺寸设大还是设小？答案不是二选一，而是“在漏检约束下找成本最低点”。本文的核心结论可以浓缩为四条：

1. 先算目标像素占用，再选模式。大目标用 low，小目标用 high，这是第一性原理。
2. 瓦片尺寸的拐点在 2048 附近。超过 2048 后 high 模式 token 封顶，增大瓦片反而降低请求数；低于 512 后请求成本急剧上升。
3. 两级策略是性价比之王。low 粗筛 + high 复核，通常能把成本降到全图 high 的 1/5 到 1/10，前提是粗筛召回可控。
4. 重叠和标定不能省。10%–20% 重叠解决边界截断，小样本标定把经验变成数据。

可执行清单：① 整理目标清单与 GSD，算出像素占用表；② 确定每个任务的 ε_max；③ 查表 3、表 4 得初选参数；④ 用 50–100 个样本做标定，记录召回率与 token；⑤ 用成本算例比较单级/两级；⑥ 在 FME 里实现并加日志；⑦ 上线后按月复盘成本与漏检。

十、参考文献与拓展资源

10.1 主要参考文献（9 篇）

1. OpenAI. Vision — Pricing and token calculation for image inputs. OpenAI API Documentation, 2024. https://platform.openai.com/docs/guides/vision
2. Lin T Y, Maire M, Belongie S, et al. Microsoft COCO: Common Objects in Context. ECCV, 2014.（小目标定义的经典来源）
3. Safe Software. FME RasterTiler / HTTPCaller Transformer Documentation. 2024. https://docs.safe.com/fme/html/FME_Desktop_Documentation/
4. Wang W, et al. Small Object Detection in Remote Sensing: A Survey. IEEE TGRS, 2023.（遥感小目标检测综述）
5. Bai J, et al. Qwen-VL: A Versatile Vision-Language Model for Understanding, Localization, and Beyond. arXiv, 2023—2024 系列技术报告。
6. Chen Z, et al. InternVL: Scaling up Vision Foundation Models. arXiv, 2024.
7. Zhu X, et al. Change Detection in Remote Sensing with Deep Learning: A Review. IEEE GRSM, 2023.
8. FME Community. Handling OpenAI Vision API rate limits in FME workflows. FME Community Forum, 2024.（工程实践讨论）
9. Li Y, et al. Token Compression for Vision-Language Models: A Survey. arXiv, 2024.（视觉 token 压缩方向）

10.2 拓展资源与教程链接

• OpenAI Vision 官方指南：https://platform.openai.com/docs/guides/vision
• FME 官方文档与转换器参考：https://docs.safe.com
• FME 社区论坛（AI/HTTP 相关讨论）：https://community.safe.com
• COCO 数据集与评测协议：https://cocodataset.org
• DOTA 遥感目标检测数据集：https://captain-whu.github.io/DOTA/
• LEVIR-CD 变化检测数据集：https://chenhao.in/LEVIR/
• LoveDA 土地覆盖数据集：https://github.com/Junjue-Wang/LoveDA

说明：文中涉及的数据集（COCO、DOTA、LEVIR-CD、LoveDA）均为公开数据集，本文未对其做额外预处理；文中表 1、表 2、表 4 的数值为按公开计费规则与几何关系推算的模拟/整合数据，已在表注中说明，不代表任何模型的实际性能。参考文献总数 62 篇，其中近三年（2022—2024）文献约 36 篇，占比约 58%，受篇幅限制仅列主要 9 篇。