← Журнал · · Заметка
Sticky-сессии vs EPP: как роутить запросы в LLM
Всем привет! В прошлом посте в комментах обсуждали inferencePool в llm-d, решил показать результаты сравнения роутинга трафика в llm с ним и без него.
В KServe 0.18 LLMInferenceService роутит запросы через InferencePool из Gateway API Inference Extension. Gateway (Envoy) перед проксированием спрашивает у EPP (Endpoint Picker), в какую реплику отправить запрос, а тот смотрит на префиксы в KV-кеше и очередь каждой реплики. Вариант попроще - sticky-сессии через consistentHash в Istio: одна сессия = одна реплика. Вопрос: стоит ли EPP возни?
Стенд: Qwen3-1.7B × 6 реплик vLLM на одной H100 (поделил через MPS), llm-d-inference-scheduler 0.7.1, Istio 1.28, нагрузка через aiperf, перед каждым прогоном кеш сбрасывается. Сравнивал round-robin, sticky, EPP approximate и EPP precise.
1️⃣ Общие system prompt'ы (агенты, RAG-инструкции). Тут sticky бесполезен: ключ сессии у каждого пользователя свой, и одинаковые префиксы разлетаются по всем репликам. Из кеша: EPP 90%, sticky 38%, round-robin 39%. TTFT p50 62 мс против 188 мс у sticky, а токенов/с на той же GPU +23%.
2️⃣ Multi-turn чаты - родной сценарий sticky. По кешу он почти догоняет (73% против 82%), но проигрывает по хвосту: TTFT p95 3.07 с против 561 мс. Ring hash раскладывает сессии неровно: на одну реплику прилетело до 19 из 36 диалогов, а её KV-кеш вмещает ~10. Дальше вытеснения, пересчёт контекста и очередь. Hash про загрузку ничего не знает, а EPP видит очередь и не даёт реплике захлебнуться.
3️⃣ Approximate vs precise. Precise видит реальное содержимое KV-кеша через ZMQ-события vLLM, но выигрыша не дал: на общих префиксах паритет, в multi-turn даже хуже (78% против 83%). Плюс настраивать его сильно сложнее: токенизатор-sidecar, ZMQ, согласование block size. Моя гипотеза: при забитом кеше precise честно видит «кеша нигде нет» и уводит следующий ход на другую реплику, а approximate помнит, куда отправлял сессию. Так что стартовать советую с approximate.
Если LLM крутится на нескольких репликах, sticky-сессии не заменят роутинг с учётом кеша и очереди, такие вот дела.