Сначала измерьте прирост диска на одной типовой задаче, а уже затем планируйте расширение: место логов сессий DeepSeek Harness нельзя надёжно оценить по числу сообщений или Token. На этой неделе стоит зафиксировать версию Harness, тип задачи, каталог запуска, длительность наблюдения и размер диска до и после выполнения.
Такой подход подходит трём группам читателей:
- долгосрочным пользователям Agent, которым важно не допустить бесконтрольного роста журналов и результатов инструментов;
- специалистам по закупкам, рассчитывающим срок аренды и запас хранилища под реальную нагрузку;
- командам эксплуатации, которым нужны правила резервного копирования, очистки и проверки восстановления.
Единица расчёта — не сообщение, а полный цикл хранения
Для планирования используется не одна цифра, а сумма отдельных компонентов:
Итоговый объём =
журнал событий сессии
+ постоянные вложения
+ результаты и артефакты в рабочем каталоге
+ временный кэш и служебные файлы
+ резервные копии и миграционные копии
В официальной архитектуре DeepSeek Harness сессия описана как добавляемый журнал типизированных SessionEvent. История сообщений для модели выводится из этого журнала, а не хранится как независимая копия. В него входят границы turn и step, сообщения пользователя, фрагменты ответа, итоговые ответы, вызовы инструментов и их результаты. Это означает, что видимый диалог в интерфейсе — только одна проекция сохранённых данных. (github.com)
Token и диск относятся к разным измерениям:
- Token показывает объём входа и выхода модели;
- байты показывают размер сериализованного события, JSON-структур, метаданных, вложений и файлов;
- один большой результат команды может добавить больше данных, чем несколько коротких реплик;
- потоковые фрагменты ответа способен сохранять отдельные записи для воспроизведения интерфейса и восстановления.
Поэтому при аудите нужно записывать минимум три результата: число событий, размер физического хранилища и размер рабочего каталога. Если измеряется только количество Token, часть расходов Mac-хранилища останется невидимой.
Где искать логи сессий DeepSeek Harness
Фиксированное имя каталога нельзя считать универсальным ответом. В текущей документации место хранения определяется выбранным persistence-бэкендом: JSONL может возвращать абсолютный путь отдельного артефакта сессии, тогда как SQLite хранит события в общей базе и не обязан иметь отдельный файл на каждую сессию. (github.com)
Сначала необходимо узнать фактический профиль и домашний каталог Harness, а не искать файлы по предположительному пути:
pwd
dsh --profile web --dump-config
find "$HOME" -type f \( -iname '*session*' -o -iname '*.jsonl' -o -iname '*.db' -o -iname '*.sqlite' \) \
-print 2>/dev/null | head -100
После этого размер следует проверять на уровне конкретного каталога или файла:
du -sh /путь/к/каталогу-сессий
find /путь/к/каталогу-сессий -type f -print0 \
| xargs -0 stat -f '%z %N' \
| sort -nr | head -30
Команда du показывает фактически занятое место, а stat помогает увидеть отдельные крупные артефакты. Для сжатого JSONL размер распакованного текста и физический размер на диске могут различаться, поэтому в отчёте нужно хранить оба значения, если бэкенд это позволяет. Официальная документация описывает JSONL как добавляемый журнал, который по умолчанию может записываться в кадры Zstandard, а SQLite — как таблицу с одной строкой на событие. (github.com)
Рост SessionEvent показывает базовую нагрузку
В расчёт нужно включать не только user/message и assistant/message. Официальная схема также описывает assistant/chunk, tool/call, tool/result, request/header, request/context, границы turn и step, а дополнительные плагины могут добавлять собственные события, например события компактизации или hook-моста. (github.com)
Из этого следуют как минимум четыре ограничения.
- Длинный ответ может иметь несколько представлений. Потоковые фрагменты сохраняются для точного воспроизведения, а собранное сообщение используется при выводе истории.
- Вызов инструмента состоит минимум из запроса и результата. В JSON могут попасть имя инструмента, аргументы, ошибка, служебные метаданные и возвращённый текст.
- Системный промпт и схемы инструментов тоже могут быть частью журнала. В
request/headerфиксируется состояние, необходимое для реконструкции следующего запроса. - Компактизация не равна удалению исходных байтов. Она может менять отображаемую поверхность истории, но безопасное удаление физического журнала требует отдельной проверки политики persistence.
Для измерения базового прироста рекомендуется использовать задачу без изображений и с контролируемым инструментом. До запуска нужно записать:
du -sk "$SESSION_DIR" "$WORKSPACE_DIR" 2>/dev/null
date -u '+%Y-%m-%dT%H:%M:%SZ'
После завершения той же задачи команда выполняется повторно. Разность между двумя замерами — прирост конкретного запуска. Если сессия уже содержит старые события, следует создать отдельную тестовую сессию или использовать новый идентификатор, иначе в результат попадёт исторический хвост.
Важно также сохранять параметры эксперимента:
Версия Harness:
Профиль:
Бэкенд хранения:
Тип задачи:
Количество запусков:
Время начала и окончания:
События до:
События после:
Размер журнала до:
Размер журнала после:
Без этих полей сравнение через месяц будет ненадёжным: изменение формата, состава системного промпта или политики компактизации может выглядеть как рост нагрузки.
Результаты инструментов определяют предел длинной задачи
На практике основным источником роста часто становится не пользовательский текст, а возвращаемые данные. Крупные логи сборки, трассировки тестов, содержимое файлов, результаты поиска и длинные ответы MCP могут попадать в tool/result. Документация указывает, что результат инструмента может содержать сообщение для модели, ошибку и JSON-сериализуемое поле meta, которое затем воспроизводится при replay. (github.com)
Нужно разделять два случая:
- результат сохранён в журнале — он влияет на размер сессии и аудит;
- результат записан в рабочий каталог — он увеличивает Mac-хранилище, но может не входить в журнал;
- результат присутствует в обоих местах — возникает двойное хранение;
- результат попал в резервную копию — добавляется ещё один физический экземпляр.
Для чистого эксперимента выполняются три одинаковых прогона:
- команда возвращает короткий итог;
- команда возвращает полный текст;
- полный текст сохраняется в файл, а в сессию передаётся только путь и краткое резюме.
Не следует заранее заявлять фиксированный процент экономии: результат зависит от формата вывода, повторяемости данных, сериализации и того, сохраняет ли конкретный инструмент meta. Надёжный показатель — только разность каталогов и журналов после одинакового теста.
BEFORE=$(du -sk "$SESSION_DIR" "$WORKSPACE_DIR" | awk '{sum += $1} END {print sum}')
# запуск одной и той же задачи DeepSeek Harness
AFTER=$(du -sk "$SESSION_DIR" "$WORKSPACE_DIR" | awk '{sum += $1} END {print sum}')
printf 'Прирост: %s KiB\n' "$((AFTER - BEFORE))"
Рабочие артефакты следует измерять отдельно:
find "$WORKSPACE_DIR" -type f -print0 \
| xargs -0 stat -f '%z %N' 2>/dev/null \
| sort -nr | head -50
Так становится понятно, требуется ли очистка журналов, ограничение вывода инструментов, перенос артефактов во внешнее хранилище или расширение диска.
Изображения считают по байтам, а не по количеству файлов
Сохраняются ли изображения вместе с сессией? Ответ нужно проверять для конкретной версии Harness и подключённого MCP или ACP-плагина. Наличие изображения в интерфейсе не доказывает, что на Mac сохранён исходный файл: плагин может хранить локальный путь, миниатюру, преобразованную копию, содержимое в событии или ссылку на внешний объект.
Для каждого изображения нужно измерить минимум четыре значения:
- размер исходного файла;
- размер преобразованной или пересланной копии;
- размер записи, если данные сериализуются внутри события;
- размер после закрытия и повторного открытия сессии.
Команды для локальной проверки:
find "$WORKSPACE_DIR" -type f \
\( -iname '*.png' -o -iname '*.jpg' -o -iname '*.jpeg' -o -iname '*.webp' \) \
-exec stat -f '%z %N' {} \; | sort -nr
Если вложение передаётся через MCP или ACP, нужно сопоставить время его появления с изменением журнала:
du -sk "$SESSION_DIR" > /tmp/dsh-before.txt
# добавить одно изображение и завершить тестовый turn
du -sk "$SESSION_DIR" > /tmp/dsh-after.txt
diff -u /tmp/dsh-before.txt /tmp/dsh-after.txt
Нельзя умножать «число картинок» на условный средний размер: скриншоты, фотографии, схемы и повторно закодированные изображения дают разный результат. Для чувствительных вложений требуется отдельная политика хранения — временный файл, архив аудита и резервная копия не должны оставаться без владельца и срока удаления.
Важно: удаление файла из рабочего каталога не гарантирует удаления его копии из события, кэша или резервного набора. Сначала нужно определить все физические представления и выполнить восстановление тестовой сессии.
Резервные копии нельзя считать свободным рабочим местом
Планирование часто ломается из-за смешения «доступного диска» и «диска, занятого копиями». Для каждого периода нужно разделить:
- активный журнал и рабочие файлы;
- локальный snapshot;
- копию для миграции;
- копию, удерживаемую на случай отката;
- временный архив перед очисткой.
Пример формулы:
Плановый объём =
активные данные
+ активные данные × число дополнительных копий
+ прирост за период удержания
+ рабочий резерв
Коэффициенты в эту формулу нельзя подставлять из универсальной статьи. Их нужно получить из внутренней политики команды: сколько копий действительно требуется, как долго сохраняется каждая копия и используется ли дедупликация.
У DeepSeek Harness уже предусмотрены отдельные механизмы загрузки, восстановления и проверки формата. Документация указывает, что при несовместимой версии журнал может быть отклонён, а наличие читаемой копии не означает, что новая версия сможет продолжить работу без обновления или миграции. Для холодной сессии восстановление также может закрыть незавершённый turn синтетическим событием, не переписывая сохранённые самостоятельные записи. (github.com)
После каждого изменения формата нужно выполнить не только проверку наличия файла, но и полный сценарий:
1. Создать копию тестовой сессии.
2. Перенести её в отдельный каталог.
3. Запустить текущую версию Harness.
4. Открыть журнал и получить список событий.
5. Продолжить сессию новым сообщением.
6. Проверить рабочий каталог и вложения.
7. Сравнить контрольные суммы исходной и восстановленной копии.
Если шаг продолжения не проходит, копия годится для архива, но не для оперативного восстановления.
Таблица измерений превращается в решение о расширении
| Компонент | Что измеряется | Как получить значение | Что делать с результатом |
|---|---|---|---|
Журнал SessionEvent |
Байты до и после типовой задачи | du, размер JSONL или SQLite |
Умножить на число задач и срок хранения |
| Результаты инструментов | Прирост после одинаковой команды | Сравнить полный вывод и вывод-ссылку | Ограничить шум или вынести артефакты |
| Изображения | Исходник, копия, запись в сессии | stat, du, повторное открытие |
Хранить отдельно и назначить срок удаления |
| Рабочие файлы | Сборка, кэш, отчёты, временные каталоги | find, du, список крупных файлов |
Установить очистку по типу артефакта |
| Резервные копии | Число экземпляров и окно отката | Размер набора после копирования | Не включать копии в свободный рабочий запас |
Для закупки или аренды используется заполняемая модель:
D_задача = D_события + D_инструменты + D_вложения + D_рабочие_файлы
D_период = D_задача × N_задач + D_исходный_архив
D_итого = D_период × (1 + N_дополнительных_копий) + D_резерв
Здесь N_задач — фактически запланированное число задач, а не число сообщений. D_резерв должен учитывать обновление, временную распаковку и неудачную миграцию, но его значение команда должна получить из собственных контрольных запусков.
Условия выбора стратегии
- Если журнал растёт, а рабочие файлы стабильны, сначала выбирается политика хранения событий и измеряется совместимость очистки; немедленное расширение может только отложить проблему.
- Если основную долю занимают результаты инструментов, сначала ограничивается вывод и вводится сохранение полного результата в отдельный артефакт.
- Если основную долю занимают изображения, вложения выносятся в отдельный контролируемый каталог с журналом происхождения и сроком удаления.
- Если копии занимают больше активных данных, пересматривается схема snapshot и миграции; рабочее пространство нельзя отдавать под резервные наборы.
- Если данные нельзя безопасно очистить из-за аудита, выбирается расширение Mac-хранилища и заранее проверяется восстановление.
- Если формат журнала изменился или версия находится в developer preview, сначала создаётся новая базовая выборка, а старые коэффициенты не переносятся автоматически.
Для команд, планирующих работу на удалённой машине, полезно заранее изучить особенности облачного Mac mini и справочный центр по облачному Mac. Эти материалы помогают отделить вычислительную задачу от требований к диску, доступу и передаче данных.
Проверка перед расчётом аренды
Перед выбором срока аренды или конфигурации следует заполнить один короткий протокол:
[ ] Зафиксирована версия DeepSeek Harness и профиль запуска.
[ ] Определён фактический persistence-бэкенд.
[ ] Измерен каталог сессий до и после типовой задачи.
[ ] Отдельно измерены результаты инструментов.
[ ] Отдельно измерены рабочие файлы и кэш.
[ ] Проверена стратегия хранения изображений.
[ ] Рассчитано число копий и окно отката.
[ ] Выполнено восстановление тестовой сессии.
[ ] Проверено продолжение восстановленной сессии.
[ ] Зафиксирована дата следующего повторного измерения.
Если требуется временная среда для тестов, аудита или миграции, аренда NodeMini может оказаться удобнее текущего варианта с локальным Mac или обычной виртуальной машиной: локальный диск быстро становится частью личной инфраструктуры, Windows/Linux-среда добавляет различия в файловых путях и правах, а самодельная облачная схема требует отдельно контролировать доступ, snapshots и восстановление. При этом для постоянной тяжёлой нагрузки, обязательных физических интерфейсов или длительного проекта с предсказуемым сроком собственное устройство может быть рациональнее.
После получения реального D_задача в расчёт следует включить не только активные логи, но и резервные копии, рабочие артефакты и запас на повторное восстановление. Для временного запуска DeepSeek Harness на удалённом Mac можно сопоставить эти данные с вариантами оформления Mac mini, а затем выбрать срок и объём без покупки лишнего хранилища «на глаз».