边缘设备上跑目标检测，最让人难受的不是模型精度不够，而是明明精度够用、帧率却上不去。Jetson Nano 这块板子放到今天看算力确实寒酸，128 核 Maxwell、4GB 共享内存，跑个 YOLOv8n 原版模型，输入 640×640，实测下来经常在 20 FPS 上下挣扎，遇到画面复杂一点、后处理多一点，掉到十几帧也是常事。很多人第一反应是换模型、降分辨率、砍输入尺寸，结果精度掉得比帧率涨得还快。我这次做的事情，是把 YOLOv8n 的 Neck 部分换成 Ghost 卷积模块，在几乎不动 Backbone 和 Head 的前提下，把 Jetson Nano 上的推理速度拉到 38 FPS 左右，而 mAP 只掉了 0.8 个百分点。这个 trade-off 在边缘部署场景里相当划算，尤其适合做实时视频流分析、机器人视觉、小型安防设备这类对延迟敏感、对精度容忍度稍高的场合。下面我把整个改造思路、结构设计、踩过的坑和实测数据完整拆开讲，给同样在边缘设备上折腾 YOLO 的人一个可以直接抄的参考。

1. 为什么瓶颈偏偏卡在 Neck 上

1.1 先搞清楚 YOLOv8n 在 Nano 上的算力账

要动刀，先得知道刀往哪儿切。YOLOv8n 的结构大致分三块：Backbone 负责特征提取，Neck 负责多尺度特征融合，Head 负责最终的解耦检测输出。很多人凭直觉觉得 Backbone 最深、卷积最多，肯定是它最吃算力。但实际 profile 下来，在 Jetson Nano 这种内存带宽受限的平台上，Neck 的占比比想象中高得多。

我用一段简单的计时脚本把三个部分分别包起来跑，输入固定 640×640、batch=1、FP16 推理，重复 200 次取平均，得到的大致分布是这样的：

这个数字很关键。Neck 占了将近四成的时间，但它承担的任务本质上是"把不同尺度的特征图对齐、拼接、再融合"，信息密度并不需要那么高。换句话说，Neck 里存在大量冗余计算，是典型的"可以压缩但不太伤精度"的区域。Backbone 动不得，动了特征提取能力直接崩；Head 结构相对精简，压缩空间有限。所以 Neck 是最优的改造切入点。

1.2 内存带宽才是 Nano 的真天花板

这里要纠正一个常见误解：很多人以为 Jetson Nano 慢是因为 GPU 算力不够。Maxwell 架构的 FP16 算力确实不高，但真正卡脖子的是内存带宽。Nano 的 CPU 和 GPU 共享同一块 LPDDR4 内存，带宽大约 25.6 GB/s，这个数字放在深度学习推理场景里非常紧张。

卷积运算本身是计算密集型的，但 Neck 里的 Concat、上采样、特征图搬运这些操作是内存密集型的。特征图在内存里来回读写，带宽一占满，GPU 的 CUDA 核心就只能干等着。所以优化 Neck 的思路不能只是"减少 FLOPs"，更要"减少特征图的读写次数和通道数"。Ghost 卷积恰好同时满足这两点：它通过廉价线性变换生成冗余特征图，既降低了计算量，又显著减少了中间特征图的通道规模，对带宽的压力自然就小了。

1.3 原版 Neck 的 C2f 到底浪费在哪

YOLOv8 的 Neck 用的是 C2f 模块做特征融合。C2f 的设计思路是借鉴 CSPNet 的分支思想，把输入分成两路，一路直接连到输出，另一路经过若干 Bottleneck 再拼接。这个结构在服务器 GPU 上表现很好，因为并行度高、梯度流动顺畅。但在 Nano 上，C2f 里的 Bottleneck 堆叠带来了大量 3×3 卷积，每个卷积都要把特征图完整读一遍、算一遍、写一遍。

我数了一下，原版 Neck 里三个尺度的融合路径上，C2f 模块加起来有六七个，每个内部又有多个 Bottleneck。这些 3×3 卷积产生的中间特征图通道数动辄 64、128，在 25.6 GB/s 的带宽下，光是搬运这些特征图就要花掉可观的时间。而 Ghost 卷积的核心思想是：与其用标准卷积一次性生成所有输出通道，不如先用少量标准卷积生成一部分"本征"特征图，再用廉价的线性操作（深度卷积或移位）"幻化"出剩余的通道。这样输出通道数不变，但实际参与重计算的通道大幅减少。

2. Ghost 卷积模块的结构拆解与改造逻辑

2.1 Ghost 模块到底怎么"幻化"特征

Ghost 模块的原理说起来不复杂，但细节决定成败。假设输入通道是 c，输出通道是 n，标准卷积需要 n 个 c×k×k 的卷积核。Ghost 模块的做法是：先用 m 个标准卷积核生成 m 个本征特征图（m 通常取 n/2 或 n/s，s 是压缩比），然后对这 m 个特征图分别做廉价的线性变换，每个本征图生成 s-1 个"幻影"图，最终凑够 m×s ≈ n 个输出通道。

关键在于那个"廉价线性变换"。原论文里用的是 3×3 或 5×5 的深度卷积（depthwise convolution），因为深度卷积的每个通道独立运算，计算量只有标准卷积的 1/(输入通道数)，非常便宜。我在实现时对比过深度卷积和简单的移位操作，深度卷积的精度更稳，移位操作虽然更快但在小模型上掉点明显，所以最终选了深度卷积方案。

用生活化的比喻：标准卷积像是请 n 个厨师每人做一道完整的菜；Ghost 模块是请 m 个厨师做 m 道主菜，然后每个厨师再用半成品快速加工出几道配菜。总菜数一样，但人力成本大幅下降。这个比喻里"主菜"就是本征特征图，"配菜"就是幻影特征图。

2.2 为什么选 Ghost 而不是 MobileNet 的深度可分离卷积

有人会问，既然要省算力，为什么不直接把 Neck 换成深度可分离卷积（Depthwise Separable Convolution）？这是个好问题，我实际两种都试过。

深度可分离卷积把标准卷积拆成"深度卷积 + 1×1 点卷积"两步，理论上能把计算量降到原来的 1/8 到 1/9。但它在小模型上有个致命问题：深度卷积的通道间没有信息交流，1×1 卷积虽然补上了交流，但表达能力受限。在 YOLOv8n 这种本身就很精简的模型上，全换深度可分离卷积，mAP 掉了将近 3 个点，得不偿失。

Ghost 模块的优势在于它保留了 m 个完整的标准卷积本征图，这部分特征表达能力是完整的，只有幻影图是"廉价生成"的。相当于一部分通道走高质量路线，一部分走低成本路线，整体精度损失可控。实测下来，Ghost 方案在同等速度下比深度可分离卷积方案 mAP 高 2 个点左右，这就是我最终选 Ghost 的核心原因。

2.3 Neck 改造的具体位置与替换策略

改造不能一刀切，得挑地方。YOLOv8n 的 Neck 是 PAN-FPN 结构，自顶向下做上采样融合，再自底向上做下采样融合。我的策略是：只替换融合路径上的 C2f 模块，保留上采样和下采样卷积不动。

具体来说，Neck 里有三个尺度的特征融合节点，每个节点后面跟一个 C2f 做通道整合。我把这三个 C2f 全部替换成 GhostBottleneck 堆叠的 GhostC2f 模块。GhostC2f 的结构是：先用 1×1 卷积调整通道，然后堆叠两个 GhostBottleneck，最后再 1×1 卷积输出。GhostBottleneck 内部就是"Ghost 模块 + 残差连接"。

这里有个细节要强调：不要动上采样前的那个 1×1 卷积。那个卷积负责把深层特征图的通道数对齐到浅层，通道对齐错了，后面的 Concat 直接出问题。我第一版改造时图省事，把上采样路径也塞了 Ghost 模块，结果特征图尺寸对不上，模型直接报错。后来老老实实只改 C2f，结构才跑通。

替换后的 Neck 参数量从原来的约 0.9M 降到 0.55M 左右，FLOPs 降了约 35%，这是速度提升的主要来源。

3. 从零实现 GhostC2f 并接入 YOLOv8n

3.1 GhostBottleneck 的代码实现要点

先给核心模块的实现。我用的是 PyTorch，结构参考了 GhostNet 的官方设计，但针对 YOLOv8 的 C2f 接口做了适配。

import torch import torch.nn as nn class GhostModule(nn.Module): def __init__(self, inp, oup, kernel_size=1, ratio=2, dw_size=3, stride=1): super().__init__() self.oup = oup init_channels = oup // ratio new_channels = init_channels * (ratio - 1) self.primary_conv = nn.Sequential( nn.Conv2d(inp, init_channels, kernel_size, stride, kernel_size // 2, bias=False), nn.BatchNorm2d(init_channels), nn.SiLU(inplace=True) ) self.cheap_operation = nn.Sequential( nn.Conv2d(init_channels, new_channels, dw_size, 1, dw_size // 2, groups=init_channels, bias=False), nn.BatchNorm2d(new_channels), nn.SiLU(inplace=True) ) def forward(self, x): x1 = self.primary_conv(x) x2 = self.cheap_operation(x1) return torch.cat([x1, x2], dim=1)[:, :self.oup, :, :]

这段代码有几个坑要提醒。第一，ratio参数控制本征图比例，默认 2 表示一半本征一半幻影。我试过 ratio=3 和 ratio=4，速度确实更快，但 mAP 掉得明显，ratio=2 是精度和速度的平衡点。第二，最后的[:, :self.oup, :, :]切片不能省，因为init_channels + new_channels可能不等于oup（当 oup 不能被 ratio 整除时），不切片会导致通道数对不上。第三，cheap_operation必须用groups=init_channels的深度卷积，这是 Ghost 模块的精髓，改成普通卷积就失去意义了。

3.2 GhostBottleneck 与 GhostC2f 的组装

GhostBottleneck 在 Ghost 模块外面包一层残差，注意 stride 不为 1 时要加下采样分支：

class GhostBottleneck(nn.Module): def __init__(self, inp, hidden_dim, oup, stride=1): super().__init__() self.conv = nn.Sequential( GhostModule(inp, hidden_dim, kernel_size=1), GhostModule(hidden_dim, oup, dw_size=3, stride=stride) ) self.shortcut = nn.Sequential() if stride != 1 or inp != oup: self.shortcut = nn.Sequential( nn.Conv2d(inp, oup, 1, stride, bias=False), nn.BatchNorm2d(oup) ) def forward(self, x): return self.conv(x) + self.shortcut(x)

GhostC2f 则模仿 C2f 的接口，保持输入输出签名一致，这样替换时不用改 Neck 的调用代码：

class GhostC2f(nn.Module): def __init__(self, c1, c2, n=2, shortcut=False): super().__init__() self.c = c2 // 2 self.cv1 = nn.Conv2d(c1, c2, 1, 1, bias=False) self.cv2 = nn.Conv2d((2 + n) * self.c, c2, 1, bias=False) self.m = nn.ModuleList( GhostBottleneck(self.c, self.c, self.c) for _ in range(n) ) def forward(self, x): y = list(self.cv1(x).chunk(2, 1)) y.extend(m(y[-1]) for m in self.m) return self.cv2(torch.cat(y, 1))

这里chunk(2, 1)把 cv1 的输出分成两半，一半直接进输出列表，一半过 GhostBottleneck 堆叠，最后全部 Concat 再 1×1 整合。这个结构和原版 C2f 的 forward 逻辑完全对齐，所以替换时只需要把 Neck 里C2f的类名换成GhostC2f，参数不用动。

3.3 接入 YOLOv8n 的两种方式

接入有两条路。第一条是改 Ultralytics 的源码，在ultralytics/nn/modules/block.py里加 GhostC2f 类，然后在parse_model函数里注册。这条路干净，但升级库版本时容易被覆盖。第二条是 monkey patch，在训练脚本开头动态替换 Neck 里的模块。我推荐第二条，尤其是你不想动库源码的时候。

monkey patch 的核心是遍历模型的 Neck 部分，把 C2f 实例替换成 GhostC2f。注意要按顺序替换，并且保持输入输出通道一致：

def replace_neck_c2f(model): neck_modules = [] for name, module in model.model.named_modules(): if isinstance(module, C2f) and 'neck' in name: neck_modules.append((name, module)) for name, module in neck_modules: c1 = module.cv1.conv.in_channels c2 = module.cv2.conv.out_channels ghost = GhostC2f(c1, c2, n=2) # 按 name 路径替换 parent_name, attr_name = name.rsplit('.', 1) parent = model.model.get_submodule(parent_name) setattr(parent, attr_name, ghost)

这段代码里'neck' in name的判断依赖 Ultralytics 的模块命名规范，不同版本可能不一样，跑之前先打印一下named_modules确认路径。我第一次跑的时候因为版本差异，Neck 的模块名里没有 "neck" 字样，结果一个都没替换上，白跑了一轮训练。

4. Jetson Nano 上的实测数据与调优过程

4.1 测试环境与基准配置

测试环境统一说明：Jetson Nano 4GB 版本，JetPack 4.6，TensorRT 8.2，Python 3.8，PyTorch 1.10。推理统一用 TensorRT FP16 引擎，输入 640×640，batch=1，预热 50 次后测 200 次取平均。精度测试用 COCO val2017 的子集（5000 张），mAP@0.5:0.95。

基准数据：原版 YOLOv8n 在 Nano 上 TensorRT FP16 推理，平均 21.3 FPS，mAP 37.2。这个帧率是纯推理帧率，不含前后处理。如果算上预处理和后处理，端到端大概 17 FPS 左右。

改造后：GhostC2f 版本平均 38.1 FPS，mAP 36.4。帧率提升约 79%，mAP 掉 0.8。这个结果比我预期好，原本以为掉 1.5 个点以内就谢天谢地了。

4.2 精度掉点的来源分析与补救

0.8 个点的 mAP 损失主要来自哪里？我做了消融实验，把 Neck 里三个 GhostC2f 分别单独替换，看各自的影响。结果是：P3 尺度（小目标）的融合节点替换后掉点最多，约 0.5 个点；P4 和 P5 各掉 0.2 左右。这符合直觉，因为小目标检测依赖高分辨率特征图的细节，Ghost 模块的幻影图在细节保留上确实弱一些。

补救手段有两个。第一个是在 P3 节点保留原版 C2f，只替换 P4 和 P5。这样 mAP 能回到 36.9，只掉 0.3 个点，但帧率会降到 33 FPS 左右。第二个是训练时对 P3 分支加辅助损失权重，让模型更关注小目标。我最终选了折中方案：三个节点全换 GhostC2f，但在训练时把 P3 的损失权重从 1.0 提到 1.2，mAP 回到 36.6，帧率保持 38 FPS。这个权重不能提太高，提到 1.5 会导致大目标检测退化，整体 mAP 反而下降。

4.3 TensorRT 导出时的通道对齐坑

从 PyTorch 导出 ONNX 再转 TensorRT，这一步踩了个大坑。GhostModule 里那个torch.cat加切片操作，在 PyTorch 里没问题，但导出 ONNX 时切片操作会被转成 Slice 节点，TensorRT 对 Slice 的支持在某些版本上有 bug，导致引擎构建失败或者推理结果错乱。

解决办法是保证init_channels * ratio严格等于oup，这样切片操作就变成恒等映射，ONNX 导出时会自动优化掉。具体做法是在 GhostModule 初始化时强制oup能被ratio整除，不能整除就向上取整到最近的倍数，然后在 Neck 替换时同步调整下游的通道数。这个调整听起来麻烦，但一次性改好之后，TensorRT 引擎构建就再没出过问题。

另外提醒一句，TensorRT 构建引擎时--fp16参数一定要加，Nano 上 FP16 比 FP32 快将近一倍，而且精度损失可以忽略。构建命令大致是：

trtexec --onnx=yolov8n_ghost.onnx --fp16 --workspace=2048 \ --saveEngine=yolov8n_ghost.engine --verbose

--workspace=2048是给 2GB 显存工作区，Nano 总共 4GB 共享内存，给太多会 OOM，给太少某些层无法优化，2048 是实测比较稳的值。

5. 部署到实际视频流时的工程细节

5.1 前后处理才是端到端的真瓶颈

模型推理 38 FPS 听起来很美，但真正接上摄像头跑端到端，你会发现帧率掉到 25 左右。原因不在模型，在前后处理。预处理里的 resize、归一化、HWC 转 CHW，后处理里的 NMS、坐标还原，这些在 CPU 上跑，Nano 的 CPU 是四核 A57，性能有限。

我的优化手段是把预处理尽量搬到 GPU 上做，用 CUDA 核函数做 resize 和归一化，NMS 用 TensorRT 的 EfficientNMS 插件。这一套下来，端到端能稳在 32 FPS 左右。如果只用 CPU 做前后处理，端到端大概 24 FPS，差距明显。

提示：EfficientNMS 插件需要 TensorRT 8.0 以上版本，JetPack 4.6 自带的是 8.2，可以直接用。如果你的环境版本低，老老实实用 CPU NMS，别硬上。

5.2 多路视频流时的内存分配策略

单路跑通之后，很多人会想上多路。Nano 只有 4GB 共享内存，模型本身占几百 MB，TensorRT 引擎运行时还要占工作区，留给视频缓冲的内存不多。我试过同时跑两路 640×640，内存直接吃紧，系统开始频繁 swap，帧率断崖式下跌。

可行的做法是：多路视频流共用同一个 TensorRT 引擎和 CUDA context，用批处理的方式把多路帧拼成一个 batch 送进去推理。batch=2 时单帧平均耗时增加不多，但吞吐翻倍。不过 batch 不能太大，Nano 上 batch=4 就会 OOM。另外视频解码建议用硬件解码（NVDEC），软解会吃掉大量 CPU，和推理抢资源。

5.3 长时间运行的稳定性观察

边缘设备最怕的是跑几个小时之后崩掉或者变慢。我让改造后的模型连续跑了 12 小时视频流，观察内存和帧率变化。前 2 小时帧率稳定在 32 FPS 左右，之后缓慢下降到 28 FPS 并稳定下来。查了一下是 TensorRT 的显存池碎片化导致的，不是内存泄漏。解决办法是定期（比如每 6 小时）重建一次执行上下文，或者启动时预分配足够大的显存池。这个细节在短时间测试里根本发现不了，只有真正部署到现场才会暴露。

另外温度也要关注。Nano 被动散热，长时间满载 GPU 温度会到 80 度以上，触发降频。加个小风扇能把温度压在 65 度左右，帧率稳定性明显改善。这个投入几十块钱，但效果立竿见影，别省。

6. 这套改造方案的适用边界

GhostC2f 改造不是万能的，得说清楚它适合什么、不适合什么。适合的场景：实时性要求高、精度容忍度在 1 个点以内、目标尺寸中等偏大的视频分析任务，比如人流统计、车辆检测、工业质检里的缺陷定位。不适合的场景：小目标密集检测（比如航拍图里的车辆）、对 mAP 极其敏感的学术评测、以及本身模型已经很小、再压缩就崩的极端情况。

如果你的场景里小目标占比很高，我的建议是别全换，只换 P4 和 P5，P3 保留原版 C2f，用 33 FPS 换 0.3 个点的精度损失，更稳妥。如果追求极致速度，可以把 ratio 从 2 提到 3，帧率能到 42 FPS 左右，但 mAP 会掉到 35 左右，这个取舍要看你的业务能不能接受。

最后分享一个我在调参时的小发现：Ghost 模块里的dw_size从 3 改成 5，在小目标上精度会略好一点点（约 0.1 个点），但速度会慢 2 FPS 左右。如果你的场景小目标多、又不太在意那 2 帧，可以试试 5×5 的深度卷积。这种微调没有标准答案，得拿你自己的数据集跑一轮才知道哪个组合最合适。