最近在往家里的 Ubuntu 服务器上传 Stable Diffusion 模型，
模型不多，但体积很大——加起来 36 多 GB。
服务器在家里，本机在家里，
同一个 Wi-Fi、同一个路由器、局域网传输。
我一开始想的是：
这不就是 scp 一行命令的事吗？
结果狠狠踩了一坑。
事情的开始：scp 一开始很快
我在 Mac 上执行：
scp *.safetensors gyq@192.168.31.82:/usr/local/deploy/stable-diffusion-webui/models/Stable-diffusion/
刚开始非常正常：
- 速度 17～18 MB/s
- 心里想：稳了，十几分钟搞定
但问题来了。
奇怪的现象：速度突然掉到 200KB/s
传着传着，速度开始明显下降：
- 17 MB/s
- 5 MB/s
- 1 MB/s
- 最后稳定在 200～300 KB/s
而且不是一会儿，是 一直慢。
更离谱的是：
- Wi-Fi 信号满格
- 同时刷网页、看视频都没问题
- 服务器和 Mac 都在家里
这就很反直觉了：
为什么“同一个 Wi-Fi”的 scp，会越传越慢？
scp 其实没错，错的是使用场景
后来排查下来，结论其实很简单。
1. scp 是“一条路一直猛冲”的那种工具
scp 的特点是：
- 单连接
- 持续推大数据
- 几乎不考虑“慢一点稳不稳”
这在 有线网络 / 机房 里没问题，
但在 家用 Wi-Fi 下，很容易出事。
2. Wi-Fi 本身不适合这种“长时间猛传”
Wi-Fi 有几个特点，平时我们感觉不到：
- 不是全双工（不能同时高速收发）
- 对延迟和抖动很敏感
- 家用路由器的缓冲区很小
scp 一口气把数据往里塞：
- 路由器先“憋着不丢”
- 延迟越来越高
- 传输工具以为“网络不行了”
- 于是主动降速
最后就卡在一个：
“不至于断，但慢到怀疑人生”的速度
3. 为什么一开始快，后面慢？
因为：
- 一开始网络是“干净的”
- 路由器缓存是空的
- 速度被瞬间拉满
跑一段时间后：
- 队列满了
- 延迟上来了
- 速度被压到极低
这也是为什么你会看到：
“开头很爽，后面像被限速”
换思路：不要“推”，让服务器来“拉”
既然 scp 这种“硬推”方式不适合，
那我就换了一个思路：
不从 Mac 推到服务器，而是让服务器自己来下载
我的解决方案：HTTP 本地服务器 + wget
1. Mac 上开一个临时 HTTP 服务
模型已经在 Mac 上了，于是我直接：
cd /Users/guoyunquan/Downloads
python3 -m http.server 8000
这一行做了什么？
- 把当前目录临时变成一个下载站
- 局域网内任何机器都能访问
2. 服务器用 wget 下载
在服务器上执行：
wget -c http://192.168.31.53:8000/sd-models.tar.zst
这一步的体验是：
- 速度稳定
- 没有突然掉到几百 KB
- 中断了还能继续
为什么 HTTP 反而更稳？
原因很简单：
- HTTP 下载是 服务器主动拉
- wget 对网络抖动更友好
- 路由器对 HTTP 流量“更熟悉”
- 即使慢，也不会“自废武功”
这也是为什么：
- NAS
- 局域网镜像
- 内部文件分发
很多都用 HTTP / SMB，而不是 scp。
最后的总结
这次踩坑给我一个很清晰的结论：
- scp 不是万能工具
- “同一个 Wi-Fi” ≠ “永远稳定高速”
- 大文件 + 局域网，让服务器来拉，比本机推更稳
如果你遇到类似情况：
- 传 AI 模型
- 传镜像
- 传几十 GB 的文件
- 速度一开始很快，后来极慢
真的别硬怼 scp。
一句话经验
scp 适合“小而快”，
HTTP / SMB 适合“大而稳”。