AI / LLM
Streaming: тест с множественным выбором
Шесть вопросов, которые проходят сквозь весь юнит. Каждый — это решение, которое ты принимаешь в реальном инциденте со streaming: не определение для зубрёжки, а компромисс, который надо взвесить, когда спиннер висит в проде.
Убедись, что ты связываешь модель латентности, жизненный цикл SSE, накопление delta, контракт частичного JSON и отказ из-за буферизации — тот синтез, к которому вёл урок.
Ответ на 400 токенов генерируется со скоростью 60 ток/с. Продукт просит «сделать ответ вдвое быстрее», включив streaming. Что ты ответишь на senior-уровне?
Твой чат идеально стримит на localhost, но в staging каждый ответ появляется разом после долгой паузы. Куда смотреть в первую очередь?
Модель вызывает tool; аргументы приходят как input_json_delta-чанки: '{"city": "San Fran', затем 'cisco", "unit":', затем ' "celsius"}'. Когда можно сделать JSON.parse буфера?
В проде tool-вызов срабатывает с input = {} (пустые аргументы), но тот же промпт локально напрямую к провайдеру работает. Самая вероятная причина?
Соединение рвётся на 200-м токене из 400. Какой честный senior-дефолт для обработки?
Reasoning-модель с chain-of-thought держит TTFT 30с, не выдав ни одного токена; пользователи говорят, что приложение «зависло». Как правильно это прочитать и починить?
Сквозная линия юнита — одна модель: streaming платит за воспринимаемую латентность скоростью чтения пользователя, схлопывая TTFT, тогда как общее время и число токенов неизменны. SSE доставляет типизированный жизненный цикл (message_start → content_block_start → content_block_delta ×N → content_block_stop → message_delta/stop), который ты накапливаешь; text-delta рендерятся сразу, а фрагменты input_json_delta для tool парсятся только на content_block_stop. Пустые аргументы tool означают, что delta съел промежуточный слой; оборванные stream — повторяемые retry всего хода; а отказ, стирающий весь выигрыш и не требующий обрыва соединения, — буферизующий прокси, превращающий TTFT обратно в общее время.