Swin Transformer 这个项目我翻来覆去看了不少遍。从 2021 年 3 月微软放出源码到现在它已经成了视觉 Transformer 家族里绕不开的一个参照系。标题里写着工程治理全景审计这其实是我自己习惯的一套评测框架——不只看模型精度有多高、论文写得有多漂亮而是把一个开源项目当成一个软件工程产物来检查代码结构是否清晰、配置系统是否完整、测试覆盖是否可靠、依赖管理是否健壮、社区维护是否可持续。这篇文章不会去复述论文里的公式推导那些官方文档和解读文章已经够多了。我更想聊的是如果你现在准备在生产环境里用它做图像分类、目标检测或者语义分割这套源码到底能不能撑得住以及你在集成、训练、部署时会踩到哪些真实的坑。这个评测面向的人群很明确正在做视觉模型选型的技术负责人要把 Swin Transformer 集成进现有训练框架的算法工程师以及刚入门 ViT 系模型、想找一个足够典型的源码来精读的研究生。我会把源码层面的关键实现细节拆开讲再从工程治理维度逐项打分最后给出一份偏向实操的落地选型建议。1. 项目概览与源码仓库全景先看整体。microsoft/Swin-Transformer这个仓库官方定位是图像分类的主代码库同时因为 Swin 本身设计成层级金字塔结构下游检测、分割任务都把它当作 backbone 来用。仓库里主要的入口是main.py通过--cfg指向 YAML 配置文件来启动训练或验证这跟 mmclassification 那套设计思路很接近。1.1 仓库目录与模块划分拿到源码之后我习惯先把目录结构过一遍心里有个地图再往下钻。Swin-Transformer/ ├── main.py # 训练/验证入口负责参数解析、dataloader、训练循环 ├── configs/ # 所有实验配置按模型规格和数据集组织 │ ├── swin_tiny_patch4_window7_224.yaml │ ├── swin_base_patch4_window12_384.yaml │ └── ... ├── models/ │ ├── build.py # 模型注册与构建工厂 │ ├── swin_transformer.py # Swin Transformer 核心实现 │ ├── swin_mlp.py # 后续加入的纯 MLP 版本 │ └── ... ├── data/ │ ├── build.py # 数据加载与增强 │ ├── datasets.py # 数据集封装 │ ├── sampler.py # 分布式采样器 │ └── ... ├── utils.py # 日志、检查点、指标统计等工具 ├── logger.py # 日志封装 ├── optimizer.py # AdamW、参数分组策略 ├── lr_scheduler.py # 学习率调度 └── run.sh # 单机/多机训练脚本示例这个结构放在 2021 年算是研(d)究(y)向代码的标准模板跟 timm、 DeiT 的仓库风格一脉相承。模型定义集中在swin_transformer.py一个文件里全部核心逻辑大约 500 行没有拆成多个 package。好处是读起来连贯坏处是如果想单独复用某个组件比如只拿PatchMerging你得手动做剪裁。契约绑定层models/build.py做了一个比较有意思的设计使用BACKBONES.register()装饰器来做模型注册并且它声明了__all__导出允许timm直接调用。这意味着你在 timm 里看到的timm.models.swin_transformer其实就是从这套源码里移植或者同步过来的。1.2 版本演进与维护状态我对照过 GitHub 的提交记录和 releases 时间线。2021 年 3 月首次发布时只有 Swin-T/S/B/L 四个规格和 image classification 相关代码2021 年下半年到 2022 年陆续补齐了 Swin V2 的代码swin_transformer_v2.py、MLP 版本、以及 ImageNet-22K 预训练配置。到 2023 年之后官方仓库的更新频率明显下降大部分新工作转向了更通用的基础模型方向。这个维护节奏其实很典型论文红利期仓库更新活跃随着研究方向转移逐渐进入稳定维护或者说低维护阶段。如果你要做二次开发得接受这个现实——Issues 里一些老问题可能长时间没人回合并 PR 的速度也会慢下来。但反过来说一个稳定不怎么变的项目恰恰适合做生产依赖不会三天两头 breaking change。1.3 许可证与依赖约束仓库采用的是 MIT 协议商用基本没有法律障碍。依赖方面比较克制核心只需要torch、torchvision、timm、pyyaml、tensorboard没有引入重量级第三方库。timm其实不是硬依赖它只在数据增强里用到了一部分像rand_augment_transform这样的工具函数但官方 README 依然要求你装因为保不准哪个增强函数内部就 import 了 timm。依赖精简在这里很加分。很多研究仓库动不动就锁一堆版本Swin 官方仓库却连requirements.txt都没有显式锁定版本上限只要求pytorch1.4.0和timm0.4.12之类的下限约束。实际我在不同 CUDA 版本的机器上跑都没遇到依赖地狱只要 torch 版本别太老就行。2. 核心源码拆解五个关键机制源码评测里最花时间的就是把核心模块逐行读明白。Swin Transformer 能在视觉领域站稳脚跟主要靠四个设计层级式下采样、窗口自注意力、相对位置偏置、移位窗口交叉通信。下面我把实现细节一条条拆开。2.1 Patch Embedding 与 Patch Merging 的设计Patch Embedding 在实现上就是一层卷积。Swin 选择用kernel_sizepatch_size、stridepatch_size的二维卷积来做非重叠 patch 嵌入。以patch_size4为例224x224 的输入图变成 56x56 个 patch每个 patch 的维度是embed_dim。代码里PatchEmbed除了做卷积还顺带计算了窗口数量num_windows这为后面 Mask 计算和窗口切分提供便利。PatchMerging是 Swin 金字塔结构的关键。它做的事跟 CNN 里的 pooling 类似但更接近 pixel shuffle 的逆操作把 2x2 邻域的 patch 在通道维拼接起来再过一层线性层把通道压缩回去。源码中是这样实现的x x.view(B, H, W, C) x x.reshape(B, H // 2, 2, W // 2, 2, C).permute(0, 1, 3, 4, 2, 5).flatten(4) x self.norm(x) x x.view(B, H * W // 4, 4 * C) x self.reduction(x) # 线性层4*C → 2*C这段操作的意图是把空间分辨率砍半、通道数翻倍形成类似 FPN 的多尺度特征。在检测/分割任务里backbone 输出的四个阶段特征图正好可以直接接到 FPN 或者 UperNet 上这也是 Swin 相比 ViT 最大的工程红利——ViT 只有单尺度输出做 dense prediction 还得额外塞一个 decoder。2.2 window_size 与全局自注意力的复杂度差异Swin 之所以不用全局自注意力根本原因在于计算复杂度随分辨率平方增长。全局注意力里每个 token 都要跟所有 token 做交互复杂度是 O(h²w²)而窗口注意力把特征图切成不重叠的 M×M 小窗口只允许窗口内交互复杂度降为 O(M²hw)。用一个具体数字说明。输入 224x224patch size4得到 56x56 个 token即 hw56。全局注意力需要构建 3136×3136 的注意力矩阵约 983 万个元素窗口大小 M7 时848 个窗口内各自构建 49×49 矩阵总共约 203 万个元素。前者是后者的 4.8 倍左右。如果分辨率升到 384x384Token 变成 9216 个全局复杂度约 8493 万窗口注意力约 663 万差距拉到 12.8 倍。分辨率越高窗口注意力的优势越明显这也是 Swin 能在高分辨率输入下保持可用性的根本原因。再看源码里的具体矩阵变换逻辑。窗口切分不是简单的 view需要把(B, H, W, C)变成(B*num_windows, window_size, window_size, C)再展平成注意力能吃的形状。代码实现了window_partition和window_reverse两个函数用reshape permute transpose来回折腾维度。调试这类代码最容易犯的错是维度顺序搞反建议读者在理解permute时直接写实验脚本打印 shape别靠脑子硬想。2.3 相对位置偏置的索引机制这是 Swin 源码里最容易劝退新手的一段看懂之后你会觉得设计得很巧妙。窗口大小为 M7每个窗口内 token 数 N49理论上两两之间的相对位置组合有 (2M−1)×(2M−1) 种也就是 13×13169 种。相对位置偏置表relative_position_bias_table的形状就是(169, num_heads)它不是直接存 49×49 的偏置矩阵而是先算好每个 token 对的相对位置索引再去表里查 bias最后 reshape 成(num_heads, N, N)加到注意力得分上。索引计算的经典代码如下coords_h torch.arange(window_size[0]) coords_w torch.arange(window_size[1]) coords torch.stack(torch.meshgrid([coords_h, coords_w])) # 2, M, M coords_flatten torch.flatten(coords, 1) # 2, M*M relative_coords coords_flatten[:, :, None] - coords_flatten[:, None, :] # 2, M*M, M*M relative_coords relative_coords.permute(1, 2, 0).contiguous() relative_coords[:, :, 0] window_size[0] - 1 relative_coords[:, :, 1] window_size[1] - 1 relative_coords[:, :, 0] * 2 * window_size[1] - 1 relative_position_index relative_coords.sum(-1) # M*M, M*M为什么coords_h方向要乘以2*M-1因为要让二维相对坐标映射成一维索引时没有冲突。如果不做这个线性化二维坐标 (1,1) 和 (0,5) 直接求和会得到相同结果导致索引碰撞。乘完之后(rowoffset) 的取值 0~12乘 13 再加列偏移正好一一映射到 0~168 的表索引。这段代码我看过好几遍逻辑很紧凑自己写的时候几乎一定会出 bug官方实现可以直接抄。2.4 移位窗口与注意力掩码移位窗口Shifted Window是 Swin 的灵魂。相邻两层的窗口位置一个规则、一个偏移 (⌊M/2⌋, ⌊M/2⌋)这样既保持窗口内部计算的高效又让不同窗口之间有机会交换信息形成全局感受野。实现上移位不是真的用循环把窗口重新切一遍而是用torch.roll把特征图整体循环滚动再按原来的窗口切分方式操作。torch.roll的妙处在于它让窗口边界错位原本属于不同窗口的区域被拼到了同一个窗口里但这些区域实际上可能并不相邻所以直接做注意力会引入错误的语义关联。为了解决这个问题源码里构造了一个attn_mask。它先用torch.zeros初始化一个形状为(num_windows, N, N)的张量然后按移位后窗口的四个象限逐块填充-100。注意力分数加上这个 mask 后不相邻区域的 softmax 概率会趋近于零等效于强制让模型只关注真正空间相邻的 token。这里有个精度细节值得注意源码选的是-100而不是-1e9或者float(-inf)。float 的 -inf 在混合精度训练下容易出现 NaN-100 在 softmax 里已经足够小又不会触发数值异常是工程上很稳妥的选择。2.5 Stage 堆叠与模型规格对应关系Swin Transformer 按四个 Stage 堆叠不同规格模型的 layer 深度和 head 数不同。默认配置表格如下模型规格embed_dim各 Stage 深度多头数量参数量ImageNet-1K 精度官方报告Swin-T96[2, 2, 6, 2][3, 6, 12, 24]28M81.3%Swin-S96[2, 2, 18, 2][3, 6, 12, 24]50M83.0%Swin-B128[2, 2, 18, 2][4, 8, 16, 32]88M83.5%Swin-L192[2, 2, 18, 2][6, 12, 24, 48]197M86.3%ImageNet-22K 微调Stage 之间的下采样由PatchMerging完成所以源码里basic_layers列表第一项是nn.Linear的PatchMerging后面才跟BasicLayer。构建模型时的num_layers列表指的就是每个 Stage 里SwinTransformerBlock的个数。读配置的时候要额外注意window_size7是一个相对小的窗口它在 ImageNet 上的表现为最优如果换数据集窗口大小需要重新调不是所有场景都适合 7。3. 工程治理全景审计从代码质量到社区运维源码读完后我会把它当作一个长期维护的框架来审计。下面是逐项结论。3.1 代码结构与可维护性swin_transformer.py把 componentPatchEmbed、PatchMerging、WindowAttention、SwinTransformerBlock、BasicLayer、模型主体和注册逻辑全部放在一个文件里。对于一个核心模型文件来说这样安排有优点也有缺点。优点在于你只需要打开一个文件就能读完整个模型的前向流程非常适合学习和二次开发。缺点也很明显SwinTransformerBlock里同时包含规则窗口和移位窗口两条分支前向函数里if分支和attention_mask判断混在一起阅读时需要盯住条件分支才能理清。我在给团队做 code review 时提过建议可以把规则窗口块和移位窗口块拆成两个子类共享WindowAttention这样分支逻辑会更集中于构造函数而不是散落前向各处。总体打分6.5/10优于平均研究代码但离生产级还有距离。如果你打算照着它二开最好内部再包一层自己的模型类别直接把官方类塞给业务方。3.2 配置系统与超参数管理这一点是这个仓库做得最像工程的地方。所有实验超参都由 YAML 管理从数据集路径、优化器类型、学习率、weight decay、warmup epochs到数据增强开关、EMA、mixup、cutmix全部能在一个文件里改完。启动命令只传--cfg和少数覆盖项避免了命令行参数一长串的混乱。配置文件的可读性也高。比如swin_tiny_patch4_window7_224.yaml里清楚地分成MODEL、DATA、TRAIN、AUG几个区块DATA区块里还包含IMG_SIZE、CROP_PCT、INTERPOLATION这些细节几乎可以直接作为实验记录。对一个以研究为主要目标的仓库来说能做到这一步已经超出平均水平。不过有两点不足。一是配置里不少值没有做合法性校验比如手滑把window_size填成偶数代码不会报错但会跑出奇怪的维度错误排查成本高。二是没有官方提供的配置配准工具换 GPU 个数后 batch size 变化学习率要不要线性缩放完全靠经验官方 README 没有给出明确建议。3.3 测试覆盖与持续集成这是整个仓库最薄弱的一环。我仔细翻过官方仓库里几乎没有像样的单元测试只有一个简单的run.sh和训练入口没有 CI 流程没有测试用例覆盖 forward shape、反向传播、mask 逻辑和模型导出。这导致一个问题社区提 PR 时只要作者说我测试过没问题就算数没有自动化保障。这在实际落地时是隐患。比如你改了某个组件想确保不破坏其他模块只能靠跑一轮训练来验证而小数据集一轮训练至少几十分钟效率很低。我在团队里通常建议参照这份源码自己补 smoke test比如用固定随机种子构造 4x224x224 的输入跑一次 forward、backward、梯度裁剪全流程并断言中间张量 shape 正确。这类测试在 CI 里只需几十秒却能把回归风险压到最低。3.4 文档质量与示例完整性README 覆盖了模型结构说明、各规格预训练权重列表、不同资源下的训练命令示例、下游任务链接检测用 Swin-Transformer-Object-Detection分割用 Swin-Transformer-Semantic-Segmentation以及常见问题。文档里还提供了 ImageNet-1K/22K 的精度速查表这个信息在选型阶段非常关键。但文档里有两个比较明显的缺失。一是没有针对从零开始训练 Swin 的资源建议很多人在单卡 V100 上想训 Swin-B跑着跑着显存就爆了官方文档没有给出分规格的显存/时间预期二是没有说明预训练权重在不同输入分辨率下的适配方法实际用 384x384 输入去加载 224x224 预训练权重时position bias 和 window size 的处理需要额外插值官方没有给出现成代码。3.5 依赖兼容性、社区活性与长期风险依赖方面前面说过比较克制。但我在新环境安装时遇到过一个坑timm版本更新后一些数据增强函数的接口变了导致旧版 Swin 仓库抛错。解决方法是把timm固定在 0.4.x 到 0.6.x 之间别升级到新版。整体兼容性给 7/10。社区活性这块得说实话。截至我写这篇评测的时间官方主仓库的最近一次实质性代码更新已经过去很久Issues 里大量问题停留在等待回复状态。但别急着放弃这个项目——真正让它活下去的是生态timm 和官方检测/分割仓库都长期维护着 Swin 的实现很多新模型ConvNeXt、Focal Transformer 等的开源实现也明里暗里借鉴了这套代码结构。选型时真正要评估的不是官方仓库还动不动而是整个生态是否还在被使用。3.6 工程治理审计总评分审计维度评分说明代码可读性6.5/10单文件可读分支逻辑有提升空间配置管理8/10YAML 统一管理覆盖度高但缺校验测试与 CI2/10几乎无测试无 CI文档7/10README 完整但缺资源预估和迁移说明依赖与兼容7/10依赖精简但 timm 版本有隐雷社区活性4/10官方更新慢生态依靠 timm/下游仓库维持项目综合定位是高质量研究代码 中等工程成熟度。它适合作学习范式和选型基准原样上生产需要自己做补丁。4. 落地选型指南何时该选 Swin以及怎么用好它从工程视角聊完代码再回到最实际的问题——项目到底选不选它。我的结论是Swin Transformer 在今天尤其是 2024 年之后已经不是一个默认首选的模型但它依然是多个典型场景里的稳妥答案。4.1 适合选择 Swin 的典型场景第一类是密集预测任务团队。如果你做的是目标检测、实例分割、语义分割这类需要多尺度特征的任务Swin-T 或 Swin-S 作为 backbone 替换 ResNet-50通常能在几乎不增加太多部署成本的情况下带来稳定涨点尤其在 COCO、ADE20K 这类中大型数据集上。这是 Swin 设计之初就瞄准的优势。第二类是处理高分辨率输入的业务。比如遥感图像、医学影像、文档扫描件输入常常是 1024x1024 甚至更高全局注意力的 ViT 在这种输入下要么爆显存要么慢得没法用Swin 的窗口注意力机制让计算量跟分辨率线性增长配合合适的窗口尺寸可以稳定跑起来。第三类是团队对 Vision Transformer 有研究倾向但还没有足够的分布式训练基础设施去挑战全局注意力的大模型。Swin-T 只有 28M 参数在单卡 24G 显存上就能训 224x224 的输入batch size 32 左右对实验环境要求友好。4.2 不建议选择 Swin 的场景如果业务是移动端或边缘端实时推理Swin 因为窗口切分的 reshape/permute 操作和相对位置偏置表的存在转 ONNX/TensorRT 时算子支持不一定顺畅NCNN 这类轻量框架对它的支持更是薄弱推理效率大概率不如同参数量的 CNN比如 MobileNet 或 ConvNeXt 的轻量版本。这些场景选 Swin 属于给自己找麻烦。如果任务是纯分类且数据集规模不大比如几万张图以内的内部数据CNN 依然是更稳妥的选择。Swin 的涨点主要体现在大数据集和大模型规模下小数据场景里它的归纳偏置不如 CNN 强训练技巧增强、正则化的敏感度也更高。还有一种情况要警惕如果你需要在生产环境里长期维护某个模型的推理链路那么一个处于低维护状态、官方 release 不再频繁更新的模型风险是存在的。这时更推荐采用 timm 中经过持续完善、社区测试覆盖更广的实现或者考虑直接采用生态更活跃的 ConvNeXt 系列它们在精度和推理速度上都与 Swin 相当工程支持却好很多。4.3 训练与微调落地的关键参数假设你已经决定了要用 Swin下面是落地时务必盯住的几个参数位置。预训练权重的选择Swin 官方仓库给出了 ImageNet-1K 和 ImageNet-22K 两套预训练权重。官网报告里先用 22K 预训练再在 1K 微调的模型精度明显更高但权重文件也更大加载后需要对应修改最后的分类头。如果你不是做 ImageNet 分类而是做下游任务微调强烈建议选 22K 版本同等训练步数下效果通常比 1K 版本好一截。学习率与 batch size 的配比官方默认配置是 batch size 1024、学习率 1e-3Swin-T这个组合下 AdamW 的默认 weight decay 为 0.05。如果你在自己数据上只有 8 卡甚至单卡batch size 缩到 256 或 128学习率不能直接用 1e-3。我实测下来的经验是batch size 从 1024 降到 256学习率按线性缩放粗略估算应该是 2.5e-4 左右再用 5 个 epoch 的 warmup 会稳很多。很多人把官方配置抄过来直接训结果 loss 一开始就不降90% 是学习率太大。输入分辨率与窗口大小的适配Swin 在训练时会根据IMG_SIZE计算特征图高宽然后和window_size做整除。如果选 384x384 输入patch size4特征图是 96x96可被 7 整除但如果有业务输入是 500x500patch 后是 125x125不能被 7 整除就需要把输入 resize 到 504x504即 126x126 可整除或者改 window_size。这个适配逻辑官方没有自动化处理必须自己提前在数据 pipeline 里做好。训练时的数据增强Swin 对增强策略的依赖比 CNN 更强。官方在 ImageNet 上用了 RandomResizedCrop、RandAugment、Mixup、CutMix、Random Erasing 一套组合拳。如果你微调时把这些增强全关掉精度会掉不少。我建议保留 RandAugment 和 Mixup这两个对 Swin 的涨点贡献最大CutMix 可以在小数据集下关闭因为它对标注噪声敏感。4.4 和近期同类模型对比以后怎么选从选型表格角度看Swin 在今天的位置比较微妙。拿 ConvNeXt 做参照ConvNeXt 在 ImageNet 上的 top-1 精度和 Swin 基本持平但推理时不需要窗口切分算子部署兼容性明显更好。Focal Transformer 等变体理论上精度更高但缺少像 Swin 一样的生态支持和预训练权重落地风险更大。我的总体建议是三层判断架构第一层明确任务类型。分类场景优先考虑 ConvNeXt 或者直接 CNN检测、分割、高分辨率业务才对 Swin 有刚需。第二层评估团队算力。单卡 24G 以下Swin-T/S 合适多卡 40G 以上可以尝试 Swin-B/L但要把显存和训练时长放进项目排期Swin-L 在单卡上训练基本不现实。第三层看下游工具的兼容情况。如果你的部署平台TensorRT、ONNX Runtime、Triton对窗口注意力的算子支持成熟Swin 可以放心选如果工具链比较旧需要提前做算子替换或使用 CNN 替代方案。4.5 推理部署与性能优化路径Swin 部署时最大的争议点在于窗口切分操作在推理框架里的表现。实际我在 ONNX Runtime 上测过 Swin-T4x224x224 输入的情况下window_partition/window_reverse涉及的大量 reshape 和 transpose 会生成很多多余算子导致推理延迟比同精度 CNN 高 30%~50%。TensorRT 虽然能合并一部分算子但遇到动态 shape 时依然会退化成多个小算子。应对方案有三个。第一是尽量固定输入分辨率避免动态 shape让推理框架可以做更多的图优化。第二是在导出 ONNX 前把 relative position bias 预先烙进一个常量张量不要让它参与动态计算。第三是做算子融合把window_partition、attention、window_reverse写成一个自定义 TRT plugin这一步收益最大但工程量也最大适合对延迟有硬性要求的场景。如果精度可以接受也可以考虑直接使用 timm 里的 Swin 实现来导出因为它内部对 JIT 和 ONNX 兼容性做了更多打磨导出过程中的报错少很多。5. 常见问题与避坑速查表下面这份速查表是我在多个项目里实际遇到并排查过的典型问题每一条后面都有对应的解决方向。问题现象根本原因解决方案加载官方权重后微调 loss 不降学习率太大或 warmup 不够按 batch size 线性缩放加 5~10 个 epoch warmup输入分辨率 500x500 报 shape 错误特征图无法被 window_size 整除resize 到 504 或调整 window_size使用 384 输入加载 224 预训练权重报错相对位置偏置表 shape 不匹配对 bias table 做双线性插值或用 timm 的resize_pos_embedONNX 导出时算子不支持window_partition 动态 shape 翻译失败固定输入 shape使用 opset14避免动态轴AMP 训练出现 NaN注意力加 mask 后 softmax 数值不稳定使用官方 -100 而非 -inf检查 relative bias 的 dtype单卡训练 Swin-B 显存不足模型较大、中间激活多开启torch.utils.checkpoint主要在深 Stage 开启timm 升级后增强函数报错接口变更锁定 timm 版本0.4.x~0.6.xCarbon 数据增强和 EMA 效果不明显默认配置依赖大数据集小数据集下关闭 CutMix保留 Mixup 和 RandAugment想用 Focal Transformer 替代 Swin精度有提升但生态不成熟建议用 Swin 换更好的训练策略比换模型更划算在所有这些坑里最让我印象深刻的是 ONNX 导出的问题。当时我们做智能质检项目输入图已经从 512 改到 640导出 ONNX 时窗口切分的动态 shape 一直过不了 TRT 的优化管线排查了整整一天才发现是把window_size硬编码在常量里之后才能稳住性能。这类经验说明Swin 的部署问题往往不是模型本身而是它留下的算子级约束。写在最后我自己在检测和分割项目里用过不少次 Swin-T 替换 ResNet-50精度的提升是实打实的但换来的是训练流程复杂度和部署链路的额外功夫。如果你问我个人最终的结论我会说Swin Transformer 值得学、值得用但它绝不是无脑选择的模型。它的源码是一个极好的学习样本——从层级结构设计、窗口注意力的实现到相对位置偏置的索引计算每一处都体现了对视觉任务特性的深刻理解读通它你对整个 ViT 家族的理解都会上一个台阶。而落地选型这件事永远不是看模型榜单上的一个数字而是看你的任务、算力、部署限制三者之间的交点在哪里。选 Swin 还是选别的答案通常已经藏在你的业务约束里了。