Server-Sent Events долгое время выглядели как идеальный транспорт для стриминга ответов ИИ: просто, по-HTTP, без сложной инфраструктуры. Именно поэтому SSE так быстро прижились в SDK и демо-проектах. Но по мере того как LLM перестали быть игрушкой и стали дорогим вычислительным сервисом, выяснилось неприятное: SSE плохо сочетается с самой природой генерации токенов.
И проблема тут не в скорости сети. Проблема — в потере прогресса.
Когда обрыв соединения становится финансовой проблемой
Генерация токенов — самая дорогая часть LLM-запроса. Транспорт стоит копейки, инференс — доллары. И именно поэтому транспорт обязан быть максимально надёжным.
SSE этому требованию не отвечает. Если соединение обрывается — а для мобильных сетей, Wi-Fi и VPN это норма — всё начинается сначала. Модель повторно генерирует уже выданные токены, пользователь снова ждёт, а счёт за инференс растёт.
Типичные сценарии выглядят так:
- 🚇 пользователь заехал в туннель
- 📡 телефон сменил сеть
- 😴 браузер выгрузил вкладку
- 🔌 кратковременный сетевой глитч
Во всех этих случаях SSE-стрим просто умирает. Без возможности «продолжить с места».
Почему «ну давайте просто WebSocket» не спасает
На первый взгляд WebSocket кажется логичным апгрейдом: двунаправленный канал, интерактивность, меньше ограничений. Но фундаментальную проблему он не решает.
Если WebSocket соединение оборвалось:
- 🧠 сервер не знает, какие токены дошли
- 🔁 клиент вынужден повторить запрос
- 💸 инференс запускается заново
То есть меняется форма трубы, но не её свойства. Прогресса как не было, так и нет.
SSE и иллюзия возобновляемости
Формально SSE допускает возобновление (resume) через Last-Event-ID. На практике это означает:
- 📌 каждый токен должен иметь индекс
- 💾 токены нужно сохранять на сервере
- 🔍 при реконнекте искать точку продолжения
Как только вы это реализуете, вы внезапно понимаете:
вы уже пишете систему доставки сообщений, просто очень неудобную.
И тут всплывает ещё одна боль — SDK. Многие популярные библиотеки заставляют выбирать: приходится выбирать: либо прерывание, либо возобновление. Совместить оба сценария корректно почти невозможно.
Pub/Sub как естественная модель для LLM
Если посмотреть на проблему без привязки к HTTP, становится очевидно: поток токенов — это лог событий. А лучший способ доставлять события — Pub/Sub.
В такой модели:
- 📣 сервер публикует токены в топик
- 👂 клиент подписывается и читает их
- 🔄 при обрыве клиент переподключается и продолжает
- 🧾 инференс не перезапускается
Это радикально меняет UX и экономику. Генерация идёт своим ходом, доставка становится независимой от качества соединения.
Но есть неприятный нюанс
Pub/Sub — не бесплатен. И тут возникает парадокс:
может оказаться, что доставка токенов дороже их генерации.
Именно поэтому SSE до сих пор живёт:
он дешёвый, простой и встроен в инфраструктуру. Просто он плохо подходит для задач, где токены — это ценный и невосполнимый ресурс.
Моё мнение: SSE — это прототип, а не продакшен
SSE — отличный инструмент для демо, внутренних сервисов и сервер-сервер сценариев. Но использовать его как транспорт для LLM-токенов в пользовательских приложениях — значит игнорировать реальность сетей и стоимость инференса.
LLM требуют другого мышления:
- 🧠 токены — это состояние
- 📜 поток — это лог
- 🔁 возобновляемость — обязательна
Как только вы принимаете это, SSE перестаёт выглядеть «достаточно хорошим» решением.
Источники и ссылки
🔗 Оригинальная статья /dev/knill:
https://zknill.io/posts/sse-sucks-for-transporting-llm-tokens/
🔗 Блог автора:
https://zknill.io