[AINews] H100 prices are melting *UP*

[AINews] Цены на H100 плавятся *ВВЕРХ*

спокойный день позволяет нам рассказать о важном тренде в GPU

На GTC 2022 NVIDIA анонсировала архитектуру Hopper, и первые H100 начали поставляться в октябре того же года. Два года спустя, в октябре 2024-го, мы опубликовали популярный материал о цикле обесценивания арендных цен на H100, который, как мы заметили, шёл быстрее предыдущих циклов, и предположили, что это лёгкая динамика лопающегося пузыря из-за временно раздутого спроса. Хотя на тот момент это было верно (дно было достигнуто после шока DeepSeek R1), это не продлилось долго; с декабря 2025 года рынок аренды H100 пошёл ОЧЕНЬ вверх:

Это подтверждается тем, что Dylan на подкасте Dwarkesh говорит, что H100 сегодня стоят дороже, чем три года назад, и это наверняка связано с общим дефицитом чипов и переломным моментом для reasoning-моделей и агентов в декабре 2025-го; полезность четырёхлетнего чипа в связке с куда более качественными reasoning-моделями и софтом для инференса означает, что сам чип гораздо ценнее, чем предполагали изначальные графики амортизации на 4–7 лет.

Если вы привыкли к острию токеномики дата-центров, вам стоит ожидать, что это имеет очень значимые последствия для бизнес-моделей дата-центров и GPU… до тех пор, пока тренд продолжается.

AI News за 26.03.2026–27.03.2026. Мы проверили 12 сабреддитов, 544 Twitter-аккаунта и больше никаких Discord. Сайт AINews позволяет искать по всем прошлым выпускам. Напоминаем, что AINews теперь является разделом Latent Space. Вы можете подписаться или отписаться от частоты рассылки!

Обзор AI Twitter

Утёкшая «Mythos»-система Anthropic и новый тир Capybara

Fortune подтверждает наличие более высокого тира Anthropic выше Opus: уже удалённый пост «Claude Mythos» сохранил @M1Astra, и несколько последующих постов ссылаются на репортаж Fortune о том, что Anthropic вводит Capybara — новый тир выше Opus, «крупнее и умнее», чем Claude Opus 4.6. Согласно обзору репортажа от @scaling01, @Yuchenj_UW и @kimmonismus, Capybara показывает заметно лучшие результаты по кодингу, академическому reasoning и кибербезопасности, при этом развёртывание ограничено соображениями стоимости и безопасности.Центральная тема — вычислительная интенсивность: несколько авторов делают вывод, что Anthropic делает серьёзную ставку на масштаб, с домыслами о модели класса ~10T параметров на основе прежних высказываний Dario, хотя это остаётся неподтверждённым за пределами комментариев; см. @scaling01 и @Yuchenj_UW. Отдельно репортаж Financial Times, переданный @FirstSquawk, сообщает, что Google близка к финансированию дата-центра Anthropic, что подкрепляет тезис о том, что фронтирная конкуренция всё больше упирается в энергию и капзатраты, а не только в алгоритмы.Нагрузка на инфраструктуру была заметна в продакшене: утечка совпала с тяжёлым днём по доступности Anthropic — массовыми жалобами пользователей на ошибки 529 / повышенный уровень ошибок от @dejavucoder, @iScienceLuvr и других. Практический вывод: Anthropic, похоже, балансирует между агрессивными амбициями масштабирования и всё ещё узким окном обслуживания запросов.

Открытые модели для кодинга, локальный инференс и продолжающийся напор GLM-5.1

GLM-5.1 усиливает давление на закрытые модели для кодинга: Zhipu объявила о доступности GLM-5.1 для всех пользователей тарифа на кодинг через @Zai_org, вместе с документацией по использованию в агентах на @Zai_org. Реакция сообщества подала это как ещё один признак того, что топовые китайские открытые или полуоткрытые модели для кодинга сокращают разрыв: @kimmonismus, @XFreeze и более широкий анализ лидерборда от Arena @arena — все указывают на куда более узкий разрыв между открытыми и закрытыми моделями, чем год назад.Экономика локального развёртывания продолжает улучшаться: повторяющаяся тема в твитах — локальные модели теперь «достаточно хороши» для многих рабочих процессов. Примеры: @TheGeorgePu меняет дорогую подписку на TTS на локальную связку Qwen 3.5 14B, @LottoLabs сообщает о хорошей экономике Qwen 27B с Hermes Agent, а @0xSero сжал Qwen3.5-35B достаточно, чтобы вместить полный контекст в 24 ГБ VRAM при падении производительности примерно на 1% в среднем.Квантизация и работа с кэшем остаются ключевыми факторами: @iotcoi выпустил форк TurboQuant vLLM со слитыми (fused) путями записи KV на Triton и decode-attention, ориентированный на Qwen3.5-35B AWQ, контекст 1M и KV-кэш 4M. Тем временем @bnjmn_marie протестировал форматы Qwen3.5 27B на RTX Pro 6000/B200/H100, причём INT4 оказался лучшим вариантом для инференса на железе класса RTX Pro 6000.Но TurboQuant теперь под активной критикой: самая громкая исследовательская полемика в подборке исходит от @gaoj0017 и более подробного разъяснения @gaoj0017, который утверждает, что статья Google TurboQuant с ICLR 2026 исказила RaBitQ в теории и бенчмаркинге, включая нечестные сравнения CPU и GPU. Это не обесценивает инженерную ценность TurboQuant, но ставит под сомнение некоторые публично заявленные сравнительные результаты.

Агенты становятся продуктами, а не демо

Hermes Agent становится точкой притяжения для открытых агентов: наиболее устойчивый продуктовый импульс в датасете принадлежит Hermes Agent от Nous Research. @NousResearch интегрировал Hugging Face как полноценного провайдера инференса с 28 отобранными моделями плюс доступом ко многим другим, а @ClementDelangue подал это как шаг к открытым агентам с памятью, постоянным доступом к машине и выбором модели. Отзывы пользователей от @fancylancer3991, @PolackJack и @alexcovo_eth подчёркивают меньшее трение и лучшую персистентность по сравнению с тяжёлыми на браузерную автоматизацию связками вроде OpenClaw.Инфраструктура для агентов взрослеет вокруг трейсов, evals и отлаживаемости: @ClementDelangue из Hugging Face призвал к открытым датасетам трейсов агентов, с продолжением, указывающим на Agent Data Protocol от @yueqi_song. LangChain выкатил пачку материалов, ориентированных на продакшен: чек-лист готовности к eval агентов @LangChain, руководство по UI в стиле IDE для Deep Agents @LangChain_JS и LangSmith Prompt Hub Environments для продвижения/отката промптов @LangChain. Направление очевидно: стек движется от «чат-бота с инструментами» к примитивам жизненного цикла ПО для агентов.Бенчмарки для агентов начинают отражать реальные нагрузки: Artificial Analysis представила AA-AgentPerf через @ArtificialAnlys, сосредоточенный на реальных траекториях кодинг-агентов, длинах последовательностей 100K+ и пропускной способности, выраженной как число одновременных пользователей на ускоритель / на кВт / на $ / на стойку. Это более релевантная для развёртывания абстракция, чем синтетические токен-бенчмарки, и должна пригодиться командам, сравнивающим системы-ускорители для обслуживания агентских нагрузок.

Кодинг-агенты, плагины Codex и многоагентные процессы разработки ПО

Экосистема Codex от OpenAI смещается к автоматизации, нативной для рабочего пространства: разработчики OpenAI представили плагины Codex и галерею сценариев использования через @OpenAIDevs, а Box выпустил плагин Codex для автоматизации процессов поверх контента Box @Box. Настроения пользователей от @theo, @nickbaumann_ и @reach_vb говорят о том, что центр тяжести смещается от схемы «промпт/ответ» к постоянным рабочим пространствам, системам задач, терминалам, PR-флоу и плагинам.Побеждающий UX-паттерн всё больше похож на «управление флотом для разработки ПО»: @VibeMarketer_ хорошо уловил формирующийся паттерн: канбан-подобные карточки, изолированные worktree, задачи, закреплённые за агентами, и ревью на основе диффов. Среди связанных инструментов — новый дашборд agent-browser от @ctatedev для отладки браузерных сессий в реальном времени, а также широкий энтузиазм по поводу многоагентных SWE-систем в комментариях, близких к Cognition/Devin, например от @JTLonsdale и @cognition.Composer 2 и evals для долгогоризонтного кодинга поднимают планку: обсуждение CursorBench здесь в основном косвенное, но @cwolferesearch отмечает сильные стороны бенчмарка: реальные сессии кодинга, недоспецифицированные промпты, более широкие измерения качества и медианные 181 изменённая строка на задачу. Это более здоровый дизайн бенчмарка, чем статичные игрушечные задачи, и он совпадает с общим поворотом к оценке агентов на длинном горизонте.

Исследования и системы: модели мира, робототехника, речь и мультимодальная инфраструктура

Meta выпустила практичное ускорение SAM 3.1: @AIatMeta выпустил SAM 3.1 — drop-in-обновление SAM 3 с мультиплексированием объектов, позволяющим обрабатывать до 16 объектов за один прямой проход. По словам Meta, это примерно удваивает пропускную способность видео с 16 до 32 FPS на одной H100 для нагрузок со средними объектами, что значимо для доступных конвейеров сегментации видео.У моделей мира и робототехники были заметные открытые релизы: @LiorOnAI отметил статью/репозиторий LeWorldModel от LeCun — небольшую открытую модель мира, спроектированную так, чтобы коллапс представлений был математически невозможен благодаря SIGReg, с заявленным планированием в 48 раз быстрее и ~в 200 раз меньшим числом токенов. По данным для робототехники @UnitreeRobotics открыл UnifoLM-WBT-Dataset — реальный датасет полнотелесной телеоперации гуманоидов, предназначенный для регулярных обновлений.Речь / открытое аудио остаётся одной из самых здоровых открытых категорий: новая модель 2B Apache-2.0 Transcribe от Cohere получила высокие оценки от @victormustar и замеры пропускной способности от @vanstriendaniel, который сообщает о 33 часах аудио, расшифрованных за 12 минут на A100. Статью Voxtral TTS от Mistral отметил @qtnx_, а браузерные/локальные демо появились от @sophiamyang и @nickfrosst.Открытые стеки для робототехники тоже становятся более воспроизводимыми: AI2 выпустил MolmoBot — открытый набор для роботизированной манипуляции, обученный полностью в симуляции, с доступными кодом, обучающими данными, конвейером генерации и evals через @allen_ai. Это дополняет датасет Unitree и сигнализирует о продолжающемся прогрессе к воспроизводимым исследованиям в робототехнике за пределами топовых лабораторий.

Топ твитов (по вовлечённости)

Утечка Anthropic/Capybara: @Yuchenj_UW о Capybara стал самым обсуждаемым техническим пунктом, кратко описав новый тир выше Opus и его заявленный прирост в бенчмарках.Лечение рака у собаки с помощью ИИ от Paul Conyngham: @sama поделился историей об использовании ChatGPT и сопутствующих инструментов для помощи в разработке протокола мРНК-вакцины от рака у собаки, что стало крупной темой обсуждения о персонализированной медицине с ИИ.Критика TurboQuant: @gaoj0017 набрал необычно высокую вовлечённость для спора о методологии статьи — вероятно, потому что он бросает вызов активно продвигаемой системной работе.Релиз GLM-5.1: @Zai_org, объявивший о широкой доступности GLM-5.1, зашёл сильно, подкрепив устойчивый интерес к открытым моделям для кодинга.Открытая инфраструктура для агентов: @OpenAIDevs о плагинах Codex и @NousResearch об интеграции Hugging Face в Hermes Agent стали самыми чёткими продуктовыми/инфраструктурными запусками с широкой релевантностью для разработчиков.

Обзор AI Reddit

Обзор /r/LocalLlama + /r/localLLM

1. Инновации TurboQuant и RotorQuant

Google TurboQuant запускает Qwen локально на MacAir (Активность: 433): В посте обсуждается эксперимент, в котором метод сжатия TurboQuant от Google был применён к llama.cpp, что позволило запустить Qwen 3.5–9B на обычном MacBook Air (M4, 16 ГБ) с контекстом в 20000 токенов. Раньше это было неосуществимо на таком железе, что подчёркивает потенциал TurboQuant для локального запуска больших моделей без облачных API. Эксперимент показывает, что даже устройства начального уровня вроде MacBook Air или Mac Mini способны справляться с большими контекстами, пусть и с некоторыми ограничениями по скорости. В качестве ресурса для локального запуска таких моделей упоминается опенсорсное приложение atomic.chat. Комментатор отмечает впечатляющее достижение — обработку контекста в 20K на базовом MacBook Air без свопинга, что указывает на потенциал для локальных сценариев, которые раньше полагались на облачные API. Другой комментатор интересуется интеграцией TurboQuant в llama.cpp, проявляя интерес к более широкой доступности.Tatrions подчёркивает впечатляющую возможность запуска модели с контекстом 20K на базовом MacBook Air с 16 ГБ ОЗУ без свопинга благодаря TurboQuant. Это говорит о том, что многие приложения, ранее полагавшиеся на облачные API, теперь могут выполняться локально, хотя остаётся любопытство по поводу деградации качества при таком уровне сжатия по сравнению со стандартным Q4 на той же модели.M5_Maxxx проводит детальный аудит реализации TurboQuant, выявляя, что это минимально изменённая версия Jan.ai. Ключевые изменения включают переименование, доработки UI и собственный форк бэкенда llama.cpp, но без нового движка инференса или поддержки архитектур моделей. 96 коммитов в основном касаются изменений в CI/сборочном конвейере, что говорит об ограниченной инновационности за пределами исходных возможностей Jan.ai.AppealThink1733 интересуется интеграцией TurboQuant в llama.cpp, проявляя интерес к тому, поддерживается ли эта технология уже популярным опенсорсным проектом, что могло бы облегчить более широкое внедрение и эксперименты.Пропуск 90% работы по деквантизации KV → +22,8% декода на 32K (llama.cpp, TurboQuant) (Активность: 744): В посте обсуждается оптимизация в реализации TurboQuant для сжатия KV-кэша в llama.cpp, которая значительно улучшает производительность декода, пропуская деквантизацию для позиций с пренебрежимо малыми весами внимания. Этот подход использует разреженность внимания, обеспечивая прирост скорости декода на +22,8% при длине контекста 32K на M5 Max без влияния на перплексию (PPL). Метод включает простую модификацию примерно из трёх строк в ядре, обходя необходимость в сложных оптимизациях вроде SIMD-трюков или слитых ядер. Результаты согласуются на разном железе, включая M2 Pro, где производительность выросла с ~0,45x до ~0,73x по сравнению со стандартным KV-кэшем q8_0. Реализация и бенчмарки доступны на GitHub, с подробным разбором. Комментаторы похвалили простоту и эффективность решения, отметив новаторское использование разреженности внимания для пропуска ненужных вычислений. Есть любопытство по поводу того, как этот подход масштабируется на ещё более длинные контексты, например 64K+, и интерес к интеграции этой оптимизации в основную ветку llama.cpp.Specialist_Sun_7819 отмечает новаторскую оптимизацию в TurboQuant для llama.cpp, где пропуск 90% работы по деквантизации ключ-значение для токенов, не оказывающих существенного влияния на вывод, приводит к приросту скорости декодирования на +22,8% при длине контекста 32K. Этот подход использует предсказуемую разреженность внимания в длинных контекстах, обеспечивая существенную экономию вычислений при минимальных изменениях кода — всего трёх строках в ядре. Комментатор интересуется масштабируемостью метода на ещё более длинные контексты, такие как 64K, и тем, продолжает ли коэффициент разреженности расти или выходит на плато.sean_hash проводит параллель между оптимизацией в TurboQuant и приёмами, используемыми в Flash Attention, отмечая, что кэширование деквантизованного вывода вместо его пересчёта на каждом шаге декодирования — схожая стратегия. Этот метод эффективно снижает избыточные вычисления, повышая производительность за счёт повторного использования ранее вычисленных значений, что является распространённой оптимизацией в высокопроизводительных вычислениях для минимизации лишних накладных расходов.Pentium95 выражает интерес к интеграции этой оптимизации в основную ветку llama.cpp, указывая на желание более широкого внедрения этого приёма. Это говорит о том, что сообщество видит ценность в этих улучшениях производительности и стремится увидеть их реализацию в широко используемых кодовых базах, что потенциально может привести к более эффективным моделям и более быстрому инференсу в различных приложениях.Бенчмарки TurboQuant в Llama.cpp (Активность: 463): В посте обсуждается реализация TurboQuant — техники сжатия от Google — во фреймворке llama.cpp, в частности на Apple Silicon с использованием Metal. Автор отмечает значительное падение производительности: TPS на 50% ниже, чем у f16, что указывает на возможные проблемы в его настройке. Он также пытался запустить ядра на CUDA-машине, но столкнулся с плохими выводами, что говорит об ошибках в подходе. Техника рассматривается как полезная для запуска локальных моделей на потребительском железе с ограниченной VRAM, потенциально позволяя выполнять более сложные задачи локально. В посте упоминаются текущие усилия по разработке в связанных проектах вроде MLX и VLLM. Комментаторы предлагают проверить KLD для оценки ценности метода и выражают интерес к таким метрикам производительности, как pp2048, поскольку pp64 не очень показателен. Другой комментатор рекомендует попробовать RotorQuant для сравнения.Velocita84 указывает на отсутствие дивергенции Кульбака–Лейблера (KLD) в бенчмарках, что критично для оценки эффективности TurboQuant. KLD — это мера того, насколько одно распределение вероятностей отклоняется от второго, ожидаемого распределения, и её отсутствие может означать упущение важных данных о производительности модели при сжатии TurboQuant.CornerLimits предполагает, что бенчмарк с использованием pp64 не очень информативен для оценки производительности, и рекомендует использовать pp2048. Метрика pp относится к перплексии — распространённой мере в языковых моделях, показывающей, насколько хорошо распределение вероятностей предсказывает выборку. Более высокие значения pp могут давать более полное представление о производительности модели.DinoAmino обсуждает компромисс между сжатием данных и точностью в TurboQuant, отмечая, что хотя он позволяет добиться более высокого сжатия данных с почти без потерь точностью, он не повышает точность. Он подчёркивает, что большинство больших языковых моделей (LLM) испытывают деградацию точности на больших длинах контекста, подразумевая, что главное преимущество TurboQuant — возможность использовать более длинные контексты без дополнительной потери точности.RotorQuant: в 10–19 раз более быстрая альтернатива TurboQuant через роторы Клиффорда (в 44 раза меньше параметров) (Активность: 652): RotorQuant представляет новаторский подход к векторной квантизации, использующий алгебру Клиффорда, достигая прироста скорости в 10–19x по сравнению с TurboQuant при 44x меньшем числе параметров. Метод заменяет случайную ортогональную матрицу d×d роторами Клиффорда, снижая вычислительную сложность с 16 384 FMA до примерно 100 FMA для d=128. Это даёт косинусную близость 0,990 против 0,991 у TurboQuant, что указывает на практически идентичную производительность. Реализация использует слитые CUDA-ядра и шейдеры Metal, значительно опережая matmul из cuBLAS на RTX PRO 4000 и Apple M4. Компромисс включает более высокий синтетический MSE на случайных единичных векторах, но с коррекцией QJL точность внимания на реальных моделях остаётся сохранённой. GitHub Статья Ключевой спор сосредоточен на теоретических различиях между RotorQuant и TurboQuant. Хотя глобальное случайное вращение TurboQuant распределяет энергию по всем измерениям, перемешивание в 3D-блоках у RotorQuant не может это воспроизвести, что приводит к более высоким максимальным значениям координат и худшему MSE при низкобитной квантизации. Тем не менее практическая производительность RotorQuant на распределениях KV-кэша признаётся, что говорит о ценном компромиссе скорость/качество для реальных моделей.Juan_Valadez подчёркивает ключевое теоретическое ограничение RotorQuant по сравнению с TurboQuant, отмечая, что глобальное случайное вращение (Хаара) у TurboQuant эффективно распределяет энергию по всем измерениям, оптимизируя скалярную квантизацию. В отличие от этого, перемешивание внутри 3D-блоков у RotorQuant ограничивает его способность достичь такого же распределения энергии, что может негативно сказаться на низкобитной квантизации, особенно на наихудших векторах вроде one-hot. Тем не менее RotorQuant всё же может быть практически полезен для распределений KV-кэша, где векторы менее враждебны.Dany0 проводит параллели между TurboQuant и приёмами, используемыми в графическом программировании, в частности ссылаясь на QuiP — схожий подход, применённый к весам моделей. Несмотря на изначальный скептицизм из-за краткости статьи и её подачи, Dany0 признаёт потенциал RotorQuant, сравнивая его использование роторов Клиффорда с применением кватернионов вместо углов Эйлера, что упрощает вычисления, сводя умножения к нулям.sean_hash комментирует неожиданное применение алгебр Клиффорда в квантизации, отмечая это как пример перекрёстного опыления из геометрической алгебры в области за пределами графики. Это подчёркивает новаторское использование математических концепций, традиционно связанных с другими доменами, и указывает на более широкую применимость этих приёмов.

2. GLM-5.1 и сравнения моделей для кодинга

Glm 5.1 вышла (Активность: 1127): Изображение анонсирует выход GLM-5.1 от Z.ai, подчёркивая её улучшенную производительность в задачах кодинга по сравнению с предыдущими версиями. График на изображении показывает, что GLM-5.1 набирает 45,3 в оценке кодинга, превосходя 35,4 у GLM-5, но всё ещё отставая от Claude Opus 4.6, набравшей 47,9. Это говорит о значительных улучшениях возможностей GLM-5.1, вероятно, благодаря усовершенствованиям в базовой архитектуре или обучающих данных. Комментаторы строят догадки о возможном выходе открытых весов GLM-5.1, что указывает на ожидание более широкой доступности. Также обсуждается задержка выхода DS v4, намекая на возможные сложности с обучением на конкретном железе вроде Ascend.power97992 предполагает возможные задержки в выходе DeepSpeed v4, считая, что могут быть проблемы, связанные с обучением на железе Ascend. Это подчёркивает сложности оптимизации ML-фреймворков под разные аппаратные архитектуры, что может влиять на сроки выпуска.zb-mrx отмечает улучшение процесса развёртывания GLM 5.1, противопоставляя его предыдущей версии GLM 5, у которой не было развёртывания в день релиза для всех. Это говорит о том, что разработчики, возможно, решили прежние логистические или ресурсные проблемы, такие как доступность GPU, чтобы обеспечить более гладкий релиз.jacek2023 упоминает ограничения локального запуска GLM из-за аппаратных ограничений, в частности ссылаясь на лимит VRAM в 72 ГБ. Это подчёркивает сохраняющуюся проблему аппаратных требований для запуска продвинутых моделей, что может быть барьером для многих пользователей без доступа к топовым GPU.

Продолжайте читать с бесплатным 7-дневным пробным периодом

Подпишитесь на Latent.Space, чтобы продолжить читать этот пост и получить 7 дней бесплатного доступа к полному архиву постов.