Мы протестировали 3 модели с открытым весом для многошаговых агентов

Источник: Telnyx•

Мы протестировали 3 модели с открытым весом для многошаговых агентов

Мы провели 45 диалогов с многошаговыми агентами с использованием GLM-5.3 Flash, GLM-5.3 и Kimi K3. Результаты показывают, как подобрать модель под вашу рабочую нагрузку.

Производственным агентам редко достается простой одношаговый промпт. Пользователь исправляет модель, удаляет требование, добавляет ограничение, а затем запрашивает итоговый формат. Каждый такой шаг — это шанс потерять нить разговора, и модель, которая хорошо справляется с одиночными промптами, ничего не говорит о том, как она удерживает диалог целиком.

Поэтому мы протестировали то, что действительно важно. Мы провели 45 полных четырехходовых диалогов на трех моделях с открытым весом, оценили финальные ответы с помощью детерминированных проверок и привлекли двух независимых слепых судьей для оценки каждого разговора без указания названий моделей. Все три модели работали через один и тот же Telnyx Inference API, на одном клиенте и с одинаковыми настройками.

Результат не сводится к единственному победителю. Kimi K3 завершила каждый диалог по мнению обоих судьей и получила безупречные оценки за исправления. GLM-5.3 Flash показала 90-процентное завершение задач с самой быстрой задержкой среди тройки. GLM-5.3 не уступила Kimi K3 в объективных проверках, обменяв скорость на глубину. Какая из них подойдет вам, зависит от того, что сильнее бьет по вашей рабочей нагрузке, и в этом суть данного руководства: нет универсально лучшей модели, есть лишь правильная модель для конкретного цикла.

Этот цикл тестирования недорог по структурной причине. Модели с открытым весом работают на принадлежащих нам GPU, благодаря чему их стоимость обслуживания на 75% ниже по сравнению с проприетарными пограничными API, а каждая модель находится за единым OpenAI-совместимым API. Тестирование трех кандидатов означает изменение одной строки в вашем клиенте, а не подключение трех разных вендоров. Именно это превращает оценку моделей из проекта по закупкам в задачу на полдня.

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

Что упускают одношаговые бенчмарки в разговорах с агентами

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

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

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

Воспроизводимая методика тестирования многоходовых агентов

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

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

Оценку работы выполняют два уровня. Детерминированные проверки верифицируют валидный JSON, обязательные поля, сохраненные факты, запрещенные отмененные факты и ограничения формата — всего 28 проверок на модель и 84 на три модели. Затем два независимых судьи, DeepSeek V4.1 Flash и MiniMax-M3, читают каждый диалог с удаленными именами кандидатов из промптов. Каждый судья выносит бинарное решение о завершении, а также ставит пять оценок от 1 до 5 по категориям: завершение задачи, корректность, отслеживание состояния в диалоге, следование исправлениям и ограничениям, а также применимость финального ответа.

Полный прогон сгенерировал 45 завершенных четырехходовых диалогов, 180 шагов модели, 84 детерминированные проверки и 90 слепых оценок. Каждая модель работала с параметром reasoning_effort, установленным в low, температурой 0 и ограничением в 4096 токенов — и все это через один и тот же OpenAI-совместимый эндпоинт вывода.

Одна деталь важна для всех, кто создает агентов. Сам оркестратор представлял собой Stateful Actor, который сохранял прогресс на протяжении всего прогона и экспортировал результаты на уровне шагов. Он выполнил 45 диалогов и 180 вызовов модели без единой ошибки HTTP, тайм-аута или усеченного ответа от любой из трех моделей. Многоходовая оркестрация с сохранением состояния — это именно та рабочая нагрузка, для которой существуют Stateful Actors, поэтому данный бенчмарк одновременно послужил проверкой платформы.

Что бенчмарк показал в отношении завершенности и качества

Завершение по мнению судьи — это бинарный вопрос о том, завершил ли диалог задачу (всего 30 решений на модель: два судьи по 15 диалогов). Объективные проверки оценивают только финальные ответы. Все три модели успешно завершили все 15 диалогов и все 60 шагов модели без ошибок HTTP, тайм-аутов или усеченных ответов, поэтому эти цифры отражают поведение моделей, а не надежность инфраструктуры.

Судьи сошлись в бинарной оценке завершения для 43 диалогов из 45 (уровень согласия 95,6%), а их пятимерные оценки различались в среднем на 0.16 балла. Такое согласие важно, поскольку оно указывает на то, что приведенные ниже рейтинги не являются следствием вкусов кого-то одного из судьей.

Kimi K3 получила наивысший или разделенный наивысший балл в большинстве комбинаций судей и параметров. Оба судьи поставили ей безупречные 5.00 из 5 за следование исправлениям — параметр, по которому многоходовые рабочие нагрузки бьют сильнее всего. По применимости финального ответа DeepSeek поставил 5.00, а MiniMax — 4.80.

Обратите внимание на то, где расходятся рейтинги. По объективным проверкам три модели находятся в пределах пяти баллов друг от друга (22, 23 и 23 из 28). Разрыв проявляется в экспертной оценке завершения, где Kimi K3 показала результат 30 из 30, а модели GLM провалили по три диалога каждая. Судья отмечает диалог как незавершенный, когда исправление остается без внимания или всплывает удаленный факт — именно с таким типом сбоев с трудом справляется фиксированный чек-лист.

Как задержка влияет на выбор модели

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

Были измерены три потоковых события. TTFT — это первый непустой вывод модели, который все еще может представлять собой рассуждение. TTFA — это время до появления первого видимого текста ответа. E2E — это момент завершения потокового ответа. Это различие имеет значение для моделей рассуждения, где в TTFT могут преобладать токены размышлений, которые пользователь никогда не видит.

GLM-5.3 Flash демонстрирует лучший профиль задержки для каждого медианного значения и завершает полный диалог на уровне p95 за 31,27 секунды, что составляет менее половины наблюдаемого «хвоста» двух других моделей. Kimi K3 обеспечивает лучший показатель p95 для первого ответа — 2,20 секунды, но самый длинный общий «хвост» диалога — 55,71 секунды, что является характерным признаком более глубоких рассуждений в середине диалога. GLM-5.3 оказывается самой медленной на каждом медианном значении, что является платой за работу флагманской модели.

Соотнесите профиль с циклом работы. Интерактивные агенты ощущают p50 первого ответа на каждом шаге, а фоновые конвейеры — общее время диалога. Разрыв между первым токеном и завершенным ответом сам по себе показателен, а более ранний бенчмарк TTFT и E2E показывает, как часто самый быстрый первый токен проигрывает гонку до завершенного ответа. Для контекста на уровне провайдеров по этим семейств моделей в специальном исследовании задержек GLM 5.3 сравнивается Telnyx с другими провайдерами. Отдельный бенчмарк GLM 5.3 Flash аналогичным образом отслеживает пропускную способность и поведение «хвостов».

Как выбрать модель для многошаговой рабочей нагрузки

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

Выбирайте Kimi K3, когда неудачный шаг обходится дорого. Это была единственная модель, которую оба судьи оценили как завершившую все 15 диалогов, и оба судьи поставили ее следованию исправлениям высшую оценку 5,00. Она также показала лучший результат p95 первого ответа среди трех моделей — 2,20 секунды. Moonshot . Kimi K3 на Telnyx Inference имеет окно контекста на 1 млн токенов с настраиваемой интенсивностью рассуждений. Цена вопроса — стоимость и задержка в «хвосте». Токены вывода Kimi K3 стоят примерно в 30 раз дороже, чем вывод GLM-5.3 Flash, и она показала самое большое время диалога p95 в этом тесте. Когда неудачный поворот означает перезапуск длинного рабочего процесса, оплата модели, которая никогда не теряет нить разговора, обычно оказывается более дешевым вариантом.

Выбирайте GLM-5.3 Flash, когда главным ограничением является объем. Она показала самый быстрый первый ответ p50 за 0,41 секунды, самый быстрый диалог p50 за 8,35 секунды, а «хвост» диалога p95 составил менее половины показателей двух других моделей. Завершенность по оценке судей составила 90 процентов, а по объективным проверкам она отстала всего на одну проверку из 28. Для агента, совершающего много шагов на задачу, повторная попытка примерно для каждого десятого диалога, который судья помечает как незавершенный, может обойтись дешевле, чем переплата за каждый токен на каждом шаге. Z.ai разработала ее для снижения вычислительных затрат на инференс, откуда и берется такой профиль задержки.

Выбирайте GLM-5.3, когда сама задача сложна. Она сравнялась с Kimi K3 по объективным проверкам (23 из 28), сохранила 90-процентную завершенность по оценкам судей, а Z.ai позиционирует ее для сложного написания кода и долгосрочных задач. Цена за это — задержка, так как в данном тесте она оказалась самой медленной моделью на каждом медианном значении. Токены вывода стоят около 30 процентов от цены Kimi K3, поэтому по стоимости она занимает промежуточное положение между двумя другими. Выбирайте ее, когда точность в сложной проблеме оправдывает затраты реального времени, а ваш бюджет находится где-то между Flash и Kimi.

Что бы вы ни выбрали, экономика подчиняется одной и той же структуре. Это модели с открытыми весами на наших собственных графических процессорах, благодаря чему они обслуживаются на сумму до 75 процентов дешевле, чем проприетарные флагманские API. Многошаговые рабочие нагрузки усиливают это преимущество, поскольку расход токенов масштабируется вместе с количеством шагов, а ценообразование кэшированного ввода снижает его еще сильнее, так как повторно отправляемая история — это именно то, для чего созданы тарифы кэширования. Кэшированный ввод Kimi K3 работает со скоростью в одну десятую от его некашированной ставки, а в четырехшаговом диалоге большая часть входных токенов тратится на историю, которую модель уже видела к третьему шагу.

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

Чего этот бенчмарк не может вам сказать

Воспринимайте эти цифры как исходное распределение, а не как перепись.

  • 15 сценариев — это выборка, а не генеральная совокупность. Рейтинги меняются при использовании другого набора промптов.
  • Сценарии являются синтетическими. Реальные исправления приходят в гораздо более запутанном виде, чем то, что производит скрипт бенчмарка.
  • Судьи — это модели. Два семейства судей и уровень согласованности 95,6 процента снижают предвзятость одного судьи, но судьи на базе LLM все равно оценивают с помощью моделей, а не людей.
  • Параметр reasoning_effort везде был низким. Более высокая интенсивность меняет качество и задержку в обоих направлениях, и рейтинги при высокой интенсивности могут отличаться.
  • Показатели задержки — это наблюдаемые распределения от одного запуска, а не гарантии уровня обслуживания. Емкость и регион влияют на «хвосты».

Практический ответ — это то, чем заканчивается данное руководство: запустите тестовый комплекс на собственном трафике, прежде чем принимать окончательное решение.

Запустите собственный многошаговый тест на Telnyx Inference

Тестовый комплекс невелик. Список сценариев, цикл, который повторно отправляет всю историю на каждом шаге, несколько детерминированных проверок и экспорт в JSON для судей. Сам вызов инференса представляет собой стандартный шаблон быстрого старта, совместимый с OpenAI, с заменой модели для каждого кандидата.

Измените строку MODEL и запустите заново. Никакого нового вендора, никаких новых счетов, никаких новых клиентов. Эта замена в одну строку — причина, по которой цикл оценки в этом руководстве дешево повторять всякий раз, когда появляется новая модель.

Для оркестрации Stateful Actor является естественной средой для многошагового тестового комплекса, поскольку он сохраняет прогресс на протяжении всего запуска, именно так и выполнялся этот бенчмарк. Запланированная функция Telnyx Function подходит для более коротких циклов оценки при каждом выпуске новой модели.

Для агентов, которые строят себя вокруг платформы, llms.txt предоставляет документацию в виде машиночитаемого индекса. Файл ai/pricing.json передает тарифы моделей в виде структурированных данных. Ваш тестовый комплекс может получать актуальные тарифы вместо их жесткого кодирования.

Оценки на одном шаге помогли вам составить короткий список. Многошаговое поведение выбирает модель. Создайте учетную запись и запустите свои 15 сценариев для всех трех моделей. Для производственных объемов с любой из них обратитесь к нашей команде для обсуждения тарифов.

О чём эта статья