The post has been translated automatically. Original language: Russian
Let's share our experience: in recent months, we have implemented several LLM tools within the team and have come to several simple conclusions about models, stacks and pipelines. Without switching to enterprise plugins and without overpaying for "AI-everything".
We divide the models by tasks
Not one universal model, but two — light and heavy. Lightweight models (Gemini Flash, Claude Haiku) cover short queries, classification, update parsing, and voice transformations. Heavy (Gemini Pro, Claude Sonnet/Opus) — long context, transcript analysis, reasoning from several sources.
In env, we keep the MODEL_FAST and MODEL_SMART variables separately. This allows you to switch models without editing the code and adjust the cost. In our experience, 70-80% of requests go to the "fast" model and are ten times cheaper than if everything flowed to the top.
Which tasks close well
- Tracking project progress with parsing of voice updates from the team
- Customer call analytics: decryption + automatic script markup
- Summarizing long meetings and comparing them with the plan
- Generation of short videos on your own GPU-infra
What was taken out on the way
- Whisper is not always needed. Modern multimodal models accept audio directly — this removes one link of the pipeline and reduces latency and cost.
- It is better to start with the thinnest pipeline: one function, one prompt. Any premature complication multiplies bugs and latencies.
- Prompta are evolving. We store them in the repository as code: reviews, versions, regression tests.
- Agent-based development environments (like Claude Code) really shorten the cycle from idea to pilot. Especially for small internal services that had never been reached before.
- GPU infra for inference: for short video tasks on distilled models, a 24 GB VRAM card is sufficient. The bottleneck is usually IO and the loading of weights, not the tensor count itself.
The base stack
Python + FastAPI, queues and background tasks on light workers, Postgres for state, minimal GPU instances for inference. For development, there is a bundle of IDE + AI agent, for operation — regular monitoring + logging of promptos and responses.
We are ready to discuss with the community which tasks are optimally covered by LLM services, and which ones are better left "as is". If you are doing something similar within the team, please share your approach in the comments.
Поделимся опытом: за последние месяцы мы внедрили внутри команды несколько LLM-инструментов и пришли к нескольким простым выводам про модели, стек и пайплайны. Без перехода на enterprise-плагины и без переплат за «AI-everything».
Разделяем модели по задачам
Не одна универсальная модель, а две — лёгкая и тяжёлая. Лёгкие модели (Gemini Flash, Claude Haiku) закрывают короткие запросы, классификацию, парсинг апдейтов, голосовые трансформации. Тяжёлые (Gemini Pro, Claude Sonnet/Opus) — длинный контекст, аналитику транскриптов, рассуждения по нескольким источникам.
В env держим переменные MODEL_FAST и MODEL_SMART отдельно. Это позволяет переключать модели без правки кода и регулировать стоимость. По нашему опыту 70–80% запросов уходят в «быструю» модель и стоят в десятки раз дешевле, чем если бы всё лилось в топовую.
Какие задачи закрываются хорошо
- Трекинг прогресса по проектам с парсингом голосовых апдейтов от команды
- Аналитика клиентских звонков: расшифровка + автоматическая разметка по сценарию
- Суммаризация длинных встреч и сравнение с планом
- Генерация коротких видеосюжетов на собственной GPU-инфре
Что вынесли по дороге
- Whisper не всегда нужен. Современные мультимодальные модели принимают аудио напрямую — это убирает одно звено пайплайна и снижает latency и стоимость.
- Лучше начать с самого тонкого пайплайна: одна функция — один промпт. Любое преждевременное усложнение умножает баги и латенси.
- Промпты эволюционируют. Храним их в репозитории как код: ревью, версии, тесты на регрессию.
- Агентные среды разработки (вроде Claude Code) реально сокращают цикл от идеи до пилота. Особенно для маленьких внутренних сервисов, до которых раньше «не доходили руки».
- GPU-инфра под inference: для коротких видео-задач на дистиллированных моделях достаточно карты на 24 ГБ VRAM. Узкое место — обычно IO и подгрузка весов, а не сам тензорный счёт.
Базовый стек
Python + FastAPI, очереди и фоновые задачи на лёгких воркерах, Postgres для состояния, минимальные GPU-инстансы для inference. Для разработки — связка IDE + AI-агент, для эксплуатации — обычный мониторинг + логирование промптов и ответов.
Готовы обсуждать с комьюнити: какие задачи у вас оптимально закрываются LLM-сервисами, а какие лучше оставить «как есть». Если делаете что-то похожее внутри команды — поделитесь подходом в комментариях.
