newsmode
search
Меню
arrow_back Назад

[AINews] H100 prices are melting *UP*

auto_awesomeКраткое саммари

Цены аренды H100 после долгого падения резко пошли вверх с декабря 2025 года, развернув цикл амортизации, который Latent Space описывал ещё в октябре 2024-го как ускоренный «лопающийся пузырь». Dylan на подкасте Dwarkesh утверждает, что H100 сегодня стоят дороже, чем три года назад — это связывают с общим дефицитом чипов и всплеском спроса на reasoning-модели и агентов конца 2025-го; четырёхлетний чип оказался куда ценнее, чем закладывали графики амортизации на 4–7 лет. В Twitter-обзоре выпуска: утечка нового тира Anthropic «Capybara» выше Opus, по сообщению Fortune — крупнее и умнее Claude Opus 4.6, с лучшими результатами по кодингу, академическому reasoning и кибербезопасности. Также обсуждаются GLM-5.1 от Zhipu, прогресс локального инференса (Qwen 3.5), споры вокруг статьи Google TurboQuant и её альтернативы RotorQuant, зрелость агентских продуктов (Hermes Agent от Nous Research, Codex-плагины OpenAI) и релизы вроде SAM 3.1 от Meta. На Reddit главными темами стали TurboQuant/RotorQuant для llama.cpp и выход GLM-5.1, набравшего 45,3 в кодинге против 35,4 у GLM-5 и 47,9 у Claude Opus 4.6.

[AINews] H100 prices are melting *UP*

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

a quiet day lets us report an important GPU trend

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

At GTC 2022, NVIDIA announced the Hopper architecture and the first H100s started rolling out in October of that year. 2 years later, in October 2024, we published a popular piece on the H100 rental price depreciation cycle, which we had observed to be a going faster than previous cycles and theorized that it was a slight bubble burst dynamic due to temporarily inflated demand. While true for the time (bottoming out after the DeepSeek R1 shock, it did not last; since December 2025 the H100 rental market has gone VERY up:

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

chart

This is corroborated by Dylan on Dwarkesh saying H100's are worth more today than they were 3 years ago, and surely related to the general chip shortage and reasoning model/agent inflection of December 2025, and the utility of a 4 year old chip now with much better reasoning models and inference software means the chip itself is much more valuable than initial 4-7 year depreciation schedules had assumed.

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

If you are used to the razor’s edge of data center tokenomics, you should expect that this has very meaningful implications on the business models of data centers and GPUs… as long as it keeps going.

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

AI News for 3/26/2026-3/27/2026. We checked 12 subreddits, 544 Twitters and no further Discords. AINews’ website lets you search all past issues. As a reminder, AINews is now a section of Latent Space. You can opt in/out of email frequencies!

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


AI Twitter Recap

Обзор AI Twitter

Anthropic’s leaked “Mythos” system and the new Capybara tier

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

  • Fortune corroborates a higher Anthropic tier above Opus: A now-pulled “Claude Mythos” post was preserved by @M1Astra, and multiple follow-on posts cite a Fortune report that Anthropic is introducing Capybara, described as a new tier above Opus and “larger and more intelligent” than Claude Opus 4.6. Reporting summarized by @scaling01, @Yuchenj_UW, and @kimmonismus says Capybara posts substantially better scores on coding, academic reasoning, and cybersecurity, with rollout constrained by cost and safety concerns.

  • Compute intensity is the central theme: Several posters infer Anthropic is leaning hard into scale, with speculation around a ~10T parameter class model from prior Dario comments, though that remains unconfirmed outside commentary; see @scaling01 and @Yuchenj_UW. Separately, the Financial Times report relayed by @FirstSquawk says Google is close to funding Anthropic’s data center, reinforcing that frontier competition is increasingly gated by power and capex rather than just algorithms.

  • Infra strain was visible in production: The leak landed amid a rough day for Anthropic availability, with widespread user complaints about 529s/elevated errors from @dejavucoder, @iScienceLuvr, and others. The practical takeaway is that Anthropic appears to be balancing aggressive scaling ambitions against a still-tight serving envelope.

  • 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, похоже, балансирует между агрессивными амбициями масштабирования и всё ещё узким окном обслуживания запросов.

    Open coding models, local inference, and GLM-5.1’s continued push

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

  • GLM-5.1 is widening the pressure on closed coding models: Zhipu announced GLM-5.1 availability to all coding plan users via @Zai_org, along with docs for agent use at @Zai_org. Community reaction framed it as another sign that high-end Chinese open or semi-open coding models are closing the gap: @kimmonismus, @XFreeze, and Arena’s broader leaderboard analysis @arena all point to a much narrower open-vs-closed gap than a year ago.

  • Local deployment economics keep improving: A recurring theme across tweets is that local models are now “good enough” for many workflows. Examples include @TheGeorgePu swapping a pricey TTS subscription for a local Qwen 3.5 14B setup, @LottoLabs reporting strong economics for Qwen 27B with Hermes Agent, and @0xSero compressing Qwen3.5-35B enough to fit full context into 24GB VRAM at roughly 1% average performance drop.

  • Quantization and cache work remain key enablers: @iotcoi shipped a TurboQuant vLLM fork with fused Triton KV write paths and decode attention, targeting Qwen3.5-35B AWQ, 1M context, and 4M KV cache. Meanwhile @bnjmn_marie benchmarked Qwen3.5 27B formats across RTX Pro 6000/B200/H100, with INT4 emerging as the best inference option on RTX Pro 6000-class hardware.

  • But TurboQuant is now under active dispute: The strongest research controversy in the set comes from @gaoj0017 and a longer clarification @gaoj0017, alleging Google’s ICLR 2026 TurboQuant paper misrepresented RaBitQ in theory and benchmarking, including unfair CPU-vs-GPU comparisons. This does not invalidate TurboQuant’s engineering value, but it does cast doubt on some of the publicized comparative claims.

  • 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, но ставит под сомнение некоторые публично заявленные сравнительные результаты.

    Agents are becoming products, not demos

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

  • Hermes Agent is emerging as the open-agent focal point: The most consistent product momentum in the dataset belongs to Nous Research’s Hermes Agent. @NousResearch integrated Hugging Face as a first-class inference provider with 28 curated models plus access to many more, while @ClementDelangue framed this as a step toward open agents with memory, persistent machine access, and model choice. User reports from @fancylancer3991, @PolackJack, and @alexcovo_eth emphasize lower friction and better persistence than browser-automation-heavy setups like OpenClaw.

  • Agent infrastructure is maturing around traces, evals, and debuggability: Hugging Face’s @ClementDelangue called for open agent traces datasets, with follow-up pointing to the Agent Data Protocol from @yueqi_song. LangChain pushed a cluster of production-oriented materials: an agent eval readiness checklist @LangChain, Deep Agents IDE-style UI guidance @LangChain_JS, and LangSmith Prompt Hub Environments for prompt promotion/rollback @LangChain. The direction is clear: the stack is moving from “chatbot with tools” to software lifecycle primitives for agents.

  • Agent-facing benchmarks are starting to reflect real workloads: Artificial Analysis introduced AA-AgentPerf via @ArtificialAnlys, focused on real coding-agent trajectories, 100K+ sequence lengths, and throughput expressed as concurrent users per accelerator / per kW / per $ / per rack. That is a more deployment-relevant abstraction than synthetic token benchmarks and should be useful for teams comparing accelerator systems for agent-heavy serving.

  • 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+ и пропускной способности, выраженной как число одновременных пользователей на ускоритель / на кВт / на $ / на стойку. Это более релевантная для развёртывания абстракция, чем синтетические токен-бенчмарки, и должна пригодиться командам, сравнивающим системы-ускорители для обслуживания агентских нагрузок.

    Coding agents, Codex plugins, and multi-agent software workflows

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

  • OpenAI’s Codex ecosystem is shifting toward workspace-native automation: OpenAI developers highlighted Codex plugins and a use-case gallery via @OpenAIDevs, while Box shipped a Codex plugin for automating workflows over Box content @Box. User sentiment from @theo, @nickbaumann_, and @reach_vb suggests the center of gravity is moving from prompt/response to persistent workspaces, issue systems, terminals, PR flows, and plugins.

  • The winning UX pattern is increasingly “fleet management for software”: @VibeMarketer_ captured the emerging pattern well: kanban-like cards, isolated worktrees, agent-owned tasks, and diff-based review. Related tools include the new agent-browser dashboard from @ctatedev for real-time browser session debugging, and broad enthusiasm for multi-agent SWE systems from Cognition/Devin adjacent commentary like @JTLonsdale and @cognition.

  • Composer 2 and long-horizon coding evals are raising the bar: The CursorBench discussion is mostly indirect here, but @cwolferesearch points out the benchmark’s strengths: real coding sessions, underspecified prompts, broader quality dimensions, and median 181 lines changed per task. That’s a healthier benchmark design than static toy tasks and aligns with the broader turn toward long-horizon agent evaluation.

  • Экосистема 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 изменённая строка на задачу. Это более здоровый дизайн бенчмарка, чем статичные игрушечные задачи, и он совпадает с общим поворотом к оценке агентов на длинном горизонте.

    Research and systems: world models, robotics, speech, and multimodal infra

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

  • Meta shipped a practical SAM 3.1 speedup: @AIatMeta released SAM 3.1, a drop-in update to SAM 3 with object multiplexing, allowing up to 16 objects in a single forward pass. Meta says this roughly doubles video throughput from 16 to 32 FPS on one H100 for medium-object workloads, which is meaningful for accessible video segmentation pipelines.

  • World models and robotics both had notable open releases: @LiorOnAI highlighted LeCun’s LeWorldModel paper/repo as a small, open world model designed to make representational collapse mathematically impossible via SIGReg, claiming 48x faster planning and ~200x fewer tokens. On robotics data, @UnitreeRobotics open-sourced the UnifoLM-WBT-Dataset, a real-world humanoid whole-body teleoperation dataset intended for rolling updates.

  • Speech/open audio remains one of the healthiest open categories: Cohere’s new 2B Apache-2.0 Transcribe model drew strong praise from @victormustar and throughput measurements from @vanstriendaniel, who reports 33 hours of audio transcribed in 12 minutes on an A100. Mistral’s Voxtral TTS paper was flagged by @qtnx_, and browser/local demos appeared from @sophiamyang and @nickfrosst.

  • Open robotics stacks are also getting more reproducible: AI2 released MolmoBot, an open robotic manipulation suite trained entirely in simulation, with code, training data, generation pipeline, and evals available via @allen_ai. That complements the Unitree dataset and signals continued progress toward replicable robotics research outside top labs.

  • 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 и сигнализирует о продолжающемся прогрессе к воспроизводимым исследованиям в робототехнике за пределами топовых лабораторий.

    Top tweets (by engagement)

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

  • Anthropic/Capybara leak: @Yuchenj_UW on Capybara was the most engaged technical item, summarizing the new tier above Opus and its reported benchmark gains.

  • Paul Conyngham’s AI-assisted dog cancer treatment: @sama shared a story of using ChatGPT and related tools to help design an mRNA vaccine protocol for a dog’s cancer, which became a major discussion point about AI-enabled personalized medicine.

  • TurboQuant critique: @gaoj0017 drew unusually high engagement for a paper-methodology dispute, likely because it challenges a heavily promoted systems paper.

  • GLM-5.1 release: @Zai_org announcing broad GLM-5.1 availability landed strongly, reinforcing sustained interest in open coding models.

  • Open infrastructure for agents: @OpenAIDevs on Codex plugins and @NousResearch on Hugging Face integration into Hermes Agent were the clearest product/infrastructure launches with broad developer relevance.

  • Утечка 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 Recap

    Обзор AI Reddit

    /r/LocalLlama + /r/localLLM Recap

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

    1. TurboQuant and RotorQuant Innovations

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

  • Google TurboQuant running Qwen Locally on MacAir (Activity: 433): The post discusses an experiment where Google’s TurboQuant compression method was applied to llama.cpp, enabling the running of Qwen 3.5–9B on a standard MacBook Air (M4, 16 GB) with a 20000 tokens context. This was previously unfeasible on such hardware, highlighting TurboQuant’s potential to enable local execution of large models without cloud APIs. The experiment suggests that even entry-level devices like MacBook Airs or Mac Minis can handle large contexts, albeit with some speed limitations. The open-source app atomic.chat is mentioned as a resource for running these models locally. A commenter notes the impressive feat of handling 20K context on a base MacBook Air without swapping, suggesting potential for local use cases that previously relied on cloud APIs. Another commenter inquires about the integration of TurboQuant into llama.cpp, indicating interest in broader accessibility.

    • Tatrions highlights the impressive capability of running a 20K context model on a base MacBook Air with 16GB RAM without swapping, thanks to TurboQuant. This suggests that many applications that previously relied on cloud APIs could now be executed locally, though there is curiosity about the quality degradation at this compression level compared to standard Q4 on the same model.

    • M5_Maxxx provides a detailed audit of the TurboQuant implementation, revealing it as a minimally altered version of Jan.ai. Key changes include renaming, UI tweaks, and a custom llama.cpp backend fork, but no new inference engine or model architecture support. The 96 commits mostly involve CI/build pipeline changes, suggesting limited innovation beyond the original Jan.ai capabilities.

    • AppealThink1733 inquires about the integration of TurboQuant into llama.cpp, indicating interest in whether this technology is already supported by the popular open-source project, which could facilitate broader adoption and experimentation.

  • Skipping 90% of KV dequant work → +22.8% decode at 32K (llama.cpp, TurboQuant) (Activity: 744): The post discusses an optimization in the TurboQuant implementation for KV cache compression in llama.cpp, which significantly improves decode performance by skipping dequantization for positions with negligible attention weights. This approach leverages attention sparsity, allowing a +22.8% increase in decode speed at 32K context length on an M5 Max, without affecting perplexity (PPL). The method involves a simple modification of about three lines in the kernel, bypassing the need for complex optimizations like SIMD tricks or fused kernels. The results are consistent across different hardware, including the M2 Pro, where performance improved from ~0.45x to ~0.73x compared to the standard q8_0 KV cache. The implementation and benchmarks are available on GitHub, with a detailed writeup. Commenters praised the simplicity and effectiveness of the solution, noting the innovative use of attention sparsity to skip unnecessary computations. There is curiosity about how this approach scales with even longer contexts, such as 64K+, and interest in integrating this optimization into the mainline llama.cpp.

    • Specialist_Sun_7819 highlights a novel optimization in llama.cpp’s TurboQuant, where skipping 90% of the key-value dequantization work for tokens that don’t significantly impact the output leads to a +22.8% increase in decoding speed at 32K context length. This approach leverages predictable attention sparsity in long contexts, allowing for significant computational savings with minimal code changes, specifically just three lines in the kernel. The commenter is curious about the scalability of this method to even longer contexts, such as 64K, and whether the sparsity ratio continues to increase or plateaus.

    • sean_hash draws a parallel between the optimization in TurboQuant and techniques used in Flash Attention, noting that caching the dequantized output instead of recalculating it at each decoding step is a similar strategy. This method effectively reduces redundant computations, enhancing performance by reusing previously computed values, which is a common optimization in high-performance computing to minimize unnecessary processing overhead.

    • Pentium95 expresses interest in integrating this optimization into the mainline llama.cpp, indicating a desire for broader adoption of this technique. This suggests that the community sees value in these performance improvements and is eager to see them implemented in widely-used codebases, potentially leading to more efficient models and faster inference times across various applications.

  • TurboQuant in Llama.cpp benchmarks (Activity: 463): The post discusses the implementation of TurboQuant, a compression technique from Google, in the llama.cpp framework, specifically on Apple Silicon using Metal. The author notes a significant performance drop, with TPS being 50% less than f16, indicating potential issues in their setup. They also attempted to run kernels on a CUDA machine but encountered poor outputs, suggesting errors in their approach. The technique is seen as beneficial for running local models on consumer hardware with limited VRAM, potentially allowing for more complex tasks to be executed locally. The post references ongoing development efforts in related projects like MLX and VLLM. Commenters suggest checking KLD to evaluate the method’s worth and express interest in seeing performance metrics like pp2048, as pp64 is not very indicative. Another commenter recommends trying RotorQuant for comparison.

    • Velocita84 points out the absence of Kullback-Leibler Divergence (KLD) in the benchmarks, which is crucial for evaluating the effectiveness of TurboQuant. KLD is a measure of how one probability distribution diverges from a second, expected probability distribution, and its absence could mean missing insights into the model’s performance under TurboQuant compression.

    • CornerLimits suggests that the benchmark using pp64 is not very informative for assessing performance and recommends using pp2048 instead. The pp metric refers to perplexity, a common measure in language models that indicates how well a probability distribution predicts a sample. Higher pp values can provide a more comprehensive view of model performance.

    • DinoAmino discusses the trade-off between data compression and accuracy in TurboQuant, noting that while it allows for higher data compression with near-lossless accuracy, it doesn’t improve accuracy. They highlight that most large language models (LLMs) experience accuracy degradation at higher context lengths, implying that TurboQuant’s main benefit is enabling the use of longer contexts without additional accuracy loss.

  • RotorQuant: 10-19x faster alternative to TurboQuant via Clifford rotors (44x fewer params) (Activity: 652): RotorQuant introduces a novel approach to vector quantization by utilizing Clifford Algebra, achieving 10-19x speed improvements over TurboQuant with 44x fewer parameters. The method replaces the d×d random orthogonal matrix with Clifford rotors, reducing the computational complexity from 16,384 FMAs to approximately 100 FMAs for d=128. This results in a cosine similarity of 0.990 compared to TurboQuant’s 0.991, indicating nearly identical performance. The implementation leverages fused CUDA kernels and Metal shaders, significantly outperforming cuBLAS matmul on RTX PRO 4000 and Apple M4. The trade-off involves higher synthetic MSE on random unit vectors, but with QJL correction, real-model attention fidelity remains intact. GitHub Paper A key debate centers on the theoretical differences between RotorQuant and TurboQuant. While TurboQuant’s global random rotation spreads energy across all dimensions, RotorQuant’s 3D block mixing cannot replicate this, leading to higher max coordinate magnitudes and worse MSE in low-bit quantization. However, RotorQuant’s practical performance in KV cache distributions is acknowledged, suggesting a valuable speed/quality tradeoff for real models.

    • Juan_Valadez highlights a key theoretical limitation of RotorQuant compared to TurboQuant, noting that TurboQuant’s global random rotation (Haar) effectively spreads energy across all dimensions, optimizing scalar quantization. In contrast, RotorQuant’s mixing within 3D blocks limits its ability to achieve the same energy distribution, which can negatively impact low-bit quantization, especially in worst-case vectors like one-hot. However, RotorQuant may still be practically useful for KV cache distributions where vectors are less adversarial.

    • Dany0 draws parallels between TurboQuant and techniques used in graphics programming, specifically referencing QuiP, a similar approach applied to model weights. Despite initial skepticism due to the shortness of the paper and its presentation, Dany0 acknowledges the potential of RotorQuant, likening its use of Clifford rotors to the application of quaternions instead of Euler angles, which simplifies computations by reducing multiplications to zeros.

    • sean_hash comments on the unexpected application of Clifford algebras in quantization, noting it as an example of cross-pollination from geometric algebra into fields outside of graphics. This highlights the innovative use of mathematical concepts traditionally associated with other domains, suggesting a broader applicability of these techniques.

  • 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 and Coding Model Comparisons

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

  • Glm 5.1 is out (Activity: 1127): The image announces the release of GLM-5.1 by Z.ai, highlighting its improved performance in coding tasks compared to previous versions. The chart in the image shows that GLM-5.1 scores 45.3 in coding evaluation, surpassing GLM-5’s score of 35.4, but still trailing behind Claude Opus 4.6, which scores 47.9. This suggests significant improvements in GLM-5.1’s capabilities, likely due to enhancements in its underlying architecture or training data. Commenters speculate about the potential release of open weights for GLM-5.1, indicating anticipation for broader accessibility. There is also discussion about the delay in the release of DS v4, hinting at possible challenges in training on specific hardware like Ascends.

    • power97992 speculates on potential delays in the release of DeepSpeed v4, suggesting that there might be issues related to training on Ascend hardware. This highlights the challenges in optimizing machine learning frameworks for different hardware architectures, which can impact release timelines.

    • zb-mrx notes the improvement in the rollout process for GLM 5.1, contrasting it with the previous version, GLM 5, which did not have a day-one rollout for everyone. This suggests that the developers may have resolved previous logistical or resource-related issues, such as GPU availability, to ensure a smoother release.

    • jacek2023 mentions the limitations of running GLM locally due to hardware constraints, specifically referencing a 72GB VRAM limit. This underscores the ongoing challenge of hardware requirements for running advanced models, which can be a barrier for many users without access to high-end GPUs.

  • 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.

    Keep reading with a 7-day free trial

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

    Subscribe to Latent.Space to keep reading this post and get 7 days of free access to the full post archives.

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