Николай Тузов

Ozon Tech запускает Route 256 Pro для опытных Go-разработчиков. https://route256.ozon.ru/go 🟢Ребята из Ozon Tech начинают новый набор на свой курс Route 256 Pro, и просили вам передать: Это бесплатный 2-месячный интенсив на реальных проектах для тех, кто готов усилить свои навыки разработки. В программе — высоконагруженные сервисы на Go, стек и инструменты разработки Ozon Tech, проектирование и управление микросервисными системами. Участие в Route 256 Pro — это шанс прокачать сразу всё: от написания кода до архитектурного мышления в масштабах бигтеха. Это сильный нетворк с контактами в закрытом комьюнити экспертов, к которым прислушивается индустрия. Это достойное портфолио с мощным проектом в известном продукте. Если интересно узнать, как всё устроено в маркетплейсе, которыми пользуются миллионы людей, подавайте заявку ———— От себя могу добавить, что Route 256 — очень крутая инициатива, давно за ней слежу. Ребята из Озона бесплатно обучают специалистов, основная мотивация — взять вас к себе в команду. А значит и учить будут как своих ☀️ Попробовать точно стоит. #партнерский_пост

☀️ Мой путь в IT — статья https://tuzov.dev//posts/my-way-to-it/ Наконец-то закончил очередную переработку одной из своих серий постов в большую статью. Как и в прошлый раз, я не просто склеил посты, а проработал текст намного лучше. ❤️Хороший повод прочитать или перечитать, если вам нравится такой жанр В посте упоминается, что я перенёс все свои старые детские программы в веб. Мне надо чуток причесать это дело, после этого опубликую и напишу отдельным постом. #статья #live

Хакатон, где важен не дедлайн, а результат Стандартная схема хакатона выглядит так: 48 часов, минимум сна, максимум энергетиков, и на выходе что-то, что работает ровно на время демо. Потом это уходит в архив и больше не открывается. Kodik Launchpad устроен принципиально иначе. Участники проходят полный цикл разработки: от идеи до публикации в маркетплейсе. Хакатон приурочен к релизу Kodik v2.0, первой российской AI-IDE, которая позиционируется не как умное автодополнение, а как второй разработчик в команде: сама меняет проект, создаёт файлы, оптимизирует код. Разработка ведётся в Kodik, а язык, фреймворк, стек — на выбор участника. Старые наработки использовать можно, но прогресс за время хакатона должен быть реальным и измеримым. Проекты оцениваются по уровню зрелости: Starter, Advanced, Pro. Новички и сильные команды в разных категориях — это принципиально, иначе честной оценки не получится. После верификации заявки насыпают 250 кредитов на платформу, а если не хватит, можно запросить еще. Участие бесплатное, можно соло или командой. Есть общий Telegram-чат с организаторами — можно задавать вопросы по ходу. Призовой фонд — 2,5 млн рублей от Kodik плюс отдельные призы от партнёров. Лучшие проекты попадают в Kodik Marketplace с возможностью монетизации. Хакатон закрывается 9 июля, осталось меньше двух недель. Регистрация и подробности: hackathon.kodik.ru #промо #текст_прислан

В последнее время меня всё больше беспокоит одна вещь — все эти разговоры про применение LLM похожи на гадание на хрустальном шаре. Мы пытаемся с умным видом рассуждать о моделях, при этом всё что мы о них знаем — то что они каким-то хитрым образом рожают нам ответ. Колдунство, не иначе. На старте, когда всё это только зарождалось, оно так сильно не беспокоило. Сейчас же мы выстраиваем очень сложные воркфлоу работы, делаем далеко идущие выводы, сравниваем модели, рассуждаем об их применимости — "большой контекст это плохо" (почему?), "это модель сильнее" (почему?),"с этой моделью правильно работать вот так" (почему?). Ну то есть, мы машем руками, смотрим как эта штука себя ведёт, а дальше начинаем чувствовать себя экспертами, "специалистами в AI-инженерии". Мне кажется, это довольно опасная дорожка. Поэтому я в последнее время стараюсь всё сильнее углубляться во внутреннее устройство LLM, чего и вам советую. Не обязательно становиться экспертами ещё и в этой области, но какое-то базовое понимание иметь стоит. По мере моего погружения, буду стараться вводить и вас в курс дела такими вот постами. Как допишу серию, соберу её уже в большую статью. ———— 🟢Это не упрёк к кому либо, а просто мой личный дискомфорт. Возникают ли у вас такие же мысли?

🤖 LLM под капотом: трансформер. Часть 2 Серия #llm_internals В прошлом посте мы разобрались, как промт превращается в набор векторов и потом прогоняется через стопку блоков, обновляясь под контекст. На выходе у нас та же последовательность векторов, но числа в каждом — уже совсем другие. Особенно интересен последний — в нём «спрессована» информация обо всём промте. Теперь обсудим самое главное — как из этого вектора рождается следующий токен Шаг 3. Генерация следующего токена Итак, у нас есть исходная последовательность токенов из промта, и мы хотим сгенерировать следующий токен. Как это сделать? На самом деле, у нас уже всё для этого есть — модель просто берёт наш последний вектор (соответствующий последнему токену промта) и сравнивает его со всеми векторами таблицы эмбеддингов. Грубо говоря, она перебирает все известные ей токены, и смотрит насколько близки их вектора к нашему последнему вектору. В итоге, в качестве следующего токена, она выберет какой-то случайный — но чем ближе его вектор к нашему, тем выше его шансы. Чтобы окончательно уложить это в голове, давайте снова упростим картину. Вернёмся к нашему 3-мерному пространству. Представьте, что в нём раскиданы 100 точек — это таблица эмбеддингов модели. А ещё где-то в этом пространстве висит особая точка — это наш последний вектор после всех преобразований. Модель измеряет, насколько он близок к каждой из 100 точек таблицы. И чем ближе точка из таблицы к нашему вектору, тем выше её шансы стать нашим следующим токеном. В реальности — пространство 12000-мерное, точек около 100k, но принцип тот же. Итак, у нас есть оценка близости к нашему вектору для всех токенов словаря. Дальше из этого набора выбирается итоговый токен. По умолчанию — самый вероятный (то есть, ближайший). Но можно специально внести случайность — за это отвечает параметр «температура». На температуре 0 модель всегда берёт самый вероятный токен (детерминированный режим). Чем выше температура — тем чаще модель отклоняется от очевидного варианта в сторону менее вероятного. На 2+ это уже почти полная фантазия — повышается риск генерации полного бреда, зато ответы интереснее и креативнее 👍 Что дальше? А дальше — повторяем цикл: 1. Выбрали следующий токен (генерация) 2. Добавили его в конец промта 3. Снова прогнали всё через все блоки (преобразования) 4. Получили новый последний вектор 5. Возвращаемся к п.1 .... И так до конца ответа. То есть, для каждого нового токена ответа модель проделывает колоссальный объём вычислений: 1. Перебирает все токены словаря (генерация — сравнение с последним) 2. Прогоняет новый токен через все 80-120 блоков — это нужно, чтобы подготовить его вектор для следующей итерации. В каждом блоке attention сравнивает его со всеми предыдущими токенами — а их с каждым шагом всё больше. И чем длиннее ответ — тем дороже становится генерация следующего токена. Именно поэтому большие LLM такие дорогие в инференсе. ———— Что ж, вот и весь трансформер. Оказывается, не так уж и сложно 👍 В следующем посте детально разберём сам механизм attention. Та самая операция, ради которой эта серия и пишется. #llm_internals

📆Где я узнаю актуальные новости про AI? Новые модели и ИИ-инструменты выходят так часто, что стоит пару дней не следить за новостями, и всё — ты безнадёжно отстал. Без преувеличения скажу, что AI for Devs — мой любимый новостной канал этой тематики. Я подписан на многие подобные каналы, но только здесь я до сих пор не отключил уведомления. Читаю его довольно давно, канал авторский, все посты строго по делу, отличная подача (инженерный минимализм, ничего лишнего), и всегда свежие актуальные новости. @ai_for_devs 🫶 Не реклама, честная рекомендация

🥂Новый сайт подкаста GoGetPodcast Наконец-то я его доделал 😩 Я давно вынашивал множество интересных идей для сайта, но времени катастрофически не хватало. Сейчас же в компании ИИ-агентов, да ещё после увольнения, я в кои-то веки смахнул пыль со своего длиннющего бэклога, и началось... Итак, что там нового и интересного: 1. Он наконец-то выглядит прилично! Раньше это была просто топорная тема для блога на VuePress. Выглядело очень грустно, но изначально меня хватило только на "работает и ладно..". Нужен был хоть какой-то кривой-косой лэндинг для проекта. Теперь же это полноценная платформа, заточенная именно под подкаст. Ну и в целом, там очень много мелочей, над которыми я долго работал. Например: - Встроенный плеер со всем необходимым функционалом, включая переход между главами - Несколько тем внешнего вида (не только светлая и тёмная, чтобы угодить всем эстетам) - Детально проработанные превьюшки для соц. сетей при шаринге ссылок И многое другое. Всё это я описываю на странице обновлений (но я начал её вести только позавчера) 2. Полный список всех ресурсов, которые обсуждались в выпуске Это ОЧЕНЬ не хватало. Порой у нас в разговоре проскакивали буквально десятки разных сервисов, книг, проектов и других ресурсов. И слушатели постоянно просили собрать их в одном месте. Но в описание под роликом такое не впихнёшь, писать каждый раз отдельный пост в Telegram не хочется, да и просто читать глазами огромный текстовый список мало кому интересно. Теперь у каждого выпуска есть удобная страница ресурсов — с фильтрами, поиском, сортировкой, пояснениями о том, кто и в каком месте что упомянул. К каждому ресурсу прилагается комментарий и ссылка на главу, в которой он обсуждался. 3. Разбор сложных понятий из выпуска Это то, чего мне самому очень не хватает в других подкастах. Список карточек с самыми интересными и сложными понятиями из выпуска, с разбором, пояснениями и комментариями. Эдакий конспект, который хочется перечитать, не переслушивая весь выпуск заново. 4. Статистика и аналитика 🦄 Честно — это больше баловство, но мне нравится ✨ Можно посмотреть, кто из спикеров больше всех говорил, насколько больше, посмотреть разные графики, метрики.. Полезного в этом мало, зато прикольно. Для всего вышеперечисленного построен удобный пайплайн, благодаря которому я могу делать всю обвязку для новых выпусков в день их выхода. Я планирую развивать его и дальше. Например, объединить ресурсы в большую библиотеку, а понятия в общую "энциклопедию" подкаста (хз как ещё это назвать 🗿), и добавлять новые фичи. ———— Списки ресурсов и понятий я формирую полуавтоматически: первые этапы выполняет LLM, а дальше я допиливаю всё руками, чтобы результат был интересным и полезным. 🟠Времени это занимает прилично, поэтому пока они доступны только для нескольких последних выпусков. Постепенно буду заполнять и остальные. На сайте наверняка ещё есть баги и просто кривые места, особенно в мобильной версии, но я буду постепенно всё это допиливать. #gogetpodcast

🥂Большой выпуск про PaaS — как Avito и Plata строят платформу для разработки / GoGetPodcast https://youtu.be/LNvcUonCWEw Когда-то давно я часто ходил на IT конференции, и один из немногих запомнившихся мне докладов был про PaaS Авито. Очень впечатлило, как у них там по нажатию одной кнопочки происходят сложные автоматизации процессов. К сожалению, поработать у них и пощупать это руками мне так и не довелось, поэтому я решил пообщаться с лидом команды DevSupport их платформы — Владом. А чтобы было ещё интересней, мы с моим бывших коллегой Ильдаром сравнили всё это с начинаниями в Plata, которая тоже активно строит свою платформу. Участники: - Владислав Сикач, тимлид команды DevSupport в Авито - Ильдар Карымов  , инженер команды Developer Experience в Plata #gogetpodcast

🏔Большая Алматинская Кругосветка — собираем группу Я планирую ещё раз сходить в поход по горам Алматы, по тому же маршруту. В этот раз пойдём группой из одних только гоферов 🔨 (не считая гида). Группа практически собрана, осталось 2-3 свободных места. 🟢Если хотите присоединиться, оставьте заявку здесь Когда: ориентировочно начало или середина августа. Точные даты согласуем вместе, когда группа полностью соберётся. Да, маршрут довольно сложный. Без подготовки будет тяжеловато, но если ты в хорошей физической форме, то пройти его вполне реально. Специально готовиться не обязательно, но лишним точно не будет — меньше придётся страдать по пути 😩 В любом случае, с нами будет крутой опытный гид, который отлично знает этот маршрут. Во все свои горные походы я ходил только с ним. Экипировку придётся покупать / искать самостоятельно, но мы с этим поможем — будет общий чат, плюс перед выходом вместе сходим в туристический магазин в Алматы и купим все необходимое. Из дорогого — палатка, хороший рюкзак и спальный мешок. Что-то из этого можно будет взять в аренду у гида, будем смотреть по ситуации. Особенно будем рады местным алматинцам, которые тоже хорошо знают этот маршрут ❤️ Если есть вопросы, пишите в комментариях, отвечу. ———— БАК — это мой самый сложный, но самый любимый маршрут из всех, которые я прошёл. Дошёл с трудом, т.к. почти не готовился. Но это первый маршрут, который я очень хочу повторить. Лучший способ отдохнуть от новостей, от работы и от ИИ, вдали от цивилизации. Связи там практически нигде не будет, так что информационный детокс получится добровольно-принудительный ✨

⚙️ Podlodka Go Crew — сезон «Лучшие практики в Go» https://podlodka.io/gocrew Ребята из Podlodka снова организуют Go Crew. Я про них уже не раз рассказывал — формат классный, делают с душой, такое хочется поддерживать. Когда: 1-5 июня Формат: пять дней живых Zoom-сессий утром и вечером, закрытое сообщество в Telegram и общение со спикерами. В программе паттерны, тестирование, нагрузка, межсервисное взаимодействие и AI в разработке. Среди спикеров есть мои хорошие знакомые, особенно хочется отметить доклад Лёши Акуловича — «Практика Go оптимизаций: растём вместе с нагрузкой». Лёша не раз участвовал в моём подкасте, и вообще часто выступает с докладами. Каждый его доклад — это глубокое техническое погружение с классной подачей. В этот раз он расскажет про путь Go-сервиса от прототипа до 3 миллионов RPS: реальные оптимизации (удачные и не очень), снижение latency, оптимизации CPU с gRPC и protobuf, и даже самописный GC поверх гошного. Всё как мы любим ✨ ———— 🟢А ещё, в этот раз там участвую я Вместе с Вовой Балуном и Эдгаром Сипки проведём круглый стол «AI в Go: хайп или новая реальность?». Поговорим с ребятами про LLM-инструменты в Go-разработке, и вообще про влияние ИИ на нашу индустрию. Купить билеты и посмотреть программу можно здесь Промокод на скидку 500р: TUZOV7 В нашем сообществе довольно редко проводят хорошие ивенты, поэтому: Дружеское #промо + личная рекомендация 🫶

🖥 Виртуальная vs Физическая память Продолжаем говорить про память. В прошлых постах мы спроектировали Stack и Heap. Но то была картина изнутри программы. Теперь поднимемся на уровень выше и посмотрим, как всё это выглядит со стороны ОС. ———— Снова надеваем каску инженера. Наша команда проектирует операционную систему, и нам поручили разобраться с менеджментом памяти — нашей ОС доступен определённый её объём, и его нужно каким-то образом распределять между процессами. Попытка 1: Нарезаем RAM — прямой доступ Самое простое решение — поделить физическую RAM на кусочки: программе A отдадим адреса 0x0000–0x1000, программе B — 0x1000–0x2000, и так далее. На первый взгляд, всё работает, но... Сразу же вылезает огромный букет проблем. 1. Безопасность: Что мешает Программе А обратиться к адресу программы Б и прочитать пароли из её памяти? Ничего. А если она туда что-то запишет, то Программа Б просто сломается. 2. Изоляция и адресация: Компилятору нужно заранее знать, по каким адресам будут лежать переменные, чтобы скомпилировать код. Но мы не можем заранее знать, какие физические адреса будут свободны в момент запуска программы 🗿 🟢Очевидно, что напрямую пускать процессы к железу нельзя. Думаем дальше. Попытка 2: Иллюзия одиночества — базовый адрес и граница Что ж, забираем у программы прямой доступ к адресам. Мы всё ещё будем присваивать ей какую-то область, но адресуем сами. То есть, каждая программа будет думать, что ей доступна вся доступная память: от 0x0000 до capacity. К примеру, [0x0000, 0x1000]. Мы же просто добавляем соответствующее смещение и следим, чтобы программа не вылезала за свои пределы. Допустим мы выдали программе диапазон [0x3000, 0x4000]. Сама она при этом работает с адресами [0x0000, 0x1000]. Когда программа обращается к ячейке 0x0050, мы просто добавляем к ней смещение +0x3000 и получаем адрес: 0x3050. А если она просит больше, чем ей доступно, выдаём ошибку. Это уже лучше! Но вылезает ещё более коварная проблема — фрагментация. Представьте, что у вас 1гб памяти, и вы запустили 500 мелких программ, которым нужно ~2мб. В итоге, ваш гигабайт будет нарезан на 500 мелких кусочков. Далее мы закрываем половину этих программ, чтобы освободить место для одной тяжёлой программы. И вот проблема: мы освободили 250 кусочков по 2мб, но они разбросаны рандомно по всему пространству! И у нас нет ни одного свободного промежутка хотя бы в 100мб:

[== Физическая память 1 ГБ ==]

1. Память забита (по 2 МБ):
|█|█|█|█|█|█|█|█|█|█|█|█|█|█|█|

2. Закрыли половину (ДЫРЫ):
|█| |█| | |█|█| |█| |█| | |█|█|
   ^   ^ ^     ^   ^   ^ ^
  2мб 2мб 4мб 2мб 2мб 4мб 2мб

(Суммарно места много, но оно 
 разбито на мелкие куски)

3. Нужен цельный кусок 100 МБ:
Требуется: |██████████|
Результат: ОШИБКА! Не влезает...

Попытка 3: Страничная организация (Paging) Очевидно, нам нужно уметь из мелких кусочков собирать большие. Давайте будем нарезать память на одинаковые мелкие кусочки — страницы (обычно по 4 КБ), а затем маппить запрошенные программой адреса с реальными через специальную таблицу (Page Table). То есть, ОС будет вести полный учёт — кому какая страница принадлежит и правильно сопоставлять адреса с помощью таблицы Программа же не догадывается об этой машинерии — она всё так же работает в своём виртуальном диапазоне, [0x0000,0x2000]. Например: 1. Программа пишет по адресу 0x1050 2. ОС смотрит в таблицу и сопоставляет: виртуальный адрес 0x1050 с физическим 0x8A3050 Что это нам даёт? Безопасность: у каждой программы своя таблица страниц — свой изолированный мир. До чужой памяти физически не дотянуться, а попытка вылезти за пределы своего пространства — ошибка. Привет, Segmentation fault! 👍 Дефрагментация: виртуальные страницы программы могут идти строго по порядку, одна за другой. А вот в физической памяти ОС может раскидать их как угодно по любым свободным промежуткам. Готово?! Да, концептуально то оно работает, но есть нюанс.. 👀 На практике мы замечаем, что наша ОС жутко тормозит — топорный программный поиск по таблице, это слишком тяжёлая операция. В следующем посте будем это оптимизирвать. #guide #memory

Как там дела с новыми роликами? Как я уже писал, после увольнения я решил отдохнуть месяцок, заставляя себя вообще ничего полезного не делать. После этого я жестко подсел на вайбкодинг Agentic Engineering. Ох и страшная штука.. Затягивает сильнее, чем Дота. Если интересно, как-нибудь позже расскажу про свои проекты (у меня там много всего, от простеньких игр, до собственной IDE). Когда меня немного отпустило, я снова взялся за сценарий ролика про GC. Но в какой-то момент я понял, что некоторые "ликбезы" настолько серьёзные, что их проще вынести в отдельные ролики, которые не будут уступать по объёму. Раз уж у меня теперь много времени на создание контента, я решил что начну с фундамента, после которого материал про GC будет восприниматься сильно легче — Memory Model, Memory Layout, аллокатор и др. В общем, планов много, работа кипит. Работаю я теперь даже больше, чем раньше — потому что интересно. Когда ждать? Не скоро. Для меня, как и прежде, качество важнее количества. Буду прорабатывать сценарий до тех пор, пока он меня полностью не устроит. Кроме того, есть и другие важные проекты. Надеюсь, что за 1-2 месяца справлюсь с ближайшим видео 😩 Но пока я им занимаюсь, буду по традиции писать сюда короткие гайды, которые подготовят вас к просмотру 🫶

🐧О чём пишут инженеры из AvitoTech? Ребята пришли ко мне с просьбой рассказать про их канал. Я почитал посты и составил подборку того, что меня зацепило: 1. Обзоры релизов Go от Паши Агалецкого Регулярная авторская серия — коротко, интересно и по делу. Я и сам регулярно их смотрю. Вот свежий разбор 1.26. К слову, Пашу я помню ещё по неплохой статье на Хабре, которую я как-то уже рекомендовал. 2. Подкаст «В SREду на кухне» — @sre_avito Отличные темы, хороший формат, хорошая подача, интересные гости: Райффайзен, Флант (Deckhouse), VK. Из свежего: error budget с Кириллом Борисовым из VK, chaos engineering, AI в SRE. 3. Подкаст «Свободный слот» — для тимлидов Примеры интересных тем: одиночество тимлидов, 50 оттенков порока: за что команды ненавидят тимлидов. 4. Inside-кухня Авито Из последнего: - Шардирование delivery-item — highload-история с продолжением через 2 года - Мониторинг сетевых устройств через BMP — со схемами и docker-compose-лабой в конце - CI/CD в цифрах: 190 автоканареек в сутки 5. Оффлайн митапы ☀️ Из ближайшего: Frontend-тусовка 19 мая и TeamLead Drinkup в Екатеринбурге 28 мая (первый их дринкап в Екб). У них регулярно проходят и тематические митапы — например, недавний Database meetup #3 с докладами про DBaaS, FoundationDB vs Cassandra 5 и Ceph на 100k+ бакетов. ———— Что я могу сказать? Не буду делать вид, что весь канал — сплошная техно-кладезь: мемы про созвоны и опросы «было ли у вас» там тоже водятся. 🟢Если вы любите оффлайн-митапы, то подписка must have — ребята регулярно их проводят, и проводят отлично. Ну и если вам просто интересен качественный контент от инженеров крупного энтерпрайза, тоже советую обратить внимание. @avitotech дружеский #партнерский_пост #avitotech

☣️ Озон попросил меня отправить тухлятину через 2 страны СДЭКом (но СДЭК отказался) Не могу не поделиться этой историей. Если вы думаете, что в вашей компании процессы выстроены абсурдно, то прочитайте сначала этот пост 💅 Недавно я писал про то, как я получил от Озона вместо мыши за 10 тыс рублей пустую коробку, а в ПВЗ у меня отказались принимать возврат. Окей, деньги в итоге вернули — с натяжкой можно предположить, что просто процессы дали сбой, бывает. Но сегодня мы столкнулись с ситуацией, где процессы сломаны by design. Вернее, они не просто сломаны, они до безумия абсурдны. Я не понимаю, кто в здравом уме вообще мог такое придумать. ———— Ситуация: заказали упаковку энергетиков (маталлические банки). Тащить такое из ПВН проблематично, поэтому привёз курьер. Вскрываем, банки повреждены, внутри всё залито жидкостью и... уже поросло плесенью! Вонища, как вы понимаете, жуткая 💩 Как вы думаете, как в этой ситуации поступит Озон? Извинится, вернёт деньги и попросит утилизировать это биологическое оружие? Нет 🗿 Пришлют курьера, чтобы он увёз биологическое оружие сам? Нет 🗿 У ребят фантазия работает куда лучше! Они попросят тебя оформить возврат самому через внешнюю службу доставки (например, СДЭК). Уже сложно, да? Но вы недооцениваете их фантазию, ведь можно ещё сложнее! Возврат нужно за свой счёт оформить на конкретный адрес в Москве! Приложив к нему подробную инструкцию для курьера, как попасть на этот сложный охраняемый объект (он должен куда-то заранее позвонить, получить пропуск, прийти в определённое время)... На самом деле, это далеко не вся инструкция — сапорт прислал нам полотно, размером с этот пост. Как думаете, СДЭК с этим справится? Нет, конечно, они послали нас ещё на этапе оформления доставки — они отказываются перевозить эту гадость! Мы им позвонили, и нам чётко ответили, что в таком виде посылку они точно не примут (и правильно делают). К тому же, сама отправка может стоить дороже, чем заказанный товар — груз тяжёлый и большой 🤡 Итого, что мы имеем. Озон прислал испорченный продукт с плесенью и поставил условия, которые заведомо невозможно выполнить. А даже если бы и было возможно — вы можете себе представить как заплесневелая протухшая коробка едет из Астаны в Москву? Попутно заражая всё, что едет рядом с ней. А сколько оно там будет храниться на складах? А главное — зачем? Последний рабочий вариант — отнести это добро на ПВЗ. Мне не очень хочется тащить тяжелую коробку так далеко, и я даже не уверен что там её примут. Но просто из принципа доведу дело до конца. ———— Какая из всего этого мораль? Конечно, как инженер, я понимаю, что сделать универсальный флоу возврватов, который учтёт все нюансы, крайне сложно, а скорее невозможно. Но дело то не в этом — ребята просто заигрались в оптимизацию. 🟢Практически все подобные проблемы, даже самые нестандартные, решаются наличием адекватного сапорта. А у Озона сапорт практически отсутствует, как и у Яндекса. Но вообще, ситуация закономерная 💩 (это не шутка), чуть позже хочу написать общий пост о подобной тенденции в целом. ———— Что ж, пополняем список правил при работе с Озоном: 1. Внимательно проверяйте под камерой что вам привезли — вскрывайте коробку, убедитесь что там не пусто и именно ваш товар. Пустую коробку назад не примут. 2. Убедитесь, что товар не подделка и не сломан. Если подделка — вам скажут, что это вы сами её подменили (у меня такое тоже бывало, с трудом добился возврата) 3. Если заказали продукты, проверяйте срок годности, целостность упаковки и.. наличие плесени! 🦠 А лучше, не заказывайте вовсе, если есть альтернатива. Это уже далеко не тот сервис, которым мы привыкли пользоваться. Озон, у вас там всё в порядке? #негатив #ozon

🤖 LLM под капотом: трансформер. Часть 1 Серия #llm_internals В недавнем посте мы разобрались, что такое токены и веса, а затем закрепили в голове понятие вектора в N-мерном пространстве. Теперь давайте заглянем внутрь самой модели — как она устроена и что вообще эти миллиарды весов делают. Ключевое слово тут — трансформер! Что такое трансформер? Это конкретный тип нейросети, придуманный в 2017 году в Google (статья Attention Is All You Need). Это самая базовая база, которую стоит знать каждому, с этого всё началось. И с тех пор ВСЕ LLM, которые вы знаете — Claude, GPT, Gemini, Llama, DeepSeek, Qwen — это трансформеры. Суть архитектуры хорошо передаётся названием — внутри модель буквально этим и занимается: берёт ваш промт (последовательность токенов) и постепенно его преобразует (трансформирует), чтобы финальному набору можно было предсказать следующий токен. Делается это в три шага: Шаг 1. Промт превращается в набор векторов (эмбеддинги) Итак, на этапе обучения модели каждому токену из её словаря сопоставляется какой-то набор параметров (8-12 тыс, зависит от модели) или, другими словами, вектор в пространстве этих параметров. Все эти вектора хранятся в одной большой таблице — её и называют таблицей эмбеддингов. 🟢Чтобы уложить в голове, представьте что у вас есть обычное 3-мерное пространство, и вам надо каким-то хитрым образом распределить по нему набор из 10 точек. Вот для модели делают то же самое, но пространство многомерное, а точек десятки и сотни тысяч. Но принцип от этого не меняется. 🦄Главная магия этой таблицы: модель училась располагать токены таким образом, чтобы близкие по смыслу оказывались рядом. То есть, «разработчик» и «программист» — рядом, а «разработчик» и «ананас» — далеко. На этой простой идее держатся все нейросети для текста. Итак, модель готова. Теперь, когда вы отправляете свой промт, он сначала разбирается на токены, а затем каждому токену сопоставляется вектор из таблицы. К примеру, если ваш промт состоял из 10 токенов, модель будет дальше обрабатывать набор из 10 векторов. А ещё к каждому вектору добавляется метка позиции, чтобы их порядок соответствовал порядку слов в промте. Шаг 2. Эти вектора прогоняются через стопку «блоков». Блок (или слой) — это просто функция, которая каким-то хитрым образом преобразовывает (трансформирует) набор наших векторов. То есть, передвигает набор точек в пространстве. У крупных моделей их 80-120 штук. Внутри одного блока — две операции: - attention — каждый вектор обновляется с учётом всех предыдущих векторов из последовательности (про эту операцию подробно в следующем посте, она для нас критически важна) - feed-forward — ещё раз обрабатывает каждый вектор уже по отдельности Важный нюанс: внутри attention каждый вектор смотрит только на предыдущие, не на последующие. Поэтому первый токен видит только себя, второй — себя и первого, а последний всех. Это техническое свойство трансформеров-декодеров (а именно ими являются все LLM, о которых мы тут говорим). Допустим, ваш промт был такой: "Напиши программу hello world". До преобразований вектор слова «world» — это просто копия из таблицы. А после всех преобразований числа в нём поменялись таким образом, что они зависят и от «Напиши», и от «программу», и от «hello». (да, на самом деле, как я уже писал, модель работает не со словами, а с токенами, но такая формулировка понятней интуитивно) То есть, точка в нашем многомерном пространстве сдвинулась в новое положение, которое учитывает предыдущие токены. Можно сказать, что этот финальный токен «получил информацию» о всех предыдущих — теперь это слово в конкретном контексте. Именно по нему модель и считает, какой токен предсказать следующим. Шаг 3. Генерация следующего токена Вот мы и добрались до самого интересного! У нас наконец на руках есть абсолютно всё, чтобы сгенерировать свой первый токен, а затем и весь ответ модели целиком.

// TODO: Написать об этом следующий пост

#llm_internals

🔧 LLM под капотом: токены и веса Серия #llm_internals В последнее время я стал всё больше углубляться во внутреннее устройство LLM. Очень полезно понимать, как работает эта неведомая «чёрная коробочка», которая пишет нам код. Кроме того, хочется в будущих постах углубляться в разбор новостей чуть больше, а для этого вам тоже нужно понимать матчасть. Итак, начинаем с самой базы Что такое токен? Наверняка вы уже интуитивно это понимаете, но давайте разберемся окончательно и закрепим. Токен — один из кусочков, на который нарезается текст перед тем, как передать его модели. Это не слово, и не буква, всё чуточку хитрее. У каждого семейства моделей свой токенайзер, но логика общая: частые слова — обычно 1 токен, редкие — 2-3 куска. Например, в токенайзере GPT-5.x «cat» — 1 токен, а «Anthropic» — 2 (Anth + ropic). У Claude или Llama они могут отличаться. Советую поиграться самостоятельно, у OpenAI токенайзер открытый и есть удобный интерфейс чтобы его потыкать. Далее токены превращаются в числа: у токенайзера есть словарь из 30-250 тысяч токенов, каждому из которых сопоставлено число. Итого, когда вы написали промт, токенайзер сначала режет его на токены, а потом превращает их в числовую последовательность. Вот именно с этими последовательностями и работает модель Когда модель возвращает ответ, она возвращает токены по одному (в виде тех же чисел), и каждый последующий зависит от предыдущих. ———— Что такое веса? Когда модель обучают, ей скармливают огромные массивы текста — статьи, библиотеки книг, код с GitHub, форумы. А что значит «скармливают»? Главный этап обучения называется pretraining: модель решает одну задачу — по куску текста предсказывает следующий токен. Ей дают текст, отрезают конец, спрашивают «какой токен идёт дальше?», смотрят на ошибку, чуть-чуть подкручивают её «внутренние числа» в нужную сторону. И так миллиарды раз — пока не начнёт угадывать стабильно. После pretraining модель ещё дополнительно доучивают (fine-tuning, RLHF) — учат отвечать полезно и безопасно. Но основное «знание мира» закладывается именно в pretraining — это самый дорогой и долгий этап. Эти «внутренние числа» и есть веса. По сути, это коэффициенты в огромной формуле, по которой модель вычисляет следующий токен. У современных больших моделей их сотни миллиардов или триллионы. Если вы работали с локальными моделями, могли видеть вот такие обозначения: Qwen3.6-27B, здесь 27B — это количество параметров (~27 миллиардов). А параметры, это в основном это веса плюс некоторые мелочи. То есть, никакой базы знаний внутри модели нет. Всё, что она «знает» — кто такой Эйнштейн и как писать на Go, закодировано в весах. Когда вы общаетесь с моделью — она ничего не ищет в "базе", она просто прогоняет ваш промт через свою "формулу" и считает, какой токен лучше выдать следующим. Этот процесс (вычисление следующего токена) называется inference Веса между сессиями не меняются. Модель не "помнит" все ваши сообщения. Ей просто отправляется ВСЯ история текущей переписки с каждым новым запросом. Веса бывают открытые и закрытые: - Открытые: Llama, Qwen, DeepSeek, Gemma, gpt-oss. Их можно скачать, запустить у себя, форкнуть, дообучить под свою задачу. - Закрытые: GPT, Claude, Gemini Полезный вывод: когда вы видите в анонсе фразу «стартап обучил свою модель поверх открытых весов» — это значит, они взяли готовую и до-обучили (fine-tune). Это нормальная практика, но это НЕ «разработали с нуля». А подают часто именно так. И ещё один очень важный термин: карточка модели (model card) — это документ, в котором написано, на чём обучали, сколько данных, какие бенчмарки прогнали, известные ограничения. Наличие такой карточки — это стандарт индустрии. Если какой-то серьёзный релиз идёт без неё — это очень сильный красный флаг. ———— В следующем посте подробнее разберёмся, что происходит внутри модели и обсудим скелет архитектуры трансформера 🤖 🟢Интересно ли вам такое? Если эта серия постов хорошо зайдёт, напишу отдельно полноценную статью и сделаю ролик. P.S. Какую же крутую схему для обложки нарисовал GPT, прям без ошибок 🫶 #llm_internals

Как выбрать лучшую LLM для агента или приложения и не переплачивать 🟢дружеское #промо #текст_прислан • 27 апреля, ПН • 19:00 по мск Рассказывает: Антипов Дмитрий — руководитель разработки AI-продуктов в Группе Сбер (АБТ). Открытый урок: как выбрать модель не по хайпу и узнаваемости, а по цене, скорости и реальной пользе для вашей задачи. И платить меньше за то же качество. Запись для всех зарегистрировавшихся

Разработчики, лиды и продакты часто выбирают модели как «самые лучшие». При этом задача - определить тональность отзыва или сделать RAG. Модель справляется блестяще, и все довольны. А потом нужно масштабироваться, и радость заканчивается. Множество задач можно делать быстрее, эффективнее, дешевле и даже без целого кластера H100.

Что будет на уроке: 1️⃣Типы LLM и по каким критериям делать выбор под свою задачу 2️⃣Почему «самая умная модель» – не всегда самый умный выбор 3️⃣Как инженерно подойти к выбору LLM и на какие метрики смотреть 4️⃣Каскады и повышение эффективности — что это такое и как помогает экономить деньги без потери качества ➡️Участие бесплатное, но регистрация обязательная

🥂GolangConf 2026 — 20 апреля в Москве Практическая конференция для Go-разработчиков: мастер-классы, воркшопы и живой нетворкинг вместо пассивных лекций. Что в программе: - ИИ для гофера Как выбрать модель на всю команду? Как не допустить утечек и что делать с кодом, написанным AI? Какие задачи машина решает стабильно, а где только создаёт иллюзию эффективности? - Платформенная разработка Как организовать платформенную команду? Где проходит граница её ответственности? Как внедрить платформу в существующий зоопарк сервисов? И главное — как сделать так, чтобы продуктовые команды реально ей пользовались? - Производительность Как понять, что сервис работает достаточно эффективно? Как снять профилирование? Как читать результаты? Как построить адекватный стенд? И главный вопрос — а точно ли у вас есть проблема? В мире Go это становится ещё интереснее. Уходите не с записями, а с конкретными инструментами и планом «что делать завтра». 400+ участников. Спикеры из Яндекса, VK, Avito и других команд. 🟠Билеты и подробности — на сайте конференции. 🟢Промокод на скидку 15%: 2026 #промо #текст_прислан