IT

Недавно для себя открыл, что приём из CUDA C Best Practices работает и на чипах Apple Ядро GPU держит сразу несколько SIMD-групп, и когда одна группа ждёт данные из памяти, ядро выполняет инструкции другой. Можно подумать, что чем больше групп на ядре, тем лучше, однако все группы делят между собой регистры и shared memory ядра, поэтому если групп становится слишком много, регистры перестают помещаться на ядре, и данные уходят в кэш. Этот трафик мешает кернелу загружать собственные данные, из-за чего ядро замедляется. Собственно, [приём] для CUDA заключается в том, что можно выделить кернелу shared memory больше, чем ему нужно - это приведет к уменьшению числа групп, и, как следствие, данные перестанут вытесняться. До M3 на чипах Apple число групп ограничивали регистры, каждая группа сразу получала их под самый тяжёлый участок кернела. С M3 регистры выделяются по ходу работы, групп на ядро влезает больше, и чтобы их данные не вытесняли друг друга из кэша, Apple добавила блок, который называет occupancy manager (далее планировщик). На M3 и M4 он снижает число групп, когда из L1, общего для регистров, shared memory и кэша буферов, начинают вытесняться данные. Но этот планировщик работает криво, потому что не снижает число групп, когда через L1 идут данные регистров. На умножении матрицы сразу на несколько токенов он держит 26-27 SIMD-групп на ядро, хотя быстрее всего кернел работает при 8-14. Такое умножение нужно для MTP, где модель набрасывает несколько следующих токенов и проверяет их за один проход. Metal не даёт задать число групп вручную, но приём для CUDA можно заставить работать и здесь. Shared memory в Metal (threadgroup memory) выделяется сразу на одну или несколько SIMD-групп, и новые группы ядро не запускает, пока для их памяти нет места, поэтому лишняя память уменьшает число групп. Чтобы компилятор её не выкинул, в кернел добавляется запись в эту память, которая никогда не выполняется. Лучшее число групп у разных матриц разное, в той же Qwen3.8 на 4 токенах умножение 5120×17408 быстрее всего при 10 группах, 17408×5120 при 24, а от типа квантования лучшее число меняется от 6 до 24. Я пытался вывести формулу по числу регистров, байтам на вес, объёму вычислений на байт и прочим переменным, но не вышло. По лучшей составной формуле кернел в среднем на 5-7% медленнее, чем с оптимумом, найденным перебором. К тому же на той же матрице при 16 группах трафика регистров уже нет, а умножение всё равно по скорости такое же, как и без ограничения (413 мкс против 418), и лучшее время в 349 мкс получается только при 10 группах. Что тормозит кернел между 16 и 10 группами, я так и не понял. Возможно, размер регистрового файла и другие константы чипа помогли бы разобраться, но Apple их не публикует. Поэтому для тестов в llama.cpp число групп подбирает тюнер, который в первые проходы генерации пробует для каждой матрицы вариант без лишней shared memory и несколько её объёмов от 2 до 32 КБ и оставляет самый быстрый, на это уходит около 2 секунд работы GPU. На первой картинке время прохода четырёх моделей в llama.cpp без тюнера и с ним. У Qwen3.8-27B в Q4_K_M проход на 4 токена сокращается со 133 до 113 мс, на 5 со 177 до 127 мс, а у той же модели в Q6_K выигрыш доходит до 38% (на 1-3 токенах llama.cpp работает другим кернелом, которому ограничение не помогает, а на 6 выигрыш почти пропадает, там кернел считает токены двумя частями по 3). На второй картинке то же умножение матрицы 5120×17408 в MLX. В f32 ограничение числа групп ускоряет его на 4 токенах с 374 до 288 мкс, правда в bf16, в котором MLX считает модели, выигрыш сильно меньше. Видимо, в bf16 кернелу нужно меньше регистров

Чем меньше вам собираются платить, тем быстрее надо бежать подаваться на вакансию 😂 Правильный ответ на вчерашнюю загадку $80K. Я тут получила доступ к данным по 1,35 млн вакансий в США, и первая же закономерность меня удивила. Оказывается, чем выше зарплата, тем дольше вакансия остается опубликованной на сайте работодателя. До $100K — 29 дней $100–150K — 36 дней $150–200K — 45 дней $200K+ — 50 дней То есть вакансии с зарплатой $200K+ живут почти в 1,7 раза дольше, чем вакансии до $100K. Я сначала подумала: ну понятно, просто низкооплачиваемые позиции чаще junior, а senior и executive искать сложнее. Но нет. Если взять только senior roles, картина практически такая же: 30, 36, 45 и 52 дня соответственно. Почему так? Есть несколько гипотез. Первая, на менее оплачиваемые позиции может быть больше подходящих кандидатов, проще требования и короче hiring process. Вторая, которая мне особенно интересна: кандидаты сами себя дисквалифицируют из вакансий с зарплатой $200K+. Даже если по опыту вполне подходят. Видят зарплату, название компании, требования и решают, что это не их уровень. Хотя hiring manager, возможно, решил бы иначе. Третья, высокооплачиваемые вакансии могут дольше висеть из-за сложности согласований, требований к кандидату или потому, что компания собирает pipeline на будущее. Но это всё гипотезы. Данных по количеству applicants у нас нет, поэтому проверить причины пока невозможно. Что из этого следует для поиска работы? Если ищете работу до $100K, я бы особенно не откладывала отклики на потом. А если целитесь в $200K+, не надо автоматически отсеивать себя из-за зарплаты. Пусть лучше работодатель решит, подходите вы ему или нет. Это первая находка из большого исследования. Дальше покажу, что происходит с remote, seniority и AI-вакансиями. Там тоже есть сюрпризы. #statistics #сша

Я мигрировал Personal OS с git repo на server-side RAG с песочницей История экспериментов с Personal OS: (1) первый эксперимент с Git+Obsidian - 8 февраля 2026 (2) Описание структуры Personal OS - 27 февраля (3) сравнение с LLM Wiki Karpathy - 5 апреля (4) субличность Марка - 23 Мая Эксперимент 12. Yggdrasil В Personal OS набралось полторы тысячи документов. Вчера я почти все с диска и перенес на сервер. Новый сервер - это самописный файловый сервер с отслеживанием версий. Он выполняет почти все мои хотелки из прошлого (кроме типизированных документов, ибо больше не важно) Основные различия по сравнению с git + Obsidian: (1) не нужно чехарды с git командами при работе. (2) в отличие от Notion и аналогов - изменения глобально версионированы (а не по файлам отдельно). Можно откатить изменение агента, даже если он поменял тысячу файлов в разных workspaces одновременно (3) у всех участников поиск работает одинаково (4) оно сразу заточено под одновременную работу нескольких человек с их агентами над общими материалами. Под капотом - golang + SQLite + CAS + MCP API 2.0 + CLI (ставится сразу в системную папку для Codex-a) + Borg Backup на удаленный сервер. Первые впечатления - стало проще работать с файлами. Можно отправить агента завести себе workspace, не задумываясь про git push/pull итп. И можно не держать в голове текущее состояние git папок при работе. Если агент сказал, что сохранил транскрипт разговора с выжимкой, значит он уже лежит там и доступен всем. Про конфликты от одновременной работы можно не беспокоиться, откаты изменений есть. Но в минус - агенты находят документы быстрее, но стали дольше копошиться с их изменением. Оказывается, когда файлы лежат где-то там, их нельзя так просто взять и изменить. У Sol 6.1 уходило 6 c половиной минут на то, чтобы отработать такой запрос: > hey, capture that latest exchange with Aigiz into Bragi (continuing our last conversation)... (Под капотом Марк должен подключиться к серверу, найти нужный workspace, понять принципы организации capture/distill/arks, подшить куда надо, немного перелопачивая файл на 70kb, собрать изменение и смерджить его) Поэтому пришлось поставить ряд экспериментов в поиске tool calling интерфейса, который бы позволил кодексу решать эту RAG задачу быстрее. Самое забавное, что этот интерфейс оказался питоном. Вместо того, чтобы тягать файлы c сервера туда-сюда (удачи со случаем, когда мы делаем replace по папке), агент пишет маленький скрипт, который отправляется на сервер и в изолированной песочнице работает с изменениями в рамках сессии там. То есть не нужно мучаться с придумыванием оптимальных инструментов для MCP/API/CLI, когда можно сказать “писать питон вот сюда, вот тебе описание SDK”. В итоге теперь аналогичная задача выполняется Sol 6.1 без лишних танцев с бубнами за три с половиной минуты. Причем половина времени тратится на RAG задачи, а вторая - на написание текста. Заодно я смог выкинуть из MCP API и CLI все инструменты и команды кроме двух - start (начать новую сессию/commit и получить в контекст описание текущего SDK) и run (запустить питон на сервере). В общем, если у вас у какой-то AI Native системы получается сложный интерфейс с кучей API-шек и инструментов - попробуйте просто дать агентам Python, благо инструментов для этого есть море, от jails до Firecracker VM. Ваш, @llm_under_hood 🤗

Как в MWS Cloud Platform тестируют Kubernetes‑операторы В Kubernetes-кластер добавили новую ноду. Теперь cloud provider должен связать её с виртуальной машиной, заполнить внутренний IP и снять ограничение на размещение подов. Только происходит всё это асинхронно — тесту нужно дождаться обработки объекта и убедиться, что необходимые действия выполнены. В MWS Cloud Platform подобные сценарии проверяют при интеграционном тестировании компонентов Managed Kubernetes. С операторами задача ещё шире: за одним Custom Resource может стоять целая иерархия связанных объектов, а их состояния способны меняться в любой момент. Добавим зависимость от Kubernetes-окружения — и привычных подходов к тестированию бэкенда уже недостаточно.

Улучшаем харнес с помощью ast-grep Утро сегодня началось не с кофе. Пока мы переезжаем (с разной степенью успешности) в другой дц, расскажу про недавнее интересное открытие, связанное с тем как сделать улучшить работу агентов и сделать больше надежных автоматических проверок разных архитектурных правил. Понятно что со временем появляется все больше и больше правил, которые описываются в AGENTS.md (или что лучше в CODING_STANDARDS.md). Но хотелось бы чтобы они чекались автоматом. Клод нам сам постоянно предлагал и в какой-то момент начал писать скрипты допом к линтингу, которые, в основном, регулярками, проверяли что-то. Кушать не просит и ладно, я не сопротивлялся, но видел что это решение на тоненького, хотя и лучше чем ничего. Когда эти скрипты начали копиться, я подумал, хм, а ведь мне ничего не стоит попросить его переписать правила как плагины к линтерам на конкретных языках. Кое что мы так действительно переписали, но в какой-то момент сам клод говорит, а давай заюзаем ast-grep. Я посмотрел и понял что проспал очень логичную штуку. Еще в 22 году, когда полетел treesitter, кто-то замутил инструмент, который грепает не исходники, а AST. Причем что важно, независимо от языка, оно все языки превращает AST и грепает по его нодам. Это резко повышает точность рабатываний, потому что вместо регулярок, которые ловят ненадежно, плюс херово работают с вложенностью, мы имеем по сути универсальный способ представить весь код (и все форматы) в виде единого AST пространства, по которому идет поиск. Ну и естессно переписали все проверки, потому что у этой штуки еще есть sdk для ноды. А все подобные скрипты у нас агент фигачит на TypeScript. Пара примеров: 1. no-unknown-in-generated-types: в сгенерированных фронт-типах (app/javascript/types/serializers/) не должно быть unknown. Typelizer пишет unknown, когда не смог вывести тип поля. Это бывает у атрибута поверх T::Struct или у вычисляемого атрибута без typelize. Тип нужно объявить явно в ресурсе. 2. no-untyped-resource-dsl: в сгенерированных RBI-сигнатурах DSL ресурсов не должно быть T.untyped. Чинить надо в ресурсе или в компиляторе typelizer.rb, а не в RBI. Но это еще оказалось не все. ast-grep в принципе полезен даже вместо обычного грепа, особенно для самих агентов, которые постоянно ищут какие-то символы в исходниках. У ast-grep есть дока с инструкцией, как подключить его к агенту, чтобы агент начал использовать его вместо grep там где это имеет смысл. p.s. Какие еще фишки вы знаете?