Скорость инференса GLM-5 на WaveSpeed: задержка и пропускная способность

Я хотела получить быстрый ответ во время написания письма для онбординга. GLM-5 казался умным, но первый токен появлялся достаточно долго, чтобы я поймала себя на том, что смотрю на курсор. Не катастрофа, просто небольшая пауза, которая повторялась снова и снова. Обычно это для меня сигнал проверить, что на самом деле происходит.

Доступно на WaveSpeedAI — прозрачная цена за токен, OpenAI-совместимый endpoint. GLM 5.1 API → · Открыть Playground →

Меня зовут Дора. Я провела простую серию тестов, чтобы понять, сколько скорости инференса GLM-5 можно выжать, не превращая рабочий процесс в научный проект. Ничего сложного — лишь достаточно, чтобы почувствовать разницу в реальной работе, а не в лабораторных условиях.

Методология тестирования (оборудование, настройки, длина запросов)

Я попробовала три способа доступа:

• WaveSpeed: лёгкий слой ускорения, который я тестировала — он управляет формированием запросов и кешированием на стороне клиента/шлюза.
• Прямой API Z.ai: прямой путь к GLM-5 через провайдера.
• OpenRouter: брокер, который перенаправляет запросы к провайдеру модели с некоторыми дополнительными возможностями.

Оборудование и контекст

• Локальный клиент: MacBook Pro (M2 Max, 64 ГБ ОЗУ). Сеть на стабильном оптоволокне (≈500 Мбит/с входящий, ≈30 мс до типичных американских эндпоинтов).
• Серверная сторона: без кастомного сервера, только клиентские вызовы, за исключением WaveSpeed, который запускает небольшой локальный шлюз для управления кешированием и пакетным формированием запросов.

Настройки, которые я держала неизменными

• Модель: GLM-5 (chat/completions), temperature 0.2, top_p 0.9, max_tokens 512.
• Стриминг включён — именно так я и работаю.
• Повторные попытки отключены, кроме сетевых ошибок.

Использованные запросы

• Короткие: 60–80 токенов (чёткая инструкция с 2–3 ограничениями).
• Средние: ≈350 токенов (черновик письма с заметками о бренде и примерами).
• Длинные: ≈1500 токенов (небольшой бриф с контекстом продукта, заметками о тоне и списками что делать/не делать).

Я провела 25 итераций для каждого условия и фиксировала:

• Время до первого токена (TTFT): от отправки запроса до первого стримингового токена.
• Пропускная способность (токенов/с): скорость вывода в стриминге после начала получения токенов.
• Переключатель «режима мышления» (reasoning traces провайдера).

Ключевые метрики

Время до первого токена (TTFT)

Короткие запросы давали TTFT в диапазоне 250–400 мс на хороших маршрутах. Средние запросы сдвигали TTFT ближе к 450–700 мс. Длинные запросы переваливали за одну секунду, если только не срабатывало кеширование. Скачок не был линейным: накладные расходы на очередь и валидацию, похоже, имели не меньшее значение, чем длина запроса.

Моё ощущение: меньше 400 мс ощущается как мгновенный ответ; всё, что больше секунды, выбивает из потока. Когда я правлю текст в реальном времени, первый токен важнее итоговой пропускной способности.

Токенов в секунду (пропускная способность)

После начала стриминга я видела 35–70 токенов/с в режиме без мышления. Для текста это вполне быстро, для дифов кода — на грани. На длинных выводах пропускная способность падала — подозреваю, что это серверное формирование запросов и проверки безопасности, а не чистая скорость модели.

Режим мышления vs. обычный режим

С включённым «мышлением» TTFT вырастал на 30–80%, а пропускная способность в ряде случаев падала вдвое. Текст получался более связным на сложных запросах, но для повседневных черновиков это было лишним. Поначалу это не экономило мне время, но после нескольких прогонов я заметила, что это снижает умственное напряжение при сложных правках. На простых задачах я оставляю режим выключенным.

Как ускорение WaveSpeed применяется к GLM-5

WaveSpeed не касался весов модели. Он делал две простые и полезные вещи на моей стороне канала: сокращал избыточную работу и формировал запросы так, чтобы провайдер мог двигаться быстрее. Для GLM-5 это выразилось в улучшенном TTFT на повторяющихся запросах и небольшом выигрыше на средних запросах.

ParaAttention и техники кеширования

• ParaAttention (мои заметки): вместо пакетирования несвязанных запросов WaveSpeed распараллеливает attention-дружелюбные блоки внутри одного длинного запроса, когда обнаруживает повторяющийся каркас. На практике он переиспользовал вступление (система + общие примеры) и передавал только дельту. Я не могу проверить внутреннее устройство, но эффект выглядел как частичное переиспользование KV-кеша на уровне шлюза.
• Кеширование: оно мемоизировало эмбеддинги для вступительной части запроса и коротких системных шаблонов. Когда я итерировала по одной задаче с небольшими правками, TTFT снижался на ≈120–180 мс. На холодных запросах выигрыш был скромнее (≈40 мс), но всё равно заметен.

Ограничения, с которыми я столкнулась

• Первый холодный запуск по-прежнему ограничен апстримом. Никаких чудес.
• Если я меняла больше ≈20% запроса, кеш не помогал.
• Режим мышления в значительной мере нейтрализовал выигрыш: reasoning trace вёл себя как отдельный поток.

Сравнение: WaveSpeed vs прямой API Z.ai vs OpenRouter

Именно здесь небольшие различия имеют значение.

• Прямой API Z.ai: стабильный. Наименьший разброс TTFT. Когда мне нужны предсказуемые старты для демо, это мой выбор. На длинных запросах штраф TTFT был реальным, но постоянным.
• OpenRouter: TTFT в среднем немного выше, чуть больше разброс, но простая настройка и гибкость маршрутизации. Хорошо, когда я работаю с несколькими моделями. Документация неплохая — см. руководства OpenRouter.

• Слой WaveSpeed: лучший TTFT на тёплых запросах и средних входных данных — вероятно, за счёт кеширования и формирования запросов. На действительно холодных длинных запросах — наравне с прямым подключением.

Ни один из этих вариантов не изменил базовое поведение GLM-5. Они изменили, насколько быстро я ощущала, что модель «просыпается», и насколько плавной была итерация.

Если вы выбираете:

• Нужна стабильная производительность и меньше движущихся частей? Идите напрямую через провайдера. Ориентир: документация ZhipuAI API.
• Нужна маршрутизация между моделями или общие ключи между инструментами? OpenRouter подойдёт, примите несколько лишних миллисекунд.
• Итерируете на похожих запросах весь день? Лёгкий слой ускорения окупается душевным спокойствием больше, чем чистой скоростью.

Советы по оптимизации для production-нагрузок

Что реально помогло на практике:

• Прогрейте вступление: держите системные запросы и общие примеры стабильными. Кешируйте их, даже на стороне клиента. Мой выигрыш по TTFT: ≈100–200 мс на повторах.
• Обрежьте хвост: ограничьте max_tokens тем, что вам действительно нужно. Снижение лимита с 1000 токенов до 400 сократило общее время на 10–20% для моих черновиков.
• Предпочитайте структурированные повторы: если нужно повторить запрос, возобновляйте стримы, а не перезапускайте их. Слепые повторы убивали TTFT.
• Контролируйте вариативность: temperature ≤0.3 для production. Меньшая энтропия сокращала серверные проходы и делала пропускную способность более стабильной.
• Откладывайте режим мышления: включайте его только на запросах, которые исторически дают сбои. Я составляю карту «сложных запросов» и переключаю флаг для каждого маршрута.
• Разбивайте длинный контекст заранее: суммируйте справочные материалы один раз, сохраняйте резюме и переиспользуйте его. Второй и третий запуски ощущаются значительно легче.
• Следите за токенизацией: разные SDK токенизируют немного по-разному. Зафиксируйте клиент и измерьте заново — именно из-за этого я видела призрачные регрессии.
• Измеряйте p95, а не только p50: скачки в хвосте вызывают видимые задержки, которые запоминают пользователи.

Сырые данные бенчмарков (таблица)

Вот снимок данных из моих запусков (25 итераций на строку). Все числа приблизительные, но репрезентативные для того, что я ощущала за клавиатурой.

Примечания

• «Тёплое вступление» означает, что системный запрос + общие примеры были кешированы шлюзом.
• Пропускная способность измеряется после первого токена. Общее время = TTFT + токены_на_выходе / пропускная_способность.
• Сеть была стабильной: когда я тестировала на гостиничном Wi-Fi, всё выглядело хуже на 10–20%.

Последнее наблюдение: сократить TTFT на 150 мс было для меня важнее, чем добавить 5 токенов/с, потому что это уменьшало маленькое ожидание, которое провоцирует переключение контекста. Это не универсальное правило — просто то, как мой мозг воспринимает потоки.