Марков цепи пропил

Робо-стартапы би лайк: позвольте представить вам дружелюбного помощника в ежедневных делах

22580: From GPT2 to Kimi3, Explained [тык] Интересный краткий пост про то, как и почему менялась архитектура ллмок. Закинул перевод на gist [тык]

Нашел скрытый гем в виде папир про механические вычисления в 21-м веке. Здесь автор пытается топологически обосновать, что связал полусумматор https://arxiv.org/pdf/2606.14062v1

В общем вроде немного отдохнул, и снова появились силы что-то делать В последнее время много думал над тем, как можно оптимизировать поиск/добавление новых провайдеров для обходов, и пока ресерчил - слегка приуныл. Я пришел к выводу, что правильным/эффективным решением будет скорее создание определенного dsl для туннелирования трафика поверх существующей сети. Не только через webrtc (потому что чем дольше варюсь в этом, тем больше потенциальных точек отказа и фундаментальных проблем вижу), а через множество нод, пригодных для п2п общения. Вроде таблиц, с3 хранилищ, мессенджеров и прочего. Но я все еще не до конца придумал, как оно должно в итоге выглядеть/взаимодействовать между собой. Короче говоря, буду дальше экспериментировать и собирать информацию в надежде, что что-то из этого да выйдет. Параллельно подумаю еще над чем-нибудь интересным с инженерной точки зрения, а пока, наверное, надо возвращаться к привычному щитпостингу. Пока что по просьбе трудящихся раскатил v0.3.8 для байпаса. Добавил возможность прикрепить email/password к диону, чтобы избавиться от проблемы с протухающими куками. Обновил ВК, добавил KCP для vp8 в wbstream (пока только там; флаг reliable в приложениях; должно поправить ssl error и его производные), сделал генерацию qr кода в creator app + qr scanner для андроида, и еще ряд мелких фиксов. Релиз как всегда здесь [тык]

Увидимся на конференции (новость - https://x.com/i/trending/2079049775828423158)

С гитхаба пропал https://github.com/flowseal/zapret-discord-youtube вместе с аккаунтом автора. Здесь два варианта: либо майкрософт стала бороться с проектами по обходе блокировок (непонятно зачем), либо до создателя добрались люди в погонах в лучших китайских традициях. В любом случае пока наблюдаем. В скором времени, наверное, напишу в какую сторону планирую двигать опенсорс для обхода блокировок, а то что-то давно не постил

Новостей пока нет, но хоть над мемами про глобальные лэйоффы HR'ов посмеёмся

Прикольное - nvidia представила ARM чип для ноутбуков https://www.nvidia.com/en-us/products/rtx-spark/

Хотел накидать пару алогоритмических длиннопостов касаемо одной CV задачи, но пока, видимо, не судьба. В ближайшее время хочу поресерчить и генерализировать одну вещь в data-over-webrtc проектах. Хз, что из этого выйдет. Сейчас раскатил v0.3.5 [тык] с небольшими улучшениями. Теперь в релизах добавлены headless бинарники для arm64. Немного улучшено андроид приложение (спасибо автору [реквеста]). Добавлена возможность закидывать трафик creator'a в проксю, ну и всякое остальное по мелочи. По возможности поднимайте на локальных машинах/одноплатниках, потому что, кажется, сейчас стали усердно следить за тем, какие айпишники совершают звонок

WB начал банить - не сидите с личных аккаунтов

Отчёты перед инвесторами дуреют от этой прикормки https://arxiv.org/abs/2309.08632

Требуются вайбкодеры убыточных Crypto AI B2B SaaS решений (не штурм)

Кажется цивилизованному миру все же нужен не дискорд по паспорту, а ЛЛМки по справке от психиатра

Weekly update - v0.3.4 Пока промежуточный билд в рамках большого обновления. Сделан полный редизайн андроида; теперь выглядит +/- по-человечески. Добавлено переподключение в случае утери связи/перехода с wifi на cellular для всех платформ. Для wbstream'a реанимирован dc режим. Так же (пока только для wbstream) появилась настройка vp8 -> dual track, чтобы получить x2 скорость в режиме data over video. По дефолту отключено, и я настойчиво прошу не нагружать инфраструктуру без крайней нужды кучей трафика. Также появилась возможность задать интерфейс для socks5 - если нужно раздать сеть надо поменять в settings -> proxy -> socks5 host с 127.0.0.1 на 0.0.0.0. Пребилды как всегда [тут], а щитпостильня с обсуждением багов feature-request'ов - [здесь] 😋

Про Groq LPU и dataflow Как говорится: “сначала маленькая историческая справка”. Dataflow-архитектуры это концепция, которую сформулировал Джек Деннис в MIT ещё в 1974. Идея простая: процессор не исполняет программу как последовательность инструкций, а гоняет данные через сеть вычислительных узлов. Узел запускается ровно тогда, когда на всех его входах накопились операнды, и порядок исполнения определяется готовностью данных, а не счётчиком команд. Сама идея идет в противовес фон Неймановской машине с регистровым файлом и указателем на следующую инструкцию. В 80-х под это пилили реальные машины (Manchester Dataflow, MIT Tagged-Token, Monsoon), и все они померли, потому что фон Нейман + кэш + спекулятивное исполнение оказались дешевле и универсальнее. Идея ушла в спячку и осталась жить в нишах вроде систолических массивов, FPGA-пайплайнов, DSP и т.п. А через 40+ лет ее снова стали реанимировать, потому что наконец появился новый клаас задач, на который эта архитектура хорошо ложится. Что это за класс задач. Инференс LLM на batch=1 упирается в memory bandwidth: на каждый сгенерированный токен надо прочитать все веса модели целиком и прогнать через них один входной вектор. Например, Llama-70B в fp16 это 140 ГБ весов, и эти 140 ГБ надо протащить из памяти в матричные юниты один раз на токен. На современном GPU с HBM3 на ~3 ТБ/с теоретический потолок 3000/140 ~ 21 ток/с, и никакие TFLOPS тензорных ядер не спасут, потому что matmul вырождается в matrix-vector ([1, hidden] x [hidden, hidden]), и использование тензорных ядер падает до однозначных процентов. Они большую часть времени простаивают в ожидании данных. Под эту нишу и заточен Groq. Так как модель исполнения другая, из чипа уходит большая часть привычной GPU инфраструктуры. HBM не нужна, потому что веса целиком держатся в on-chip SRAM. Кэши не нужны, из-за той же SRAM с равномерным доступом => иерархию строить незачем. Warp scheduler не нужен, потому что нет конкурирующих за вычислители потоков. Остаются функциональные блоки: MXM для матриц, VXM для векторов, SXM для пермутаций, MEM для банков SRAM. Они разложены полосами, и данные физически текут через них с фиксированной скоростью, один шаг полосы за такт. Всё расписание фиксируется на этапе компиляции: компилятор знает, что веса лежат в таком-то банке SRAM, активация окажется напротив MXM на такте T, и расставляет операции так, чтобы под каждым юнитом в каждый такт был нужный тензор. В рантайме железо просто исполняет план. В такой архитектуре кратно возрастает пропускная для весов. SRAM сидит прямо рядом с MAC-ами, доступ занимает фиксированное число тактов, без промахов кэша и без очередей к контроллеру памяти. По пропускной способности это на порядок выше любой HBM (в текущем поколении LP30 порядка 150 ТБ/с против 20 ТБ/с на стек HBM3e). MXM-массивы не простаивают, потому что операнд гарантированно приедет в нужный такт по расписанию. Но у этого подхода есть ряд недостатков. SRAM маленький, поэтому модель приходится размазывать на много чипов в детерминированной сети + компилятор планирует ещё и межчиповые передачи такт в такт. Под обучение всё это в принципе не годится: там нужны большие батчи, динамические графы, бэкпроп и прочее. Плюс вся сложность размещения, шедулинга и межчиповой синхронизации переехала в компилятор, и под каждую модель надо перекомпилировать весь граф