Тоже Паша Техник

😞 Anthropic выкатили очень интересный ресерч про то, как Claude "думает" внутри (даже видосик красивый показали) у модели нашли что-то похожее на внутренний рабочий стол. Маленькое пространство, куда попадают промежуточные мысли перед ответом. Не chain-of-thought, не скрытый текст, а именно паттерны в активациях модели. Назвали это J-space. Концепция на самом деле достаточно простая, постараюсь объяснить. Когда вы спрашиваете модель: "сколько ног у животного, которое плетёт паутину?" модель не обязана писать слово "павук", но внутри ей всё равно нужно прийти к промежуточной мысли: 1. животное, которое плетёт паутину = spider 2. spider = 8 legs 3. ответ = 8 И вот Anthropic научились подсвечивать такие внутренние промежуточные штуки. В J-space у модели реально появлялся spider, хотя в вопросе и ответе этого слова не было. А теперь самое интересное. Они не просто посмотрели на эту активацию, а попробовали её заменить. Мы убираем spider, подставляем ant — модель начнет отвечать 6. То есть это не просто красивая визуализация, а реально часть вычисления. Технически они используют штуку под названием Jacobian lens. Это "линза", которая смотрит на скрытый слой модели и пытается понять, какие слова/концепты эта активация сделает более вероятными в будущем ответе. То есть мы не просто смотрим "что модель сейчас напишет", а пытаемся понять "какая мысль сейчас лежит у неё на внутреннем столе". Почему это важно? Модель может не написать свои промежуточные мысли, но всё равно использовать их для решения задачи. Для обычных чатиков это просто интересно, а вот для агентов уже становится критично. Если агент вызывает тулзы, меняет файлы, делает PR, ходит в API и оптимизирует какие-то метрики, хочется понимать не только финальный ответ, но и внутреннюю траекторию: • что он понял? • что решил? • какие намерения у него возникли? • не пытается ли он обойти ограничение? • почему он дропнул продовую бд!!! И вот такие методы — это шаг к нормальному observability для LLM. Не только логи tool calls, промптов и ответов, а ещё попытка заглянуть в промежуточные представления модели. Главное с ума не сходить: это не доказывает, что Claude сознательный. Скорее это показывает, что у больших моделей появляются внутренние механизмы, похожие на "рабочую память" для рассуждений. Механизмы, которые в них не закладывали, но они возникают сами по себе в ходе обучения/оптимизации. раньше мы смотрели на LLM как на чёрный ящик, который магически предсказывает следующий токен. Сейчас этот ящик начинают аккуратно разбирать и находить внутри вполне инженерные компоненты: где хранятся промежуточные мысли, где планирование, где автоматические навыки. И вот это уже реально интересно 🧠

😞 прочитал статью про TurboQuant от гугл — это такое логичное продолжение поста про ScaNN источники: запись в блоге и папира TL;DR: главная идея TurboQuant — сначала сделать вектор удобным для сжатия, потом сжать, а потом отдельно поправить ту часть ошибки, которая ломает скалярное произведение. --- напомню идею ScaNN: если нам нужен поиск ближайших векторов, то не обязательно идеально восстанавливать исходный float32-вектор после квантизации. Важно не сломать порядок ближайших кандидатов. То есть оптимизируем не красивую прокси-метрику, а то, от чего реально зависит задача. TurboQuant очень похож по духу, только теперь история не только про vector search, но и про KV-cache в LLM. Что такое KV-cache? Когда LLM генерирует текст, она хранит key/value-вектора прошлых токенов, чтобы не пересчитывать всё заново на каждом следующем токене. Контекст длиннее -> токенов больше -> KV-cache жирнее -> памяти не хватает. Давайте возьмем эти key/value-вектора и сожмем. Например, не хранить их в bf16/fp16, а упаковать в 4 или даже 3 бита. Но если сделать это тупо, то можно поломать attention. Потому что attention живёт на скалярных произведениях: • query умножается на key -> получаем attention score • потом через него взвешиваем value attention_logit_i = q_current · k_i attention_output = sum softmax(logits)_i * v_i То есть нам снова не нужно идеально восстановить каждый float. Нам нужно не сломать dot product. Вот TurboQuant как раз про это. Упрощенно: 1. Сначала вектора случайно поворачивают. Поворот не меняет расстояния и углы между векторами, но “размазывает” информацию по координатам. Было условно [0.01, 0.98, 0.02, 0.01], стало что-то более ровное. Такие вектора проще сжимать в 3–4 бита, потому что квантизация меньше убивает отдельные важные координаты. 2. Потом основную часть вектора жмут через PolarQuant. Идея: хранить не координаты по осям напрямую, а что-то ближе к “длина + направление”. Для attention это логично, потому что важны не сами float-числа, а то, как вектор потом участвует в dot product. 3. После сжатия всё равно остаётся маленькая ошибка — residual. QJL не пытается восстановить её полностью, а хранит дешёвые 1-bit подсказки: в какую сторону эта ошибка влияет на скалярное произведение. То есть основной квантизатор сохраняет вектор, а QJL маленьким довеском чинит bias в attention score. подробнее с кодом, картинками и гифками можно глянуть здесь. • То есть ScaNN из прошлого поста говорил: "давайте квантизовать так, чтобы не ломать ранжирование" • TurboQuant говорит: "давайте квантизовать так, чтобы не ломать скалярные произведения". Но ресерчеры из vLLM хорошо напоминают базу: красивая идея в статье != бесплатный production win — об этом, для самых пытливых умов, закину инфу в комменты, чтобы пост на раздувать 😑

😑 как-то давно прочитал статью про ScaNN от гугл, написал этот пост в черновики и благополучно забыл про него. Сейчас хочется быстро пройтись по этому scann, чтобы потом рассказать про идейное продолжение в статье TurboQuant, опять же от гугл. - - - Я уже рассказывал здесь про задачу поиска ближайших соседей, но не упомянул про еще один класс решений. задача: есть вектора и мы должны по запросу найти ближайшие к этому запросу вектора. Например, есть набор текстов книг, а вы хотите задавать какой-то конкретный вопрос и получать список релевантных к этому вопросу книг. книг очень много и попарное сравнение вопроса со всеми книгами займёт слишком много времени. И мы, как истинные инженеры, идем подбивать костыли. Как вообще решают задачу поиска ближайших соседей: • наши вектора лежат в каком-то пространстве. Давайте просто рандомно разобъем это пространство на куски и нужные книги будет искать по запросу только в нужном куске. Это первая идея, это random projection trees типа annoy (было здесь) • в хэшировании очень не любят коллизии, когда два разных элемента получают одинаковые хеши после какой-то функции. А нам бы это как раз подошло. Нам нужна функция, которая будет складывать близкие вектора в один ящик. Тогда при запросе мы будем хэшировать вопрос, смотреть в какой ящик попадает этот вопрос и искать уже только там. (было здесь) • HNSW: чуть сложнее для понимания, но, условно, мы строим граф, где каждый вектор знает своих соседей. А потом при поиске не сравниваем запрос со всей базой, а прыгаем по этому графу: сначала грубо на верхних уровнях, потом всё точнее на нижних. То есть идея HNSW не в том, чтобы сжать вектора или разбить пространство на куски, а в том, чтобы быстро добежать до хороших кандидатов через связи между уже близкими точками. • и есть квантизация. Допустим у нас есть вектор, который состоит из 768 чисел типа float32. Давайте хранить этот вектор в более дешёвом виде, например ближе к int8. Тогда при поиске нам нужно меньше таскать данных из памяти, а приближённое сравнение становится сильно дешевле. Вот ScaNN — это как раз про квантизацию, но более умную. В задачах квантизации оценивается то, как хорошо мы можем восстановить исходный float32 вектор X из квантизованного Q. В гугл сказали: если нам для поиска похожих важно не нарушить порядок векторов, то давайте именно это и будем оценивать при квантизации. Они ввели anisotropic loss, который сильнее штрафует ошибку вдоль важного направления, чем ошибку поперёк него. Потому что для поиска важнее не испортить порядок лучших кандидатов, чем идеально восстановить весь вектор. На первой картинке идея такая: обычный loss одинаково смотрит на ошибку во все стороны, а anisotropic loss считает некоторые направления важнее других. На второй картинке — слева обычная квантизация сильнее искажает проекцию на запрос и из-за этого может ломать ранжирование, а справа новый лосс лучше сохраняет относительный порядок кандидатов. 👀 идея scann понравилась не потому, что он быстрее чего-то в ваккуме, а потому что в нем очень правильная идея: надо оптимизировать бизнес метрику, а не прокси метрики

💧 Уже два с лишним года я занимаюсь боксом. И захотелось подумать вслух про спорт в жизни обычных людей. ➡️ Для меня любой спорт — это маленькая жизнь. Первые шаги, полное непонимание. Период «я вроде уже что-то умею». Первые победы. А потом приходит человек, который тренировался в два раза больше, и аккуратно возвращает тебя в реальность. Но самое ценное — спорт в игровой форме учит проходить через барьеры, с которыми мы сталкиваемся везде: поражение, злость, дисциплина, усталость, страх, сравнение себя с другими, желание всё бросить. Только цена ошибки сильно ниже. Проиграл в спарринге — наибольший урон лишь у самооценки. Но ты не потерял деньги, не развалил проект, не уволил половину команды. А навык остаётся: ты учишься проигрывать, вставать, анализировать и видеть за поражением не конец света, а материал для следующей попытки. Я занимался спортом с 3-4 лет. Футбол, баскетбол, акробатика, чтобы даже падать красиво. 🔜 Самый сильный урок мне преподнесла лёгкая атлетика. Каким-то образом открылся талант. Почти два года я выигрывал всё, где участвовал. Единственное исключение — второе место на всероссийских соревнованиях. А дальше — классика. Я почувствовал вкус побед, расслабился, начал меньше пахать. А ребята, которые год назад проигрывали мне с большим отрывом, продолжали тренироваться как проклятые. И в какой-то момент они начали обходить меня в каждом забеге. 👍 🔜 Неприятный, но полезный урок: талант — это не чит-код, а стартовый бонус. Если его не докрутить работой, дисциплиной — тебя догонят те, кто каждый день эту базу делают. При этом я не считаю, что каждый должен стать великим достигатором. Красота жизни — что её можно прожить по-разному и всё равно прийти к своему счастью. Скорее мысль в другом: спорт хорошо зеркалит твои паттерны поведения в обычной жизни. Как реагируешь на неудачу. Как быстро сдаёшься. Умеешь ли терпеть скучную базу. Не психуешь ли, когда прогресса не видно. Сможешь ли вернуться после того, как тебя размазали. ➡️ Почему именно бокс? Задействовано почти всё: сердце, руки, ноги, корпус, координация, реакция, дыхание, внимание. Высокий коэффициент полезности за единицу времени, вот и все🗿 🧐Какой самый неудобный урок вы вынесли из спорта? Не вдохновляющий, а прямо неприятный, но полезный.

😑 посмотрел интенсив от Яндекса Agents Week(там в описании есть ссылки на все лекции и практики) — неделю рассказывали, как строить агентские системы. Сначала по фактам, потом бахну никому не нужное мнение. 1. Первая лекция — базовая база. что такое LLM, что Яндекс называет агентами, что такое tools и MCP. по сути: agent = runtime(Model + prompts + tools + memory + guardrails + planning skills) 2. Вторая — про память и guardrails. Память бывает в рамках сессии, всего общения и они еще выделили отдельно подтип долгосрочной — про сущности (люди, места и т.д.). Про RAG в миллионный раз рассказали и как для него качественнее запросы формировать. Как формировать контекст, если нет денег на модель с лям контекстом: • окно по последним сообщениям • векторная БД по особщениям + подтягивать только релевантное • ну либо модель на лям токенов... 😑 Guardrails — это вообще про то, что если у модели есть тулза “сделать скидку 100%”, кто-нибудь обязательно попытается это сделать. Значит, проверки нужны везде: input -> checks -> agent -> checks -> tool -> checks -> answer Что важно закрывать как можно скорее: • модерация/валидация запросов и ответов • проверка параметров тулзов • проверка доступов к субагентам и инструментам • маскирование чувствительных данных перед любым походом в LLM 3. Третья лекция — агенты и мультиагенты. Агентский цикл простой: подумал -> сделал -> посмотрел, что вышло. Мультиагенты строятся поверх агентов через одну из стратегий: • иерархическая. Есть оркестратор, который раздает задачки субагентам и потом собирает ответ и выдает пользователю • децентрализованная. Каждый агент может общаться с каждым, главное решить задачку. • роутер. ничего не оркестрирует, а просто перенаправляет в более подходящего субагента • shared message pool. Агенты обмениваются данными асинхронно, не завися от адресов и доступности друг друга. Такой подход позволяет системе масштабироваться и совместно решать задачи через общую "доску объявлений" 4. Наверное самая интересная для меня лекция, так как агентов уже каждый агент строит, а вот как их оценивать — уже вопрос. Основные мысли: • собирать корзину тестов не только с запросом, но и с состоянием системы • проверять не текст ответа, а финальное состояние • прогонять eval на том же агенте, что и в проде • смотреть хотя бы на: решил ли задачу, те ли tools вызвал, насколько был эффективен по шагам • оценивать через rules, человека или llm-as-judge Мне кажется, в eval с самого начала сильно упарываться не надо, но хоть какой-то пайплайн лучше собрать сразу — итерации потом идут быстрее. 5. Последняя лекция — инженерные костыли продакшена. Самое важное — observability. По логам должно восстанавливаться всё: какой был запрос, какие tools дергались, какие были входы/выходы, по какой траектории агент пришёл к ответу. Были ещё задачки, но там в основном вопросы по материалу и сборка простого реакт-агента в подготовленном ноутбуке. 😶 В целом интенсив сильно легче прошлых двух яндексовских — про обучение LLM и про scaling обучения/инференса. Чего-то мега нового я не узнал, но это, наверное, один из самых хорошо структурированных рассказов про построение мультиагентов. Правда, я так и не понял, для кого он: для инженеров мало, а для вайбкодеров готовых промптов не завезли 🗿

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

2022 год: эпл из за санкций закрыли доступ к оплате подписок и покупок в app store через российские карты, но способ через симкарты продолжал работать (лично я платил через мтс) 2026 год: минцифры попросили операторов с 1 апреля отключить возможность оплаты через симки в app store Забавно что американские санкции не справились с ограничением оплаты у россиян, а минцифры смогли Кто-то назовет это friendly fire, а я скажу, что все персонажи и ситуации вымышлены, а совпадения случайны 👍

почти полгода пользуюсь Whoop и захотелось рассказать про опыт На самом деле очень тяжело рассказывать про плюсы и минусы своего правого уха — я просто привык, что оно у меня есть. вот так же и с вуп: он стал моей неотъемлемой частью. сразу отвечу на главный вопрос: — станете ли вы ультра-сигмой с вуп? — нет как я им пользуюсь: • утром смотрю, как поспал, какое recovery и что советует их AI-ассистент по нагрузке • в течение дня трекаю активности: ходьбу, бег, бокс, вождение и тд. Есть и recovery-активности типа йоги или дневного сна. Со временем вуп запоминает, как ты двигаешься, и сам понимает, когда ты, например, побежал. Так что вручную я сейчас почти ничего не добавляю • вечером, за чашечкой да хун пао, заполняю дневник. Это вообще одна из самых интересных частей: отмечаешь только то, что реально может влиять на состояние, а потом приложение показывает инсайты — что именно и насколько сильно на тебя влияет еще докупил себе бицепс-бэнд, потому что обычный ремешок на кисти во время бокса в перчатках вообще неудобен. отдельно — мои recovery-инсайты за полгода. что дает сильный буст: • качество сна. Если ложусь и встаю примерно в одно и то же время, recovery заметно лучше. По их цифрам это дало суммарно +22%. Даже если сплю часов 5, но ложусь в промежутке 22:00–00:00, recovery у меня часто 70%+, и это прям ощущается • дни с глубоким отдыхом. Прогулки, игры, встречи с друзьями — когда ты целый день разрешаешь себе вообще не подходить к рабочим вопросам что влияет хуже всего: • утренние тренировки • стресс и любая средне-высокая нагрузка • алкоголь — это вообще смэрть. Хуже этого, по-моему, ничего быть не может. Не скажу, что стал трезвенником, но выпивать стал точно реже, потому что уже знаешь цену каждого бокала вина но не надо слепо доверять цифрам и, увидев 30% recovery, говорить себе: «ну все, сегодня ничего не делаю». Это просто числа, которые помогают жить чуть более осознанно и не загонять себя в работе, тренировках и жизни в целом. плюсы: • заряжаю раз в две недели • сам подгоняет спать, сам понимает, когда вы уснули и когда проснулись • реально интересно следить, что и как влияет на твое здоровье и состояние. В какой-то момент это вообще превращается в игру. Приложение пишет тебе что-то вроде: «baseline уровень кислорода в крови повысился, ты стал выносливее», — и ты реально это ощущаешь. Это прям бустит мораль главный плюс — я реально стал лучше прислушиваться к своему организму. Да, это можно делать и без Whoop. Но с ним просто интереснее. минусы: • надо прилежно вести дневник, иначе половина прикола теряется • надо записывать нагрузки • надо иногда сверять свои ощущения с цифрами и разговаривать с AI 👀 моя оценка: 42 Apple Watch из 10

👋 дочитал ML System Design от @cryptovalerii и @partially_unsupervised это одна из самых полезных книг не про модели и не про то, как натянуть очередной алгоритм на задачу, а про то, почему ML-проекты разваливаются уже после красивого demo главная мысль лично для меня: ml system design — это сначала понять проблему, цену ошибки, ограничения, как будем интегрировать, что нужно мониторить и только потом уже учить что-то умное. вообще я бы назвал эту книжку настольной. Иногда перечитывать и заострять свое внимание на важных моментах очень полезно. вот как раз эти мысли, про которые было бы хорошо вспоминать при разработке различных систем: 1. понимание problem space важнее чем solution space очень частая ошибка в командах разного уровня: тебе говорят "давайте сделаем персональные рекомендашки" и инженеры начинают блестать своими знаниями о зоопарке различных алгоритмов. А потом оказывается, что крутая модель по оффлайн метрикам вообще не вывозит онлайн, так как рассматривает товары по одиночке, а бизнесу, например, важно собирать наборы товаров. книга напоминает: сначала решаем для кого делаем решение, что реально у них болит, как выглядит успешное решение, сколько стоит цена различных ошибок. 2. дизайн док — это не бюрократия, а способ не потратить 3 месяца вникуда. Док нужен, чтобы вовремя понять — может 90% результата можно достигнуть обычными правилами 3. валидация важнее, чем кажется можно получить красивые оффлайн метрики и потом убить систему в production просто потому, что split был нереалистичным. Банально, если в реальности данные меняются со временем, то random split для разделения выборки часто рисует тебе влажные фантазии а не реальность 4. мониторинг — это не только цпу/рам и задержка! Нужно смотреть минимум на 4 слоя: инфра, качество данных, качество модели, бизнес метрики. Да, модель может не сломаться технически, но, например, по метрикам модели или бизнес метрикам вы можете заметить что модель начала деградировать из за дрифта, нового сегмента пользователей или изменения продукта 5. Главная мысль для сеньор уровня. ml system design = правильно поставить задачу -> выбрать честные метрики -> собрать и провалидировать данные -> построить baseline -> улучшать через анализ ошибок -> упаковать в пайплайн -> встроить в продукт -> мониторить дрифт модели и KPI метрики -> заранее обеспечить поддержку системы в будущем. В книге это и есть настоящий e2e взгляд на ml систему, где модель лишь один из компонентов, а не центр решения проблемы. В целом книга понравилась. Иногда было водянисто, но полезные советы выцепить не трудно. Книга очень коррелирует с моими мыслями: лучше стабильный бейзлайн и итеративное его улучшение, чем крутая модель с полугодовой разработкой, которая после месяца использования деграднет 🕺

кремировал свой старый айфон 📱 в 2020 году купил себе первый iphone xr, а пару лет назад пересел на 15 pro. последний год этот дед просто стоял у меня на столе в треноге и работал вебкой (мак умеет по беспроводу тянуть видео с айфона), так что старичок еще послужил. неделю назад я начал разгребать рабочее место, и тренога с xr первой попала под зачистку территории. продавать его не хотелось — мороки много, ценности почти ноль. и тут я вспомнил, что когда-то хотел заказать себе штуку от XReart — они разбирают старые айфоны, красиво раскладывают все внутренности по рамке и продают это как артефакт для техногиков. ну и я подумал — сами сделаем. Крякнем плюнем и надежно склеим скотчем. что сделал: 1. нашел продавца, который делает макет под конкретную модель: где лежат детали, что подписано, как это все скомпоновано. для xr купил jpeg-шаблон примерно за 12 евро. (закину в комменты джипеги для XR). 2. купил набор бит от xiaomi где-то за 1900 рублей и пошел разбирать телефон. тут начался путь настоящего инженера через страдание. • с девушкой долго пытались отклеить экран: грели феном, поддевали, крутили, пыхтели — по нулям • относить в сервис на полный разбор не хотелось, потому что тогда в чем вообще мой вклад в этот арт-объект • в итоге нашел компромисс: в сервисе мне просто помогли отстегнуть экран, потом я еще пару раз заходил добить особенно мерзкие болты и отклеить батарею, потому что я, как настоящий мастер, забыл нормально прогреть крышку и клеевые ленты благополучно порвались 3. распечатал шаблон на нормальной фотопечати и купил глубокую рамку 4. дальше пошла сборка: • клей момент — для ровных и гладких деталей • клеевой пистолет — для крышки и всяких неровных штук • аккуратность Карины — для того, чтобы это все не выглядело как последствия дтп • по итогу получилось прям кайф по деньгам вышло примерно так: 1. шаблон с расположением деталей — ~1к 2. рамка + печать — ~2к 3. набор бит — ~2к 4. клеевой пистолет — ~500 рублей 5. помощь сервиса — ~500 рублей итого: около 6к–6.5к и неделя возни и честно — мне очень нравится сама идея так «отправлять технику на пенсию» не просто кинуть в ящик или продать за копейки, а превратить девайс, с которым у тебя был кусок жизни, в нормальный физический артефакт. ⚰️ как вам такая утилизация?

👋 прочитал от Игоря Котенкова лонгрид про домашку от антропик Anthropic's Original Performance Take-Home читал в 3 захода. очень интересно, но мои джипитишные мозги уже тяжеловато заставить шестеренкам крутить 😎 вот сам лонгрид в целом вся задачка, это показательный кейс про то, как вообще рождается перформанс. вот в этом посте я разбрал лекци от яндекса, где тоже рассказывали про насущную проблему memory/compute bound вычисленй в обучени LLM. в целом лонгрд имеет отличную структуру повествования. сначала у тебя есть наивная реализация. потом ты понимаешь: • можно векторно обрабатывать сразу пачку объектов • не надо бессмысленно гонять одни и те же данные между DRAM и scratchpad • мало просто ускорить математику — нужно еще плотно упаковать инструкции, чтобы больше утилизировать доступных мощностей ну и наверное для меня самая полезная мысль, как для инженера: ботлнек почти никогда не живет только в алгоритме. важно думать о том, как именно двигаются данные и как железо переваривает нструкции. в общем, кайфовый материал 😎

решил все таки подсобрать свои заметки по YC startup school и написать свои мысли. это бесплатная онлайн школа от Y Combinator, которя покрывает весь путь создания продукта. Здесь собраны основные идеи которыми пользуются большинство предпринимателей. Просмотрев этот курс, скорее всего ни один, даже платный "курс создания гига бизнеса" вас не удивит. эта школа целом выбивает из головы весь гламур из подхода к созданию продукта. мы отказываемся от мыслей про фандрайзинг, про выбор идеального стека, про красивые разговоры о росте выручки и приходим к довольно жёсткой мысли: стартап = сделать штуку, которую люди реально хотят. Всё. Остальное вторично. что мне особенно понравилось: • нельзя влюбляться в технологию раньше проблемы. Я с таким сталкивался, когда разобрался как работает блокчейн, пописал какие-то смарт-контракты и думал "куда же можно натянуть блокчейн, чтобы было хорошо". YC опускает на землю и говорит, что хорошие идеи обычно растут из founder–market fit, личную боль и реальную экспертизу • запуск — это не одно событие, а цикл: запуск -> обратная связь -> итерируемся -> снова запускаем. Не надо ждать идеально момента для запуска, не надо надо вылизывать ваше решение. • фаундер в начале делает то, что не масштабируется. Надо лично писать юзерам, лично продавать, онбордить, собирать фидбек. Продукт почти никогда не рождается сразу готовым. Он дотачивается руками, в плотном контакте с первыми пользователями. Запустите максимально сырую версию, найдите 10 человек, которым ваше решение помогает и полируйте решение с учетом их фидбэка. • не путайте занятость с прогрессом. Фаундеры пипец занятые: встречи, фичи, обсуждения бренда, найм, юристы, псевдо полезные разговоры. И при этом могут вообще не двигать главные метрки. YC в этом месте очень категоричны: найди bottleneck и бей только в него, потом ищи следующее узкое место и снова бей. Всё остальное часто fake progress. • будет много неудачных гипотез. Часто ошибаются даже в самой постановке проблемы, в её остроте, в целевом пользователе и в том, стоит ли её вообще решать. думаю видео и статьи из этой школы полезны не только будущим фаундерам. Инженерам она очень хорошо ставит продуктовый взгляд. Предпринимателям дисциплину мышления. А всем остальным напоминает простую вещь: реальный прогресс обычно выглядит намного менее глянцево, чем кажется со стороны.

ну что, роднички ❤️ каждый раз когда подписываюсь на канал с многовековой историей 🗿 ощущаю fomo — канал интересный, но я уже пропустил кучу постов. Ну и тут два выхода: либо читать все, либо ничего захотелось помочь тем, кого занесло на мой канал что бы я прочитал, зайдя сюда: - Серия постов по мл базе с конспектами: линейки, метрические методы, леса, ансамбли, случайный лес, бустинги, подбор гиперпараметров. - Простой и быстрый алгоритм для отбора признаков — алгоритм тупой, но долгое время в проде работал, так как быстрый и ошибается не значимо. - про заметки, obsidian и zettelkasten - Писал на хабре статью небольшую про стратегическое планирование - Лонгрид про блокчейн и как это все устроено низкоуровнево - как у Valve получается создавать крутые игры/продукты для юзеров при учете того, что штат весьма не велик. Здесь же можно почитать про работу в OpenAI и про Пашу Дурова с телегой - Достаточно легкий постец про историю RL и как дипсики пришли к GRPO и ходом можно сразу заметку по GSPO почитать - whoop — может кто то думает брать или нет, будет полезно - здесь в посте про один митапчик от яндекс прикольная идея про LLM Cache - мысли и конспекты про серию лекций от яндекс LLM Scaling Week старички, кто со мной давно, можете в комменты закинуть какой из этих постов больше всего вам понравился/запомнился 😎

⚠️ ща чуть духоты наволю, а на днях про опыт с вуп расскажу и какие-то мысли по ходу разработки стартапчика 😑 посмотрел, законспектировал неделю лекций от Яндекса про масштабирование LLM при обучении и инференсе Душно и навряд ли пригодится какому-то prompt context engineer, но мне нравится когда мне поебывают мозги, расширяет кругозор 🌌 1. Арифметика глубокого обучения. Здесь про основные проблемы обучения LLM (гпу простаивает, обучение занимает много памяти — не влезает в одну гпу, надо как то параллелить). Рассказали про логистику данных данных в рамках гпу и хоста. Были интересные примеры расчетов времени выполнения каких то базовых операций на гпу. Типы коммуникаций между несколькими карточками. 2. Mixture of Experts. Думаю многие знают идею. В LLM знания "хранятся" в полносвязном слое. Давайте сделаем его достаточно большим, чтобы модель смогла впитать в себя как можно больше знаний. Тогда возникает проблема: слой большой -> инференс долгий. Но нам не нужны все занния, если мы спрашиваем модель "Почему небое голубое?". Решение: давайте разобьем этот большой слой на N маленьких, давайте перед этим слоем с экспертами поставим промежуточный полносвязный слой, который будет просто распределять токены по разным экспертам. Во время обучения добавляем к лоссу штраф за неравномерное распределение по экспертам и в конце получаем экспертный параллелизм. У нас есть N экспертов, N гпу, на каждом гпу свой эксперт. Роутер возварщает распределение вероятностей по экспертам -> выбираем топ K экспертов -> отправляем токен на гпу с этими экспертами. Выигрыш — мы можем обучить огромную модель и распределить ее знания между несколькии картами. 3. Ускорение за счет FP8 и смешанной точности. В целом лекция про инференс моделек 3.1 Лексия Самая интересная лекция лично для меня. - Слышал про спекулятивный декодинг, но тут более менее разобрался + почитал статейки. Если упрощенно, то на инференсе очень дорого по компьюту генерить токены большой моделькой так как на каждый токен нужно делать полноценный форвард. Идея: давайте генерить маленькой моделькой K токенов, а потом проходить одним форвардом по всей последовательности и проверять маленькую модель. Если мелкая модель ошиблась, тогда честно пересчитываем токены в которых ошиблись. - квантизация. Модель у нас в fp32, но можно попробовать считать в меньшей точности без потерий качества — выигрываем и по скорости, и по памяти. Мне очень понравился блок про SmoothQuant: веса квантовать легко, а при квантовании активаций появляются выбросы (так как в активациях какие то значения ультра мелкие, какие то ультра большие и их тяжело смаппить на разреженную сетку значений INT8. У смузкванта идея простая — давайте перельем "сложность" квантования с активаций на веса. Звучит непонятно, но это надо смотреть на то как это работает и на каких то абстракциях все очевидно становится. - ну и про дистилляцию знаний рассказали. Есть большая модель-учитель и мы на ее ответах учим мелкую модель-ученика подрожать своему учителю. 4. Коммуникации в распределении. Про то как распределять данные по гпу, как собирать данные с гпу при распределенном обучении/инференсе. 5. Ну и семинарчик тоже был Закину в коммента коспектики со слайдами и какими то моими записями по ходу лекций