Как ускорять тяжелую модель рекомендаций в рантайме
Есть трансформерная модель рекомендаций по истории пользователя. Как сделать так, чтобы она не ломала online-сервис?
Ответить самому
Сначала сформулируйте ответ как на собеседовании, затем откройте разбор и оцените себя.
Короткий ответ
Кэшировать item embeddings и последний user state, пересчитывать только изменившуюся часть истории, отделить генерацию кандидатов от реранжирования, использовать batching/quantization и держать fallback на популярное или старый top-K.
Полный разбор
Сначала нужно понять, что именно должно быть online. Item embeddings почти всегда можно считать заранее: каталог меняется медленнее пользовательских событий. User representation можно обновлять по событию, по TTL или при входе в секцию, но не пересчитывать всю длинную историю при каждом запросе.
Практичная схема: генерация кандидатов через ANN/векторный индекс или готовые эвристики, затем легкий реранкер по ограниченному числу кандидатов. Для heavy transformer стоит хранить последний user state или хотя бы последние top-K, инвалидировать его при новых важных событиях и пересчитывать асинхронно. Если нужен sync endpoint, он должен иметь жесткий timeout и fallback.
Инференс ускоряют batching, quantization FP16/INT8, ONNX/TensorRT/Triton, precomputed item vectors, cache hit rate monitoring и autoscaling. Но оптимизация не заменяет продуктовый контракт: сколько freshness реально нужно и что показываем, если модель не успела ответить.
Теория
В production RecSys latency чаще выигрывается архитектурой кэшей и разделением retrieval/реранжирования, а не только оптимизацией модели.
Типичные ошибки
- Каждый раз прогонять всю историю пользователя через трансформер.
- Не иметь fallback на случай timeout или пустых рекомендаций.
- Смешивать генерацию кандидатов и тяжелое реранжирование в один дорогой online-запрос.