手元でモデルを動かすようになると、大きなファイルを持ち回る場面が増えます。モデル本体、検証用のデータ、生成した成果物。数十GB規模になることも珍しくありません。
この回は、差分同期の道具を扱います。全部を毎回送るのではなく、変わった分だけを送るという考え方です。
1. 何が問題になるか
大きなデータの転送では、素朴なコピーが機能しなくなります。
| 問題 | 起きること |
|---|---|
| 時間がかかる | 数十GBの転送に数時間 |
| 途中で失敗する | 最初からやり直しになる方式だと致命的 |
| 毎回全部送っている | 1ファイルしか変わっていないのに全部 |
| 大量の小ファイル | 1件あたりの固定コストが積み上がる |
| 同じものが複数箇所にある | どれが最新か分からなくなる |
2行目と3行目が、道具を変えるだけで解決します。差分だけを送り、中断しても再開できる道具を使えば、この2つは消えます。
大量の小ファイルは、合計サイズが小さくても遅くなります。1件ごとに固定の手間がかかるためです。この場合、まとめて1つにしてから送るほうが速いことがあります。
2. 道具の使い分け
代表的な3つを、接続先で使い分けます。用途が重ならないので、迷う場面は多くありません。
| 道具 | 得意な相手 | 特徴 |
|---|---|---|
| rsync | サーバ間、手元同士 | 差分転送が高速。定番 |
| クラウドストレージ | 多数のサービスに対応 | |
| 手元の機器同士（常時） | 双方向で自動。設定後は意識しない |
3行目だけ性質が違います。rsync と rclone が「実行したときに同期する」のに対し、Syncthing は「変更を検知して自動で同期し続ける」。用途としては、作業用の機器同士を常に揃えておくという使い方に向きます。
逆に、大きなモデルファイルを常時同期させるのは向きません。変更のたびに全機器へ転送されるため、意図しない負荷になります。明示的に実行する道具（rsync / rclone）のほうが制御できます。自動で揃うことは便利ですが、何がいつ転送されるかを把握できないという代償があります。
3. 実際の使い方
よく使う形を並べます。オプションの意味を理解して使うことが、事故を防ぎます。
# 基本形: 差分だけを送り、進捗を出す# -a: 属性を保つ / -v: 詳細表示 / -z: 圧縮して転送# --partial: 中断時に途中まで残す（再開が速い）# --info=progress2: 全体の進捗を出すrsync -avz --partial --info=progress2 \ ./models/ user@host:/data/models/
# 送る前に、何が転送されるかを確認する（実行しない）rsync -avzn --delete ./models/ user@host:/data/models/
# 相手側の余計なファイルも消して完全に一致させる# ※ --delete は危険。必ず -n で確認してから外すrsync -avz --delete ./models/ user@host:/data/models/
# 大きなファイルの途中再開を効かせるrsync -avz --partial --append-verify \ ./big-model.gguf user@host:/data/models/`-n`（確認だけ）を先に実行する習慣をつけてください。特に `--delete` は、指定を1つ間違えると相手側のファイルを消します。末尾のスラッシュの有無でも挙動が変わるため、確認は必須です。
# 接続先を設定する（対話式）rclone config
# 中身を確認するrclone ls mydrive:models/ --max-depth 1
# 実行前に差分を確認する（--dry-run）rclone sync ./models/ mydrive:models/ --dry-run --progress
# 実際に同期する（並列数と再試行を指定）rclone sync ./models/ mydrive:models/ \ --progress \ --transfers 4 \ --checkers 8 \ --retries 3 \ --exclude "*.tmp" \ --exclude ".DS_Store"
# 双方を突き合わせて、差分がないことを確認するrclone check ./models/ mydrive:models/`rclone sync` は片方向で、相手を送り元に一致させます。相手側にしかないファイルは消えます。双方向にしたい場合は `bisync` という別の機能があるので、目的に合わせて選んでください。
最後の `check` が実務で効きます。転送したあとに、本当に一致しているかを確認する。レガシー再生の現場 EP.06 で扱った突き合わせと同じ考え方です。
4. 事故を防ぐ
同期の道具は強力なぶん、設定を誤ると大量のファイルを消します。防ぐ方法は決まっています。
- 1必ず先に確認モードで実行する — `-n` / `--dry-run`
- 2削除を伴う操作は特に慎重に — `--delete` / `sync`
- 3末尾のスラッシュを確認する — 有無で挙動が変わる
- 4大事なものは、先に別の場所に複製 — 取り返しのつかない操作の前に
- 5よく使う組み合わせはスクリプトにする — 毎回打つと打ち間違える
5番目が地味に効きます。手で打つと、いつか打ち間違えます。よく使う同期はスクリプトにして、確認モードと実行を分けておくと事故が減ります。
#!/usr/bin/env bash# usage: sync-models.sh [--apply]set -euo pipefail
SRC="$HOME/models/"DST="user@host:/data/models/"
if [[ "${1:-}" == "--apply" ]]; then echo "実行します: $SRC -> $DST" rsync -avz --partial --info=progress2 --delete "$SRC" "$DST"else echo "確認のみ（実行するには --apply を付ける）" rsync -avzn --delete --info=stats2 "$SRC" "$DST"fi既定を確認モードにするのが要点です。`--apply` を明示しない限り実行されないので、うっかり実行してしまうことがありません。LLM時代のテスト戦略 EP.09 で扱った「間違えたらエラーになる形」と同じ発想です。
5. 何を同期し、何をしないか
全部を同期する必要はありません。むしろ、同期しないものを決めるほうが重要です。
| 対象 | 同期するか | 理由 |
|---|---|---|
| モデルのファイル | する | 大きく、再取得に時間がかかる |
| 検証用のデータ | する | 同じ条件で確認するため |
| 生成した成果物 | 場合による | 再生成できるなら不要 |
| 一時ファイル・キャッシュ | しない | 容量を食うだけ |
| などの鍵 | 絶対にしない | 次回扱う |
| 再取得できる公開データ | しない | 元から取り直せばよい |
5行目は次回（EP.22）で扱いますが、同期の対象から必ず除外してください。除外設定に入れ忘れると、鍵が複数の機器に散らばります。
「あとで除外する」は間に合いません。一度送ってしまうと、相手側から消す作業が必要になります。同期を設定する時点で、除外リストを先に書いてください。
6. 選び方の整理
最後に、判断の順序をまとめます。
- 1相手はどこか — サーバなら rsync、クラウドなら rclone、機器同士の常時なら Syncthing
- 2明示的に実行したいか、自動で揃えたいか — 大きいものは明示的に
- 3削除を伴うか — 伴うなら確認モードを必須にする
- 4除外するものを先に決める — 鍵・一時ファイル・キャッシュ
- 5転送後に確認するか — 重要なら `check` で突き合わせる
1番目で大半が決まります。用途が重ならないので、どれか1つを選ぶというより、状況に応じて使い分けるという形になります。3つとも入れておいて損はありません。ただし次回以降で扱うとおり、道具は増やすほど維持の対象も増えます。使わないものまで入れる必要はありません。
接続先で使い分ける ── サーバ間は rsync、クラウドは rclone、機器同士の常時同期は SyncThing。大きいものは明示的に実行する道具を選ぶ。必ず確認モードを先に実行し、削除を伴う操作は特に慎重に。除外設定は最初に書く（後からでは間に合わない）。そして重要なものは転送後に突き合わせて確認してください。
この記事の感想を教えてください
あなたの 1 クリックで、本当にこの記事は更新されます。「もっと詳しく」「続編希望」が一定数集まった記事は、 ふくふくが 実際に内容を拡充したり続編記事を公開 します。 送信したリアクションはお使いのブラウザに記録され、再カウントされません。