Когда я впервые столкнулся с необходимостью использовать большие языковые модели в рабочих задачах, передо мной стоял не только вопрос качества ответов. Гораздо важнее оказались три вещи: куда уходят мои данные, сколько я готов платить за инфраструктуру и насколько гибкой должна быть настройка под конкретные сценарии. Именно эти соображения привели меня к тому, чтобы внимательно изучить возможности DeepSeek — китайской компании, которая с 2025 года открыто публикует веса своих моделей. Для меня как для разработчика это означало принципиально иной уровень контроля по сравнению с обычными облачными API.
Сразу скажу: я не преследовал цель просто «попробовать нейросеть». Мне нужен был инструмент, который можно встроить в продуктовый контур, не опасаясь, что чувствительная информация утечёт наружу. Кроме того, хотелось избавиться от жёстких ограничений на количество запросов и получить возможность при необходимости дообучать модель под собственные нужды. Всё это заставило меня разобраться в том, какие варианты развёртывания существуют и чем они отличаются друг от друга.
На этом изображении как раз отражена суть подхода DeepSeek: открытые веса позволяют развернуть модель в собственном окружении, не полагаясь на внешний сервис. Для меня это стало отправной точкой в выборе стратегии.
Почему открытые веса решают больше, чем кажется
Первое, что я осознал, — публикация полных весов, а не только доступа через API, кардинально меняет правила игры. Компания разрешает коммерческое использование моделей по лицензии MIT, то есть без каких-либо отчислений. Для бизнеса это означает предсказуемость расходов и отсутствие юридических рисков, связанных с использованием проприетарных решений. Когда я увидел, что DeepSeek-R1 вышла ещё в январе 2025 года как открытая рассуждающая модель, которая демонстрирует цепочку размышлений перед финальным ответом, стало понятно: это не игрушка, а серьёзный инструмент.
Дальше — больше. Появилась линейка V3.x, а в 2026 году компания представила архитектурно новое семейство V4. Я следил за этим развитием с особым интересом: превью вышло 24 апреля 2026 года, затем 31 июля появилась V4-Flash с открытыми весами, а 12–13 августа — V4-Pro. Наконец, 10 сентября была выпущена V4.1-Flash с поддержкой мультимодальности, но пока только через API. Такая скорость обновлений говорила о том, что экосистема активно развивается, и мне нужно было выбрать момент для внедрения.
Для меня как для разработчика у DeepSeek есть три ключевые особенности. Во-первых, открытые веса — это возможность полного аудита и контроля. Во-вторых, архитектура Mixture-of-Experts, при которой на каждом шаге вычислений работает только часть модели, что заметно снижает стоимость инференса. В-третьих, переключение между режимами с рассуждением и без — это гибкость, которой мне не хватало в других решениях. Именно сочетание этих факторов заставило меня углубиться в тему развёртывания.
Какие модели вообще можно запустить у себя
Когда я начал изучать доступные варианты, оказалось, что выбор не так прост, как хотелось бы. Всё зависит от того, какими вычислительными ресурсами я располагаю. DeepSeek-V4-Pro — это флагман на 1,6 триллиона параметров всего и 49 миллиардов активных. Веса занимают около 960 ГБ, что требует узла из восьми топовых GPU. Для большинства команд, включая мою на начальном этапе, такая конфигурация доступна только через API. Это дорого и избыточно для пилотных задач.
Более реалистичным вариантом оказалась DeepSeek-V4-Flash — 284 миллиарда параметров всего и 13 миллиардов активных. В зависимости от формата веса занимают от 130 до 290 ГБ, и здесь уже нужен сервер с несколькими GPU. Я понимал, что для продакшена это рабочий вариант, но для экспериментов всё ещё тяжеловато. Тогда я обратил внимание на дистиллированные модели — DeepSeek-R1-Distill на базе Qwen и Llama размером от 1,5 до 70 миллиардов параметров. Они обучены повторять ответы R1, но при этом занимают от 1 до 40 ГБ в 4-битном формате. Такие модели запускаются даже на обычном ПК или ноутбуке, и именно с них я решил начать.
Отдельно хочу подчеркнуть важный момент, который часто становится причиной ошибок. Обе модели V4 поддерживают контекст до 1 миллиона токенов, и цифра «13 миллиардов активных параметров» вводит многих в заблуждение. На каждом шаге действительно работает только часть экспертов, но в видеопамяти должны лежать веса всех, потому что роутер может выбрать любого из них на следующем шаге. Вывод «13B активных, значит, хватит видеокарты на 24 ГБ» неверен — нужна память под все 284B. Я сам едва не попал в эту ловушку, пока не разобрался в деталях архитектуры.
Ещё одно распространённое заблуждение касается Distill-моделей. Например, deepseek-r1:7b в Ollama не равна DeepSeek из веб-чата по качеству. Это компактная копия на базе другой модели, а не урезанная версия оригинала. Понимание этого факта сэкономило мне массу времени и уберегло от завышенных ожиданий на старте.
Сколько видеопамяти реально нужно
Когда я перешёл к практическому планированию, пришлось детально разобраться с требованиями к железу. Для ноутбука или ПК без мощной GPU с 8–16 ГБ памяти подходят только дистиллированные модели размером от 1,5 до 8 миллиардов параметров в 4-битном формате, и работают они медленно. Для быстрого прототипирования этого достаточно, но о комфортной работе речи не идёт. В качестве инструментов я использовал Ollama и LM Studio.
Если в распоряжении есть GPU на 24 ГБ, например L4, A30 или RTX 4090, можно запускать Distill-модели на 14–32 миллиарда параметров в 4-битном виде. Это уже более серьёзный уровень, позволяющий решать реальные задачи. С GPU на 48–80 ГБ, такими как L40S или A100 80GB, становятся доступны Distill-модели на 32 миллиарда в FP16 или 70 миллиардов в 4-битном формате, и здесь уже стоит использовать vLLM для эффективного инференса.
Для V4-Flash в квантизованных форматах требуется несколько GPU по 80 ГБ и больше. А полноценный узел из 8 GPU H200 или B200 необходим для V4-Flash в полном формате и V4-Pro. Когда я всё это осознал, стало очевидно, что расход памяти складывается не только из весов модели. KV-кэш растёт вместе с длиной контекста, и при диалоге на миллион токенов он может в разы превышать объём самих весов. Плюс нужен служебный запас. Важна и архитектура GPU: нативный формат V4-Flash (FP4+FP8) рассчитан на Blackwell, на Hopper применяют FP8-сборку около 284 ГБ, а на Ampere поддержка FP8 ограничена, поэтому там используют квантизованные сборки. Это тонкий момент, который я бы рекомендовал проверить заранее.
Мой путь: от локального запуска к облачному развёртыванию
Для первого знакомства с дистиллированной моделью я выбрал Ollama. Установка с официального сайта заняла буквально несколько минут. Затем я выбрал модель по объёму видеопамяти и запустил её командой ollama run deepseek-r1:8b, предварительно сверив актуальный тег в библиотеке на дату запуска. Ollama автоматически подняла локальный OpenAI-совместимый эндпоинт, а проверить, что модель действительно работает на GPU, помогли команды nvidia-smi и ollama ps. Для тех, кому неудобен терминал, я бы порекомендовал LM Studio с графическим интерфейсом — там всё делается буквально парой кликов.
Однако довольно быстро я понял, что дистиллированной модели не хватает для продакшен-нагрузки с параллельными запросами. Тогда я перешёл к развёртыванию на сервере с GPU. Distill-модели умещаются на одной видеокарте, но V4-Flash требует многопроцессорной конфигурации, и формат весов под конкретные GPU нужно проверять заранее. Порядок действий оказался таким: создать виртуальную машину с GPU, проверить драйвер, скачать веса с Hugging Face из официального репозитория deepseek-ai, запустить vLLM с OpenAI-совместимым API и проверить сервис запросом к эндпоинту. Ключевые параметры vLLM, которые я настраивал, — число GPU для деления модели, ограничение длины контекста и доля видеопамяти, которую можно занять.
Особое внимание я уделил безопасности. Порт API после запуска нужно обязательно закрыть правилами группы безопасности: доступ только из своей сети или через балансировщик с авторизацией. Открытый в интернет порт инференса — частая причина утечки данных и вычислительных ресурсов, и мне не хотелось пополнить эту статистику. Для продакшен-нагрузки с автоматическим масштабированием модель разворачивают на GPU-узлах в Managed Kubernetes: под с контейнером vLLM запрашивает ресурс GPU, а кластер масштабирует число подов под нагрузку. В качестве альтернативы vLLM я рассматривал SGLang, но остановился на более привычном для меня варианте.
Что выбрать в итоге: три сценария для разных задач
Проанализировав свой опыт, я выделил три основных сценария. Локально на ПК — это быстрый тест, когда данные не должны покидать компьютер разработчика; здесь доступны только Distill-модели, но для проверки гипотез этого достаточно. Своя инсталляция в облаке на GPU — это продакшен-нагрузка, масштабирование и полный контроль над данными; доступен весь модельный ряд при достаточном числе GPU, а обновлять модель я могу самостоятельно. Наконец, API DeepSeek — это скорость старта и доступ к самым сильным версиям, включая V4-Pro, без забот об инфраструктуре. Но каждый запрос уходит на серверы провайдера в Китае, и этот факт нужно учесть до того, как через API пройдут чувствительные данные.
Я также не могу не упомянуть ограничения, с которыми столкнулся. GPU стоят денег даже при простое, поэтому облачную инсталляцию нужно планировать с учётом реальной нагрузки. Модели DeepSeek обновляются каждые 1–2 месяца, и за этим нужно следить. Дистиллированные версии заметно уступают флагманским, поэтому для ответственных задач их использовать не стоит. А длинный контекст резко увеличивает расход видеопамяти, что может стать неприятным сюрпризом при работе с большими документами.
Если подвести краткий итог: для быстрого теста на своём ПК я рекомендую ставить Ollama и дистиллированную модель подходящего размера. Для продакшен-нагрузки и контроля над данными — разворачивать DeepSeek на GPU в облаке через vLLM, начиная с одной видеокарты и масштабируясь по мере роста нагрузки. А если важнее скорость старта без забот об инфраструктуре — использовать API, помня, что запросы уходят внешнему провайдеру. Мой собственный путь прошёл через все три этапа, и каждый из них дал мне ценный опыт, которым я и поделился.
Данные, на которые я опирался, актуальны на 2 октября 2026 года.