Однако настоящий переломный момент наступил не от увеличения размера моделей, а от изменения архитектуры. И ключевым событием этого перехода стала публикация в 2017 году статьи «Attention Is All You Need», которая переопределила будущее не только NLP, но и всей области искусственного интеллекта.

На первый взгляд, это была очередная работа по машинному переводу, но на деле она заложила основу для самого масштабного прорыва в области искусственного интеллекта за последние десятилетия.

Авторы предложили новую архитектуру — трансформер, которая полностью отказывалась от рекуррентных и сверточных слоев, доминировавших до этого. Вместо них они внедрили три ключевых механизма:

• Механизм внимания (attention) — позволил модели динамически фокусироваться на наиболее релевантных частях входной последовательности, будь то слова в предложении или элементы в коде.
• Многоголовочное внимание — здесь используется несколько параллельных “голов”, которые как бы смотрят на текст с разных углов, чтобы уловить разные связи между словами и фразами. Это помогает модели лучше понимать контекст.
• Позиционное кодирование — для учета "места" каждого слова в тексте авторы предложили особый метод, основанный на синусоидальных и косинусоидальных функциях. Что позволяет модели «помнить» о расположении элементов, что важно для выделения общего "смысла".

Эти идеи не просто усилили возможности обучения — они сделали его масштабируемым. Вскоре стало ясно: трансформеры можно обучать не только на параллельных корпусах для перевода, но и на огромных объемах неразмеченного текста.

Так родилась парадигма трансферного обучения:

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

Именно этот подход стал мостом от простых языковых моделей к современным ИИ-агентам, способным не просто отвечать, а планировать, исследовать, проверять гипотезы и взаимодействовать с внешними инструментами — то, что сегодня называют системами глубокого исследования (Deep Research).

2018: год двух прорывов — GPT и BERT

Если архитектура трансформера задала новый технический стандарт, то GPT-1, представленный OpenAI в 2018 году, определил новую методологию обучения. В статье «Improving Language Understanding by Generative Pre-Training» команда показала, как можно эффективно использовать огромные массивы неразмеченного текста для подготовки универсальной языковой модели — без ручной аннотации миллионов примеров.

Основой GPT-1 стал decoder-only блок трансформера — упрощенная, но мощная архитектура, ориентированная на генерацию последовательностей. Но настоящим прорывом стала двухэтапная схема обучения:

• Предобучение (unsupervised pre-training) — модель обучается предсказывать следующее слово в тексте на основе контекста. Этот этап работает как “языковой тренажер”: нейросеть усваивает грамматику, факты, логические связи и даже элементы рассуждения — все это из «сырых» данных интернета.
• Дообучение (fine-tuning) — на втором этапе модель адаптируется под конкретную задачу: классификацию тональности, распознавание именованных сущностей, анализ намерений и т.д. При этом используется небольшой размеченный датасет, но благодаря качеству предобучения результат оказывается значительно лучше, чем у моделей, обученных только на размеченных наборах с нуля.

Хотя GPT-1 по современным меркам выглядит скромно (всего 117 млн параметров), он продемонстрировал ключевую идею: универсальная языковая модель, предобученная на общих данных, может быть эффективно дообучена под узкие задачи. Эта парадигма — transfer learning через масштабное предобучение — стала основой не только для всех последующих GPT, но и для большинства современных LLM, включая те, что сегодня используются в ИИ-агентах и системах глубокого исследования.

Практически одновременно Google представила BERT (Bidirectional Encoder Representations from Transformers), предложив альтернативную стратегию. В отличие от GPT, который обрабатывает текст слева направо, BERT анализирует каждое слово с учетом контекста и до, и после него. Это резко повысило точность понимания семантики, особенно в задачах, где значение слова зависит от окружения — например, в вопросно-ответных системах или извлечении фактов.

Обучение BERT тоже проходило в два этапа, но с инновационными методами:

1. Masked Language Modeling — техника обучения, при которой используется текст, в котором "затираются" (маскируется) часть слов. При этом задача модели - восстанавливать их.;
2. Next Sentence Prediction — вспомогательная задача обучения, при которой модель должна была определять связаны ли данные пары предложений или нет.

Эти задачи заставляли модель глубже понимать связи между словами и предложениями, а не просто улавливать поверхностные паттерны.

Так GPT заложил основу для генеративных, автономных моделей, а BERT — для понимающих, контекстно-точных систем. Вместе они сформировали парадигму transfer learning, которая сегодня лежит в основе всех современных LLM — от код-ассистентов до ИИ-агентов, способных проводить глубокие исследования.

2019–2020: уточнение, унификация и масштаб

Если 2018 год стал временем архитектурных прорывов, то следующие два года оказались временем глубокой оптимизации и методологической зрелости.

В 2019 году команда Facebook* (* признана в России экстремисткой организацией, ее деятельность запрещена) AI представила RoBERTa — не новую архитектуру, а переосмысление принципов обучения BERT. Авторы провели масштабный анализ гиперпараметров и пришли к важным выводам:
Динамическое маскирование слов (Dynamic Masking Language Modeling) дает лучшее обобщение, чем статическое:

• Задача Next Sentence Prediction, использованная в BERT, на самом деле вредит качеству и может быть отброшена;
• Обучение с большими по размеру батчами (до 8 тыс. примеров) и расширенным словарем BPE (метод токенизации Byte-Pair Encoding;100 тыс. subword-единиц) значительно повышает стабильность и точность модели.

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

Почти в то же время Google предложила радикально иную идею — унифицировать все NLP-задачи как «текст → текст». В рамках проекта T5 (Text-to-Text Transfer Transformer) любая операция — от перевода и суммаризации до классификации и генерации вопросов — формулировалась как преобразование входного текста в выходной. Это не только упростило сравнение моделей на бенчмарках, но и заложило основу для промпт-инжиниринга как дисциплины: если все — текст, то управление моделью сводится к искусству формулировки запроса.

Параллельно OpenAI продолжала развивать линейку GPT. От скромного GPT-1 (117 млн параметров) в 2018 году к GPT-2 (1.5 млрд) в 2019-м и GPT-3 (175 млрд) в 2020-м — рост был не просто количественным, а качественным.

Таким образом, развитие GPT стало ярким примером, как масштабирование и улучшение данных помогают искусственному интеллекту учиться лучше и справляться с все более сложными задачами.

Эти три направления — оптимизация обучения (RoBERTa), унификация интерфейса (T5) и масштабирование (GPT) — сформировали фундамент для следующего этапа: появления ИИ-агентов, которые не просто отвечают, а планируют, исследуют, проверяют гипотезы и взаимодействуют с внешними инструментами — то, что сегодня называют системами глубокого исследования.

От промптов к “очеловечиванию”: Few-Shot и RLFH

К 2020 году стало ясно: большие языковые модели вроде GPT-3 обладают удивительной способностью выполнять новые задачи без специального дообучения (изменения своих весов). Достаточно просто описать цель в текстовом запросе — и модель адаптируется на лету.

Этот подход получил название few-shot learning:

• При zero-shot — модель получает только описание задачи («Переведи на французский: “Hello”»);
• При one-shot — ей дают один пример («“Привет” → “Bonjour”. “Спасибо” → ?»);
• При few-shot — несколько демонстраций, после которых модель должна ответить по аналогии.

Такой метод устранил необходимость в дорогостоящем fine-tuning для каждой новой задачи и превратил LLM в универсальный инструмент, управляемый через естественный язык. Но вместе с гибкостью пришла новая проблема: модели стали слишком буквальными. Они могли генерировать правдоподобные, но ложные утверждения, повторять токсичный контент из обучающих данных или давать опасные советы — все это под видом нейтрального ответа.

Решение предложили в 2021 году. Команда OpenAI внедрила Reinforcement Learning from Human Feedback (RLHF)— метод, который позволил снизить риск появления нежелательных ответов, сохранив при этом качество работы системы.

Процесс RLHF состоит из трех этапов:

Supervised Fine-Tuning (SFT) — модель дообучают на парах «запрос → желаемый ответ», подготовленных людьми. После этого ожидаемое поведение закрепляется с помощью::

• Создание модели вознаграждения (Reward Model) — на основе множества сгенерированных ответов, ранжированных людьми по качеству, обучается отдельная сеть, которая предсказывает, насколько «хорош» тот или иной ответ.
• Обучение с подкреплением — основная модель оптимизируется так, чтобы максимизировать оценку от Reward Model.

В результате GPT-3 Instruct и последующие системы начали избегать вредоносного, токсичного или недостоверного контента — не потому что это «запретили», а потому что они научились понимать, чего люди действительно хотят.

Этот сдвиг — от умения к ответственности — стал критически важным шагом на пути к современным ИИ-агентам, которые сегодня не просто генерируют текст, а проводят исследования, проверяют факты и взаимодействуют с внешним миром, оставаясь в рамках этических и функциональных границ.

2022–2024: от ответа к рассуждению и управляемому диалогу

Если ранние LLM умели генерировать правдоподобный текст, то к 2022 году исследователи начали учить их мыслить шаг за шагом. Ключевым прорывом стала техника Chain-of-Thought (CoT): вместо того чтобы сразу выдавать ответ, модель получала примеры, где решение раскрывалось через последовательность логических промежуточных шагов — как будто человек вслух рассуждает над задачей.

Оказалось, что даже без изменения архитектуры или весов, простое добавление таких "мыслительных цепочек" в промпт резко повышает точность модели в сложных задачах — особенно в математике, логике и программировании. CoT стал мостом между генерацией и имитацией рассуждения.

В 2023 году эта идея развилась дальше — в метод Self-Refine (адаптивное итеративное уточнение). Теперь модель не просто дает ответ, а сама его оценивает и улучшает. Процесс выглядит так:

1. Генерируется черновой ответ;
2. Тот же LLM (или другая модель) анализирует его на соответствие цели, полноту, точность;
3. На основе этой обратной связи формируется улучшенная версия.
4. Цикл повторяется до достижения нужного качества — все это без обновления весов. Это превратило LLM из «одноразового генератора» в итеративного редактора, способного к самокоррекции.

Параллельно складывались и практические принципы эффективного взаимодействия с моделями. К 2023–2024 годам сформировались основные принципы управления:

Роль задает контекст: фраза «Ты — senior-разработчик на Python…» сразу направляет модель в нужную предметную область, исключая двусмысленность (например, термин «модель» теперь точно относится к ML, а не к авиамоделизму).

Формат вывода контролируется примером: достаточно показать желаемую структуру — JSON, markdown, таблицу — и модель будет следовать ей.

В совокупности это дало простую, но мощную формулу:

Роль + Контекст + Пример формата = Предсказуемый и качественный результат.

Эти подходы легли в основу современных ИИ-агентов: они не просто отвечают, а планируют, проверяют, уточняют и адаптируются — все благодаря эволюции самого способа общения с моделью.

От масштаба к разуму: MoE, reasoning и Deep Research

К 2023 году стало ясно: просто увеличивать число параметров — не самый эффективный путь. Настоящий прорыв пришел с архитектурой Mixture of Experts (MoE). Модель Mixtral 8x7B, представленная в декабре 2023 года, заменила традиционные полносвязные слои на разреженные блоки экспертов — небольшие подсети, каждая из которых специализируется на обработке определенных частей данных.

Ключевое нововведение — маршрутизатор (gate network), который для каждого токена выбирает только подходящих экспертов, активируя лишь необходимые вычисления. Это резко снижает потребление ресурсов и ускоряет инференс.

Подход оказался настолько успешным, что стал основой для следующего поколения гигантов:

• Grok-1 (314 млрд параметров, 2024),
• DeepSeek R1 (671 млрд, 2024),
• Llama 4 Behemoth (~2 трлн, 2025).

Но даже MoE не решал главную проблему: глубокое рассуждение. Классические LLM часто зависали на задачах, требующих многошагового планирования, математических выводов или проверки гипотез. В ответ на это в 2024 году появились reasoning LLM — модели, способные не просто генерировать текст, а мыслить по шагам.

Такие системы, как OpenAI o1 или DeepSeek, имитируют человеческий когнитивный процесс: они формулируют подзадачи, проверяют промежуточные результаты и корректируют стратегию — все это внутри одного запроса.

Эта парадигма достигла зрелости в 2025 году с появлением функции Deep Research. Теперь ИИ-ассистенты — от Claude (Anthropic) до Grok (xAI) и Perplexity — могут выполнять автономные исследования:

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

Это уже не просто ответ на вопрос — это исследовательский агент, работающий в реальном времени. Также подобные подходы сегодня лежат в основе платформ вроде OpenClaw, где пользователь получает не текст, а решение, построенное на глубоком анализе, контроле качества и взаимодействии с внешними инструментами.

Как обычный GPU-сервис становится основой для передовых ИИ-задач

Сегодня разработка и развертывание современных ИИ-систем — от reasoning-моделей до агентов с Deep Research — требует не просто вычислительной мощности, а предсказуемой, изолированной и масштабируемой инфраструктуры.

Именно это и обеспечивает immers.cloud.

Все GPU-серверы в облаке построены на процессорах Intel Xeon Scalable (2–5 поколений) с поддержкой AVX-51.2 и DL Boost, оснащены до 8 ТБ DDR5 ECC RAM и NVMe-хранилищем до 7,68 ТБ. Каждый GPU — от RTX 3080 до H200 141 ГБ — закреплен только за одним пользователем, без оверселлинга.

Это гарантирует 100% производительности даже при длительных нагрузках: обучении MoE-моделей, инференсе Llama 4 Behemoth или запуске ИИ-агентов через OpenClaw.

Благодаря посекундной тарификации, бесплатному трафику до 20 Гб/с и готовым образам с предустановленными стеками (vLLM, Docker, ComfyUI, Automatic1111, OpenClaw), вы можете:

• Развернуть приватный эндпоинт Qwen3-Coder-Next за несколько минут минут,
• Запустить агента для автоматизации кодинга в VS Code,
• Провести глубокое исследование через собственный LLM,
• Или обучить кастомную модель на 8×H200 — все это без единого часа, потраченного на настройку железа.

Таким образом, immers.cloud — это не просто аренда сервера с GPU. Это готовая платформа для экспериментов, разработки и production-развертывания самых сложных ИИ-систем — от генерации кода до автономного исследования.

Архитектура и масштаб

GLM-5 содержит 744 млрд параметров, из которых 40 млрд активны при генерации каждого токена — заметный рост по сравнению с GLM-4.7 (~32 млрд активных). Такой подход повышает вычислительные требования на инференсе, но дает ощутимый прирост в качестве рассуждений и кодогенерации.

Модель поддерживает контекст до 200K токенов на входе и 128K на выходе, благодаря применению технологии DeepSeek Sparse Attention (DSA), которая оптимизирует использование памяти при работе с длинными последовательностями.

Только текст

На текущем этапе GLM-5 остается text-only моделью, сфокусированной на задачах программирования, логического вывода и агентного взаимодействия. Vision-версия, вероятно, появится позже — как это происходило с предыдущими поколениями (например, GLM-4.5 → GLM-4.5V).

В то же время конкуренты, такие как Kimi K2.5 и MiniMax M2.5, уже выпускаются с мультимодальной поддержкой из коробки.

Результаты бенчмарков

GLM-5 демонстрирует выдающиеся результаты в открытых тестах:

• 77.8% на SWE-bench Verified — лучший показатель среди всех open-weight моделей;
• 56.2 на Terminal-Bench 2.0;
• 92.7% на AIME 2026 I.

В агентных сценариях (BrowseComp, HLE) модель уверенно опережает не только другие открытые решения, но и ряд проприетарных систем.

Обучение на китайском железе — и совместимость с NVIDIA

Интересная особенность: GLM-5 была полностью обучена на чипах Huawei Ascend. Это объясняет, почему исходные веса выпущены в формате BF16 — китайские ускорители не поддерживают FP8 на аппаратном уровне. Тем не менее, команда Zhipu предоставила и FP8-версию, специально конвертированную для запуска на оборудовании NVIDIA.

Как запустить GLM-5 в облаке?

Для полноценного инференса GLM-5 требуется сервер с мощными видеокартами. Веса модели в BF16 занимают около 1.5 ТБ, что не помещается даже на 8 GPU. Однако в FP8 (~755 ГБ) модель легко размещается на восьми видеокартах NVIDIA H200 (по 140 ГБ VRAM каждая), оставляя достаточно памяти под KV-кэш и служебные структуры.

Ожидаемая скорость генерации — 40–50 токенов в секунду на один запрос, что сопоставимо с DeepSeek-R1 671B на аналогичном железе.

При INT4-квантизации GLM-5 можно запустить уже на четырех H200, что делает ее доступной для более широкого круга исследователей и компаний.

Модель поддерживается в популярных фреймворках: vLLM и SGLang, что упрощает интеграцию в существующие pipeline’ы.

Почему стоит арендовать облачный сервер для GLM-5?

Локальная сборка машины с 8×H200 — дорогостоящая и длительная задача. Гораздо эффективнее воспользоваться возможностью аренды облачного сервера с готовой инфраструктурой.

В immers.cloud вы можете:

• Запустить виртуальный сервер с видеокартой H200 за считанные минуты;
• Выбрать конфигурацию с 4 или 8 GPU — в зависимости от бюджета и требований;
• Использовать предустановленные образы с CUDA, Docker и vLLM;
• Платить только за фактическое время использования (посекундная тарификация).

Подробнее о модели GLM-5 и рекомендуемые конфигурации для инференса смотрите в нашем каталоге нейросетевых моделей.

Модель построена по архитектуре MoE: из общего числа 80 миллиардов параметров активно задействовано около 3 миллиардов, что обеспечивает высокую эффективность использования ресурсов. В основе лежит гибрид линейной модели (Gated DeltaNet) и трансформера, ориентированный на агентные задачи. По результатам бенчмарка SWE-Bench точность генерации кода сопоставима с DeepSeek V3.2, а скорость инференса достигает порядка 60 токенов в секунду.

Модель успешно работает в AWQ-квантизации INT4 даже на трех видеокартах RTX 4090. Для запуска можно использовать публичный эндпоинт или локальное развертывание. При работе через vLLM требуется версия не ниже 0.15.0, так как именно с неё добавлена поддержка Qwen3-Coder-Next.

Подробная инструкция по развертыванию модели в облаке доступна по ссылке.

Особый интерес представляет интеграция модели в среду разработки. Наиболее удобные варианты — расширения для VS Code, совместимые с OpenAI-совместимыми API.

Например, Cline подключается за несколько шагов: после установки расширения достаточно указать URL эндпоинта и ключ доступа — дополнительная настройка не требуется.

Среди поддерживаемых API-провайдеров есть как OpenAI-совместимые эндпоинты, так и реализации в формате Anthropic Messages API — последний доступен в свежих версиях Ollama. Это расширяет гибкость интеграции модели в разные инструменты разработки.

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

На простых задачах, таких как реализация классических алгоритмов на Python, модель демонстрирует качество, сопоставимое с ведущими проприетарными решениями.

На практике ключевым этапом при создании даже схематичного прототипа реального приложения становится не столько генерация кода, сколько корректное планирование и адаптация к уточнениям в техническом задании. В этом Qwen3-Coder-Next проявляет себя уверенно: его объяснения логичны, детализированы и ориентированы на конкретные технические требования.

Дополнительное удобство — возможность просмотра diff между текущей версией кода и предлагаемыми изменениями, а также запрос пояснений к каждому изменению прямо в интерфейсе редактора.

Для работы с расширением Codex в VS Code сначала необходимо задать две переменные среды:

OPENAI_API_KEY — для аутентификации, 

OPENAI_BASE_URL — для указания адреса эндпоинта. 

После этого можно запускать редактор командой code.

Важный нюанс: Codex работает только с API в формате OpenAI Responses, а не с классическим Completions. Это ограничивает совместимость с некоторыми открытыми моделями и инфраструктурными решениями, так как Completions остаётся де-факто стандартом для большинства open-source LLM.Чтобы обойти это ограничение, модель Qwen3-Coder-Next можно запустить через Ollama — начиная с последних версий, она поддерживает Responses API. Процесс развёртывания при этом остаётся простым и не требует сложной настройки.

ollama pull qwen3-coder-next

Поскольку расширение Codex распознаёт только ограниченный набор имён моделей из экосистемы OpenAI — например, gpt-5.2-codex — для совместимости требуется переименовать Qwen3-Coder-Next на стороне сервера.Для этого создаётся файл Modelfile со следующим содержимым:

FROM qwen3-coder-next:latest

Затем в терминале выполняется команда:

ollama create gpt-5.2-codex -f Modelfile

После этого модель станет доступна под именем gpt-5.2-codex:latest, что можно проверить по адресу http://ollama-host:11434/api/tags. Этого достаточно для корректной работы расширения Codex в VS Code.

Расширение Codex ориентировано на более осторожное взаимодействие с файловой системой: по умолчанию оно запрашивает подтверждение на каждое изменение, если пользователь не разрешил полную автономию в настройках.

Это делает его подходящим для сред, где важен контроль над изменениями кода. Интерфейс напоминает ChatGPT, что может быть удобно для тех, кто привык к такому формату общения с ИИ.

Оба инструмента — Cline и Codex — предлагают схожий функционал, но с разной степенью интерактивности и стилем представления. Это даёт разработчикам гибкость в выборе подхода в зависимости от задачи и предпочтений команды.

На фоне роста числа решений для AI-ассистированной разработки становится очевидно: открытые модели достигли уровня качества, достаточного для профессионального использования.

Qwen3-Coder-Next демонстрирует, что локальное или приватное развёртывание может обеспечить производительность, сравнимую с ведущими проприетарными аналогами.

Главное преимущество такого подхода — возможность использовать ИИ в корпоративной среде без передачи кода и данных во внешние облака, что снижает риски утечки интеллектуальной собственности и соответствует требованиям безопасности многих software-компаний.

Почему это важно знать бизнесу сегодня? Потому что понимание эволюции ИИ помогает отделить хайп от реальных возможностей; и принимать взвешенные решения о том, какие модели разворачивать, как их масштабировать и где искать конкурентное преимущество. Давайте пройдемся по ключевым вехам пути от абстрактной идеи нейрона до архитектур, меняющих рынок прямо сейчас.

Зарождение: когда нейросеть была лишь метафорой (1943–1950)

Все началось не с кода, а с идеи. В 1943 году нейрофизиолог Уоррен МакКаллок и логик Уолтер Питтс предложили первую математическую модель нейрона — пороговый элемент, реагирующий на взвешенную сумму входов. Сеть из таких элементов еще не предполагала обучение: веса задавались вручную, адаптация отсутствовала. Но сама постановка задачи впервые формализовала смелую мысль:

«А что, если мозг — это вычислительная машина?»

Уже через шесть лет Дональд Хебб в книге «Организация поведения» сформулировал ключевой принцип обучения: связи между нейронами укрепляются при совместной активации. Это правило Хебба стало прообразом современного обучения без учителя — и вдохновило Марвина Минского на создание первой нейросетевой машины SNARC (1951) с 40 синапсами. А параллельные исследования Хьюбела и Визеля в зрительной коре заложили основу для будущих сверточных сетей: иерархия признаков, многоканальная обработка, обратные связи — все это было подсмотрено у природы.

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

От фантазии к первым разочарованиям (1950–1970)

1950 год: Алан Тьюринг публикует статью «Вычислительные машины и интеллект» и предлагает тест, ставший символом цели ИИ — обмануть человека в диалоге. Шесть лет спустя Дартмутский семинар официально провозглашает рождение искусственного интеллекта как науки. Оптимизм зашкаливал: казалось, машины скоро освоят язык, абстракции и самосовершенствование.

Но реальность оказалась жестче. Программы вроде General Problem Solver (1959) работали лишь в узких микромирах. Перцептрон Розенблатта (1960-е) вызвал ажиотаж, но быстро столкнулся с фундаментальными ограничениями: он не мог решать даже простые нелинейные задачи вроде XOR. Провал проектов машинного перевода и осознание масштаба проблемы привели к первой “зиме ИИ” — эпохе скепсиса и сокращения финансирования.

Зима, однако, не остановила науку — она заставила ее копать глубже. И в 1980-е годы из-подо льда начали проступать идеи, которые изменят все.

Фундамент современного ИИ: идеи, опередившие свое время (1970–2000)

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

Появились архитектуры, актуальные до сих пор:

• Сверточные сети (Ян ЛеКун, конец 1980-х) — вдохновлены зрительной корой, они обрабатывают изображения локальными фильтрами, игнорируя позицию объекта. Именно поэтому сеть одинаково хорошо узнает лицо и в центре кадра, и в углу группового фото;
• Автокодировщики (Хинтон, Румельхарт, 1986) — учатся сжимать данные без дополнительной информации об источнике, "без учителя", для выделения важных признаков, закладывая основу для современных методов представления;
• Рекуррентные сети и LSTM (Хохрайтер и Шмидхубер, 1997) — впервые позволили моделям помнить контекст в последовательностях, став прообразом языковых моделей.

Но прогресс замедлился: данных было мало, а вычислительной мощности — еще меньше. ИИ вновь ушел в тень до тех пор, пока не созрели три условия одновременно.

На рубеже веков созрела идеальная буря: экспоненциальный рост данных, дешевые GPU и новые методы обучения. ИИ был готов выйти из лабораторий в реальный мир.

Революция, которая изменила бизнес (2005–2017)

2005–2006 годы стали точкой невозврата. Группы Хинтона (Торонто) и Бенджио (Монреаль) научились эффективно обучать глубокие сети — и мир заговорил о Deep Learning. После этого параллельно начали развиваться направления:

• Фреймворки прошли путь от ручной работы с матрицами в MATLAB до PyTorch и TensorFlow — инструментов, где собрать сеть можно за час, а не за месяц;
• Наборы данных для обучения выросли с 10 МБ (MNIST) до терабайтов (ImageNet);
• Использование GPU привело к ускорению обучения в десятки раз, что сделало всю работу коммерчески оправданной.

Результат не заставил себя ждать:

• 2012: нейросети ворвались в распознавание речи (Microsoft, Google);
• 2014: VGG и Inception победили в ImageNet, а свертки 3×3 стали стандартом;
• 2015: ResNet с остаточными связями позволил строить сети в сотни слоев. До сих пор лежит в основе большинства систем компьютерного зрения;
• 2015: U-Net открыл эру точной сегментации изображений, позже став ключевым компонентом Stable Diffusion.

Бизнес впервые увидел ИИ не как научную диковинку, а как инструмент: распознавание лиц в соцсетях, автопилоты, анализ медицинских снимков — все это стало возможным благодаря архитектурам, рожденным в этот период.

Настоящий взрыв ждал нас впереди, когда архитектура, изначально созданная для перевода текста, вдруг оказалась универсальным ключом ко всем модальностям.

Эпоха трансформеров: когда ИИ стал мультимодальным (2017 — настоящее время)

2017 год. Исследователи Google Brain публикуют статью «Attention Is All You Need» и представляют архитектуру Transformer. Отказавшись от рекуррентности в пользу механизма внимания, она позволила обрабатывать последовательности параллельно, масштабироваться до миллиардов параметров и, самое главное, легко адаптироваться под любые задачи.

Последствия были взрывными:

• 2018–2024: генерация изображений по тексту (DALL·E, Stable Diffusion, Kandinsky, Flux);
• 2019–2025: взрыв популярности больших языковых моделей: от GPT и LLaMA до российских разработок;
• 2021–2025: мультимодальные модели (GPT-4 Vision, CLIP, LLaVA), которые понимают одновременно текст, изображения, видео и аудио.

Сегодня гонка сместилась с архитектур на масштаб: данные, параметры, вычислительные ресурсы. Компании выпускают целые линейки моделей: от легких версий для мобильных устройств до гигантов с сотнями миллиардов параметров. И здесь возникает практический вопрос бизнеса: как развернуть такую модель быстро, экономично и без головной боли с инфраструктурой?

Почему история ведет нас в облако

Каждый этап развития ИИ, от перцептрона до трансформера, требовал новых вычислительных мощностей. Сегодня обучение современной модели может стоить миллионы долларов и требовать сотен специализированных GPU. Но даже готовую модель непросто запустить: локальные серверы часто не справляются с нагрузкой, а закупка железа под разовые задачи экономически нецелесообразна.

Именно здесь облако становится стратегическим преимуществом. Аренда GPU-серверов позволяет:

• Мгновенно масштабироваться под задачу — от тестирования небольшой модели до запуска мультимодального инференса;
• Избежать капитальных затрат на оборудование, которое быстро устаревает;
• Фокусироваться на продукте, а не на настройке драйверов, кластеров и балансировщиков.

В immers.cloud мы создаем инфраструктуру, которая превращает сложность ИИ в простоту использования. Наши серверы с новейшими GPU (NVIDIA RTX 5090, H100 NVLink, H200 и другие) доступны за пару кликов без долгих согласований и предоплаты.

Хотите протестировать модель, вроде Kimi-K2-Thinking? Запустить свою LLM? Или собрать пайплайн для генерации контента на базе Stable Diffusion? Мы даем вам мощность — а вы воплощаете идеи.

История ИИ учит нас одному: прорывы случаются там, где технологии становятся доступными. Мы делаем следующий шаг этой истории — помогаем сделать нейросети вашим инструментом уже сегодня.

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

Многие AI-лаборатории — OpenAI, Google, IBM — уже имеют свои версии агентов глубокого поиска. Но мы также знаем и открытые реализации. Возьмём хотя бы Open Deep Research от LangChain — проект, который отлично демонстрирует архитектуру такого пайплайна. Как и любой качественный Deep Research-процесс, он включает три ключевые фазы: уточнение цели исследования, сбор информации и формирование итогового отчёта.

На практике это выглядит как мультиагентный сценарий: агент-супервайзер планирует задачи, а агенты-исполнители выполняют конкретные действия — например, вызывают внешние функции, запрашивают данные из баз или анализируют документы.

Основных проблем остаётся две:

— Скорость выполнения — чем больше шагов, тем дольше итоговый ответ;
— Доступ к качественным источникам — без надёжных данных даже самый умный агент выдаст «правдоподобную ерунду».

В этой статье мы хотим объяснить, что такое Deep Research-агенты, как они устроены и зачем они нужны.

immers.cloud — это облачный GPU-сервис, ориентированный на разработчиков, исследователей и команды, работающие с ресурсоёмкими ИИ-проектами. Его основная задача — снизить порог входа в эксперименты с крупными моделями и сложными вычислениями.

Вместо необходимости приобретать и обслуживать дорогостоящее оборудование, пользователи получают доступ к мощным GPU (включая H100, A100, 4090) по модели посекундной тарификации. Это позволяет быстро запускать прототипы, тестировать агентские системы, обучать модели и масштабировать вычисления по мере необходимости — без долгосрочных вложений и привязки к железу.

Скорость, архитектура и доступ к данным: техника за кадром

Скорость выполнения зависит от используемой LLM — именно поэтому для агентных систем сейчас активно разрабатываются модели с высокой пропускной способностью и упором на быстрый, точный reasoning. К таким разработкам относится недавний релиз первой модели нового поколения — Nemotron 3 от NVIDIA. Эта серия LLM была заявлена как вклад компании в развитие открытого агентного ИИ.

Производительность инференса повышена за счёт гибридной архитектуры: трансформер плюс Mamba. Преимущества Mamba в контексте пропускной способности и экономии памяти на KV-кэше хорошо известны — особенно при длинных последовательностях запросов, характерных для многошаговых исследований.

Однако гибридные архитектуры — не единственный путь к усилению агентных возможностей. Например, DeepSeek предлагает выгодную альтернативу благодаря реализации MLA-внимания (Multi-Head Latent Attention), которое обеспечивает высокопроизводительный инференс за счёт значительно меньших по сравнению с полным вниманием затрат на KV-кэш.

Далее возникает другая проблема: одна и та же реализация Deep Research может давать очень разные результаты — в зависимости от доступности и качества данных. Для веб-поиска существуют удобные инструменты, интегрируемые с ИИ-агентами, например Tavily. Однако далеко не все вопросы можно решить простым «погуглив».

Часто требуется доступ к закрытым или частным источникам — внутренним базам знаний, документации, корпоративным API. В таких случаях становится необходимым развёртывание Deep Research в приватном окружении. Мы в immers.cloud работаем с разными подходами к этой задаче: от облачных приватных эндпоинтов до локально или в облаке развёрнутых LLM-серверов.

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

Например, если доступ к LLM есть не только у вас — вы либо не даёте доступ вообще, либо строго его ограничиваете. Можно также реализовать модель согласия: запрашивать разрешение у владельца данных перед каждым обращением — что поддерживается протоколом MCP.

Наконец, необходимо совершенствовать поисковые способности открытых моделей. Крупные компании активно дообучают свои LLM, чтобы повысить эффективность в многошаговых поисковых сценариях — например, Gemini 3 Pro, на котором работает новый агент Deep Research.

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

Этот инструмент может быть полезен не только для закрытых систем, но и для улучшения открытых моделей, решаемых те же задачи. Его преимущество — в качественной ручной сборке примеров, категоризации данных по областям знаний и фокусе не просто на точности ответа, а на его полноте, структурированности и проверяемости.

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

Чтобы такие системы работали надёжно и автономно, нужно развитие по трём направлениям:

— Более эффективные и быстрые архитектуры моделей;
— Безопасный доступ к разнообразным источникам данных;
— Методы проверки и валидации результатов.

Именно эти факторы определяют, насколько ИИ-агент сможет заменить или дополнить человека в сложном исследовательском процессе.

Главная возможность современных нейронных сетей (а именно их я буду подразумевать под ИИ в этой статье, хотя это понятие существенно шире) — выполнять ту работу и решать те задачи, с которыми ранее мог справляться только человек. Эта особенность и стала отправной точкой автоматизации процессов с использованием ИИ.

Хочется отметить, что автоматизация бывает разная: от комплексов управления беспилотными автомобилями до чего-то очень простого, но от того не менее полезного в повседневном применении для конкретного пользователя — того, что позволяет автоматизировать наши рутинные задачи.

Сегодня мы часто слышим, что сложные математические расчёты, аналитика данных, построение отчётов, графиков, дашбордов, создание презентаций и так далее стали простыми задачами для ИИ. Но тут важно понимать, что речь, как правило, идёт об определённых программах — продуктах на базе нейросетей, а не о нейронных сетях как таковых. А вот чаты — та форма, которая известна, доступна и широко используется большинством пользователей, — хотя и достаточны для целого ряда практических задач, но не всегда способны удовлетворить их ожидания; отсюда нередко появляется скептическое отношение к способностям ИИ.

На связи блог immers.cloud. Наша цель — рассказывать о технологиях искусственного интеллекта и показывать, как наш облачный GPU-сервис помогает эффективно решать такие задачи.

Дело в том, чтобы предоставлять действительно сложную аналитику, ИИ, как правило, должен быть дополнительно обучен и встроен в сервис, который создают команды программистов, промпт-инженеров, экспертов предметной отрасли, дизайнеров и многие другие — например, «Нейроюрист» от Яндекса.

Таким образом, чат — это не волшебная кнопка, а довольно несовершенный инструмент, обращаться с которым нужно очень аккуратно. Проиллюстрирую сказанное на примере реального кейса.

Мой друг провёл анкетирование через Яндекс.Формы, опросил 170 человек и получил таблицу в Excel с ответами на вопросы. Далее он составил очень подробный промпт, в котором указал, какую аналитику нужно провести по этим данным, на что обратить особое внимание и как структурировать ответ. Этот промпт вместе с файлом таблицы он загрузил в Perplexity и уже на второй генерации получил идеальный отчёт с графиками, таблицами, выводами и рекомендациями — а главное, в виде готового Word-документа.

На радостях, что сделал работу за два дня всего за пять минут, он уже почти отправил этот документ руководителю, но решил ещё раз внимательнее его прочитать. И ужас: уже на первой странице, в графике распределения пола респондентов, он увидел, что их 140, а не 170, как в исходной таблице. Дальше — хуже: все числа в отчёте, а значит, и метрики, не соответствовали действительности. Повторные генерации не помогли — они только ухудшали отчёт.

С этой проблемой он обратился ко мне. Ситуацию мы исправили довольно просто: я скопировал первые пять строк из Excel-таблицы анкетирования в чат DeepSeek (да, если будете так делать — не обращайте внимания, что эти данные в интерфейсе чата будут выглядеть как откровенная ерунда; модель прекрасно поймёт, что это таблица, и получит необходимые сведения о её структуре), а затем попросил написать скрипт на Python для Google Colab, который запросит загрузку исходной таблицы, рассчитает требуемые статистики, распределит ответы на открытые вопросы по категориям и запишет результат в простой текстовый файл.

Потом мы загрузили этот файл в чат Perplexity, где ранее был сгенерирован визуально отличный, но совершенно неточный отчёт, и попросили модель исправить отчёт, опираясь строго на рассчитанные нами самостоятельно статистики. Результат был великолепным.

Не проси ответ — проси скрипт

Мораль этой истории такова: в некоторых ситуациях просить у модели в чате готовый результат — плохая идея (особенно если это просто текстовая модель, а в интерфейсе чата не реализована возможность вызова инструментов). Всё, что модель отвечает, нужно тщательно проверять.

Но попросить её написать код, который позволит получить промежуточный результат — и который потом можно будет использовать для аналогичных задач (например, получить статистику по другой анкете) — вот это уже хорошая история. Здесь как раз доступная всем форма чата оказывается достаточно эффективной: модель способна написать довольно сложную программу по вашему пожеланию. Это уже следующий шаг к автоматизации процессов, а сам подход называется AI pair programming или, в народе, «vibe coding».

Мне кажется, это сейчас одно из золотых правил: во многих случаях лучше попросить ИИ написать код, который решает задачу, чем просто попросить решить саму задачу.

И тут мы переходим к предметной части статьи. А что, если — и это вполне нормально — у пользователя нет навыков программирования? Как он будет запускать и использовать код, сгенерированный моделью? Мало кому из моих знакомых, кто не занимается программированием, хочется решать повседневные задачи, просматривая и копируя выводы из консоли IDE или Google Colab.

Интерфейс вместо консоли

Большинству пользователей — да и программистам, иногда тоже — нужен понятный и удобный интерфейс для использования кода в автоматизации простых рутинных задач. И тут на помощь приходят HTML, JS и CSS, которые позволяют создавать и запускать небольшие приложения прямо в браузере.

И да, это тоже код — и чаты на базе ИИ отлично справляются с его написанием.

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

Что я сделал? Я попросил нейросеть написать мне код браузерного приложения на HTML и JS, которое позволяло бы вставлять в исходное поле JSON, задавать ключи для поиска, сортировать найденные значения и отображать результат на экране в нужном формате. Получилось следующее:

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

Безусловно, это довольно специфический — отраслевой — пример и относительно простая задача. На текущем этапе автоматизации я этим уже не занимаюсь — эту работу выполняет программа, запускаемая по расписанию. Но на том предыдущем этапе это мини-приложение очень помогло мне ускорить процесс.

Вот другой пример:

Интерактивные презентации

Дочь попросила меня помочь сделать презентацию по биологии на тему простейших организмов. Я снова обратился к возможностям ИИ в создании браузерных мини-приложений. Модель сгенерировала код приложения, которое открывается в любом браузере — включая мобильные телефоны.

На экране симпатичная инфузория-туфелька хаотично движется и «поедает» бактерии. При нажатии на кнопку информации появляется изображение её внутреннего строения с интерактивными подписями-кнопками для всех органелл. При клике на каждую — всплывает окно с описанием.

Презентация имела успех у учеников: дети с удовольствием читали описания и при этом не забывали следить за происходящим на экране — соревновались, у кого инфузория «съела» больше еды и насколько подросла.

Ещё один пример — интерактивная презентация по информатике на тему форматов чисел, с которыми работают машины: как их правильно конвертировать и почему возникают ошибки в вычислениях.

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

Теперь перейдём к практике — и здесь нужно ответить на два вопроса: какую нейросеть выбрать для генерации кода и как правильно действовать.

Выбор модели: от чатов к агентам

Отвечая на первый вопрос, скажу, что идеальный вариант — это сервисы с ИИ-агентами, например Cursor и им подобные. Пожалуй, главное удобство таких сервисов — в механизме редактирования кода. При необходимости внесения исправлений не нужно писать: «исправь мне класс такой-то или функцию такую-то» (хотя и желательно), — можно просто сказать: «в моём приложении не работает вот это — сделай что-нибудь». Агент при этом изучает текущий код и точечно вносит изменения, не переписывая всё с нуля, как это часто делают модели при общении в чате.

Ещё один серьёзный плюс — система контроля версий (но это уже отдельная история). К сожалению, Cursor требует оплаты подписки. Хорошая новость в том, что существуют открытые и бесплатные модели, способные генерировать качественный исполняемый код, причём доступны они не только на платформе Hugging Face — в первую очередь ориентированной на разработчиков и инференс, — но и в уже упомянутых чатах. Но какая из них лучше?

Чтобы ответить на этот вопрос, я протестировал самые известные на рынке решения на задачах генерации, на мой взгляд, самых сложных браузерных мини-приложений — а именно игр. Программирование игр требует прописывания сложных условий и логики взаимодействия объектов, поэтому не случайно разработчики нейросетей демонстрируют возможность генерации игр в своих релизах — например, здесь или здесь. Если модель умеет хорошо создавать игры, она без труда справится с логикой вашего мини-приложения для автоматизации рутинных операций.

Мои оценки моделей основаны не на бенчмарках, а на практической пользовательской метрике: запускается ли игра и реализованы ли все её механики. Результат получился однозначным. Из протестированных — DeepSeek, Qwen, Kimi K2 и ряда других (включая ChatGPT и Gemini) — лучшими оказались серии моделей GLM 4.5, GLM 4.6 и GLM 4.7 от компании z.ai, доступные в чате chat.z.ai. Именно этим моделям удалось сгенерировать серию узнаваемых и горячо любимых классических игр. Примеры результатов я покажу ниже, а пока расскажу о процедуре.

Переходим по адресу chat.z.ai, в окне чата вводим простейший промпт:

Сгенерируй мне код браузерной версии классической игры pacman в одном файле. Используй html, js, css. Можешь использовать emoji. … Далее вы можете сразу описать какие-то особые пожелания

В ответе вы увидите примерно следующее:

При нажатии на объект №1 (артефакт генерации) справа откроется окно с превью игры в браузере. Далее переключаемся на вкладку №2 (отображение кода) и нажимаем кнопку «Копировать» (№3) — код игры скопируется в буфер обмена.

Затем создаём текстовый документ в обычном блокноте (подойдёт любой простой редактор), вставляем скопированный код и нажимаем Ctrl + S, чтобы сохранить файл.

Пока это просто текстовый файл, чтобы он запускался в браузере, необходимо изменить его расширение с .txt на .html. Для этого щёлкните правой кнопкой мыши по иконке файла, выберите «Переименовать» и подтвердите предупреждение об изменении расширения.

Далее запускаем игру двойным щелчком левой кнопкой мыши (ЛКМ) или нажатием клавиш Enter — и всё, смотрим, что получилось!

Если в игре что-то не работает или работает не так, как вам нужно, — возвращайтесь в чат с моделью и отправьте промпт, в котором опишите проблему и попросите её исправить.

Советы по эффективному генерации кода

Модель чаще всего сгенерирует код с нуля, хотя может создать и фрагмент для исправления. Если лень искать нужный участок или разбираться в структуре — просто попросите переписать код или создать новый артефакт (для модели это эквивалентно).

Еще раз повторюсь: переписывание кода с нуля — не лучший подход, но если у вас нет возможности использовать ИИ-агенты для редактирования, — придётся смириться. Либо научиться использовать агентов 😊 — правда, это потребует не только времени, но и определённых затрат.

Несколько практических советов:

• Чем подробнее вы опишете механику игры, управление и функции — тем лучше будет результат. Детализация помогает модели точнее понять задачу.
• Популярные игры, информация о механике которых есть в интернете, генерируются качественнее. То же справедливо и для мини-приложений: модель легко создаст калькулятор под любую специфическую задачу, потому что «знает», как он должен выглядеть и работать.
• Не бойтесь начинать новый диалог — более того, это строго рекомендуется. Да, модель теоретически помнит контекст, но с каждым запросом на исправление она вынуждена перечитывать весь диалог. Чем он длиннее — тем сложнее ей сохранять фокус. Ответы начинают деградировать вопреки ожиданиям. Не используйте один чат более чем для 5–7 корректировок (одна игра в среднем занимает около 1000 строк кода).
• Создайте новый диалог: скопируйте в него последнюю рабочую версию кода и изложите, что именно вас не устраивает в текущей реализации.
• Не пытайтесь исправить всё сразу. Вместо промпта с длинным списком багов — просите исправлять по одной проблеме за раз. Это повышает точность и снижает шанс ошибки.
• В какой-то момент захочется вносить правки самостоятельно. Начните с простого: цвет интерфейса, ширина игрового экрана, текстовые пояснения. Скорее всего, так и случится — ведь модель, умея решать сложные задачи, иногда путается в мелочах. Вы можете попросить её добавить комментарии к каждому блоку кода или указать, в какой строке реализуется та или иная механика.

Так вы сможете сами изменить количество врагов, координаты их появления или цвет стен — и постепенно приобщитесь к программированию. Для этого рекомендую открывать файл с игрой в редакторе, например, VS Code — мощном, бесплатном и удобном инструменте. Скачать его можно здесь.

Что получилось: игры, созданные ИИ

Далее стоит показать, что получилось у меня — и почему я отдал предпочтение моделям GLM. Ниже — небольшой список игр с кратким описанием их механик и скриншотами:

Pac-Man

Классическая аркадная видеоигра, разработанная японской компанией Namco и вышедшая в 1980 году. Колобок в лабиринте должен собирать точки-энерджайзеры, одновременно уворачиваясь от монстров-привидений.

Если Пак-Ман съест «арбуз» (power pellet), он получает возможность временно съесть привидение и заработать дополнительные очки.

• Количество строк кода: 692.
• Главная сложность: плавная анимация открывания и закрывания рта у колобка.

Donkey Kong

Компьютерная игра в жанре платформера, разработанная и выпущенная компанией Nintendo в 1981 году.

Наша версия немного упрощена: игрок управляет Прыгуном, который бегает и прыгает по платформам, собирает мешки с деньгами, а собрав все — получает право добраться до флага финиша на верхней платформе. При этом ему нужно уворачиваться от бананов, которые в него кидает Донки Конг.Дойдя до финиша, игрок переходит на следующий уровень, где меняется расположение платформ, а Донки Конг бросает бананы всё быстрее и точнее.

• Количество строк кода: 1 121.
• Главная сложность: плавная анимация ходьбы персонажа (для отрисовки использовались простые эмодзи).

Тетрис

Компьютерная игра, изобретённая и разработанная советским программистом Алексеем Пажитновым. Игра была выпущена в 1985 году; её механика, пожалуй, одна из самых узнаваемых в истории и практически не требует объяснений.

С учётом её популярности и культового статуса модели удалось сгенерировать очень аккуратную и полностью играбельную версию — с постепенным повышением сложности и корректной реализацией механики дропа.

• Количество строк кода: 818.
• Главная сложность: плавное и резкое опускание фигур («мягкий» и «жёсткий» дроп), требующее точной синхронизации с игровым циклом.

Звериный Dig Dug

Моя версия аркадной игры Dig Dug, разработанной и выпущенной компанией Namco в 1982 году в Японии.

В игре кролик пробирается по норам под землёй, собирая алмазы и морковки, одновременно уворачиваясь от змей. Он может копать туннели и уничтожать врагов, сбрасывая на них камни — за это начисляются дополнительные очки. Архитектура уровней генерируется случайным образом; сложность зависит от количества врагов и расположения алмазов.

• Количество строк кода: 932.
• Главная сложность: синхронизация плавности анимации всех движущихся объектов — особенно камней при падении на змей.

Asteroids

Аркадный шутер, выпущенный компанией Atari в 1979 году. Игрок управляет космическим кораблём, пролетающим сквозь пояс астероидов, по которому периодически перемещаются летающие тарелки. Цель игры — стрелять и уничтожать вражеские корабли (астероиды при этом не разрушаются), избегая столкновений со всеми объектами. С каждым новым уровнем увеличиваются скорость, количество астероидов и врагов.

Для отрисовки игровых объектов использовались изображения, сгенерированные в чате Qwen — к слову, он отлично справляется с генерацией изображений и коротких видео (но это уже тема для отдельного обсуждения).

• Количество строк кода: 673.
• Главная сложность: точная настройка точки вылета лазерного луча — она должна исходить строго из центра носа корабля, что потребовало тонкой привязки координат в JavaScript-анимации.

Морское приключение

Моя авторская задумка, вдохновлённая классическими аркадными играми.

Рыбка плавает по экрану, собирая хаотично движущиеся креветки. При этом ей нужно избегать акул, кальмаров и других хищных морских обитателей, которые на высоких уровнях начинают атаковать с разных сторон экрана. Периодически на дне появляются бонусы — дополнительные жизни, ускорение или защита. Чтобы получить их, игрок должен перехитрить крабов, ползающих по дну.

Игра простая по механике, но получилась очень красочной, динамичной и увлекательной. Все объекты, кроме пузырей, выполнены в виде эмодзи.

• Количество строк кода: 1 173.
• Главная сложность: создание красивых и плавно движущихся пузырей — обычный CSS-анимируемый круг не подошёл, пришлось экспериментировать с градиентами и прозрачностью для эффекта объёма.

От игр — к реальным задачам

Почему я начал с vibe coding мини-приложений для работы, а пришёл к играм? Ответ прост: технология и процесс генерации мини-приложений по представленному мной алгоритму — тот же самый, что и у игр, а зачастую даже проще. ИИ-модели, включая GLM, справляются с такими задачами быстрее и качественнее.

Приведу пример браузерного мини-приложения, которое я создал с помощью нейросети GLM. По работе мне нужно было тестировать открытые и проприетарные модели ИИ через API — в том числе те, которые развёртывала наша команда. Цель — быстро оценить не качество ответов по бенчмаркам (у них сейчас, похоже, совсем другая роль), а способность модели чувствовать системный промпт, корректно работать с параметрами вроде температуры, top-p и другими настройками генерации.

Не все Spaces на Hugging Face предоставляют такую возможность, а Playground от разных разработчиков позволяют экспериментировать только со своими моделями. Вдоволь насмотревшись на экран IDE, я решил использовать vibe coding и за один промпт собрал всё необходимое в одном HTML-файле — лёгкое, автономное приложение, которое решает эту задачу.

Далее — сам чат. Первоначально он создавался для визуализации диалога, но быстро оброс полезными возможностями: поддержкой загрузки документов и извлечением текста из них — чтобы модель могла работать с контекстом; экспортом чата в документ (да, именно в форме чата — красиво оформленным, что есть далеко не у всех современных ИИ-чатов); а также возможностью сохранять и загружать диалоги прямо в браузере, без привязки к серверам.

Это приложение оказалось приятнее и удобнее IDE — и, что самое главное, позволяло быстрее решать задачи, поставленные передо мной. Его основа была написана с нуля моделью GLM 4.5 по тому же сценарию и правилам, что и генерация игр.

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

А ведь именно этого так часто не хватает в обычном общении с ИИ: да-да, если вы три раза получили отличный ответ по хорошему промпту, ничто не гарантирует, что на четвёртый раз результат будет таким же. А вот код, однажды сгенерированный и проверенный, остаётся неизменным. Двигателем такого приложения становится программный код, который фактически отражает все ваши пожелания — а для его запуска достаточно любого интернет-браузера (доступ к Сети при этом вовсе не обязателен).

Поэтому всем рекомендую попробовать vibe coding браузерных приложений. А если не знаете, с чего начать — начните с игр. 😊

Технологии ИИ развиваются стремительно, но настоящая сила скрывается не в том, чтобы просто спрашивать, а в умении заставить ИИ работать на вас. Браузерные мини-приложения — это простой, доступный и мощный способ превратить идею в инструмент за считанные минуты. И неважно, вы программист или нет — главное, иметь задачу и желание её автоматизировать.

А мы в immers.cloud верим, что будущее — за такими подходами. За теми, кто не ждёт готовых решений, а создаёт свои. Наши облачные GPU-сервисы разработаны именно для таких задач: где нужно обучать модели, запускать тяжёлые вычисления или масштабировать ИИ-инструменты, созданные с помощью vibe coding.

Если вам интересно больше узнать о том, как облачные технологии помогают раскрывать потенциал искусственного интеллекта — подписывайтесь на наш блог. Здесь мы рассказываем не только о возможностях ИИ, но и о том, как сделать их своими — практично, быстро и без лишней сложности.