DeepSeek без жёсткой привязки к API: как устроен локальный агент через браузер

Повод: пользовательский кейс, а не релиз DeepSeek

Материал на Хабре описывает AI Free как локальное open-source-приложение. Оно объединяет DeepSeek, Qwen и ChatGPT через браузерные или сессионные интеграции и поверх них строит общий агентный рантайм. В публикации заявлены desktop-интерфейс, CLI, локальная память, skills, code-agent workflows, browser tools, VS Code-интеграция и совместимые API. Это не официальный продукт DeepSeek и не внедрение у крупного заказчика, а авторский инженерный кейс уровня «как я собрал рабочий контур».

Фактическая ценность кейса в смене оптики. LLM, то есть большие языковые модели, здесь рассматриваются не как отдельные чат-боты, а как взаимозаменяемые провайдеры внутри локального инструмента. DeepSeek не единственный центр системы: оркестратор обращается к нему наряду с другими моделями. В такой архитектуре конкурируют уже не только модели, но и адаптеры, память, управление контекстом, политики доступа к файлам, ретраи, наблюдаемость и UX.

Нужно отделить факт от интерпретации. Факт: автор описал рабочий прототип AI Free и схему подключения нескольких провайдеров. Интерпретация GPT House: кейс важен не как «бесплатная замена API», а как демонстрация паттерна developer tools вокруг DeepSeek, где модель становится частью локального рабочего слоя.

Главная идея кейса не в том, чтобы заменить DeepSeek браузером или отменить официальный API. Разработчик строит локальный слой оркестрации, где DeepSeek становится одним из основных провайдеров, а пользователь получает общий интерфейс, память, skills, CLI, desktop-оболочку и интеграцию с редактором кода. Локально здесь работает не сама модель, а рантайм, состояние, сессии и логика управления инструментами.

Цитата в переводе

«Главная идея AI Free в итоге сформулировалась так: браузер не обязательно окно, в которое смотрит человек.»

Как работает браузерная оркестрация

В классическом варианте разработчик подключает модель через официальный API: получает ключ, отправляет запросы на документированный endpoint, обрабатывает ответы, лимиты, ошибки и биллинг. В браузерной схеме логика другая. Локальное приложение использует авторизованную веб-сессию пользователя и взаимодействует с механизмами, которые обычно обслуживают веб-чат: cookies, профиль браузера, сетевые запросы, потоковые ответы, иногда элементы интерфейса.

По описанию AI Free, DeepSeek-интеграция построена ближе к HTTP-клиенту. Автор говорит о challenge/proof-of-work, локальном WASM-солвере, отправке completion и чтении SSE-потока. SSE, или Server-Sent Events, это способ получать от сервера поток событий по одному HTTP-соединению. Для пользователя это выглядит как постепенное появление ответа модели. Для агента такой формат удобен тем, что результат можно обрабатывать ещё до завершения генерации.

У других провайдеров транспорт может быть устроен иначе: где-то оркестратор опирается на fetch внутри авторизованной страницы, где-то фактически управляет веб-интерфейсом. Поэтому «браузер вместо API» не один универсальный трюк, а набор адаптеров к разным веб-клиентам. Поверх них появляется общий агентный слой: он принимает задачу, выбирает модель или маршрут, подставляет контекст, вызывает инструменты, хранит состояние и возвращает результат в CLI, desktop-интерфейс или редактор.

Что здесь действительно локальное

Слово «локальный» в таких проектах легко понять неправильно. AI Free не превращает облачный DeepSeek в модель, которая работает на ноутбуке пользователя. Локально находится приложение-оркестратор: интерфейс, конфигурация, сессионные данные, память, skills, рабочие директории и логика взаимодействия с инструментами. Сами запросы к DeepSeek, Qwen или ChatGPT уходят к внешним сервисам, если используется их веб-интерфейс или API.

Это различие критично для безопасности и приватности. Локальный слой уменьшает зависимость от SaaS-агрегатора и позволяет пользователю контролировать рабочее пространство. Но он не отменяет передачу промптов, фрагментов кода или документов внешнему провайдеру. Если агент получает доступ к репозиторию, терминалу или локальным файлам, разработчику нужно заранее определить, что можно отправлять модели, какие команды разрешены и какие действия требуют ручного подтверждения.

Практическая польза локального рантайма в том, что он становится «операционной системой» для LLM-задач на машине разработчика. Пользователь может хранить контекст проекта, подключать несколько моделей, работать через один CLI, запускать code-agent workflows и менять провайдера без полной перестройки инструмента. Но вместе с этим возникают эксплуатационные вопросы: где лежат cookies и профили браузера, как они защищены, как разделить личные и рабочие аккаунты, как журналировать действия агента и как откатывать изменения.

Главный практический вывод простой: локальная оболочка не равна локальной модели. Она может быть удобной, расширяемой и контролируемой на уровне пользовательской машины, но всё равно оставаться зависимой от внешних сервисов. Для рабочих задач это нужно проговаривать заранее, особенно если через агента проходят закрытые фрагменты кода, конфигурации, документы или данные клиентов.

Официальная рамка DeepSeek: API остаётся базовым маршрутом

На стороне DeepSeek официальная рамка устроена иначе, чем в браузерном кейсе. В документации Models & Pricing указана V4-линейка и два основных имени моделей: deepseek-v4-flash и deepseek-v4-pro. Для них заявлены OpenAI-format base URL и Anthropic-format base URL, то есть совместимость с двумя привычными форматами API-доступа. DeepSeek сам снижает стоимость интеграции через официальные паттерны, и браузерная обвязка не остаётся единственным способом собрать агента.

По документации, обе V4-модели поддерживают thinking и non-thinking modes, контекст до 1M токенов, maximum output 384K, JSON Output, Tool Calls, а также beta-возможности Chat Prefix Completion и FIM Completion в non-thinking mode. Для агентных систем особенно важны Tool Calls и JSON Output: первый механизм позволяет модели структурированно запрашивать вызов инструментов, второй помогает получать машинно-обрабатываемый ответ, а не только свободный текст.

Цена DeepSeek API в документации разделена по cache hit, cache miss и output tokens. Для deepseek-v4-flash указаны $0.0028 за 1M input tokens при cache hit, $0.14 за 1M input tokens при cache miss и $0.28 за 1M output tokens. Для deepseek-v4-pro указаны $0.003625, $0.435 и $0.87 соответственно. Там же указан concurrency limit: 2500 для v4-flash и 500 для v4-pro. Эти числа важны как инженерные параметры: они влияют на стоимость, очереди задач и стратегию выбора модели.

Есть и миграционный риск. Документация предупреждает, что старые имена deepseek-chat и deepseek-reasoner должны быть выведены из обращения 24 июля 2026 года в 15:59 UTC; на переходном этапе они соответствуют non-thinking и thinking mode модели deepseek-v4-flash. Для авторов локальных клиентов это не мелочь. Адаптер может сломаться не из-за качества модели, а из-за устаревшей интеграционной схемы.

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

Цитата в переводе

«deepseek-chat и deepseek-reasoner будут выведены из обращения после 15:59 UTC 24 июля 2026 года.»

Почему DeepSeek удобно включать в мульти-модельный пайплайн

DeepSeek в AI Free интересен не изолированно, а как часть мульти-модельной архитектуры. В такой схеме разные LLM могут выполнять разные роли: одна быстрее отвечает на простые запросы, другая лучше подходит для рассуждения, третья удобнее в конкретном интерфейсе, четвёртая служит fallback при сбоях. Оркестратор становится диспетчером: выбирает маршрут, подготавливает контекст, нормализует ответы и скрывает от пользователя различия транспортов.

У DeepSeek есть несколько свойств, которые делают его удобным кандидатом для такого слоя. Первое: официальная совместимость API-форматов. Второе: присутствие моделей DeepSeek в open-weight-экосистеме, что видно по каталогу deepseek-ai на Hugging Face. Open-weight означает, что веса модели доступны для использования вне закрытого облачного сервиса на условиях соответствующей лицензии. Третье: фокус V4-линейки на длинном контексте и режимах thinking/non-thinking, что полезно в задачах анализа больших файлов, кодовых баз и документов.

Но демонстрация не равна доказательству production-готовности. AI Free показывает, что DeepSeek можно включить в общий workflow с другими моделями. Это не доказывает, что браузерная схема безопасна для корпоративного использования, стабильна при изменениях веб-интерфейса или всегда выгоднее официального API. Для таких выводов нужны отдельные нагрузочные тесты, аудит безопасности, юридическая проверка и эксплуатационная статистика.

Мульти-модельность становится полезной только тогда, когда оркестратор объясним. Команде нужно понимать, почему задача ушла в DeepSeek, когда включается Qwen, когда используется ChatGPT и что произойдёт при ошибке одного из маршрутов. Без такой логики система быстро превращается в набор адаптеров, который сложно отлаживать и почти невозможно надёжно поддерживать.

Бенчмарки DeepSeek V4: сильный сигнал с важной оговоркой

Внешние измерения помогают понять, почему DeepSeek остаётся заметным элементом агентных систем. Но их нельзя читать как гарантию качества конкретного локального workflow. Artificial Analysis в разборе V4 пишет, что DeepSeek вернулся в группу ведущих open-weights-моделей с V4 Pro и V4 Flash. В их сравнении V4 Pro получил 52 на Artificial Analysis Intelligence Index, а V4 Flash Max получил 47. В том же материале V4 Pro указан как #2 open weights reasoning model в соответствующем сравнении Artificial Analysis.

Эти результаты объясняют интерес разработчиков: линейка выглядит конкурентоспособной не только по заявлениям поставщика, но и во внешних тестах. Для агента это означает потенциально сильное рассуждение, работу с длинным контекстом и способность быть центральной моделью в сложных задачах. Однако бенчмарк оценивает модель, а не всю цепочку с браузером, cookies, файловыми инструментами, UI-автоматизацией и правами доступа.

Главная оговорка из того же источника: hallucination rate. Artificial Analysis фиксирует 94% для V4 Pro и 96% для V4 Flash в своём AA-Omniscience setup. Это не означает, что модель «всегда ошибается» в бытовом смысле: речь о конкретной методике тестирования. Но для агентных workflows сигнал серьёзный. Чем больше прав у агента, тем дороже обходится уверенная ошибка модели. Поэтому нужны human-in-the-loop, подтверждение опасных операций, sandbox, журнал вызовов инструментов, diff-before-write и тесты перед применением изменений.

Именно здесь начинается разница между демонстрацией и эксплуатацией. В демо агент может впечатляюще пройти несколько задач подряд. В рабочем контуре он должен выдерживать повторяемость, проверку фактов, тесты, контроль прав и понятное восстановление после ошибки. Поэтому сильный бенчмарк DeepSeek V4 стоит воспринимать как повод тестировать модель в своём сценарии, а не как разрешение сразу отдавать агенту широкие права.

Цитата в переводе

«DeepSeek возвращается в число ведущих open-weights-моделей с V4 Pro и V4 Flash.»

Скорость и стоимость зависят не только от модели

Для разработчика локального агента важны не только лидерборды, но и задержка первого токена, скорость генерации, цена и стабильность маршрута. Artificial Analysis на странице провайдеров для DeepSeek V4 Flash non-reasoning указывает для DeepSeek как провайдера 119.3 tokens/s, 1.18 s time to first token и $0.06 blended price per 1M tokens. Методика blended price использует соотношение 7:2:1 для cache hit, input и output tokens. Эти числа полезны как ориентир, но не заменяют тестов на конкретной задаче.

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

Поэтому «быстро в чате» не всегда означает «быстро в агенте». Агент может тратить время на сбор контекста, чтение файлов, вызов инструментов, повторные попытки, синхронизацию памяти и постобработку ответа. Если одна модель используется для планирования, другая для генерации кода, третья для проверки, пользователю важен не tokens/s одной модели, а время до полезного результата.

В практической оценке стоит измерять полный маршрут: от постановки задачи до применимого результата. Для code-agent workflows это может быть не только текст ответа, но и diff, прогон тестов, список изменённых файлов, объяснение риска и подтверждение перед записью. В таком сценарии модельная скорость остаётся важной, но не единственной метрикой.

Где браузерная схема ломается

Самая очевидная слабость браузерной оркестрации: зависимость от интерфейса и внутренних контрактов веб-сервиса. Если меняется DOM, логика авторизации, challenge, формат сетевого ответа или потоковая схема, локальный адаптер может потребовать срочного обновления. Для персонального инструмента это неприятность, для команды, которая завязала на такой агент рабочий процесс, это риск простоя.

Вторая проблема: неодинаковость провайдеров. DeepSeek в описанном кейсе подключается одним способом, Qwen и ChatGPT другими. Оркестратор вынужден поддерживать несколько типов транспорта и нормализовать их поведение. Ошибка может возникнуть не в модели и не в промпте, а в слое адаптера: истёкшая сессия, изменившийся selector, закрытая вкладка, нераспознанный SSE-chunk, повторная captcha или конфликт профилей.

Третья проблема: границы допустимого поведения. Поскольку речь не об официальной API-интеграции, нельзя автоматически считать, что любой способ автоматизации веб-сессии разрешён провайдером и устойчив с продуктовой точки зрения. В публичной статье можно обсуждать архитектуру, но нельзя подавать браузерную схему как юридически безопасный универсальный обход API. Для корпоративного использования требуется отдельная проверка правил конкретного сервиса и сценария.

Четвёртая проблема: безопасность локального рабочего пространства. Агент, который умеет читать файлы, запускать команды и менять код, должен рассматриваться как мощный автоматизированный пользователь. Ему нужны минимальные права, allow-list команд, запрет на опасные операции без подтверждения, изоляция секретов, журналирование и понятный режим отката.

У браузерной схемы есть и бытовые эксплуатационные риски. Сессия может истечь в самый неподходящий момент. Профиль браузера может оказаться связан с личным аккаунтом. Потоковый ответ может оборваться без корректной ошибки. Локальный клиент может сохранить лишние данные в логах. Всё это не делает подход бесполезным, но переводит разговор из плоскости «получилось подключить» в плоскость «можно ли это безопасно поддерживать».

Российский контекст: практический интерес без лишних обобщений

Российский контекст подтверждён прежде всего самим поводом: кейс опубликован на Хабре и адресован русскоязычной разработческой аудитории. Для неё тема локального агента вокруг DeepSeek практична. Команды и отдельные разработчики сравнивают несколько LLM-провайдеров, экспериментируют с IDE-ассистентами и пытаются понять, где проходит граница между удобным персональным инструментом и небезопасной автоматизацией рабочего контура.

В разрешённом наборе источников нет достаточной базы, чтобы уверенно приводить широкие российские рыночные цифры по внедрению ИИ-ассистентов, долям зарубежных моделей или облачных контуров. Поэтому корректнее не усиливать текст тезисами про «массовый переход» или «суверенную альтернативу». Надёжнее сказать так: AI Free это русскоязычный инженерный кейс, который показывает паттерн мульти-модельной оркестрации с участием DeepSeek.

Практическая ценность такого кейса в том, что он помогает разделить уровни зависимости. Можно зависеть от модели, от API, от веб-интерфейса, от облачной инфраструктуры, от локального клиента, от браузерного профиля и от навыков команды поддерживать всё это в рабочем состоянии. Локальный оркестратор уменьшает одну зависимость, но не уничтожает остальные. Для зрелой стратегии нужно честно нарисовать карту этих зависимостей, а не называть любую локальную оболочку «локальным ИИ».

Для русскоязычных разработчиков этот разбор полезен ещё и как язык обсуждения. Вместо лозунгов про замену API можно обсуждать конкретные уровни: модель, транспорт, сессию, память, инструменты, права, логи, fallback и стоимость. Такой разговор лучше подходит для командной инженерной практики, чем спор о том, какой чат-бот «лучше» в общем виде.

Что кейс говорит о развитии DeepSeek

Развитие DeepSeek видно не только по релизам моделей и ценам API, но и по тому, как разработчики встраивают его в реальные рабочие схемы. AI Free показывает важный сигнал: DeepSeek воспринимают как компонент инфраструктуры для разработки, а не только как чат-бот. Модель становится частью локального инструмента, где рядом есть память, skills, IDE, терминал и другие LLM.

Это сдвигает конкуренцию. Раньше пользователь выбирал «лучший чат». Теперь разработчик выбирает связку: модель, транспорт, стоимость, latency, tool calling, длинный контекст, безопасность, удобство логирования и возможность переключиться на fallback. DeepSeek выигрывает, если остаётся удобным в разных режимах доступа: через официальный API, через open-weight-экосистему и в составе сторонних developer tools. Но у каждого режима своя цена владения.

Авторская интерпретация GPT House: браузерные эксперименты не отменяют API, а показывают, какие функции официальному API нужно закрывать особенно хорошо. В этот список входят стабильные имена моделей, понятные лимиты, потоковая выдача, структурированный вывод и инструментальные вызовы. Кейс AI Free не доказывает, что браузерная оркестрация станет стандартом для всех. Он доказывает другое: у разработчиков есть потребность в локальном управляющем слое поверх нескольких моделей, и DeepSeek уже участвует в таких схемах.

Для DeepSeek это важная позиция. Модельная линейка конкурирует не только в тестах, но и в том, насколько легко её подключить к рабочему инструменту. Если API совместим с привычными форматами, если есть понятные режимы thinking/non-thinking, если доступны long context и tool calling, то вокруг модели проще строить агентные клиенты. Если при этом существует open-weight-присутствие, разработчики получают ещё один аргумент смотреть на DeepSeek как на часть инфраструктуры, а не только как на веб-чат.

Что это означает на практике

Практические выводы из кейса AI Free лучше формулировать не как инструкцию по обходу API, а как набор инженерных проверок. Браузерная оркестрация может быть удобной для эксперимента, персонального workflow и быстрой сборки прототипа. Но чем ближе сценарий к рабочему контуру, тем важнее документированный транспорт, контроль прав и наблюдаемость.

Если команда использует DeepSeek в агентной системе, ей нужно заранее решить, какой маршрут является основным, какой резервным и какие действия агент может выполнять без человека. Особенно это касается задач с файлами, кодом, терминалом и секретами. DeepSeek может быть сильной моделью внутри маршрута, но безопасность определяется всей цепочкой, а не только качеством генерации.

• Для production-интеграции с DeepSeek безопаснее начинать с официального API: он документирован, поддерживает совместимые форматы, имеет явные цены, лимиты и имена моделей.
• Если локальный агент использует веб-сессию, считайте её хрупким транспортом: закладывайте повторную авторизацию, сбои потока, изменение интерфейса и возможность переключения на другой маршрут.
• Не называйте такой подход «локальной моделью»: локальны оркестратор, память и состояние, но запросы к DeepSeek при веб- или API-доступе уходят внешнему провайдеру.
• Проверьте model names: старые deepseek-chat и deepseek-reasoner в документации DeepSeek привязаны к миграционному сроку 24 июля 2026 года 15:59 UTC.
• Для агента с доступом к файлам и командам обязательны allow-list, sandbox, журнал инструментов, diff-before-write и ручное подтверждение опасных действий.
• Мульти-модельность полезна только при управляемом выборе маршрута. Если система не объясняет, когда и почему использует DeepSeek, Qwen или ChatGPT, её сложно поддерживать.
• Бенчмарки DeepSeek V4 стоит читать вместе с оговорками: сильные показатели рассуждения не отменяют hallucination risk и необходимости проверки фактов человеком или тестами.

Вывод

Кейс AI Free важен тем, что показывает DeepSeek в реальной рабочей сборке, а не в изолированном окне чата. Разработчик использует браузер как транспортный и сессионный слой, а локальное приложение как оркестратор, который объединяет модели, память, skills и инструменты разработки.

Но правильный вывод из кейса не «API больше не нужен». Скорее наоборот: чем больше разработчики экспериментируют с браузерными маршрутами, тем отчётливее видно, какие качества официального API критичны для зрелых агентных систем. Это стабильность, структурированный вывод, tool calling, понятные лимиты, предсказуемая стоимость и миграционная дисциплина.

DeepSeek оказывается в центре этой темы не потому, что один закрывает все задачи, а потому, что встраивается в разные контуры: официальный API, open-weight-экосистему и сторонние локальные инструменты. Рациональный подход не выбирать идеологически между браузером и API, а строить архитектуру, где транспорт можно заменить, действия агента наблюдаемы, а риск ошибки ограничен до того, как она попадёт в рабочий проект.

Для GPT House главный редакционный вывод такой: развитие DeepSeek стоит оценивать не только по релизам и ценам, но и по тому, как модель входит в инструменты разработчиков. AI Free показывает именно этот слой. Он пока не снимает вопросы о стабильности, безопасности и правилах автоматизации веб-сессий, зато хорошо демонстрирует спрос на локальную оркестрацию поверх нескольких моделей.

Источники

• Хабр: Браузер вместо API: как я объединил DeepSeek, Qwen и ChatGPT в одного локального агента
• DeepSeek API Docs: Models & Pricing
• Artificial Analysis: DeepSeek is back among the leading open weights models with V4 Pro and V4 Flash
• DeepSeek API Docs: List Models
• Hugging Face: deepseek-ai models
• Artificial Analysis: DeepSeek V4 Flash non-reasoning
• Artificial Analysis: DeepSeek V4 Flash non-reasoning providers

Частые вопросы

AI Free запускает DeepSeek локально на компьютере?

Нет. По описанию кейса, локально работает приложение-оркестратор: интерфейс, память, сессии, skills и логика инструментов. Запросы к DeepSeek при веб- или API-доступе уходят внешнему провайдеру.

Браузерная оркестрация заменяет официальный API DeepSeek?

Нет. Она может быть гибким экспериментальным маршрутом, но официальный API остаётся более предсказуемой базой для production-интеграций: у него есть документированные модели, лимиты, цены и форматы доступа.

Какие модели DeepSeek указаны в документации V4?

В документации Models & Pricing указаны deepseek-v4-flash и deepseek-v4-pro. Для них заявлены thinking и non-thinking modes, контекст до 1M токенов, maximum output 384K, JSON Output и Tool Calls.

Почему старые имена deepseek-chat и deepseek-reasoner важны для локальных клиентов?

Документация DeepSeek предупреждает о выводе этих имён из обращения после 15:59 UTC 24 июля 2026 года. Если локальный клиент или адаптер жёстко завязан на старое имя модели, интеграция может потребовать срочного обновления.

Какие главные риски есть у агента через браузерную сессию?

Основные риски связаны с изменениями веб-интерфейса, истечением сессии, нестабильностью потоковых ответов, хранением cookies и профилей, а также с правами агента на чтение файлов, запуск команд и изменение кода.

Как читать бенчмарки DeepSeek V4 в контексте агентных систем?

Бенчмарки полезны как сигнал о возможностях модели, но они не проверяют всю агентную цепочку: браузер, cookies, инструменты, права доступа, логи и обработку ошибок. Поэтому нужны собственные тесты, human-in-the-loop и ограничения опасных действий.

Практический чек-лист

Памятка: как оценить локального агента с DeepSeek

PDF для downloads/checklist.pdf должен дублировать практический блок статьи в удобном для печати виде: что проверить перед использованием DeepSeek в локальном или браузерном агентном workflow.

Маршрут интеграции

• Определите основной маршрут: официальный API DeepSeek, браузерная сессия или гибридная схема.
• Проверьте, какие модели используются: deepseek-v4-flash, deepseek-v4-pro или старые имена deepseek-chat и deepseek-reasoner.
• Учтите миграционный срок для старых имён моделей: 24 июля 2026 года 15:59 UTC.
• Опишите fallback: что делает агент, если DeepSeek, браузерная сессия или другой провайдер недоступны.

Безопасность локального рабочего пространства

• Разделите личные и рабочие браузерные профили.
• Проверьте, где хранятся cookies, сессии и логи агента.
• Ограничьте доступ агента к файлам и директориям минимально необходимым набором.
• Включите allow-list команд и запретите опасные операции без подтверждения.
• Используйте sandbox для действий с кодом и файлами.

Наблюдаемость и контроль результата

• Ведите журнал вызовов инструментов и маршрутов между моделями.
• Показывайте diff-before-write перед изменением файлов.
• Запускайте тесты перед применением изменений в рабочем проекте.
• Добавьте human-in-the-loop для операций с высоким риском.
• Оценивайте не только tokens/s, но и время до полезного результата.

Оценка качества модели

• Сравнивайте бенчмарки DeepSeek V4 с собственными тестами на рабочих задачах.
• Учитывайте hallucination risk и проверяйте факты человеком или тестами.
• Не переносите выводы из чата напрямую на агентный workflow с файлами и командами.
• Фиксируйте, когда система выбирает DeepSeek, Qwen или ChatGPT, чтобы маршрут был объяснимым.