Мы делаем Cloudflare лучшим местом для создания и развертывания агентов. Но надежные агенты строятся не только на промптах; им требуется надежная, скоординированная инфраструктура базовых примитивов.
В Cloudflare мы годами создавали эти примитивы: Durable Objects для сохранения состояния, Workflows для долгосрочных задач и Dynamic Workers или контейнеры Sandbox для безопасного выполнения. Мощные абстракции, такие как Agents SDK, разработаны, чтобы помочь вам создавать агентов поверх Cloudflare Developer Platform.
Но эти примитивы обеспечивали только среду выполнения. Агенту по-прежнему нужна была модель, способная его питать.
Начиная с сегодняшнего дня, Workers AI официально вступает в игру больших моделей. Теперь мы предлагаем передовые модели с открытым исходным кодом на нашей платформе AI-инференса. Мы начинаем с выпуска модели Kimi K2.5 от Moonshot AI в Workers AI. Обладая полным контекстным окном в 256k токенов и поддержкой многозадачного вызова инструментов, визуальных входных данных и структурированных выходных данных, модель Kimi K2.5 отлично подходит для всех видов агентских задач. Внедряя модель фронтьерного масштаба непосредственно в Cloudflare Developer Platform, мы делаем возможным запуск всего жизненного цикла агента на единой унифицированной платформе.
Сердце агента — это AI-модель, которая им управляет, и эта модель должна быть умной, с высокими способностями к рассуждению и большим контекстным окном. Workers AI теперь запускает такие модели.
Точка оптимального соотношения цены и производительности
Последние несколько недель мы тестировали Kimi K2.5 в качестве движка для наших внутренних инструментов разработки. В нашей среде OpenCode инженеры Cloudflare используют Kimi как ежедневный инструмент для агентских задач по программированию. Мы также интегрировали модель в наш конвейер автоматизированного ревью кода; вы можете увидеть это в действии через нашего публичного агента для ревью кода, Bonk, в репозиториях Cloudflare на GitHub. В производственной среде модель доказала свою эффективность как быстрая и экономичная альтернатива более крупным проприетарным моделям без потери качества.
Предоставление Kimi K2.5 началось как эксперимент, но быстро стало критически важным после оценки производительности модели и её экономической эффективности. В качестве наглядного примера: у нас есть агент, который проводит проверки безопасности кодовых баз Cloudflare. Этот агент обрабатывает более 7 миллиардов токенов в день, и с помощью Kimi он обнаружил более 15 подтвержденных проблем в одной кодовой базе. По приблизительным подсчетам, если бы мы запускали этого агента на проприетарной модели среднего уровня, мы потратили бы 2,4 миллиона долларов в год только на этот один случай использования в одной кодовой базе. Запуск этого агента с Kimi K2.5 обошелся лишь в малую часть этой суммы: мы сократили затраты на 77%, просто перейдя на Workers AI.
С ростом внедрения ИИ мы наблюдаем фундаментальный сдвиг не только в том, как работают инженерные команды, но и в том, как работают отдельные люди. Все более распространенной становится ситуация, когда у человека есть персональный агент, например OpenClaw, работающий круглосуточно. Объем инференса стремительно растет.
Этот новый рост персональных и программистских агентов означает, что стоимость перестала быть второстепенной проблемой; теперь это главное препятствие для масштабирования. Когда у каждого сотрудника есть несколько агентов, обрабатывающих сотни тысяч токенов в час, расчеты для проприетарных моделей перестают работать. Предприятия будут стремиться перейти на модели с открытым исходным кодом, которые предлагают рассуждения уровня фронтьерных моделей без проприетарной ценовой политики. Workers AI здесь, чтобы облегчить этот переход, предоставляя все — от бессерверных эндпоинтов для персонального агента до выделенных инстансов, питающих автономных агентов по всей организации.
Стек инференса больших моделей
Workers AI обслуживает модели, включая LLM, с момента своего запуска два года назад, но исторически мы отдавали приоритет более мелким моделям. Отчасти это было связано с тем, что некоторое время LLM с открытым исходным кодом сильно отставали от моделей ведущих лабораторий. Это изменилось с появлением таких моделей, как Kimi K2.5, но для обслуживания этого типа очень больших LLM нам пришлось внести изменения в наш стек инференса. Мы хотим поделиться с вами некоторыми деталями того, что происходит за кулисами для поддержки такой модели, как Kimi.
Мы работали над пользовательскими ядрами для Kimi K2.5, чтобы оптимизировать обслуживание модели, которая построена поверх нашего проприетарного движка инференса Infire. Пользовательские ядра улучшают производительность модели и утилизацию GPU, открывая доступ к выгодам, которые остались бы неиспользованными, если бы вы просто запускали модель "из коробки". Существует также несколько техник и конфигураций оборудования, которые можно использовать для обслуживания большой модели. Разработчики обычно используют комбинацию методов параллелизации данных, тензоров и экспертов для оптимизации производительности модели. Также важны такие стратегии, как распределенный префилл (disaggregated prefill), при котором этапы префилла и генерации разделяются на разные машины для повышения пропускной способности или лучшей утилизации GPU. Реализация этих техник и их интеграция в стек инференса требует большого опыта и усилий, чтобы все сделать правильно.
Workers AI уже провела эксперименты с техниками обслуживания, чтобы обеспечить отличную пропускную способность для Kimi K2.5. Многое из этого не доступно "из коробки" при самостоятельном хостинге модели с открытым исходным кодом. Преимущество использования такой платформы, как Workers AI, заключается в том, что вам не нужно быть инженером по машинному обучению, экспертом по DevOps или инженером по надежности сайтов (SRE), чтобы выполнить необходимые оптимизации для её хостинга: мы уже сделали сложную часть, вам нужно лишь вызвать API.
За пределами модели — улучшения платформы для агентских рабочих нагрузок
Параллельно с этим запуском мы также улучшили нашу платформу и выпускаем несколько новых функций, которые помогут вам создавать лучших агентов.
Кеширование префиксов и отображение закешированных токенов
При работе с агентами вы, вероятно, отправляете большое количество входных токенов в качестве части контекста: это могут быть детальные системные промпты, определения инструментов, инструменты сервера MCP или целые кодовые базы. Входные данные могут быть размером с контекстное окно модели, поэтому теоретически вы можете отправлять запросы с почти 256 тысячами входных токенов. Это очень много токенов.
Когда LLM обрабатывает запрос, запрос разбивается на два этапа: этап префилла обрабатывает входные токены, а этап вывода генерирует выходные токены. Эти этапы обычно идут последовательно, где входные токены должны быть полностью обработаны, прежде чем можно будет генерировать выходные токены. Это означает, что иногда GPU используется не полностью, пока модель выполняет префилл.
В многозадачных диалогах, когда вы отправляете новый промпт, клиент также отправляет модели все предыдущие промпты, инструменты и контекст сессии. Разница между последовательными запросами обычно составляет всего несколько новых строк ввода; весь остальной контекст уже прошел этап префилла во время предыдущего запроса. Здесь помогает кеширование префиксов. Вместо того чтобы выполнять префилл для всего запроса, мы можем закешировать входные тензоры из предыдущего запроса и выполнить префилл только для новых входных токенов. Это экономит много времени и вычислительных ресурсов на этапе префилла, что означает более быстрое время до первого токена (TTFT) и более высокую пропускную способность (токенов в секунду, TPS), поскольку вы не блокируетесь на префилле.
Workers AI всегда выполнял кеширование префиксов, но теперь мы отображаем закешированные токены как метрику использования и предлагаем скидку на закешированные токены по сравнению с входными токенами. (С информацией о ценах можно ознакомиться на странице модели.) У нас также есть новые техники, которые вы можете использовать для повышения процента попаданий в кеш префиксов, сокращая свои расходы.
Новый заголовок привязки к сессии для повышения процента попаданий в кеш
Для маршрутизации на один и тот же экземпляр модели и использования преимуществ кеширования префиксов мы используем новый заголовок x-session-affinity. Когда вы отправляете этот заголовок, вы улучшите свой процент попаданий в кеш, что приведет к увеличению количества закешированных токенов и, как следствие, к более быстрому TTFT, более высокой TPS и снижению стоимости инференса.
Вы можете передать новый заголовок, как показано ниже, с уникальной строкой для каждой сессии или каждого агента. Некоторые клиенты, такие как OpenCode, реализуют это автоматически "из коробки". Наш Agents SDK starter также уже настроен для этого.
curl -X POST
"https://api.cloudflare.com/client/v4/accounts/{ACCOUNT_ID}/ai/run/@cf/moonshotai/kimi-k2.5"
-H "Authorization: Bearer {API_TOKEN}"
-H "Content-Type: application/json"
-H "x-session-affinity: ses_12345678"
-d '{
"messages": [
{
"role": "system",
"content": "Вы полезный ассистент."
},
{
"role": "user",
"content": "Что такое кэширование префиксов и почему это важно?"
}
],
"max_tokens": 2400,
"stream": true
}'
Переработанные асинхронные API
Бессерверный вывод (inference) — это действительно сложно. При модели оплаты за токен это дешевле для единичного запроса, потому что вам не нужно платить за целые GPU для обработки ваших запросов. Но есть компромисс: вам приходится конкурировать с трафиком других пользователей и ограничениями по пропускной способности, и нет строгой гарантии, что ваш запрос будет обработан. Это не уникально для Workers AI — очевидно, это характерно для всех поставщиков бессерверных моделей, учитывая частые новости о перегруженных провайдерах и сбоях в обслуживании. Хотя мы всегда стремимся обслужить ваш запрос и имеем встроенное автомасштабирование и ребалансировку, существуют жёсткие ограничения (такие как аппаратное обеспечение), которые делают это задачей непростой.
Для объёмов запросов, которые превышают синхронные лимиты скорости, вы можете отправлять пакеты запросов на вывод для асинхронного выполнения. Мы представляем переработанный Асинхронный API, что означает: для асинхронных сценариев использования вы не столкнётесь с ошибками "Нехватка ресурсов" (Out of Capacity), и вывод будет надёжно выполнен в какой-то момент. Наш асинхронный API больше похож на гибкую обработку, чем на пакетный API, где мы обрабатываем запросы в асинхронной очереди, пока у нас есть свободные ресурсы в наших экземплярах моделей. По внутреннему тестированию, наши асинхронные запросы обычно выполняются в течение 5 минут, но это будет зависеть от текущей нагрузки. По мере открытия доступа к Kimi для публики, мы соответствующим образом настроим масштабирование, но асинхронный API — лучший способ гарантировать, что вы не столкнётесь с ошибками нехватки ресурсов в надёжных рабочих процессах. Это идеально подходит для сценариев, не требующих работы в реальном времени, таких как агенты сканирования кода или исследовательские агенты.
Workers AI ранее имел асинхронный API, но мы недавно переработали внутренние системы. Теперь мы используем систему, основанную на pull-модели (подтягивании), в отличие от исторической push-модели (проталкивания), что позволяет нам забирать запросы из очереди, как только у нас появляются свободные ресурсы. Мы также добавили улучшенные средства управления для настройки пропускной способности асинхронных запросов, отслеживая загрузку GPU в реальном времени и забирая асинхронные запросы, когда загрузка низкая, чтобы критически важные синхронные запросы получали приоритет, при этом эффективно обрабатывая асинхронные запросы.
Чтобы использовать асинхронный API, вы отправляете свои запросы, как показано ниже. У нас также есть способ настроить уведомления о событиях, чтобы вы могли узнавать о завершении вывода, вместо того чтобы опрашивать статус запроса.
// (1.) Поместить запрос в очередь
// передать queueRequest: true
let res = await env.AI.run("@cf/moonshotai/kimi-k2.5", {
"requests": [{
"messages": [{
"role": "user",
"content": "Расскажи анекдот"
}]
}, {
"messages": [{
"role": "user",
"content": "Объясни теорему Пифагора"
}]
}, ...{<добавь больше запросов в пакет>} ];
}, {
queueRequest: true,
});
// (2.) Получить идентификатор запроса
let request_id;
if(res && res.request_id){
request_id = res.request_id;
}
// (3.) Опрашивать статус
let res = await env.AI.run("@cf/moonshotai/kimi-k2.5", {
request_id: request_id
});
if(res && res.status === "queued" || res.status === "running") {
// повторить, опросив снова
...
}
else
return Response.json(res); // Это будет содержать окончательный завершённый ответ
Попробуйте сегодня
Начните работу с Kimi K2.5 на Workers AI уже сегодня. Вы можете прочитать нашу документацию для разработчиков, чтобы узнать информацию о модели и ценообразовании, а также как воспользоваться преимуществами кэширования промптов через заголовки сходства сессий (session affinity) и асинхронного API. Стартовый пакет SDK для агентов теперь также использует Kimi K2.5 в качестве модели по умолчанию. Вы также можете подключиться к Kimi K2.5 на Workers AI через Opencode. Чтобы попробовать вживую, испытайте модель в нашей песочнице (playground).
И если этот набор проблем, связанных с бессерверным выводом, оптимизацией машинного обучения и GPU-инфраструктурой, кажется вам интересным — мы нанимаем!
