Оптимизация Claude: как Anthropic ускорила модель в три раза за две недели

Когда пользователи взаимодействуют с большими языковыми моделями, субъективное ощущение скорости зависит не только от времени генерации токенов в серверном кластере. Значительная часть задержки накапливается прямо на клиенте: при открытии веб-страницы, инициализации компонентов интерфейса, обработке введенного текста и отрисовке потокового ответа. В конце сентября 2026 года инженерная команда Anthropic под руководством Реймонда Вонга, Сэма Аттарда и Айзека Г. опубликовала отчет о внутреннем спринте, в рамках которого отклик веб-сервиса claude.ai и десктопного клиента Claude Desktop удалось ускорить в 3,1 раза всего за 14 дней.

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

Итоги двухнедельного спринта в цифрах

Измерения проводились по 13 независимым пользовательским сценариям на 75-м перцентиле (p75) реальной аудитории. Геометрическое среднее показало совокупный выигрыш в скорости в 3,1 раза. Наиболее заметные изменения коснулись первого контакта пользователя с приложением:

• Холодная загрузка claude.ai в браузере до момента, когда поле ввода готово принимать текст, сократилась с 3085 мс до 550 мс. Интерфейс стал доступен в 5,6 раза быстрее, а задержка снизилась на 82%.
• Холодный запуск настольного приложения Claude Desktop на базе Electron и Chromium ускорился почти вдвое: время ожидания упало с 6310 мс до 3328 мс.
• Создание новой ветки диалога в веб-версии теперь занимает 273 мс вместо прежних 416 мс (-34%), а в десктопном клиенте — 224 мс вместо 460 мс (-51%).
• Старт сессии консольного инструмента Claude Code сократился с 837 мс до 347 мс (-59%).
• Открытие уже существующей длинной беседы в браузере ускорилось с 1557 мс до 646 мс (-59%), в десктопном приложении — с 1353 мс до 488 мс (-64%), а в корпоративных сессиях совместной работы Claude Cowork — с 2566 мс до 728 мс (-72%).
• Обработка нажатия кнопки отправки сообщения показала наиболее радикальный прогресс: в вебе задержка упала со 180 мс до 59 мс (-67%), на десктопе — со 140 мс до 64 мс (-54%), в Claude Code — с 250 мс до 52 мс (-79%), а в Claude Cowork сократилась в 19 раз — с 928 мс до 48 мс (-95%).

Почему привычный замер времени в CI заводит в тупик

Первым препятствием на пути к планомерной оптимизации стала нестабильность классических замеров времени выполнения (wall-clock time). Когда тесты производительности запускаются в виртуальных машинах непрерывной интеграции (CI), физическое время работы функции постоянно колеблется. На него влияют фоновые процессы соседних контейнеров, планировщик операционной системы, температура серверного процессора и частота работы памяти.

Погрешность физического таймера на одном и том же наборе данных нередко достигала 15–20%. В таких условиях невозможно настроить строгий порог, блокирующий неэффективные изменения: если объявить провалом замедление на 5%, тесты будут регулярно падать из-за случайного шума среды. Если же ослабить допуск до 20%, разработчики неизбежно пропустят десятки мелких регрессий, которые постепенно сведут на нет любые оптимизации.

Инженеры Anthropic отказались от таймера реального времени на этапе автоматической проверки и перешли к детерминированному подсчету процессорных инструкций (instruction counting). Для этого тестовые сценарии запускаются под управлением профилировщика Valgrind с флагом детерминизма Node.js node --predictable. В изолированном контуре одинаковый набор входных данных и детерминированное выполнение JavaScript-кода всегда требуют строго одного и того же числа инструкций процессора с точностью до единицы. Это превратило производительность из вероятностной величины в строгую математическую метрику.

Механизм храповика и автоматический контроль регрессий

На базе детерминированного подсчета инструкций команда внедрила паттерн «храповика» (ratchet). Храповик — это механизм, позволяющий оси вращаться только в одну сторону и блокирующий движение назад. В инженерном пайплайне этот принцип реализован на двух уровнях:

1. Блокировка на уровне проверки изменений: каждый входящий pull request прогоняется через эталонные сценарии в тестовой среде. Если предлагаемый код хотя бы на небольшую величину увеличивает суммарное число инструкций на критическом пути, пайплайн автоматически завершается ошибкой и запрещает объединение ветки.
2. Ночной сдвиг планки: как только удачные оптимизации снижают количество инструкций на целевом пути, специальный ночной фоновый процесс пересчитывает базовые лимиты и жестко фиксирует новую планку. Вернуться к прежним, более медленным показателям система уже не позволяет.

Благодаря храповику разработчикам больше не нужно вручную контролировать, не приведет ли новая интерфейсная кнопка или дополнительная валидация к замедлению приложения: защита работает автоматически для всей инженерной команды.

Автоматизация поиска узких мест через агента в Slack

Чтобы удерживать темп в сотни изменений в день, ручного труда инженеров было недостаточно. Команда задействовала внутреннюю агентную систему Claude Tag, работающую в корпоративном мессенджере Slack на базе модели уровня Opus 5.5.

Рабочий процесс строился по замкнутому циклу:

• Инженер отправлял в выделенный канал ссылку на медленный компонент или прикреплял короткую запись экрана с демонстрацией подтормаживания.
• Агент подключался к репозиторию, воспроизводил сценарий в тестовом контуре, снимал детальный профиль вызовов через Callgrind и локализовал проблемные функции.
• Затем агент формулировал гипотезу, самостоятельно писал изолированный микробенчмарк, вносил точечные правки в код и открывал pull request.
• Чтобы исключить любые риски для стабильности сервиса, каждое изменение закрывалось динамическим фиче-флагом.
• Новая ветка последовательно тестировалась на внутреннем трафике сотрудников Anthropic, затем раскатывалась на один процент внешней аудитории и только после подтверждения телеметрии в Datadog переводилась на 100% пользователей.
• После успешного развертывания временный фиче-флаг удалялся, а лимит храповика автоматически сдвигался вниз.

Главные архитектурные находки команды

В процессе аудита рантайма инженеры выявили несколько неочевидных проблем, которые годами накапливались в архитектуре веб-приложения и десктопного клиента:

1. Зависание при рендеринге тире и кавычек. При разборе длинных ответов модели с блоками кода движок JavaScript V8 неожиданно подвисал на целую секунду. Оказалось, что при появлении в тексте типографского тире (em dash) или фигурных кавычек движок переводил всю строку из однобайтового формата Latin-1 в двухбайтовую кодировку UTF-16. Это вызывало лавинообразное перевыделение памяти в библиотеке подсветки синтаксиса. Проблему полностью устранили компактной правкой всего в двадцать строк кода, нормализовавшей представление символов перед передачей в парсер.
2. Паразитная нагрузка на каждое нажатие клавиши. Анализ жизненного цикла компонентов показал, что при вводе каждого отдельного символа в поле сообщения повторно выполнялись 6900 хуков React и опрашивались 900 подписок на центральное хранилище состояния. Разделение контекста ввода и изоляция внутреннего состояния редактора избавили приложение от лишней работы.
3. Статический композер до гидратации. При медленном интернет-соединении пользователю приходилось ждать полной загрузки и гидратации многомегабайтного бандла скриптов, прежде чем курсор становился активным. Команда внедрила в начальную HTML-разметку страницы легковесный статический композер на чистом HTML. Пользователь может начать печатать запрос мгновенно, а введенный текст бесшовно передается в React-компонент, как только скрипты завершают инициализацию.
4. Предварительная компиляция кэша кода V8. В десктопном клиенте Claude Desktop основной процесс тратил секунды на повторный парсинг скриптов при каждом запуске. Внедрение генерации кэша байткода V8 (code cache) на этапе сборки дистрибутива позволило сократить время холодного старта почти в два раза.
5. Оптимизация боковой панели диалогов. Обновление списка активных чатов приводило к каскадному рендерингу всех элементов навигации. Мемоизация виртуализированного списка сократила количество лишних отрисовок боковой панели на 90%.

Опыт Anthropic доказывает, что радикальное ускорение сложных клиентских приложений складывается из двух составляющих: строгой культуры измерения без аппаратного шума и последовательного устранения мелких неэффективностей, которые невозможно обнаружить без глубокого профилирования инструкций.