Оптимизация ПК на Windows для работы с ИИ: RAM, SSD, G-Helper, Docker и облако

Оптимизировать Windows 11 для одновременной работы IDE, браузера, Docker/WSL и AI-инструментов — значит найти реальное узкое место, внести одно обратимое изменение и повторить тот же тест. Чаще всего заметный результат дают достаточный запас RAM и диска, ограничение WSL по измеренному пику, порядок в автозагрузке и перенос тяжёлых сборок или инференса на удалённую машину. Отключение файла подкачки, Defender, Windows Update и десятков служб обычно добавляет риск, а не производительность.

Актуально на 5 сентября 2026 года. Названия пунктов меню могут немного отличаться между сборками Windows 11 и версиями Docker Desktop.

Что за «популярный чёрный пакет от разработчика»

Наиболее вероятный кандидат — Chris Titus Tech Windows Utility, или WinUtil. Это популярная утилита с тёмным интерфейсом и разделами для установки программ, настроек Windows, исправлений и обновлений. Однако одного описания «чёрный пакет» недостаточно: так могут называть Blackbird, Winhance, Optimizer, Atlas/AME Wizard и другие наборы твиков.

Перед запуском попросите ссылку, точное название или скриншот. У WinUtil открыт исходный код и виден состав изменений, но это не делает любой пресет безопасным для конкретного рабочего ПК. В официальном репозитории WinUtil есть и умеренные, и глубокие настройки служб, компонентов и поведения обновлений. Запуск скачанного PowerShell-кода от администратора передаёт ему полный контроль над системой.

Безопасная граница для WinUtil и любого похожего набора:

• фиксируйте версию и просматривайте действия до запуска;
• создайте резервную копию важных данных и сохраните ключ восстановления BitLocker;
• применяйте один понятный переключатель, затем перезагружайтесь и повторяйте тест;
• не используйте универсальный «debloat everything»;
• не отключайте Defender, SmartScreen, Windows Update, файл подкачки, IPv6 и неизвестные службы;
• не создавайте облегчённый установочный образ для основной машины, пока не проверили его в виртуальной машине;
• храните список изменений и способ отмены.

Точка восстановления полезна для системных настроек, но она не заменяет резервную копию пользовательских файлов, баз данных и Docker volumes.

Сначала измерьте узкое место

Снимите baseline в реальном сценарии. Откройте обычный набор вкладок, IDE и проект, запустите нужные контейнеры, сборку или локальную модель. Дайте машине поработать 10–20 минут: короткий всплеск при старте мало что говорит о длительной производительности.

Запишите:

• длительность загрузки проекта, сборки, теста и первого ответа модели;
• задержку интерфейса: ввод текста, переключение окон, открытие файлов;
• CPU, Memory, Disk и GPU в Диспетчере задач;
• Committed — «Выделено X/Y», Available — «Доступно», paged и non-paged pool;
• Active time и response time диска, процесс-источник ввода-вывода;
• Dedicated и Shared GPU memory, а не только общий процент GPU;
• температуры, частоты и признаки power/thermal limit во время длинной задачи;
• свободное место на системном диске, внутри WSL и в Docker data disk.

Удобный минимальный набор инструментов:

• Диспетчер задач — быстрый обзор процессов, commit, диска, GPU и влияния автозагрузки;
• Монитор ресурсов (resmon) — hard faults, очередь диска, файлы и процессы с вводом-выводом;
• Системный монитор (perfmon) — запись счётчиков на протяжении типичной нагрузки;
• Безопасность Windows → Производительность и работоспособность устройства — проблемы хранилища, батареи и программ;
• Монитор стабильности (perfmon /rel) — падения приложений, драйверов и обновления по датам;
• Sysinternals — Process Explorer для процессов и DLL, RAMMap для состава памяти, Autoruns для полного автозапуска.

Для углублённой записи памяти в PerfMon добавьте Memory\\Committed Bytes, Memory\\Commit Limit, Memory\\% Committed Bytes In Use, Memory\\Available MBytes, Memory\\Pages Output/sec, а для процессов — Process(*)\\Working Set и Process(*)\\Private Bytes. Для диска полезны PhysicalDisk(*)\\Avg. Disk sec/Read, Avg. Disk sec/Write и Current Disk Queue Length. Смотрите графики вместе: один счётчик редко доказывает причину.

Как читать типичные симптомы

Симптом	Чем подтвердить	Первое безопасное действие
Переключение окон и вкладок замирает	Commit приближается к limit, растут Pages Output/sec, диск занят paging	Закрыть крупнейший ненужный потребитель, проверить system-managed pagefile, уменьшить пик WSL, затем оценить апгрейд RAM
Сборка медленная, интерфейс отзывчив	Один или все CPU загружены, RAM и диск не упираются в предел	Сравнить Balanced и Best performance, проверить thermal throttling, параллелизм сборки и удалённый CI
Docker медленно видит тысячи файлов	Репозиторий в /mnt/c, много мелких операций	Перенести Linux-проект в файловую систему WSL и открывать его через WSL/Remote workflow
Диск C: постоянно красный	Мало свободного места, растут Docker/WSL VHDX, кэши сборок	Разобрать категории Storage, Docker usage и VHDX; очистить только подтверждённо воспроизводимые данные
Локальная модель падает с OOM	Dedicated VRAM заполнена, затем растут Shared GPU memory и RAM/commit	Уменьшить модель, context или batch; изменить offload; вынести инференс на GPU-сервер
Ноутбук быстро стартует, затем замедляется	Частоты падают при росте температуры или срабатывании power limit	Проверить вентиляцию, штатный профиль, блок питания и драйверы; сравнить длинный тест
Паузы появляются после обновления или установки	Монитор стабильности и Event Viewer показывают совпадающее событие	Откатить один драйвер/параметр, а не менять всю систему

Зафиксируйте безопасный эксперимент

Перед настройкой сохраните результаты baseline и состав системы. Эти команды ничего не оптимизируют и не удаляют:

Get-CimInstance Win32_OperatingSystem |
  Select-Object Caption, Version, BuildNumber, TotalVisibleMemorySize, FreePhysicalMemory

Get-PhysicalDisk |
  Select-Object FriendlyName, MediaType, HealthStatus, Size

wsl --version
wsl --status
wsl -l -v

docker system df -v
docker buildx du

Если Docker или WSL не установлен, соответствующая команда просто не нужна. Не публикуйте полный вывод команд: имена дистрибутивов, путей, образов и проектов могут раскрывать внутреннюю информацию.

Выберите один повторяемый тест. Например, чистая сборка, затем тёплая сборка, запуск тестов и короткий запрос к локальной модели. Проведите по три одинаковых запуска и сравните медиану. Холодный и тёплый кэш измеряйте отдельно. Одновременно смотрите, не ухудшились ли температура, шум, автономность и стабильность.

Правило изменения простое: один параметр → перезапуск нужного компонента → тот же benchmark → решение «оставить или откатить». Если за пределами разброса результата выигрыша нет, верните исходное значение.

RAM: смотрите на commit, а файл подкачки оставьте Windows

Процент «Используется» в Диспетчере задач включает полезный кэш. Большой Standby list обычно означает, что Windows использует свободную память для ускорения доступа и может освободить её при необходимости. Очистка Standby-кэша ради красивого процента часто делает следующий запуск медленнее.

Ключевой показатель — system commit. Windows обещает процессам память, которую должна обеспечить RAM или файлами подкачки. В строке «Выделено 24/40 ГБ» первое число — текущий commit charge, второе — commit limit. При приближении к пределу новые выделения могут завершиться ошибкой, процессы — упасть, система — зависнуть.

Оставьте файл подкачки в режиме System managed. Microsoft объясняет, что pagefile расширяет commit limit и участвует в создании crash dumps. Его наличие не означает, что Windows постоянно заменяет быструю RAM медленным SSD. Опасный сценарий — отключить pagefile, одновременно запустить IDE, браузер, WSL и локальную модель и тем самым уменьшить запас commit.

Проверьте три условия:

• на томе с pagefile есть место для роста;
• во время пика commit не подходит устойчиво к limit;
• paging не сопровождается высокой задержкой диска и потерей отзывчивости.

Если commit близок к пределу, сначала сократите ненужный пик. Закройте лишние Electron-приложения, остановите неиспользуемые контейнеры, уменьшите параллелизм сборки или контекст модели. Если типичный рабочий сценарий всё равно стабильно давит память, физическая RAM даст более надёжный результат, чем твики.

Перед покупкой модулей проверьте максимальный объём для модели ноутбука или платы, число слотов, распаянную память, тип DDR и поддерживаемые конфигурации. Для рабочей машины стабильный комплект важнее агрессивного XMP/EXPO. После установки выполните расширенный тест памяти и повторите baseline.

Стартовые профили для 8, 16, 32 и 64 ГБ

Это ориентиры для первого теста, а не универсальные нормы. Лимит WSL делят все WSL2-дистрибутивы и Docker Desktop; его выбирают по измеренному пику, оставляя запас Windows, IDE и браузеру.

RAM	Реалистичный локальный сценарий	Стартовый потолок WSL2	Стартовый swap WSL	Рекомендация по AI
8 ГБ	Один редактор, умеренный браузер, один-два лёгких контейнера по очереди	2–3 ГБ	2 ГБ	Облачная модель/API; локальный CPU-инференс будет конкурировать с IDE и WSL
16 ГБ	Обычная веб-разработка, несколько сервисов, браузер и AI-клиент	4–6 ГБ	2–4 ГБ	Небольшие квантизованные модели только после проверки RAM/VRAM; тяжёлое — в облако
32 ГБ	Многоконтейнерный стек, IDE, большой браузер, параллельные тесты	8–12 ГБ	4 ГБ	Комфортнее для локального offload и небольших/средних квантизованных моделей, но VRAM остаётся отдельным пределом
64 ГБ	Несколько стеков, локальные базы, тяжёлые сборки и анализ данных	16–24 ГБ	4–8 ГБ	Больше места для CPU offload, больших context и нескольких процессов; GPU может остаться главным ограничением

Если сборка внутри WSL получает OOM, поднимайте лимит небольшими шагами. Если Windows теряет отзывчивость при свободной памяти внутри WSL, уменьшайте его. swap=0 не является бесплатным ускорением: непредвиденный пик превращается в Linux OOM. Чрезмерный swap тоже не заменяет RAM и способен одновременно нагрузить SSD вместе с Windows pagefile.

SSD и NVMe: свободное место важнее «чистильщика реестра»

Системному диску нужен рабочий резерв для pagefile, Windows Update, временных файлов, кэшей IDE, Docker data и растущих WSL VHDX. Единого правильного процента нет: на маленьком SSD важен процент, на многотерабайтном — реальный объём. Для dev-машины разумная стартовая цель — не допускать красного индикатора Windows и держать десятки гигабайт сверх измеренного пика обновления, сборки и роста виртуальных дисков. Если Docker активно используется, резерв в 50–100 ГБ часто практичнее абстрактных 10%.

Откройте Параметры → Система → Память и разберите категории. Контроль памяти Storage Sense можно включить с консервативными правилами. Отдельно проверьте сроки для Корзины, Downloads и облачных файлов: автоматическая очистка Downloads подходит не всем.

Windows сама обслуживает накопители. В «Оптимизации дисков» HDD дефрагментируется, а SSD получает TRIM. Не запускайте сторонний дефрагментатор SSD и не делайте ежедневный ручной TRIM. Проверьте, что плановая оптимизация включена и диск отображается как SSD.

Свободное место и здоровье накопителя — разные вещи. HealthStatus = Healthy не гарантирует отсутствие деградации, а один высокий процент Active time не доказывает поломку. Смотрите задержку, ошибки, температуру и данные фирменной утилиты производителя SSD. Обновление firmware делайте только по инструкции производителя и после backup.

Индексация без крайностей

Не отключайте Windows Search целиком. Сначала подтвердите, что SearchIndexer.exe создаёт значимую нагрузку во время работы. Затем исключите только большие воспроизводимые каталоги: кэши сборки, временные выгрузки, сгенерированные артефакты. Исходный код и документы лучше оставить индексируемыми, если системный или IDE-поиск ими пользуется.

По той же причине не добавляйте весь репозиторий, каталог WSL или Docker data в исключения Defender ради гипотетического ускорения. Узкое исключение допустимо только после измерения и оценки риска. Production-секреты, скачанные зависимости и выполняемые артефакты особенно опасно выводить из проверки.

Автозагрузка, браузер и IDE

В Параметры → Приложения → Автозагрузка или на вкладке Startup apps Диспетчера задач отключите программы, которые не нужны сразу после входа. Начните с мессенджеров, игровых лаунчеров, автообновляторов периферии и Docker Desktop, если контейнеры используются не каждый день. Не отключайте защиту, шифрование, драйверы тачпада/звука, корпоративный VPN и компоненты, назначение которых неизвестно.

Autoruns показывает больше: службы, scheduled tasks, shell extensions и другие точки запуска. Для первого прохода скройте подписанные записи Microsoft. Снимайте галочку с одной сторонней записи и проверяйте результат; не удаляйте её. Так возврат сводится к установке той же галочки.

Браузер

Браузер часто расходует больше RAM, чем IDE. Полезны встроенный Memory Saver/Sleeping Tabs, удаление дублирующих расширений и отдельный профиль для разработки. Проверьте внутренний диспетчер задач браузера: одна тяжёлая вкладка или расширение может объяснить весь пик.

Не выгружайте активную документацию и DevTools слишком агрессивно: повторная загрузка меняет benchmark и иногда увеличивает расход CPU. Для созвона, профилировщика и WebGL-приложения оставьте аппаратное ускорение включённым, если нет подтверждённой ошибки драйвера.

IDE

Отключите неиспользуемые расширения для конкретного workspace, а не глобально. В VS Code/Cursor проверьте Running Extensions и Extension Bisect; в JetBrains — Diagnostic Tools и профилирование плагинов. Исключите из watchers и анализа только генерируемые каталоги вроде dist, coverage и больших cache, сохранив исходники и конфигурацию.

Не запускайте одновременно несколько индексаторов одного проекта без цели: IDE, отдельный language server, антивирус, Windows Search и контейнерный bind mount могут читать одни и те же тысячи файлов. После каждой настройки проверьте навигацию по коду, hot reload, тесты и поиск — выигрыш в памяти не должен ломать рабочий цикл.

Питание, охлаждение и драйверы

Для обычной работы оставьте Balanced. Режим Best performance полезно включать от сети на время измеренной CPU/GPU-задачи. Он повышает энергопотребление и нагрев; на ноутбуке короткая сборка может ускориться, а длинная — упереться в охлаждение. Сравнивайте не пиковую частоту в первые 20 секунд, а стабильное время 10–20-минутного теста.

Проверьте:

• используется ли штатный блок питания нужной мощности;
• не закрыты ли воздухозаборники;
• стабилизируются ли частоты под длительной нагрузкой;
• меняется ли результат после очистки внешних решёток при выключенном ноутбуке;
• актуальны ли BIOS, chipset, GPU и OEM System Control Interface;
• исчезла ли проблема после отката последнего драйвера.

Скачивайте BIOS и системные драйверы со страницы производителя устройства, а GPU-драйвер — у производителя ноутбука или GPU с учётом OEM-рекомендаций. Не используйте «driver booster». BIOS обновляйте от сети, с сохранённым BitLocker recovery key и без прерывания питания.

Когда уместен G-Helper

G-Helper имеет смысл только на поддерживаемом ноутбуке или handheld ASUS. Он выбирает доступные устройству BIOS/firmware-профили, режим GPU, кривые вентиляторов, лимит заряда и другие функции. Он не превращает произвольный ПК в более быстрый и не заменяет драйверы.

Перед переходом проверьте точную модель и доступные функции в требованиях G-Helper. Нужен ASUS System Control Interface; конкретные кривые, MUX, undervolt и лимиты зависят от железа и BIOS.

Armoury Crate, ASUS Smart Display Control, MyASUS и G-Helper могут менять одни и те же параметры. Два активных контроллера создают «перетягивание каната»: последний записавший профиль определяет режим, MyASUS может переписать лимит заряда, Smart Display Control — частоту экрана. Безопасная последовательность:

1. Запишите текущие профили, лимит заряда, режим GPU и поведение вентиляторов.
2. Запустите G-Helper без удаления Armoury Crate и проверьте базовые функции на штатных значениях.
3. Не включайте undervolt, overclock и ручные power limits в первом тесте.
4. Если переход устраивает, используйте официальный Armoury Crate Uninstall Tool или остановку ASUS services через G-Helper.
5. Для отката снова запустите ASUS services либо переустановите Armoury Crate/MyASUS с сайта ASUS.

Температура сама по себе не равна throttling. Ищите повторяемое падение частоты, power/thermal limit и увеличение времени задачи. Тихий профиль закономерно ограничивает мощность; «Turbo» закономерно повышает шум и нагрев.

GPU и VRAM для локального ИИ

Локальный инференс ограничивает не общий объём RAM, а сочетание VRAM, RAM, размера и квантизации модели, длины контекста, batch size и реализации runner. Файл весов на диске не равен пиковому расходу: добавляются KV cache, рабочие буферы и иногда дублирование весов при загрузке.

В Диспетчере задач включите столбцы GPU Engine, Dedicated GPU memory и Shared GPU memory. Для NVIDIA используйте nvidia-smi как дополнительный источник. Shared memory берётся из системной RAM и commit; переход туда часто резко снижает скорость. CPU offload позволяет запустить модель, которая не помещается в VRAM, но переносит давление на RAM и пропускную способность памяти.

Стартовая оценка пригодности выглядит так:

Видеопамять	Чего ожидать	Что снижать первым
Только iGPU / shared	Небольшой CPU/iGPU-инференс, сильная конкуренция с IDE и браузером	Размер модели, context, параллельность; для регулярной работы — API/облако
6–8 ГБ	Небольшие квантизованные модели и умеренный контекст, один процесс	Context и batch, затем более сильная квантизация
12–16 ГБ	Более широкий выбор небольших и средних квантизованных моделей	Параллельные сессии, context, объём GPU offload
24 ГБ и больше	Крупнее модель или контекст, но предел всё равно зависит от runner и архитектуры	Профилировать KV cache и фактический пик, а не полагаться на размер файла

Перед скачиванием большой модели проверьте её memory estimator или опыт именно для вашей версии runner. Запустите короткий тест с логированием tokens/s, первого токена, VRAM, RAM, температуры и мощности. Если модель нужна эпизодически, GPU endpoint или арендуемая VM часто рациональнее покупки и постоянного нагрева рабочей станции.

Docker Desktop и WSL2 без мифов

При WSL2 Docker работает внутри общей Linux VM. Поэтому VmmemWSL отражает не только Docker: память делят все запущенные WSL-дистрибутивы, Linux page cache и процессы. Сначала обновите WSL, убедитесь в версии backend и измерьте контейнеры через docker stats, а общий хост — через Task Manager/PerfMon.

Лимиты через WSL Settings и.wslconfig

Текущая документация .wslconfig рекомендует менять настройки через приложение WSL Settings. Они применяются глобально ко всем WSL2-дистрибутивам. Если нужен файл, сохраните оригинал:

Copy-Item -LiteralPath "$env:USERPROFILE\.wslconfig" `
  -Destination "$env:USERPROFILE\.wslconfig.before-tuning" `
  -ErrorAction SilentlyContinue

Пример только для машины с 32 ГБ RAM после измерения пика:

[wsl2]
memory=10GB
swap=4GB

[experimental]
autoMemoryReclaim=gradual

Не копируйте числа без проверки. Параметр processors добавляйте только при подтверждённом конфликте за CPU: он задаётся в логических процессорах и не должен превышать их фактическое число. Оставьте Windows ресурсы для IDE, браузера и интерфейса. autoMemoryReclaim имеет варианты disabled, gradual и dropCache; настройка всё ещё относится к experimental, а поведение и default зависят от текущей версии WSL.

Перед применением сохраните работу и остановите контейнеры. Команда ниже немедленно завершает все WSL-дистрибутивы:

wsl --shutdown

После перезапуска повторите сборку, docker stats и проверку commit. Для отката восстановите сохранённый .wslconfig; если файла раньше не было, переименуйте текущий в .wslconfig.disabled. Затем снова выполните wsl --shutdown. Переименование сохраняет эксперимент для разбора и не удаляет данные.

Resource Saver иautoMemoryReclaim

В режиме WSL Docker Resource Saver приостанавливает Docker Engine, поэтому снижает фоновую нагрузку CPU. Он не выключает общую WSL VM и сам по себе не возвращает занятую ею память Windows. Для освобождения Linux page cache Docker рекомендует autoMemoryReclaim.

Оставьте Resource Saver включённым, если Docker простаивает. Если после тяжёлой сборки VmmemWSL долго удерживает RAM, проверьте обновление WSL и сравните gradual с документированным текущим default. Агрессивный reclaim может ухудшить повторную тёплую сборку, поэтому измеряйте оба сценария.

Где хранить исходники, bind mounts и volumes

Для Linux toolchain и контейнеров держите исходники в файловой системе WSL, например ~/projects/app, а не в /mnt/c/Users/.... Docker отдельно рекомендует этот путь: мелкие операции и inotify работают быстрее внутри Linux filesystem. Открывайте проект из IDE через WSL integration.

Используйте разные типы хранения по задаче:

Данные	Предпочтительный вариант	Причина
Исходники, которые редактирует разработчик	Bind mount из Linux filesystem	Видны IDE и Git, быстры для Linux-контейнера
PostgreSQL/MySQL data, package cache	Named volume	Docker управляет путём, меньше межсистемного I/O
Секреты	Secret manager или ограниченные env/files	Не запекать в image и не коммитить
Временные данные	tmpfs, если потеря допустима	Не раздувает writable layer/VHDX
Артефакт для обмена с Windows	Явный bind mount небольшой папки	Понятная граница и backup

Bind mount по умолчанию позволяет контейнеру менять host-файлы. Для входных данных используйте readonly, если запись не нужна. Named volume переживает удаление контейнера и требует отдельного backup.

BuildKit, кэш и свободное место

Build cache ускоряет повторные сборки. Его регулярное полное удаление заставляет заново скачивать и собирать слои. Начните с read-only инвентаризации:

docker system df -v
docker buildx du

Если подтверждено, что старый build cache съел место, используйте фильтр и оставьте интерактивное подтверждение:

docker buildx prune --filter "until=168h"

Это удаляет воспроизводимый кэш старше недели, но прямого rollback нет: данные вернутся только при следующей сборке. Не добавляйте --all, --force или --volumes без отдельной инвентаризации. docker system prune -a --volumes способен удалить нужные образы, остановленные окружения и данные; для универсальной оптимизации он не подходит.

Ускоряйте BuildKit структурой Dockerfile: стабильные зависимости копируйте до часто меняющегося исходного кода, используйте .dockerignore, cache mounts и multi-stage builds. Меньший build context особенно важен при remote/cloud builder.

Почему VHDX растёт и как его уменьшать

WSL2 хранит файловую систему дистрибутива в динамическом ext4.vhdx. Файл растёт по мере записи, но удаление данных внутри Linux не обязано сразу уменьшать физический размер на Windows. Сначала различите три величины: свободное место на C:, фактически занятое внутри distro (df -h) и размер VHDX на host.

Безопасная последовательность:

1. Удалите только подтверждённо ненужные данные штатными средствами приложения: старый BuildKit cache, package cache, временные файлы.
2. Проверьте df -h, Docker inventory и свободное место Windows.
3. Экспортируйте важный WSL-дистрибутив и сделайте отдельный backup Docker volumes/баз.
4. Полностью остановите Docker Desktop и WSL.
5. Для новых VHD рассмотрите sparseVhd в текущих WSL Settings. Для существующего диска используйте только актуальную процедуру Microsoft для detached/readonly VHD.
6. После compaction запустите distro, проверьте файловую систему, приложение и размер файла.

Не перемещайте, не редактируйте и не подменяйте WSL-файлы в AppData через Проводник. Microsoft предупреждает, что это способно повредить дистрибутив. Ручной compact vdisk — офлайн-операция с предварительным экспортом, а не еженедельная очистка.

Безопасный экспорт создаёт дополнительный файл и не удаляет исходный дистрибутив:

wsl --export Ubuntu "D:\Backups\Ubuntu-2026-09-05.tar"
Get-Item "D:\Backups\Ubuntu-2026-09-05.tar"

Замените Ubuntu на точное имя из wsl -l -v и выберите диск с достаточным местом. Не выполняйте wsl --unregister, пока не проверили размер, доступность и пробное восстановление экспорта: unregister безвозвратно удаляет дистрибутив.

Перенос Docker data disk

Для WSL backend Docker хранит данные на C: по умолчанию. Поддерживаемый перенос выполняется в Docker Desktop: Settings → Resources → Advanced → Disk image location. Не копируйте docker_data.vhdx вручную и не применяйте старые рецепты с unregister внутренних Docker-дистрибутивов.

До переноса:

• сохраните Compose-файлы и конфигурацию;
• сделайте service-native dump баз данных;
• отдельно сохраните named volumes;
• нужные локальные images отправьте в приватный registry или сохраните через docker image save;
• остановите контейнеры;
• убедитесь, что целевой локальный NTFS-диск исправен и имеет достаточный запас.

После Apply & Restart прочитайте настройку снова, выполните docker ps -a, docker images, docker volume ls, поднимите один тестовый stack и убедитесь, что активный VHDX изменяется в новом месте. Старую копию не удаляйте, пока backup и рабочая нагрузка не проверены. Порядок резервного копирования описан в Docker Desktop backup and restore.

Что переносить в облако

Облако полезно, когда задача воспроизводима из репозитория и конфигурации, требует CPU/GPU/RAM короткими пиками и не зависит от локального железа. Оно не исправляет медленный SSD или 8 ГБ RAM, если IDE, браузер и десятки вкладок всё равно остаются локально.

Нагрузка	Подходящий вариант	Что остаётся локально	Главный риск
Интерактивное редактирование + тяжёлая сборка	Remote SSH/devbox	UI IDE, клавиатура, часть extensions	Задержка сети, зависимость от SSH
Повторяемая среда проекта	Devcontainer/Codespaces	Браузер или клиент IDE	Стоимость compute + persistent storage
Build/test/lint	CI или remote builder	Просмотр логов и diff	Очередь, cache transfer, минуты выполнения
Локальная база для большого dataset	Managed DB или remote container	Клиент и небольшой dev snapshot	Data residency, egress, latency, доступ
Локальная модель	GPU VM или inference API	UI и минимальный клиент	Цена GPU, секреты, передаваемые данные
Автономная coding-задача	Cursor Cloud Agents или Codex Cloud	Постановка задачи и review	Repo permissions, environment drift, prompt injection
USB, драйвер, Windows UI, локальная сеть	Локальная машина	Почти всё	Облачный runner не видит физический контекст

Codespaces, Remote SSH и devcontainers

GitHub Codespaces создаёт devcontainer на облачной VM. Это хороший путь для воспроизводимой Linux-разработки, onboarding и эпизодических тяжёлых сборок. Remote SSH даёт больше контроля: вы арендуете или используете собственную Linux-машину, а IDE подключается к ней. Devcontainer переносит версии runtime, системные зависимости и setup в код.

Начните с небольшого пилота:

1. Опишите зависимости в devcontainer.json или setup script.
2. Поднимите чистую удалённую среду без локальных dotfiles.
3. Запустите сборку и тесты.
4. Настройте auto-stop/idle timeout и бюджет.
5. Передавайте секреты через secret store с минимальными правами.
6. Оставьте локальный способ запуска хотя бы smoke tests.

Большой репозиторий, Docker build context или dataset способен съесть выигрыш загрузкой. Измеряйте время до первого полезного результата, повторный запуск с cache и объём входящего/исходящего трафика.

Cursor: Remote SSH и Cloud Agents решают разные задачи

Remote SSH переносит файлы, language servers, команды, контейнеры и сборку на удалённый host, сохраняя локальный интерфейс IDE. Cursor Cloud Agents — отдельный режим: они работают в изолированных облачных VM, клонируют репозиторий, устанавливают зависимости, используют настроенные secrets/network/startup commands, выполняют тесты и передают изменения через branch/PR.

Cloud Agent подходит для автономной задачи с машинно запускаемой проверкой. Он не является побайтовой копией вашего Windows desktop и не получает автоматически локальные файлы, авторизации, USB и GUI-состояние. Для успеха нужны подключённый source control, необходимые repo permissions и воспроизводимое окружение.

Давайте агенту только нужный репозиторий и временные scoped credentials. Ограничивайте outbound domains, где функция доступна, не передавайте production-токены, проверяйте diff и логи. Отдельно уточняйте текущий тариф, spend limit, retention, регион обработки и subprocessors перед рабочими данными.

Codex Cloud

Codex Cloud запускает coding tasks в отдельных облачных окружениях, позволяет выполнять работу параллельно и описывать зависимости, инструменты, переменные и setup для репозитория. Результат нужно проверять по summary и diff; при готовности можно продолжить задачу или открыть pull request.

Это способ вынести автономную работу с кодом, тестами и review с локального ПК. Он не переносит весь Cursor/Codex-сеанс с Windows и не обещает совместимость с локальными драйверами или GUI. Не закладывайте в архитектуру неизвестные тарифы, квоты, регион или доступность: проверьте их в своём аккаунте и официальной OpenAI Docs непосредственно перед миграцией.

Базы, контейнеры и GPU inference

Для базы перенесите в облако сервис и обезличенный dev dataset, а не единственный локальный экземпляр без backup. Миграции проверяйте локально и в staging. Учитывайте RTT: сто маленьких запросов к далёкой базе могут быть медленнее одного тяжёлого локального запроса.

Контейнеры хорошо переносятся, если образ не зависит от host bind paths и секретов. Используйте registry, healthcheck, versioned image tags и инфраструктуру как код. Данные контейнера живут отдельно: volume, object storage или managed database должны иметь свой backup и restore test.

GPU inference выгодно выносить для редких или пакетных задач. Сравнивайте полную стоимость: время VM, attached disk, хранение модели, cold start, входящий/исходящий трафик и простой. Останавливайте GPU-инстанс автоматически, но не удаляйте единственную копию результата вместе с ephemeral disk.

Проверка перед переносом

Ответьте на вопросы:

• допустимо ли отправлять код и данные выбранному провайдеру;
• в каком регионе они хранятся и обрабатываются;
• какие subprocessors и сроки retention применяются;
• сколько стоит compute, GPU, storage, snapshot и egress;
• какой RTT до разработчика, базы и пользователей;
• как ограничены токены, SSH-ключи и repo permissions;
• можно ли полностью воспроизвести среду из Git и secret store;
• как экспортировать данные и вернуться локально;
• что произойдёт при отключении интернета или блокировке аккаунта.

Сохраните резервный локальный путь: checkout репозитория, небольшой dataset, lock-файлы зависимостей, Compose/devcontainer и инструкция запуска. Облако должно уменьшать нагрузку, а не превращаться в единственную точку восстановления.

Безопасный план оптимизации на неделю

Baseline

В первый день ничего не удаляйте. Выполните реальный сценарий, соберите Task Manager/PerfMon, время задач, commit, диск, VRAM и температуры. Зафиксируйте версии Windows, WSL, Docker и драйверов.

Обратимые изменения Windows

Во второй день отключите две-три очевидные программы автозагрузки. Настройте sleeping tabs и отключите одно подозрительное расширение IDE. Оставьте pagefile system-managed, Defender и Update включёнными. Перезагрузитесь и повторите тест.

RAM и диск

В третий день разберите Storage categories, свободное место и Docker inventory. Настройте Storage Sense без Downloads, если эта папка используется для работы. Проверьте Optimize Drives, здоровье SSD и реальный commit. При подтверждённом дефиците спланируйте RAM upgrade.

Docker и WSL

В четвёртый день перенесите один тестовый Linux-проект из /mnt/c в ext4 WSL, сравните install/build/watch. Затем задайте консервативный лимит WSL по таблице и пику. Проверьте autoMemoryReclaim, Resource Saver и rollback.

Power и thermal

В пятый день сравните Balanced и Best performance на длинной задаче. На совместимом ASUS протестируйте G-Helper только со штатными профилями. Не меняйте undervolt и разгон одновременно с заменой контроллера.

Облачный пилот

В шестой день вынесите одну хорошо проверяемую задачу: CI build, тесты, devcontainer или небольшой inference job. Настройте budget, auto-stop, scoped secret и сохранение результата. Измерьте полное время и стоимость.

Решение и rollback

В седьмой день оставьте только изменения с измеримым выигрышем. Верните настройки, которые ухудшили стабильность, автономность или время задачи. Сохраните финальные показатели и дату следующей проверки.

Чек-лист

• [ ] Измерен реальный сценарий, а не idle после загрузки.
• [ ] Записаны commit X/Y, Available, paging и задержка диска.
• [ ] Pagefile оставлен System managed.
• [ ] На C: есть запас для Update, pagefile, кэшей и VHDX.
• [ ] Storage Sense не удаляет нужные Downloads и cloud files.
• [ ] Defender, SmartScreen и Windows Update включены.
• [ ] В автозагрузке отключены только понятные сторонние приложения.
• [ ] Проверены browser tabs/extensions и IDE extensions/watchers.
• [ ] Power mode сравнен на длинной задаче с температурой и частотой.
• [ ] G-Helper используется только на подтверждённо совместимом ASUS.
• [ ] Armoury Crate/MyASUS/G-Helper не меняют одновременно один параметр.
• [ ] WSL limit выбран по пику и оставляет запас Windows.
• [ ] После .wslconfig проверен rollback.
• [ ] Linux-проекты Docker не живут без причины в /mnt/c.
• [ ] Перед prune просмотрены docker system df -v и docker buildx du.
• [ ] Docker volumes и базы имеют отдельный backup.
• [ ] VHDX не перемещается вручную через AppData.
• [ ] Перенос Docker data выполнен через поддерживаемый интерфейс.
• [ ] Облачный пилот имеет budget, auto-stop, scoped secrets и план возврата.
• [ ] Diff и тесты AI-агента проверяет человек.