1 ноября 2026 года при входе в Claude Code разработчику из России предложили пройти верификацию. Через несколько дней его аккаунт в Anthropic заблокировали, и это уже третья блокировка за восемь месяцев работы с инструментом. Вместо поиска обходных путей он неделю проработал на локальных моделях: Qwen 3.8 Flash Next на одной NVIDIA DGX Spark и DeepSeek-V4.1-Flash-1017 (EXL3) на кластере из двух Spark.
Ответ на главный вопрос сразу: заменить облачный ассистент локальным стеком можно. Плата за это известна. Цикл разработки вырастает примерно в 3-4 раза, а DeepSeek требует двух машин, тогда как Qwen укладывается в одну. Приватность, отсутствие лимитов на запросы и независимость от блокировок при этом переходят к вам полностью.
Ниже разобрано, что именно известно из опубликованного отчёта о первой неделе на локальных Qwen и DeepSeek, какие требования к железу из него следуют, как читать метрики TPS и TTFT и в каких случаях такая замена оправдана.
Почему Claude Code отвалился и что делать после блокировки
Хронология в источнике простая. 1 ноября 2026 года Claude Code запросил верификацию. За пару дней до этого с той же проблемой столкнулись знакомые разработчики, и всех их в итоге заблокировали после прохождения процедуры. Автор отдавать паспортные данные не стал и сразу перешёл к поиску замены.
За восемь месяцев работы это третья блокировка. Такой режим означает, что доступ к основному инструменту разработки может исчезнуть в любой момент, и держать план Б имеет смысл до того, как он понадобится.
Верификация Anthropic: почему автор не стал её проходить
Решение отказаться от верификации опирается на наблюдение за окружением: у знакомых разработчиков процедура закончилась блокировкой, а не восстановлением доступа. В этом кейсе паспортные данные не дали результата, которого от них ждали.
Источник не даёт оснований для выводов о политике Anthropic в целом: описан личный опыт одного разработчика и его знакомых, а не статистика блокировок. Формулировка «всех блокируют после верификации» здесь была бы натяжкой, корректная рамка - «в этом окружении верификация не помогла».
Почему не Kimi K3.1 и не Codex
Знакомые автора рассматривали те же альтернативы, что и он: Kimi K3.1 и Codex. Оба варианта их разочаровали. Конкретные причины в источнике не раскрыты, поэтому честная формулировка такая: несколько разработчиков попробовали и отказались, детали и критерии оценки остались за кадром.
Автор пошёл другим путём и выбрал локальные китайские модели с открытыми весами, Qwen 3.8 Flash Next и DeepSeek-V4.1-Flash-1017 (EXL3). Логика простая: веса лежат на вашем диске, и заблокировать к ним доступ извне нельзя.
Одна оговорка, важная для честности материала: железо для экспериментов выделил работодатель, компания, которая сдаёт DGX Spark в аренду. Автор сам оговаривает, что это личный опыт, а не реклама.
Железо и развёртывание: один Spark под Qwen, два под DeepSeek
Qwen 3.8 Flash Next работала на отдельном DGX Spark команды больше месяца до описываемого эксперимента. Модель развёрнута по рецепту Qwen3.8-Flash-Next-Single-DGX-Spark-TensorFold. Это ключевая деталь для оценки порога входа: одна машина, готовый рецепт, проверенная конфигурация.
DeepSeek-V4.1-Flash-1017 (EXL3) развернули по рецепту для кластера из двух Spark. На одной машине этот вариант не поднять: конфигурация рассчитана на две.
| Модель | Железо | Рецепт | Роль в процессе |
|---|---|---|---|
| Qwen 3.8 Flash Next | 1 × DGX Spark | Qwen3.8-Flash-Next-Single-DGX-Spark-TensorFold | Рабочая модель, инфраструктурные задачи, деплой |
| DeepSeek-V4.1-Flash-1017 (EXL3) | 2 × DGX Spark, кластер | Рецепт для кластера из двух Spark | Более сильное планирование, сложные задачи |
Рецепты развёртывания Qwen и DeepSeek
Готовые рецепты снимают часть боли: не нужно собирать конфигурацию с нуля и угадывать параметры запуска под конкретное железо. В случае Qwen это Qwen3.8-Flash-Next-Single-DGX-Spark-TensorFold, в случае DeepSeek - рецепт под кластер из двух Spark.
Содержимое рецептов в источнике не раскрыто, поэтому шаги запуска и параметры квантования здесь не описываются. Практический вывод ограничивается фактом: оба варианта разворачиваются по опубликованным рецептам, а не собираются вручную с нуля.
Автоматизация деплоя через Ansible силами самой локальной модели
Подготовку и деплой автор автоматизировал через Ansible. Разведку машин, сбор требований, написание плейбуков и их прогон выполняла Qwen 3.8 Flash Next, запущенная на соседнем Spark. На всё ушло примерно один рабочий день, DeepSeek запустился с первой попытки.
Этот эпизод полезнее любых синтетических тестов. Локальная MoE-модель на одной машине провела инвентаризацию окружения, собрала требования и написала рабочие плейбуки для второй машины. Инфраструктурные задачи такого масштаба ей по силам, причём без выхода в интернет и без оплаты за токены.
Со второго дня обе модели использовались в реальной работе, а не в демонстрационном режиме. Полный отчёт с деталями развёртывания и замерами опубликован на Habr.
Замеры TPS, TTFT p50 и prefill на контекстах 2K-128K
Автор прогнал замеры на контекстах 2K-128K и зафиксировал три метрики: TPS, TTFT p50 и скорость prefill. Числа приведены в исходной статье, в доступном пересказе их нет. Подставлять оценочные значения вместо реальных было бы обманом читателя, поэтому ниже объясняется, что эти метрики значат и как их читать применительно к работе.
Что значат TPS, TTFT p50 и prefill для разработчика
| Метрика | Что измеряет | На что влияет в работе |
|---|---|---|
| TPS | Токенов в секунду на генерации ответа | Как быстро появляется код целиком после того, как модель начала отвечать |
| TTFT p50 | Медианное время от запроса до первого токена | Отзывчивость ассистента: сколько ждать начала реакции |
| Prefill | Скорость обработки входного контекста, токенов в секунду | Сколько стоит прикреплённый файл, лог или длинная история переписки |
TPS отвечает за скорость печати ответа. Если генерация идёт медленно, задача на 500 строк кода превращается в долгое ожидание, но само ожидание предсказуемо и линейно.
TTFT p50 важнее для интерактивности. Медиана, а не среднее: одиночные выбросы не должны искажать картину, а разработчику нужно типичное время реакции. Когда первый токен приходит быстро, работа ощущается как диалог. Когда через десятки секунд, работа превращается в очередь заданий.
Prefill бьёт сильнее всего по длинному контексту. Каждый файл в промпте и каждая страница лога увеличивают объём входных токенов, которые модель обрабатывает до начала генерации. На коротком запросе prefill незаметен, на контексте 128K он становится главным слагаемым времени до первого токена.
Как читать графики на контекстах 2K-128K
Рамка интерпретации простая. Смотрите на TTFT p50 и скорость prefill при переходе от 2K к 128K и ищите точку, где ожидание начинает чувствоваться в цикле правок. Для агентной работы это критично: ассистент делает десятки вызовов за сессию, и задержка умножается на их число.
Второй ориентир - рост контекста по ходу задачи. В реальной сессии он накапливается: план, файлы, результаты ревью. Регрессия на длинном контексте означает, что к концу сессии модель отвечает медленнее, чем в начале, а привычная манера держать всю историю в промпте прощает всё меньше.
Что с этим делать на практике: резать контекст до нужного, разбивать задачу на короткие сессии, прикреплять конкретные файлы вместо всего проекта. Тонкости ускорения инференса MoE-моделей без изменения весов разобраны в материале об оптимизации локального инференса MoE в llama.cpp: часть патчей даёт прирост, часть приводит к регрессиям.
Рабочий процесс: двойное планирование, субагенты и параллельные worktree
Схема, к которой автор пришёл за неделю, состоит из четырёх элементов: двойное планирование двумя моделями, имплементация через субагентов, параллельные worktree и двухраундовое ревью. Детали в источнике раскрыты не полностью, поэтому ниже логика схемы, а не пошаговая инструкция.
Зачем планировать двумя моделями
Qwen и DeepSeek ошибаются по-разному. Двойное планирование ловит слабые места до того, как код написан: если обе модели пришли к похожему плану, риск ошибки ниже, если планы расходятся, есть что обсуждать до имплементации.
Субъективная оценка автора: DeepSeek примерно на 20% «умнее» Qwen. Это не бенчмарк и не результат воспроизводимого теста, а личное впечатление от недели работы. Qwen при этом остаётся рабочим вариантом для одного Spark, и разрыв в качестве не отменяет её пригодности.
Субагенты, worktree и двухраундовое ревью на практике
Общая последовательность выглядит так: план от двух моделей, имплементация субагентами в параллельных worktree, первый раунд ревью, правки, второй раунд ревью. Субагенты распараллеливают написание кода, worktree позволяют вести несколько веток одновременно без конфликтов, два раунда ревью нужны потому, что первый проход пропускает часть дефектов.
У схемы есть цена. Каждый лишний шаг добавляет вызовы модели, а каждый вызов на локальном железе стоит времени. Часть замедления в 3-4 раза объясняется скоростью самих моделей, часть - накладными расходами на планирование и двойное ревью.
Насколько такой процесс масштабируется на длинных задачах, показывает другой локальный кейс: 10 000 строк кода на Qwen3.8-Flash-Next за 8 часов на одной DGX Spark при контексте 262K и скорости порядка 35 токенов в секунду.
Цена замены: цикл разработки в 3-4 раза дольше
Главный вывод автора звучит без оптимизма: работать можно, но цикл разработки стал занимать значительно больше времени. Оценка роста - в 3-4 раза. Это и есть цена замены, и её стоит считать заранее.
Что вы получаете: приватность, отсутствие лимитов и блокировок
Данные не уходят провайдеру: код, логи и внутренние документы остаются в вашей сети. Лимитов на запросы нет, ни дневных, ни недельных, ни по числу токенов. Риск блокировки аккаунта исчезает как класс.
Для автора последний пункт не абстракция: три блокировки за восемь месяцев, и каждая означала потерю рабочего инструмента. Локальный стек снимает этот риск полностью, вместе с зависимостью от верификации и паспортных данных.
Чем платите: скорость, качество и сложность инфраструктуры
Минусы перечисляются прямо. Цикл разработки в 3-4 раза дольше. DeepSeek требует двух Spark, а не одной машины. Нужен деплой и его автоматизация: рецепты, Ansible, плейбуки. Качество планирования ниже, чем у Claude Code, и это чувствуется именно на сложных задачах, где ошибка в плане дороже медленной генерации.
Отдельная статья расходов - администрирование. Кластер из двух машин, рецепты развёртывания и плейбуки живут не сами по себе: обновления, конфигурация и диагностика требуют времени разработчика. В кейсе автора эту работу частично выполнила сама локальная модель, но проверить результат всё равно должен человек.
Денежную сторону в этом материале посчитать нельзя: цен на DGX Spark и на подписку в источнике нет. Качественный вывод такой: локальный стек покупает независимость временем разработчика, а не экономией. Почему локальный хостинг редко экономит деньги и что реально удерживает людей на своём железе, разобрано в статье о стоимости самостоятельного хостинга AI.
Qwen или DeepSeek: что выбрать под свою задачу
Выбор сводится к железу и сложности задач. Qwen 3.8 Flash Next проверена больше месяца в работе и на деплое через Ansible, DeepSeek-V4.1-Flash-1017 (EXL3) даёт более сильное планирование, но требует кластера.
Когда хватает Qwen на одном Spark
Один Spark и задачи уровня инфраструктуры, разведки окружения, рутинной имплементации. Подтверждение из кейса: Qwen провела разведку машин, собрала требования и написала плейбуки Ansible примерно за один рабочий день. Модель развёрнута по рецепту Qwen3.8-Flash-Next-Single-DGX-Spark-TensorFold и работает на одной машине.
Ограничение: 20% разрыва в «уме» никуда не денутся, и на сложном планировании это заметно. Если задача требует долгой многошаговой декомпозиции, одной Qwen может не хватить. Как выбирать между поколениями моделей на фиксированной видеопамяти, разобрано в материале о переходе на более крупные локальные LLM.
Когда нужен DeepSeek на двух Spark
Вторая машина есть, задачи сложные, качество плана важнее скорости ответа. Тогда DeepSeek-V4.1-Flash-1017 (EXL3) по рецепту для кластера из двух Spark даёт лучший результат на планировании. Запуск в кейсе прошёл с первой попытки, но подготовка кластера заняла около рабочего дня.
Главное ограничение: на одной машине этот вариант не развернуть. Если второго Spark нет, выбор автоматически сводится к Qwen.
Стоит ли вам уходить с Claude Code на локальные LLM
Решение зависит от того, что для вас дороже: время цикла разработки или независимость от внешнего сервиса. Готового вердикта для всех здесь нет, есть критерии.
Кому локальный стек подойдёт
- Вы зависите от облачного ассистента и уже сталкивались с блокировками или лимитами.
- Приватность кода и данных входит в требования, а не в пожелания.
- Есть доступ к DGX Spark или сопоставимому железу, хотя бы к одной машине.
- Вы готовы потратить рабочий день на деплой и потом поддерживать конфигурацию.
- Вам нормально работать в режиме «поставил задачу, вернулся через двадцать минут».
Кому лучше остаться в облаке
Если скорость цикла критична и каждый час на счету, локальный стек сейчас проигрывает: рост в 3-4 раза перекрывает выгоды от приватности. Если железа нет, вариант отпадает ещё до сравнения качества. Если задачи упираются в сложное планирование, разница с Claude Code будет ощутимой.
Знакомые автора пробовали Kimi K3.1 и Codex и разочаровались, но это не приговор облачным альтернативам: их опыт ограничен несколькими людьми и неизвестным набором задач. Проверять альтернативы на своих сценариях всё равно придётся самостоятельно.
Итог по существу вопроса: локальные Qwen и DeepSeek на DGX Spark работают как замена Claude Code. Qwen хватает на одной машине и на инфраструктурных задачах она себя оправдала. DeepSeek заметно сильнее в планировании, но требует кластера из двух Spark. Взамен вы получаете приватность, отсутствие лимитов и невозможность потерять доступ из-за блокировки, а платите ростом цикла разработки в 3-4 раза. Если такой обмен вам подходит, начинайте с одного Spark и рецепта Qwen3.8-Flash-Next-Single-DGX-Spark-TensorFold: это минимальная конфигурация, на которой уже можно работать.