这两年遥感行业里最热的一个词肯定绕不开大模型。尤其是卫星影像数据量越攒越多，传统的分割、检测、分类思路开始明显吃力，场景大、目标小、标注稀缺这三座大山压得很多团队喘不过气。我自己在最近一个模拟项目X里，完整做过一套遥感影像解译系统从传统CNN方案迁到遥感大模型方案的改造，还用上了国产自研AI计算生态做训练和推理。这篇文章就把我在这个过程中拆过的思路、踩过的坑、拿到手的配置和排查方法整理出来，希望对正在往遥感大模型方向走的同行有点用。

先说一下这篇内容适合谁：如果你在地理信息、遥感、测绘或者泛图像领域做算法和工程，手里有大量影像数据，正准备上大模型但不知道怎么选算力、怎么组织训练、怎么处理显存爆炸和推理精度回不到零点的问题，那你往下看基本都能找到对应的参考。我不讲花里胡哨的前沿概念，尽量把从数据到训练再到上线的链路拆开讲，讲清楚每一步为什么这么做。

1. 遥感大模型时代的技术背景与核心思路拆解

1.1 遥感数据量级带来的模型架构升级要求

以前很多团队做遥感影像解译，主流方案是靠ResNet、UNet这些卷积网络，再配合FPN之类的多尺度结构。在小范围、单景影像、类别相对固定的任务里，这套东西能跑，工程化也成熟。但当输入变成大规模遥感影像时，问题就冒出来了：一景高分辨率影像可能达到几万乘几万像素，目标尺寸却可能只有几十个像素，而且不同地物之间的空间关系需要跨很远距离才能建立联系。卷积网络受感受野限制，很难在同一层里同时看到“小目标”“周边环境”和“全局纹理背景”三层信息。

大模型的好处恰恰在这里。以视觉基础模型常见的自注意力机制为例，它能在一张特征图上建立全局像素关联，哪怕输入图像切成了瓦片，模型也能通过注意力权重把远距离的上下文拉回来。我们这块经常用的一句话是“用上下文换精度”，传统卷积要堆很多层才能把感受野撑大，大模型天生就是全局视野，这对遥感里那种“大场景中的小目标”问题非常关键。另外，随着模型容量变大，训练阶段吸收海量无标注影像的能力也变强了，自监督预训练可以做掩码重建、对比学习这类任务，让模型先把遥感影像的空间结构和光谱规律学会，再在下游任务上做少量标注微调，效果往往比从零训练好很多。

还有一个不可忽视的趋势是数据模态的融合。光学影像、SAR影像、高光谱影像，甚至DEM地形数据，经常要放到同一个任务里做联合解译。以前的做法是分别出特征再拼接，融合得比较浅。大模型时代更流行的做法是把不同模态数据统一编码成序列化特征，放到同一个特征提取骨架里做交互。这种情况下，模型参数动辄几亿到十几亿，算力需求是一道硬门槛，选能扛得住大规模并行训练的AI计算平台，就成为整个项目能不能落地的决定性因素。

1.2 AI加遥感融合的主要业务场景和收益点

遥感大模型并不是一个抽象概念，它最终要落到几个具体的业务方向。我自己接触比较多的是语义分割、目标检测和变化检测。语义分割做地物分类，比如把影像分成建筑、水体、裸土、植被、道路等类别；目标检测侧重定位小目标，比如车辆、船只、油罐等，遥感目标很多是带旋转角度的，普通水平框效果不好，现在不少团队用旋转框检测加注意力特征增强；变化检测则是给两个时相的影像做差，自动识别新建、拆除、灾损等变化区域。

这几个场景里，大模型的直接收益非常明显。拿变化检测举例，以前传统的像素级差值法对光照、季节差异特别敏感，很容易把植被生长也当成变化。换上大模型后，模型能自行学到“哪些变化是地物真实变化，哪些只是成像条件不同”，误检会大幅下降。拿语义分割举例，大模型的边界恢复能力通常好于普通UNet，边缘更规整，后处理矢量化的时候能省很多工作量。

我整理一个表格，把几个常见主任务、输入输出、关键痛点和大模型切入方式列出来，方便你直接参考。

在不同行业里，遥感大模型的应用也会有所侧重。在自然资源调查里，大家更关心地类识别精度和是否够细；在应急减灾场景里，速度比精度更敏感，模型需要在灾后几小时内完成大范围影像推理，这对推理引擎的吞吐量要求很高。所以我一直认为，做遥感大模型不能只盯着训练指标好看，更要看能不能在业务场景里把模型用起来。这也是为什么这次项目里，我特别重视在国产自研AI计算平台上把训练和推理一起串通。

1.3 为什么可以选择国产自研AI计算生态作为底座

可能有人会问，遥感大模型这种大算力任务，用成熟的一些AI计算方案不就够了，为什么还要费劲适配国产自研平台？我原来也有这个疑问，但实际接触后，态度有了一些变化。首先，遥感数据本身有相当一部分涉及地理空间底图、重点区域影像，数据不出域、训练推理环境国产化是很多单位的硬性要求。算力底座如果完全依赖外部环境，数据迁移、合规和数据安全都会变成隐患。其次，这几年国产AI计算生态进步比很多人想象中大，主流深度学习框架的算子覆盖度已经很高，常见视觉模型的迁移成本在可控范围内。

从我实际测试的体感来看，这套平台最明显的优势是大显存和异构并行调度。遥感大模型训练时，显存消耗大头通常不在模型本身，而在激活值和优化器状态。大显存意味着每张加速卡可以塞下更大的batch size和更高分辨率的输入瓦片，分布式训练时的卡间通信次数也能降下来。另外，国产平台对动态图静态图转换做了不少自动优化，训练代码基本可以做到改动很小就能跑起来，同时对推理阶段提供专门的图优化和算子融合，能在不损失精度的前提下把吞吐量提上去。

当然，我也得说实话，国产AI生态不是完全没有学习成本。部分算子和开源社区里最新的网络结构之间存在适配时间差，遇到新出的结构可能需要自己手写自定义算子的情况也是存在的。但从长期看，把遥感大模型这类关键任务跑在可控的算力底座上，本身就是一种工程策略。企业或者单位里如果已经有国产AI加速卡存量，那么它用来跑遥感大模型不仅更可控，还能省下不少硬件采购成本。

2. 环境准备与硬件选型：算力规划和软件栈搭建

2.1 显存估算与硬件选型的实用公式

做遥感大模型，第一件事不是写模型代码，而是算清楚显存和算力。很多新手上来就开大模型训练，结果显存OOM，或者训练速度慢得离谱，最后还把责任推给框架，其实是选型阶段没算明白。

显存占用主要分四块：模型权重、梯度、优化器状态、激活值。前三个和模型参数总量直接相关，也可以用公式粗略估算。假设模型参数量为 P，权重用FP16存，占用 2P 字节；如果用Adam优化器，还得多存一份FP32主权重、一阶动量和二阶动量，这部分大体上是 8P 到 12P 字节；梯度临时占 2P 到 4P。把这些加起来，静态模型部分大概要 12P 到 16P 字节。比如一个约2亿参数的分割模型，静态开销大约在2.4GB到3.2GB，看起来不多，但激活值才是大头。输入是1024乘1024的瓦片，层层特征图叠加，激活显存轻易就能吃掉十几GB甚至几十GB。

所以我给团队的建议是先定一条公式：单卡需要的显存约等于模型静态开销加激活值开销，激活值开销按batch size乘单样本激活占用估算，而这个单样本激活占用最好通过一次小batch的实际测量确定，纸上谈兵容易翻车。选择加速卡时，在预算允许范围内优先挑单卡显存大的，因为遥感大模型对batch size和输入分辨率异常敏感，显存不够时很多优化手段都会变得别扭。

下面是我做模拟项目X时的硬件选型参考表，可以作为一个起点。

我个人的选择是优先保证单卡显存够大，再考虑卡数。因为遥感大模型很多优化技巧，比如大分辨率推理、长序列、多模态融合，都会把显存需求往上推。如果单卡显存太小，分布式方案会变得极度复杂，调试成本成倍增长。

2.2 软件环境配置与容器化部署

硬件到位后，软件环境的准备遵循一个原则：先把干净稳定的深度学习镜像固定下来，再在镜像里装遥感大模型相关的依赖，避免每个人都从零配环境。这个流程我建议用容器实现，好处是环境可复现，换机器也能保持一致性。

实际部署时，我一般分四步走。第一步，在宿主机上安装驱动和固件，确认加速卡能被系统识别，用系统工具能看到设备列表和显存容量。第二步，拉取和硬件厂商匹配的基础镜像，基础镜像里通常已经预装了推理运行时和编译工具链。第三步，在容器里安装深度学习框架版本，这里要注意和驱动版本的兼容关系，不是越新越好，以官方兼容矩阵为准。第四步，验证环境，跑一个简单的矩阵乘或者小网络训练，确认算力正常参与运算。

我贴一段示意性的配置脚本，不一定是完整命令，但逻辑可以参考：

# 启动容器并映射数据目录和模型目录 docker run -it \ --name rscap_model \ --device /dev/davinci0 \ --device /dev/davinci_manager \ -v /data/remote_sensing:/data \ -v /models:/models \ base_image:latest # 在容器内确认加速卡状态 python -c "import platform; print(platform.device_count())" # 设置半精度训练相关环境变量，提升算子执行效率 export ENABLE_FP16=1 export OPTIMIZE_LEVEL=O2

很多同事第一次跑国产平台时，喜欢沿用多年来的环境变量习惯，结果发现一些参数不认，其实是生态差异。建议不要凭感觉配，直接看官方文档里的参数说明，尤其是混合精度、内存池和通信库相关配置，这对性能影响很大。

2.3 推理格式转换与量化精度控制

模型训练好以后，要把权重从训练框架导出到推理引擎，这一步在遥感任务里特别容易踩雷。很多人以为导出就是把权重存下来，实际推理引擎要做图优化、算子融合和量化，每一步都会影响最终精度。

在正式导出前，我习惯先跑一个新的小数据集，对训练好的模型做一次前向推理，把结果存成npz或者npy文件，作为后续对比的基准。然后使用推理引擎提供的转换工具，将训练模型格式转换成更高效的推理格式。转换过程中有几个关键选项必须关注：输入分辨率、batch size是否固定、是否开启动态shape。遥感推理场景中，输入瓦片的尺寸经常变化，所以我通常保留动态shape能力，避免上线后因为尺寸不同而反复导模型。

量化是另一个敏感点。遥感小目标对量化误差的容忍度非常低。我见过一个目标检测模型直接从FP16降到INT8后，小目标召回率下降了接近15个百分点，原因是量化校准集没有覆盖小目标样本。如果要用INT8量化，校准数据的选取必须贴近真实业务分布，包含足够的边缘场景、小目标、低对比度影像，而不是随便挑几张干净影像凑数。更保守的做法是先用FP16部署，在吞吐量确实不够的情况下再上INT8，同时对小目标类别单独做精度验证。

3. 数据处理与自监督预训练：让大模型真正理解遥感影像

3.1 影像瓦片切分与重叠策略

遥感影像和自然图像最不一样的地方，就是输入尺寸太大了。一整景原始影像动辄几万像素，不可能直接塞进模型。瓦片切分就成了绕不开的预处理步骤。切分看起来简单，其实对最终精度影响很大。

比较常用的设置是瓦片大小1024乘1024或者512乘512，同时保留一定的重叠区域，比如64像素或128像素。为什么要重叠？因为模型在推理时，瓦片边缘的上下文信息不完整，预测结果通常会比中心区域差一截。保留重叠区后，推理时把每个瓦片边缘的预测结果丢弃，只保留中心区域，再通过拼接得到完整结果，这样可以有效消除接缝效应。

我踩过的一个坑是切分时没有考虑地面采样距离，也就是每像素对应的实地尺寸。同一张瓦片在不同分辨率下覆盖的真实范围完全不同，如果模型训练时用的是0.5米分辨率的数据，推理时直接喂进去2米分辨率的数据，目标尺度和纹理特征全部错位，效果会断崖式下降。所以在训练和推理的数据预处理环节，必须固定GSD或者做重采样，保证输入数据分布一致。这个细节看起来老生常谈，却是遥感大模型效果翻车的高频原因。

3.2 标注稀缺环境下的自监督预训练

遥感影像标注成本极高，尤其是像素级语义标注，一位熟练的标注人员花一天时间可能只能标出很少的样本量。指望大模型靠人工标注从零开始训练，既不现实也没必要。更理性的做法是先做自监督预训练，用海量无标注影像学通用特征，再用少量人工标注做微调。

我在项目里使用了掩码自编码的思路。简单理解就是，随机遮住输入影像的一部分像素或者Patch，让模型根据剩余部分重建被遮住的内容。这么做的好处是模型被迫学习影像的空间结构和纹理规律，而不是简单记忆类别标签。预训练完成后，再加载到具体分割任务上微调，收敛速度明显加快，而且在小样本类别的表现比从零训练好不少。

还有一个实用技巧是半监督自训练。用预训练模型对未标注影像做预测，筛选出置信度高的区域作为伪标签，再合并进训练集迭代训练。这里要注意的是，伪标签不能盲目全收，置信度阈值设高一点，同时过滤掉类别概率过于平均的样本。半监督做得好不好，很大程度上取决于伪标签的质量控制，我一般会把置信度阈值作为一个重要参数，在验证集上反复调，保证质量而不是凑数量。

3.3 面向遥感特点的数据增强方案

通用图像里的随机裁剪、翻转、色彩抖动在遥感上可以继续用，但识别精度更高的增强方案需要结合遥感数据特点来设计。遥感影像具有明确的方向感，比如房屋和道路的方向分布通常不是完全均匀的，但做任意角度旋转增强是合理的，因为航空影像不固定正北朝上。

多光谱数据增强需要特别小心。可见光波段的数值扰动可以做得激进一点，但对植被指数、水体指数相关的波段做大范围偏移，很容易破坏地物物理意义。我这里会用一种做法：对多光谱影像保留原始数值，只对可见光做色彩抖动，同时对红外波段做少量高斯噪声注入，增强模型的鲁棒性，又不过度扭曲光谱特征。

CutMix、MixUp这类混合增强对遥感任务很有效，尤其是小目标检测和变化检测。CutMix能把不同影像中的目标拼到同一张图里，相当于变相增加了样本数量。不过混标签时要记得按照面积比例做软标签加权，不能两张大图各算各的。对比实验里，加上这类增强后，模型在复杂地物边界上的表现提升明显，而且并没有带来负面作用。

4. 大模型训练与调优的实操记录

4.1 混合精度训练和梯度累积的配合

大模型训练如果要追求速度，混合精度几乎是必选项。具体做法是，前向传播和反向传播用FP16做，但把主权重保存在FP32里，更新权重时用FP32的梯度做累加，防止精度丢失。我在国产AI平台上跑遥感分割模型时，开启混合精度后训练速度大约是纯FP32的1.8倍到2.2倍，效果非常可观。

但混合精度会带来一个训练不稳定问题，特别是梯度值跨越几个数量级时，FP16的表示范围可能不够，出现Loss变成NaN的情况。解决方式通常是动态Loss缩放，自动检测梯度是否溢出并调整缩放因子。绝大多数现代框架都内置了这个机制，关键是别随手关掉，也别把缩放因子固定死。

梯度累积解决的是小显存和稳定性的矛盾。显存不够时，batch size设得很小，导致BatchNorm统计量不准，训练噪声大。梯度累积做法是把多个小batch的梯度累加后再更新一次参数，等效于增大了实际batch size。我建议遥感分割任务里梯度累积步数不要超过8步，否则等效batch过大也会让模型收敛变慢，这个平衡需要自己实验。

4.2 学习率策略和分层调参

遥感大模型的调参，我认为最该重视的是学习率策略。用固定学习率从一个随机初始化的视觉Transformer开始训练，很容易发散或者收敛极慢。我测试下来，一个比较稳的方案是先用5%到10%的步数做线性预热，把学习率从小数值逐渐升到峰值，再用余弦退火降到很低的水平。这种策略的好处是，训练早期参数还没稳定，学习率太大容易冲坏；训练后期希望精细收敛，低学习率能有效调优。

分层学习率也很值得试试。大模型通常包含预训练骨干和任务头两部分，骨干已经学到了很好的通用特征，不需要用太大学习率去扰动；任务头是随机初始化的，需要学的东西多，学习率可以放大。比如预训练骨干的学习率设1e-5，任务头学习率设3e-4，能兼顾全局特征稳定和下游任务适配。

我还想提一个经常被忽略的参数，即权重衰减。视觉Transformer、尤其是ViT系列的权重衰减设置，和CNN不太一样。CNN在卷积核上加大权重衰减问题不大，但ViT如果衰减过大，位置编码和注意力头会被过度压扁，影响模型表征能力。一般建议ViT的权重衰减设成CNN的1/5左右，从0.02降到0.005这种量级，效果会更稳定。

4.3 分布式训练拓扑与通信优化

模型大了以后，单卡跑不动，分布式训练是必然选择。遥感大模型常见的并行方式包括数据并行、模型并行、混合并行。数据并行最直观，每张卡复制一份模型，吃不同batch的数据，每轮梯度做Allreduce；模型并行则是把一个大模型切成几段放在不同卡上，解决单卡放不下整个模型的问题。

在国产AI平台上做分布式训练，我最想提醒的一点是通信占比。模型并行会显著增加卡间通信次数，如果卡间通信带宽不够或者拓扑结构不当，训练速度不升反降。我的经验是，优先做数据并行，只有在模型确实单卡放不下时才引入模型并行。通信库的调优参数也很重要，比如设置合理的梯度分桶大小、开启梯度压缩，都能有效降低通信瓶颈。

这里也把经验整理成一个表，方便对照排查。

实际训练过程中，为了防止训练到一半因为环境问题白跑，我会定期保存全量权重和优化器状态，并设置好检查点保存策略。做遥感大模型，动辄几十个小时训练，一旦中途崩溃又没有可恢复的检查点，代价非常大。我一般每500到1000步保存一次，同时保留最近几个检查点，避免磁盘被写满。

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

5.1 OOM显存溢出：从应急方案到根治思路

显存溢出是用大模型做遥感任务时遇到概率最高的问题。我第一次拿一个约5亿参数的分割模型做训练，用1024分辨率输入，batch size设8，结果一个batch都没跑完就直接OOM。那时候第一反应是缩减batch size，但这只能应急，后面发现激活值占用的显存才是主要矛盾。

更推荐的思路是开启动态图显存复用和内存池优化，把临时释放的显存重新利用，减少碎片化。如果还不行，就开启梯度检查点功能，用少量计算换显存，以一部分运算量来降低激活值存储，通常能省30%以上的显存。我在模拟项目X里，确实通过梯度检查点和混合精度配合，把可用batch size从4提升到了16，预训练收敛快了很多。

还有一种容易忽略的情况是推理阶段OOM。训练时大batch没问题，但推理时如果一次喂进去整张大幅影像，系统一样会扛不住。这时候要做分块推理，控制单次输入数量，同时避免一次性把所有结果都保存在内存里。GPS标注这类中间结果建议直接落盘，别攒着。

5.2 多卡分布式训练Loss不稳定或者掉不下去

分布式训练中，Loss掉不下去往往不是因为模型有问题，而是数据喂重复了。尤其在做自监督预训练时，如果每张卡用的数据没有正确分片，就会出现不同的卡学到完全相同的数据，梯度更新方向不够多样，Loss下降就没动力。正确做法是给每个分布式进程分配互不重叠的数据分片，同时保证每个迭代的数据混洗不同。

另一个常见原因是梯度同步异常。在分布式训练里，每步训练结束后要把各卡梯度做同步，如果某一卡出现异常导致梯度没有回传，其他卡会一直等待，整个训练卡死。我会在日志里同步输出每一步的Loss和梯度统计，方便快速定位是哪张卡出了问题。排查时优先看显存是否溢出、进程是否掉线、通信库是否存在报错。

还有一种情况是BN层在分布式下的同步。大模型常用GroupNorm或者LayerNorm替代BatchNorm来避免这个问题，因为BatchNorm的均值方差统计在分布式里要跨卡同步，计算复杂且容易不收敛。如果模型里还留着BN层，建议把它冻结或者替换成其他归一化方式，遥感大模型用BN确实不太省心。

5.3 推理结果和训练时不一致的三大原因

模型训练完，导出到推理引擎后效果变差，这是不少同事遇到过的现象。最开始他们怀疑是推理引擎的图优化把模型改坏了。实际上，大多数时候问题出在数据预处理不一致。

第一个原因是归一化参数对不上。训练时用的是ImageNet统计量，推理时却用业务数据自己算的均值和方差，输入数据分布完全不匹配，模型给出的结果自然漂移。这个问题最好在代码里用一个统一的预处理模块，训练和推理都调同一个函数，避免写两套逻辑。

第二个原因是输入分辨率不同导致尺度偏差。训练时输入是1024瓦片，推理时为了省时间直接缩小到512，目标像素跨度变小，检测和分割精度都会掉。这时候哪怕用公开的大模型也一样会翻车。更稳妥的方式是保持输入分辨率不变，用分块推理来缓解计算压力。

第三个原因是量化导致的精度损失。FP16精度通常够用，但INT8对小目标和细碎地物比较敏感。我建议做量化前后在固定测试集上对比掩膜IoU或者检测mAP，如果指标下降超过两个点，就得考虑改进校准集或者改回FP16。

5.4 数据管线阻塞导致加速卡利用率低

训练速度慢，很多人第一反应是显存不够，但总有那么几次现象是显存没爆、算力也没吃满，卡却大面积空闲。这种情况八成是数据加载线程跟不上训练速度，也就是所谓的数据管线阻塞。

大模型对于数据的吞吐要求很高，我做过一次统计，在训练时如果采用普通磁盘加载瓦片，GPU等待时间能占到总时间的30%以上，而把瓦片预处理成TFRecord或者内存映射格式后，等待时间能压到5%以内。对于遥感大模型，建议在训练前把所有口数据统一预处理并存储为框架友好的格式，而不是每次实时做复杂解码和增强。数据增强也可以放在CPU线程上异步执行，不让训练进程堵住。

我踩过的一个坑是直接把原始TIFF路径作为训练输入，训练时每个step都做磁盘IO，结果训练速度慢到令人发指。把数据批量转成统一格式后，训练速度提升了将近三倍。对于大规模遥感预训练，这一步几乎是必须做的。

6. 打造一条完整的遥感大模型业务流水线

思路和问题都梳理完后，把这条流水线完整串起来，我认为应该是这样：原始影像入库、纹理与辐射预处理、瓦片切分、模型推理、瓦片结果拼接、矢量化后处理、质量抽检。每一环之间都要留出中间产物，方便追溯和分析错误。

瓦片推理后的拼接很有讲究。由于瓦片边缘存在重叠区域，直接拼接会出现条带和错位，我采用的做法是记录每个瓦片的原点坐标和重叠偏移量，在拼接时生成一个权重矩阵，中心区域权重高、边缘权重低，然后做加权平均。这样做出来的整景分割结果明显更平滑，也减少了很多后处理的噪声。

矢量化是遥感业务里的常规需求，因为很多下游系统只认矢量格式。把像素级的分割结果变成面状矢量，常见做法是先做连通域分析，再提取轮廓，最后做简化。对于大模型分割结果，模型越强，边缘越精细，矢量化出来的多边形越贴近真实地物边界。但要注意，过于复杂的轮廓会让矢量文件体积暴涨，我一般会用道格拉斯-普克算法控制顶点数量。

质量抽检要设计成独立的环节。我会随机抽取若干瓦片，把原始影像、预测掩膜、人工标注三张图叠在一起显示，专门盯着小目标、边界、阴影区域看。很多模型问题不能只看指标，必须用肉眼抽检才能发现系统性错误。比如水体提取时，如果训练数据主要是蓝绿色水体，模型可能对泥沙含量高的河流产生漏检，这种问题要靠在抽检中发现。

最后要提一下可解释性。遥感大模型的输出要真正支撑业务决策，视觉化解释还是很有必要的。我现在会在推理时额外输出注意力热力图或者特征响应图，帮助分析模型在某个区域做出判别的依据。这在大规模业务落地时，非常有利于和业务方以及审核方沟通。

最后再分享两个小技巧

实际做完整条流水线后，我自己感受最深的经验有两条。第一，在开始训练大模型之前，一定先把推理部署的预处理逻辑写透，并跑通一次最小化流程。别等训练完了再回头补推理代码，那时候很多不一致问题都被模型权重掩盖了，排查起来会让人非常崩溃。

第二，遥感大模型想直接上亿级参数之前，先用一个几百万参数的小模型把数据管线、训练步数、分布式配置全部验证一遍。小模型跑通不代表大模型一定能跑通，但它能帮你过滤掉大量环境问题和数据问题，让大模型训练时把有限的调试时间花在真正的模型问题上。

国产自研AI计算生态这几年的进步速度确实让人意外，很多以前被认为很难跑通的模型，现在迁移适配的成本已经低了很多。但算力只是手段，不是终点，真正决定项目上限的，还是我们对遥感任务的理解和对工程细节的掌控。希望这篇文章能帮你在遥感大模型这条路上少踩几个坑，顺利把模型落到业务里。