Anthropic записала оптимизацию GPU-ядер в меры безопасности — и спорит вся сеть

Anthropic выпустила новые модели, и внимание части сообщества привлекла не таблица бенчмарков, а одна строчка в анонсе. Оптимизация ядер GPU там оказалась в разделе мер безопасности, в одном ряду с биологическими угрозами и хакингом. Автор телеграм-канала «Метаверсище и ИИще» пересказал это с понятным возмущением. Мы опираемся на его пересказ и ссылку на анонс. Точные формулировки стоит прочитать в первоисточнике, а не в чьей-то интерпретации.

Что именно утверждается

Главный тезис такой: если попросить модель ускорить вычисления на видеокарте, вы не увидите привычного «извините, я не могу с этим помочь». Модель ответит, но, по описанию, сделает это хуже, чем способна. Автор говорит, что это не фильтр поверх ответа, а результат обучения. Поэтому классический джейлбрейк, который обманывает защитный слой, тут якобы бесполезен: обходить нечего, навык просто приглушён.

Официальное объяснение звучит так: опасно ускорять разработку самого ИИ. Чем эффективнее код под GPU, тем быстрее идут эксперименты и обучение, в том числе у тех, кто строит системы без оглядки на безопасность.

Почему это раздражает практиков

Кернелы — это не экзотика для лабораторий. Работа с ядрами влияет на то, сколько токенов в секунду вы получите на своём железе. От неё зависит, влезет ли свежая локальная модель в память старой RTX 3090. Для тех, кто запускает LLM у себя, это повседневный инструмент, а не оружие.

Главная проблема не в самом ограничении, а в его форме. Отказ вы видите сразу и идёте искать другой инструмент. Незаметно ухудшенный ответ выглядит как рабочий код. Вы можете потратить день на отладку, прежде чем поймёте, что модель просто не старалась. Ограничение, о котором не предупреждают в момент ответа, подрывает доверие ко всему остальному, что модель пишет.

Безопасность или деньги

В соцсетях быстро появилась версия, что дело не в Скайнете. Если люди хуже оптимизируют локальные модели, они охотнее платят за API. Железо дорожает, память скупают дата-центры, и аргумент выглядит правдоподобно.

Доказательств нет, и стоит держать это в голове. Версия про безопасность тоже логична для компании, которая строит репутацию на осторожности. Выбор между этими объяснениями — вопрос веры, а не фактов. Фактом остаётся другое: за ограничением стоит решение вендора, и пользователь не может его проверить.

Что делать разработчику и продакту

• Проверьте формулировку в анонсе. Узнайте, о каких задачах идёт речь: об обучении фронтирных моделей или о любой работе с кернелами.
• Не принимайте код на веру. Профилируйте и сравнивайте с эталоном: замеры времени, throughput, проверка корректности. Это нужно и без всяких ограничений, но теперь особенно.
• Сравните модели на своей задаче. Дайте один и тот же промпт на оптимизацию ядра нескольким моделям, включая открытые, и посмотрите на разницу в качестве.
• Не завязывайте критичный пайплайн на одну модель. Если низкоуровневая оптимизация — часть вашего продукта, держите запасной вариант.

Главный вывод шире, чем один релиз. Вендоры всё чаще настраивают модели не только на то, что они отказываются делать, но и на то, в чём они намеренно слабее. Пока это можно только подозревать, а не измерить. Поэтому собственные бенчмарки на своих задачах из приятного дополнения превращаются в обязательную часть работы.