Смотри что нашел

Релизнули GLM-5.3 https://z.ai/blog/glm-5.3 С точки зрения архитектуры LLM ничего нового нет (на первый взгляд) это чисто post-training релиз. Просто стало выше-сильнее-умнее. Надеюсь следующий релиз будет мажорный, где скопируют работу с KV кешем из DeepSeek. Забавно, что в ZCode модели еще нет (я на max плане). Вообще вот DeepSeek мне еще нравится тем, как они релизы делают. Все везде и сразу. У z.ai с этим конечно беда бедовая. Пойдите найдите на сайте хоть что-то про 5.3, удачи :)

DeepSeek выкатил (пока в превью) свой агентский харнесс https://github.com/deepseek-ai/deepseek-harness P.S. если вы не знали, то тут секта DeepSeek-а 😂

ничего себе акция невиданной щедрости на qwencloud.com qwen3.8-max, кстати, неплох. Особенно в простом чате, для исследования пейперов или погружения в конкретную тему. Единственное помните, что qwen модели раскрываются при построени промпта по фреймворку…

ничего себе акция невиданной щедрости на qwencloud.com qwen3.8-max, кстати, неплох. Особенно в простом чате, для исследования пейперов или погружения в конкретную тему. Единственное помните, что qwen модели раскрываются при построени промпта по фреймворку C.O.S.T.A.R. (это прямо написано в документации)

Земля пухом сервисам Яндекса. https://yandex.ru/company/news/29-07-2026-01 Ну вот почему 75%? Почему не 67%? Просто ради красивой циферки? Многие смеялись над гигачатезацией в одной зеленой компании, а по итогу вон как получилось…

Митап «Старый добрый Go в мире AI-агентов» — 24 июля в 18:30 в Санкт-Петербурге, в офисе VK (ТДЦ «У Красного моста», наб. реки Мойки, 73). Совместно с VK канал IT-подкастов «Алло, Ада» проводит Go-митап о том, какую роль язык играет в эпоху AI-агентов и как интегрируется в инженерный контур облаков и инфраструктуры. В программе — три доклада и круглый стол: - как обезопасить доступ ИИ к проду через Go и MCP 💪 - как превратить работу с инфраструктурой данных в навык AI-агента 🤖 - как DRA-драйвер на Go меняет модель работы с GPU 💻 - действительно ли простота Go — преимущество или недостаток в эпоху AI-агентов 🤔 Среди спикеров — представители VK, Фланта, h3llo cloud и MWS Cloud Platform. Регистрация: https://allo-ada.tech/meetups/go-ai-agents

Привет. Это мой небольшой разбор статьи из прикрепленного файла. Я решил сконцентрироваться на главной идее, но в самой статье есть технические детали реализации, которые не менее интересны. Найдите время почитать. Слышали такой тезис «сеть узкое место, CPU в избытке»? И раньше действительно было так, и оверхед на TCP стек был небольшой. Увы, эти времена прошли :( За 10 лет aws инфраструктура под сетевые нагрузки выросла радикально: сеть с 10 до 200 Gbps (×20), но CPU за ней не успевает. Если в 2013 году нужно было всего 3% CPU для утилизации сети, то сейчас уже больше 30% (20 ядер из 64 только на сеть). Почему так вышло? Современные NIC (Network Interface Card) могут переваривать порядка 30 миллионов сообщений в секунду, таким образом сервер на 64 ядра 2.6GHz сможет раскрыть такой NIC, если будет тратить на одно сообщение порядка 5000 тактов. Проблема тут в том, что на обработку одного сообщения через kernel TCP стек будет уходить около 10000 тактов. Это приводит к тому, что сетевая карта простаивает 50% времени. TCP такой дорогой не потому, что он сильно плохо реализован в ядре Linux, а потому, что сам алгоритм не простой: - congestion control - in-order delivery - segmentation (фрагментация по MTU) - stream semantic aka мы платим за гарантии, которые TCP предоставляет. Окей, гарантии нам нужны, но давайте возьмем userspace реализацию TCP — Seastar. Крутая штука, но выигрыш будет порядка 30%: kernel TCP (io_uring): 5.83 Gbps/core TCP (Seastar): 7.60 Gbps/core (+30%) Кстати, а что там с UDP? Ну, kernel реализация уступает TCP для больших сообщений: 5.83 Gbps/core против 4.67 Gbps/core. А вот если перенести в userpsace на DPDK, то на UDP можно выжать 190 Gbps/core! Шикарно, да? Но у UDP нет гарантий доставки и порядка сообщений (и еще кучи всего). И вот тут нужно себя спросить: а всегда ли нам нужны эти гарантии? Суть статьи кроется как раз в ответе на этот вопрос: не выбирать между TCP и UDP, а использовать каждый протокол там, где он лучше всего раскрывается и приносит максимальную пользу. Bi-channel paradigm -- разделение коммуникации на два класса: 1. data channel -- быстрый канал на UDP, для передачи данных 2. control channel -- медленный TCP для координации Разберем пример для лучшего понимания. Представим, что нам нужно сделать распределенный join. В этом случае много данных будут отправляться по сети между узлами. При этом, если это hash join, то порядок нам не важен, важно, чтобы нужные данные попали в нужные узлы. Тогда мы можем сами tuple-ы слать по UDP, а TCP использовать как канал для ACK-ов, в котором будет ничтожно мало трафика. P.S. Паттерн разделения исполнения на fast path/slow path достаточно распространен в программировании. Посмотрите на реализацию mutex в Golang: сначала пытаемся покрутиться в spinlock немного, ожидая, что лок будет освобожден быстро, и только потом сваливаемся в futex. Или как делается inlining. Делим функцию на 2 части: 1. маленькую и быструю, которая будет заинлайнена и будет вызываться в большинстве сценариев 2. fallback на громоздкую, которая не подлежит инлайнингу, но вызваться она будет реже.

Наконец-то выкладываю запись к себе в канал https://www.youtube.com/watch?v=XLLIAXR2M2Q. Презентация тоже по ссылке в описании.

Я сам еще не смотрел, но Леша фигни не делает :)

Ну наконец-то приняли https://github.com/golang/go/issues/77273#issue-3845127408 Отрадно, что generic-и в Golang развиваются. Вопрос конечно почему сразу не сделать нормально открытый, как всегда :) tldr; теперь можно будет делать generic методы на обычном не дженерик типе или расширять методы другим дженериком

Мои знакомые из Центрального Университета устраивают митап по ИИ 21го мая в 18:30, кампус Центрального Университета - Москва, ул. Гашека, 7 (метро Маяковская). Будет три доклада, где ребята поделятся опытом запуска LLM на iPhone, расскажут про Agent Client Protocol и как его использовать при построении своего Cursor, а также затронут тему подготовки проекта к агнетскому программированию. В конце будет круглый стол на тему прайваси при использовании моделей внутри компаний. Ссылка на регистрацию. P.S. Мне самому будет интересен круглый стол, ибо еще пару месяцев назад, я считал, что лучшая стратегия это всегда выбирать Opus, так как код стал комодити и смысла бояться его "утечки" нет (конечно с оговорками некоторыми). Но последние новости с баном аккаунтов антропиками, ухудшением моделей, с баном аккаунтов в openrouter наводят на мысли, что для компаний иметь личный кластер условного DeepSeek или GLM не такая уж и бредовая идея :)

вот только вчера думал, почему нет хорошего бенчмарка агнетов :) Вообще с выходом (и использованием на постоянку) deepseek v4 еще глубже укоренилась мысль у меня, что на данный момент больше решает агент (или если более широко, то harness), чем модель. Ибо модели уже достаточно хороши для повседневных задач. https://artificialanalysis.ai/agents/coding-agents

https://lightfoot.dev/direct-i-o-for-cassandra-compaction-cutting-p99-read-latency-by-5x/ Наткнулся на офигенный разбор про Cassandra и дисковый ввод-вывод. TLDR; чел заставил компакшн работать через direct i/o и получили пятикратный буст по p99. Вся боль в том, что компакшн (да и любые фоновые процессы работающие с диском) по идее должен быть … фоновыми, то есть не сильно на себя забирать ресурсы системы, но по факту происходит "драка" за page cache" между основным процессом и компакшеном (в случае с Cassandra). В итоге идея проста: давайте откажемся от page cache и будем ходить в диск напрямую :) тогда linux никак не будет нам мешать своими оптимизациями. Статья — очередное доказательство тому, что узко специализированное решение бьет generic подход. P.S. на самом деле занести direct i/o это не тривиальная задача. Возникает требование к выравниванию, ты теряешь оптимизации ядра, которые помогали, а не мешали и дальше куча НО. Короче, думать нужно об этом далеко не впервую очередь и то, что Cassandra жила столько времени без direct i/o тому доказательство

Ну, полетели!

Продолжаем геммапропаганду. В прошлом году у NVIDIA вышла неплохая статья о том, как ловить людей, которые доливают тест в трейн. CoDeC – нормализованный показатель перплексии, где для тестсета бенчмарка считают изменения в перплексии с дополнительными примерами из того же бенчмарка. Для неконтаминированных моделек мы ожидаем, что дополнительные примеры не будут сбивать модель с толку, а в лучшем случае помогут. С другой стороны, если модель запомнила текст из теста, дополнительные примеры собьют её с толку и уверенность модели в ответе упадёт. Шкала нормализована от 0 до 100, где ~80% значит, что примеры из теста модель видела буквально, ~40% – в перефразированном виде. Товарищ с твиттера посчитал CoDeC для Gemma 4 и сравнил с Qwen 3.5 – почему-то у наших китайских коллег модель почти запоминает примеры из теста.

вы не поверите! никогда такого не было и вот опять ловят китайские модели за руку :)

🚨 В ближайшее время Claude резко подорожает — скорее всего, в 10+ раз. Если вы потребляли 10 миллиардов токенов за восемь месяцев при тарифе Max за 100 долларов в месяц, то теперь компании за тот же объём API должны платить 15 000 долларов всего за одного разработчика. Причина в том, что лицензией Anthropic уже запрещено покупать фикс-тарифы компаниям, а разрешено только фрилансерам. Изменение лицензии гласит: "Organizations currently using seat-based Enterprise plans with Standard and Premium seats will not be able to continue with this billing model past your next contract renewal" В Claude Code внедрена обширная телеметрия, и при обнаружении использования индивидуальных подписок внутри компаний такие аккаунты банятся. В серьёзном бизнесе, который не пойдёт на нарушение лицензионных соглашений, это на деле уже не вариант. Расчёт Дарио очень простой: значительному количеству его богатых клиентов из Fortune 500 просто «не деньги» платить ему в месяц даже по 10 000–15 000 долларов с разработчика. Разработчики часто стоят на контракте около 40 000–50 000 долларов в месяц, поэтому это «приемлемая цена». В реале счета скорее всего будут несколько тысяч долларов в месяц на разработчика, что Enterprise приемлемо совсем. Дарио сознательно идёт на то, что «мелочь отвалится», но сверхдоход от Enterprise-клиентов перекроет потери. Получится со временем диковинная ситуация, когда Claude — инструмент студента-фрилансера (на тарифе фиксе) и разработчика долларового миллионера вроде тех, что в Nvidia. Тем не менее, кто оказался посередине, уже стоит думать о «Плане Б». Счета по 10 000 долларов в месяц более чем реалистичны. У нас в чате бывали пользователи через API — они действительно сжигали по 400 долларов в день на тарифы в токенах у Anthropic. Вопрос не касается тут того, что у всех вендоров LLM искусственно дотируются тарифы. Из финансового отчёта Anthropic за 2025 год видно, что на мощностях GPU в ЦОД, которые они ввели в эксплуатацию, они зарабатывают порядка 1,6 доллара с одного вложенного доллара в оборудование. Убыток там от расходов на ЦОД, которые еще не стали приносить кеш и еще строятся. Вопрос в том, что Дарио хочет стать «Apple в мире LLM». Ему просто не нужны 90 % пользователей, он готов их отдать OpenAI и Google, а хочет забрать себе 10 % пользователей, которые согласны переплачивать за бренд сколько скажут. И это более чем работает. В случае Apple у неё порядка 10 % мировых продаж смартфонов, но 90 % прибыли всего рынка смартфонов. Поэтому бизнес-модель Дарио более чем рациональна. Тем не менее, такой подход приведёт к тому, что доля Claude начнёт сейчас быстро сжиматься. И вопрос — кто станет «Android в мире LLM», которому будет принадлежать 90 % рынка в терминах пользователей. В прочем, Дарио еще может и одуматься. Ряду корпоративных клиентов он предлагает Team/Enterprise подписки с аналогом фикса, но это индивидуальные предложения. https://blog.kilo.ai/p/anthropic-doesnt-want-your-subscription

А я вам говорил!