Llama в проде ломается не на “качестве”, а на выборе размера, контекста и кванта

Llama в проде ломается не на “качестве”, а на выборе размера, контекста и кванта

Если нужен быстрый и предсказуемый API, сначала выбирают не “лучшую” модель, а режим работы: 8B для дешёвого high-throughput, 70B для сложных ответов, а между ними — компромисс по latency и VRAM. Ошибка №1 — тащить слишком большую модель в маленький контекст и ждать стабильного throughput.

Второй фильтр — квантизация. FP16 даёт максимум качества, но съедает память; int8 часто остаётся почти без потерь; int4 спасает VRAM, но сильнее бьёт по long-context и точности на редких токенах. Для чата и автоматизации int4 обычно ок, для критичных извлечений и сложного кода лучше держать запас по разрядности.

Третий вопрос — движок инференса. vLLM выигрывает на батчинге и высокой загрузке GPU, TGI удобен в сервисной обвязке, llama.cpp полезен там, где важны CPU/edge и GGUF. Если workload рваный, считайте не только tokens/sec, но и p95 latency: модель может быть “быстрой” в среднем и непригодной для интерактива.

Четвёртая ошибка — верить, что большой контекст “бесплатный”. На практике длина промпта режет throughput, а после определённой точки качество ответа падает даже без явных ошибок. Для продакшена лучше резать вход, делать retrieval и держать системный промпт коротким.

Правило простое: сначала выбери размер под задачу, потом квантизацию под VRAM, и только потом — фреймворк под твой профиль нагрузки.