夸克网盘CLI踩坑记（官方Skill是有上传限制的）：

一个 13GB 大文件上传,我把速度从 52KB/s 干到了 8.9MB/s

起因是我要从 Civitai 下载一个 13.1GB 的 AI 模型(safetensors 格式),归档到夸克网盘。夸克官方出了一个命令行工具,支持大文件断点续传,本来以为直接一把梭,结果连续踩了三个坑,挨个手撕源码打补丁,最后把上传时间从 70 小时压到了 25 分钟。过程还挺有意思,记录一下。

坑 1:上传永远在半路崩掉

第一次跑,进程跑一会儿就报错:

ACK timeout for batch 0 (>60000ms)

报错位置不在主程序里,在一个叫 hash-worker.cjs的 Worker 线程文件里。13GB 大文件上传前要先做分块哈希(SHA1+MD5),Worker 算完一批分块后要等主进程回一个 ACK 才能继续。而这个等待超时是硬编码的 60 秒——13GB 文件的分块算不完,60 秒一到直接判死。

修复:把超时从 60 秒改成 600 秒。改完不崩了,但新的问题来了——速度只有 52KB/s。按这个速度,13GB 要传 70 个小时。

坑 2:哈希 Worker 一次只处理 1 个分块

翻主进程代码,发现启动哈希 Worker 时传的参数是 batchSize:1——也就是说 Worker 每算完一个64KB 分块,就要停下来等一次 ACK。13GB 文件分成约 20 万个分块,主进程和 Worker 之间要来回 20 万次,光通信开销就拖垮了速度。

修复:把 batchSize:1改成 batchSize:256,一次处理 256 个分块再汇报。速度提升 4 倍,但依然只有 200KB/s。

坑 3:上传并发数只有 6

继续挖,发现 SDK 里有个默认配置 maxConcurrentPartSize: 6——同一时间只允许 6 个分块并行上传。64KB 的小分块 × 6 个并发,宽带利用率惨不忍睹。

这个值在打包后的 SDK 配置对象里,直接改:6 → 64 → 128 → 256,每翻一倍速度就翻一倍:

并发 6:52 KB/s(70 小时)

并发 64:2.2 MB/s(1.5 小时)

并发 128:4.3 MB/s(50 分钟)

并发 256:8.9 MB/s(25 分钟)🔥

8.9MB/s 已经接近家用宽带上行极限(约 70Mbps),再往上加并发只会触发服务端限流。

中间还踩了个雷

顺手把批次也试了试 1024,结果服务端直接报 参数错误: [part list exceed]——单次 part 列表上限约 256,贪多直接炸,老老实实回退。

总结

3 个补丁,2 个文件:超时 60s→600s、批次 1→256、并发 6→256

提速 170 倍:52KB/s → 8.9MB/s,70 小时 → 25 分钟

第二天用同一套配置传 13.5GB,29 分钟稳定跑完,补丁经得起复验

给 AI 行业朋友的启示:官方 CLI 的默认参数往往为"小文件+通用场景"设计,大文件上传记得先看三样东西——超时时间、批次大小、并发数。这仨调好了,速度天壤之别。