Яндекс-Алиса сломалась наглухо
Сегодня сутра происходят с Алисой интересные вещи. Сутра пишу в чат устройство "лампочка в зеленой комнате", устройство есть, на месте - я его так включал раньше через чат с компа. Алиса начинает рассуждать почему комната зеленая, наверное фитоламна а что сделать, включить и на сколько и ни хера не делает. Через 3 повтора начала мне что-то из поиска тащить, пришлось открывать приложение. Ладно - включил приложением.
Есть сценарий - сказать "проветри" - включить вытяжки на максимум. Говорю колонке "Алиса, проветри" А что проветрить а как? Говорю "сценарий проветри" отвечает мне какую-то дичь что можно сделать сценарии и т.д. Охереть - запустил через приложение.
Нужен будильник через час и пятнидцать минут - раньше работало, ну тут-то что может сломатьяс? Говорю Алиса, посставь будильник через час пятнадцать (время 10-40) отвечает что "поставила будильник на 11 часов 40 минут 15 минут. Что бл?
Говорю убери будильник поставь через полтора часа "поставила будильник на 11 часов 40 минут 39 минут. Охренительно! В общем варианты были еще с секундами - потом назвал время будильника вроде правильно поставила.
@Yandex, вы кого там набрали по объявлению? Тестируете хоть что-то? Я не уверен что это всё - чтото много сразу говна стало да так что Алису пользовать не возможно..
Это я не говорю что ни как нормальную поддержку датчиков некоторых не сделаете, говорит розетка и всё тут, а выключатель для вытяжки например назначить как вентиляция нельзя. Это что за сырой продукт ещё и ломающийся так резко?
Психиатрия нового поколения
Ленты в последнее время стали 🤮... Пора вводить новую классификацию ИИ-типичных расстройств личности ... Что-то типа маниакально-депрессивного синдрома создателя контента... или ИИ-типичное пассивно-агрессивное расстройство тоже подойдёт...
Как устроена архитектура ИИ-платформы: от загрузки данных до готового ответа нейросети
Генеративные нейросети прочно вошли в рабочие процессы многих компаний: их используют для создания текстов, анализа документов, написания кода, обработки изображений и решения более сложных задач вроде глубоких исследований или работы с большими объемами данных. Но за внешней простотой — закинул запрос, получил ответ — скрывается сложная техническая инфраструктура. Разберем, из чего она состоит и как устроен путь от нажатия кнопки «Отправить» до появления сгенерированного текста.
С чего всё начинается: входная точка и авторизация
Пользователь заходит на ИИ-платформу через веб-интерфейс или подключается через API. В случае с API, например, может использоваться стандартный OpenAI-совместимый формат, что позволяет разработчикам легко интегрировать нейросети в свои приложения без переписывания кода под каждого конкретного провайдера.
На этом этапе система проверяет API-ключ или учетную запись пользователя: есть ли доступ к запрашиваемой модели, активен ли аккаунт и достаточно ли средств на балансе, если речь идет о платежной модели. В случае с оплатой по токенам — а именно такой формат набирает популярность — списание происходит не за время работы сервера, а за фактически обработанный объем данных: входящие и исходящие токены.
Маршрутизация: куда отправляется запрос
После авторизации запрос попадает в балансировщик нагрузки. Это точка входа в инфраструктуру, которая распределяет входящие вызовы между доступными экземплярами моделей. Задача балансировщика — не допустить перегрузки одного сервера, если в тот же момент поступает много запросов, и обеспечить равномерное распределение нагрузки.
Если платформа использует несколько моделей, на этом этапе также происходит роутинг к нужному экземпляру: пользователь выбрал GPT 5.5 — запрос идет к нему, выбрал Qwen 3.7 Max или Claude Sonnet 5 — соответственно, на другой эндпоинт. Современные ИИ-платформы объединяют десятки моделей в едином интерфейсе, и пользователю не нужно знать, на каком сервере физически развернута каждая из них — это задача инфраструктуры.
Инференс-слой: где нейросеть думает
Самый ресурсоемкий этап — инференс, то есть процесс генерации ответа нейросетью. Именно здесь происходят все вычисления, которые требуют мощных GPU (графических процессоров) и много памяти для размещения MoE-моделей. Запрос в виде текста преобразуется в последовательность токенов — это числовые представления слов и частей слов, которые модель способна обрабатывать. Затем нейросеть, состоящая из миллионов или миллиардов параметров, вычисляет вероятности следующего токена, генерирует его, и процесс повторяется до тех пор, пока не будет сформирован полный ответ.
Это требует колоссальных вычислительных мощностей. Если модель развернута на выделенных GPU-серверах, клиент получает максимальную производительность и контроль. Но есть и другой путь — доступ к моделям через API без аренды собственных GPU. В этом случае пользователь арендует не железо, а вычислительную мощность по факту использования: модель работает в инфраструктуре провайдера, а клиент платит только за обработанные токены. Для бизнеса это означает отсутствие капитальных затрат на закупку и обслуживание GPU-серверов, а также экономию на инженерах, которые настраивают и поддерживают инференс.
Облачная или локальная LLM: что выбрать для своего проекта — читайте в блоге Рег.облака.
Работа с данными: контекст и долгосрочная память
Современные ИИ-платформы умеют работать не только с сиюминутным запросом, но и с большими контекстами — десятками и сотнями тысяч токенов. Это позволяет загружать в модель целые документы, инструкции или базы знаний и получать ответы на их основе.
Для этого в архитектуру добавляются дополнительные слои: системы управления контекстом, механизмы поиска по документам (RAG — Retrieval-Augmented Generation) и инструменты для обработки больших массивов данных. Когда пользователь загружает файл и задает вопрос по его содержанию, платформа сначала векторизует документ, затем находит релевантные фрагменты в базе знаний, и только потом передает их модели вместе с запросом. Это позволяет получать точные ответы без необходимости помещать весь документ в память нейросети, что технически нецелосообразно или недоступно из-за окна контекста, стоимости, задержки и качества.
Мультимодальность: текст, картинки, голос
Многие современные модели — мультимодальные. Это значит, что они способны обрабатывать не только текст, но и изображения, аудио и видео. В случае с мультимодальными запросами в архитектуре появляются дополнительные модули: кодировщики изображений, которые преобразуют картинку в числовое представление, которое затем передается в основную языковую модель.
С технической точки зрения мультимодальные запросы сложнее. Вес изображения может превышать вес текста, а его обработка требует отдельного этапа в пайплайне. Кроме того, нужно обеспечить совместимость разных типов данных в рамках одного запроса, чтобы модель одновременно понимала и текст, и картинку.
Мониторинг и управление ресурсами
На протяжении всего процесса — от поступления запроса до возврата ответа — система собирает метрики: время обработки, количество токенов, загрузку GPU. Это нужно как для контроля расходов (вспоминаем оплату по токенам), так и для обеспечения стабильности работы. Если какой-то узел перегружен, система может перенаправить запрос на другой сервер или, в случае внешней модели, переключить пользователя на альтернативный эндпоинт.
Пользователю при этом в личном кабинете доступна статистика использования: сколько токенов потрачено по каждой модели, какова динамика расходов, какие модели используются чаще. Это позволяет контролировать бюджет, если в компании несколько сотрудников или команд работают с нейросетями.
Что на выходе: от токенов к человекопонятному тексту
Когда модель завершает генерацию, система выполняет обратное преобразование: последовательность токенов превращается в обычный текст на естественном языке. Если запрос проходил через интерфейс с поддержкой форматирования (например, разметка Markdown или выделение кода), на финальном этапе добавляются стили и оформление.
В случае с API ответ возвращается в JSON-формате, содержащем не только сам текст, но и служебную информацию: количество использованных токенов, время обработки, идентификатор запроса. Это позволяет разработчикам интегрировать ответы нейросетей в свои приложения, логировать взаимодействие и анализировать расходы.
И всё это — без собственного GPU
Ранее, чтобы запустить нейросеть, компании покупали или арендовали отдельные мощные GPU-серверы, настраивали на них инференс, управляли очередями запросов и решали задачи масштабирования. Это требовало серьезных инвестиций и квалифицированных инженеров. Теперь ситуация меняется: на рынке появляются платформы, которые предоставляют доступ к десяткам моделей через единый API, а оплата идет не за железо, а за реально использованные токены.
Кстати, о платформах
В России такие решения тоже появляются. Например, Рег.облако недавно добавил возможность оплачивать по токенам доступ к своей ИИ-платформе. Пользователям доступны более 30 моделей — от GPT 5.5 и Claude Sonnet 5 до Gemini 3.1 Pro, Kimi K2.6 и Qwen 3.7 Max, закрывающие широкий спектр задач: от текстовой генерации до мультимодальных сценариев, глубоких исследований, работы с длинными контекстами и использования для подключения агентов. При этом для тех, кому критичен приватный контур или полный контроль над инфраструктурой, сохраняется возможность аренды выделенных GPU-серверов. Получается гибридный подход: платформа закрывает быстрые сценарии через API, а выделенные мощности — для задач, где важны безопасность и кастомизация.
Вместо итога
Архитектура современных ИИ-платформ — это сложный конвейер, в котором задействованы балансировка нагрузки, GPU-вычисления, работа с контекстом, мониторинг и системы управления данными. Но с точки зрения пользователя всё это скрыто за одним интерфейсом или API-запросом. Технологии движутся в сторону максимального упрощения доступа: не нужно разбираться в инференсе и управлять серверами — достаточно выбрать модель, отправить запрос и получить результат. А оплата по токенам превращает ИИ из капитальной инвестиции в операционные расходы, что особенно актуально для бизнеса, который только начинает внедрять нейросети в рутинные процессы.
Вышла новая модель Granite 4.2
Озвучено первое семейство плотных рассуждающих только с декодером моделей Granite 4.2 (https://huggingface.co/collections/ibm-granite/granite-42-la...) от IBM в размерах 3B, 8B и 30B под лицензией Apache 2.0 с контекстом до 512K токенов.
Мышление переключается между "мышлением", "без мышления" и режимом низких усилий (короткое рассуждение для простых задач). Вызовы инструментов нативно поддерживаются и совместимы с форматом OpenAI.
Архитектура трансформера только с декодером эксплуатирует GQA, RoPE (θ=10M), SwiGLU, RMSNorm и раздельные эмбеддинги, причём версии 3B, 8B и 30B имеют 40, 40 и 64 слоя соответственно.
Претрейнинг начался с нуля на токенах объёмом около 15T, следуя стратегии из 5 фаз, отталкиваясь от веб-данных к высококачественному миксу и удлинению контекста.
Обучение с учителем (SFT) обладало объёмом около 7.2 млн сэмплов (примерно 100B токенов) и состояло из 31.6% агентных данных (код, терминал, поиск) и 68.4% неагентных (инструкции, код, математика), где качество контролировали LLM-судьями (GPT-OSS, Gemma), удаляя галлюцинации, битые вызовы инструментов и дубликаты, а у 30B была вторая фаза SFT с упором на агентный код.
Многостадийное и мультисредовое обучение с подкреплением (RL) осуществлялось по алгоритму Async GRPO (без сети оценки, групповые преимущества) на инфраструктуре из NeMo-RL (тренинг) и NeMo-Gym (среды).
На фундаментальном (все модели) этапе RL использовали RLVR с проверяемыми наградами (математика, код, наука, инструкции) и бустеры с короткими прогонами для прокачки навыков (IF, GPQA, код). На агентном (только 8B и 30B) этапе RL применили SWE Agent для решения задач в реальных репозиториях с тестами (OpenHands), Terminal Agent для работы в живом терминале (Harbor и Terminus) и Search Agent для многопроходного поиска в вебе (награда от LLM-судьи). На финальном (все модели) этапе RL прибегли к RLHF для юстировки под предпочтения человека и безопасность (с штрафом за длину рассуждений).
Версия 3B подверглась только фундаментальному RL и RLHF, в отличие от версий 8B и 30B, прошедших полный цикл, включая агентные стадии (от SWE до Terminal и Search).
Инфраструктура основывается на железе кластера NVIDIA GB200 NVL72 и софте из контейнеров .sqsh, PyTorch и NeMo-RL.
В результате 30B лидирует с 57.0 на SWE-Bench Verified и 89.17 на AIME25. 8B силен в агентности за свой размер с 47.67 на SWE-Bench и 50.29 на BFCL. 3B хорош в базовых задачах с 78.33 на AIME25.












