Контролируемые галлюцинации
1.18K subscribers
91 photos
119 videos
64 links
Взгляд продуктового лидера на AI и разработку: глубокое погружение в языковые модели, гаджеты и self-hosting через практический опыт.
Download Telegram
MoE vs. SSM: Два пути из «Тирании Квадрата» Трансформеров

Архитектура Трансформеров гениальна, но у нее есть врожденный порок. Фундаментальный изъян, который превратился в главный тормоз на пути к по-настоящему умному AI. Имя этому пороку — «Тирания Квадрата».

Технически это сложность O(n²): удвоение длины контекста в четыре раза увеличивает объем вычислений. На практике — это экономическая и инженерная стена, в которую мы уперлись на полном ходу. Мы научились строить гениальных спринтеров, но мир требует от нас марафонцев. Поиск замены Трансформеру — это не мода, а гонка на выживание, потому что масштабировать его «в лоб» — значит обанкротиться.

И из этой тирании наметилось два совершенно разных пути.

Первый путь — это философия «Разделяй и властвуй», воплощенная в архитектуре Mixture-of-Experts (MoE). Вместо того чтобы задействовать всю гигантскую нейросеть для обработки каждого токена, специальный «роутер» направляет его только к нескольким наиболее подходящим «экспертам» — небольшим, специализированным подсетям. Это позволяет масштабировать объем знаний модели до триллионов параметров, сохраняя стоимость вычислений на приемлемом уровне. Но у этого подхода есть свой демон: колоссальные требования к видеопамяти. Чтобы модель работала, в VRAM нужно загрузить всех экспертов, даже если для конкретной задачи нужны всего два из них.

Второй путь — это философия «Помнить всё», реализованная в моделях пространства состояний (State Space Models, SSM). Эта архитектура подражает нашему сознанию. Она не перебирает все прошлые события, а сжимает весь опыт в одно непрерывное «состояние», которое влияет на настоящее. SSM обрабатывают данные с линейной сложностью O(n), окончательно свергая «Тиранию Квадрата». Это открывает дорогу к работе с практически бесконечным контекстом — будь то анализ годового архива кода, аудиопоток или геном. Их слабое место? Это «новые дети на районе», и их экосистема пока не так зрела, как у Трансформеров.

Мы стоим на перекрестке. MoE масштабирует знания, создавая модель-энциклопедию. SSM масштабирует контекст, создавая модель с бесконечной памятью. Но правда в том, что будущее — не за выбором одного из них, а за их комбинацией. Эпоха, где одна монолитная архитектура решала все, закончилась. Наступает эра модульности, где AI-архитекторы будут, как из LEGO, собирать модели из разных блоков: небоскребов-MoE для знаний, сверхскоростных магистралей-SSM для памяти и уютных парков-Трансформеров для локальной точности. Старый императив «масштабируй» мертв. Новый — «комбинируй».

Хотите понять, какой путь выбрать для вашей задачи? В полной версии статьи здесь или на сайте я подробно разбираю конкретные модели вроде Llama 4, Jamba и Nemotron-H, привожу наглядную таблицу сравнения архитектур и, самое главное, даю свой «Компас архитектора» — четыре простых правила, которые помогут вам сделать правильный выбор уже сегодня.

Если зашел контент, не забывайте на него реагировать. Подписывайтесь на канал, делитесь статьей с друзьями и оставайтесь любопытными.
❤6👍5🔥4
Сначала был кремний: Почему архитектура чипов, а не код, определяет будущее AI

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

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

Все началось с «идеального брака» — союза архитектуры Трансформера и GPU от NVIDIA. Инженеры NVIDIA встроили в свои чипы Тензорные Ядра — узкоспециализированные конвейеры, заточенные под одну операцию: сверхбыстрое умножение матриц. И так совпало, что сердце Трансформера, механизм внимания, — это и есть одна гигантская последовательность матричных умножений. Это был идеальный ключ для идеального замка, который ускорил обучение моделей в разы и создал всю современную AI-индустрию.

Но любая монополия порождает боль — высокую стоимость, дефицит и неэффективность для простых задач. И эта боль породила восстание. Сегодня битва за будущее AI идет на трех новых фронтах.
Первый — это битва за задержку, где компания Groq со своим «языковым процессором» LPU предлагает не пиковую мощность, а предсказуемо низкую задержку для приложений реального времени.
Второй — битва за масштаб, где Cerebras создает гигантский чип размером с целую кремниевую пластину, чтобы устранить главное узкое место — обмен данными между тысячами GPU.
И третий, самый тихий фронт — битва за эффективность на периферийных устройствах, где маленькие и холодные чипы приносят AI прямо к источнику данных.

Эпоха универсального швейцарского ножа от NVIDIA подходит к концу. На смену ей приходит эпоха набора хирургических скальпелей. Мы, как разработчики, больше не можем игнорировать «геологию». Наш новый закон прост: подбирай чип под задачу, а не задачу под чип. Выбор между сверхнизкой задержкой Groq, масштабом Cerebras или энергоэффективностью Edge-чипа — это больше не техническая деталь, а фундаментальное решение, которое определяет экономику и архитектуру всего продукта.

В полной версии статьи мы погрузимся глубже: вас ждет детальный разбор лобовой атаки AMD на NVIDIA, анализ того, как Google, Amazon и Apple строят собственные кремниевые крепости для защиты своих бизнес-империй, и, самое главное, как большая геополитическая игра и санкции против Китая создают совершенно новый ландшафт open-source моделей, который влияет на каждого из нас. Все это — по ссылке здесь или на сайте.

Если зашел контент, не забывайте на него реагировать. Подписывайтесь на канал, делитесь статьей с друзьями и оставайтесь любопытными.
❤4🔥4👍2
API Парижа: точка входа «Пигаль»

Любой сложный проект начинается с анализа входных данных. В нашем случае это: 2 недели, 4 города, 3 страны и 6 перелетов. Жесткий SLA, в рамках которого нужно не просто перемещаться в пространстве, но и успеть потрогать траву. Моя жена называет это «невероятным путешествием».

Первый эндпоинт нашего трипа — Париж. Точнее, его специфический район Пигаль, куда мы задеплоились на 24 часа. Это важная деталь. Заходить в Париж через парадный вход у Лувра или Эйфелевой башни — это как знакомиться с продуктом по лендингу. Мы же решили сразу заглянуть в его API, и Пигаль для этого — идеальная точка входа. Шумная, не всегда стабильная, с сомнительной документацией, но абсолютно честная.

Первое, что ты получаешь в ответ на свой GET-запрос к этому району, — это не отполированный JSON с достопримечательностями. Это сырой, неструктурированный поток данных. Звуки сирен, смешивающиеся с аккордеоном. Запахи свежей выпечки из boulangerie, которые на следующем углу перебиваются запахом мокрого асфальта и мусорных баков. Неоновые вывески кабаре, работающие как бесконечный цикл while(true), отбрасывают глитчующие блики на фасады зданий XIX века. Это не баг, это фича. Исторический легаси-код, поверх которого на скорую руку набросали яркий, кричащий фронтенд.

Наблюдать за трафиком здесь — отдельное упражнение. Есть два основных потока. Первый — туристы. Они движутся по заранее прописанным скриптам: Мулен Руж -> фото -> сувенирная лавка -> поиск «где поесть недорого». Их user flow предсказуем до байта. Второй поток — местные. Они перемещаются по району как фоновые процессы в операционной системе: с максимальной эффективностью, игнорируя «туристический» UI и используя только им известные шорткаты через дворы и переулки. Два разных уровня доступа к одной и той же системе.

Конечно, в работе этой системы хватает и необработанных исключений. Многие пишут про «разочаровывающий Париж», указывая на мусор или толпы. С моей точки зрения, это не столько недостатки, сколько артефакты рендеринга. Город — это живой, постоянно меняющийся организм, а не статичная картинка. И когда система работает под такой высокой нагрузкой 24/7, появление подобных артефактов неизбежно. Это технический долг, накопленный веками.

Наши 24 часа истекли. Обязательный протокол «открытия шенгена» (читай: handshake с пограничным сервером) выполнен успешно. Соединение установлено, первые пакеты данных получены и поставлены в очередь на обработку. Система показала себя работоспособной, хоть и со своими особенностями.

Сейчас мы уже в аэропорту, готовимся к подключению к следующему модулю нашей системы — Барселоне. Посмотрим, какой у неё API.

Пишите в комменты, какой город помог вам ‘перезагрузиться’.
❤8🔥6👍3