# CREEX TEAM (Full Context) > CREEX TEAM — издательство и продвижение инди-игр на ПК. Помогаем хорошим играм достучаться до игроков, а разработчикам — до релиза. > Этот файл содержит полный контент и статьи сайта для автоматического индексирования ИИ-агентами. --- ## О компании и услугах ### Что мы делаем Всё что нужно игре чтобы найти свою аудиторию: - **Вывод игры на рынок** - **Performance-кампании** - **Brandformance** - **Influence-маркетинг** - **A/B-тестинг Steam страницы** - **Креативы и трейлеры** - **Исследование аудитории** - **Плейтесты** ### Стадии работы Мы работаем на разных этапах разработки: 1. **Идея** (концепция, жанр, референсы — без играбельного прототипа) 2. **Прототип** (есть играбельная механика, но нет контента и финального арта) 3. **Демо** (играбельная демка с финальным артом и базовым контентом) 4. **MVP** (почти готовая игра — нужна поддержка выхода) Мы предлагаем варианты как без финансирования (за долю от дохода), так и с финансированием (бюджет на разработку, маркетинг и локализацию до $XX,XXX). ### Контакты - **Сайт:** https://creex.team/publishing/ - **Основатель:** Алексей Кострыкин - **Telegram:** https://t.me/imikao - **Email:** hello@creex.team --- ## Статья: Как я строил AI-инфраструктуру для игрового сервиса с 2M DAU **Ссылка:** https://creex.team/publishing/blog/ai-infrastructure-for-games/ **Дата публикации:** 12 мая 2025 **Тема:** AI / ML, Gamedev ### С чего всё началось В начале 2024 года ко мне пришёл клиент — мобильный издатель с флагманской игрой, которая держит около 2M DAU. Задача казалась простой: «хотим добавить AI-ассистента, который помогает новым игрокам освоиться». На деле это оказалось задачей, которая коснулась всей backend-архитектуры. В этой статье я разберу весь путь: от первоначального анализа до production-деплоя. Покажу, какие решения принимали и почему, включая те, от которых в итоге отказались. ### Почему облачные API не подошли Первым порывом было взять OpenAI API или Anthropic и быстро интегрировать. Мы провели нагрузочное тестирование и получили цифры, которые нас остановили: - Средняя задержка — **340мс**, P99 — **1.2с** - При пике 50k одновременных пользователей — rate limiting и очереди - Стоимость при текущем объёме — **~$28k/месяц** - GDPR не позволял отправлять игровой контекст наружу Последний пункт стал ключевым. Игровой контекст — прогресс игрока, история действий, инвентарь. Всё это PII в трактовке европейского регулятора. **Ключевые метрики эффективности решения:** - P99 latency: **80мс** (задержка ответа ассистента на 99-м перцентиле) - Нагрузка: **2M DAU** без деградации производительности - Экономия: **-74% стоимости** (снижение расходов относительно облачного API) ### Глоссарий - **DAU:** Daily Active Users — количество уникальных пользователей за сутки. Ключевая метрика нагрузки на backend. - **P99 latency:** 99-й перцентиль задержки ответа: 99% запросов обрабатываются быстрее этого значения. Жёстче среднего, показывает реальный worst case. - **RAG:** Retrieval-Augmented Generation — подход, при котором LLM получает релевантный контекст из базы знаний перед генерацией ответа. - **vLLM:** Высокопроизводительный inference-движок для LLM с поддержкой continuous batching и PagedAttention. Де-факто стандарт для self-hosted inference. - **Quantization:** Сжатие весов модели с float32/float16 до int4/int8. Q4_K_M — формат llama.cpp: 4-битные веса, минимальная потеря качества. - **Prefix caching:** Кэширование KV-состояния общего префикса промптов (системный промпт, контекст игры). Резко снижает время до первого токена при повторяющихся запросах. ### Выбор модели и inference-инфраструктура Нам нужна была модель, которая умеет: отвечать на вопросы по контексту игры (RAG), генерировать подсказки на русском языке, работать в пределах 4k токенов контекста. При этом — помещаться на GPU, которые мы могли себе позволить. После сравнения Mistral 7B, Llama-3 8B и Phi-3 mini остановились на **Llama-3 8B** в quantized версии (Q4_K_M через llama.cpp). На A10G она держала ~180 tok/s, чего нам хватало с запасом. #### Inference-кластер Развернули vLLM с continuous batching на 4×A10G. Перед ним — Ray Serve как маршрутизатор с балансировкой по queue depth. Кэш промптов через prefix caching (системный промпт с описанием игрового мира повторялся в 94% запросов). ```python # vllm_config.py — конфиг inference-сервера from vllm import AsyncLLMEngine, AsyncEngineArgs engine_args = AsyncEngineArgs( model="meta-llama/Meta-Llama-3-8B-Instruct", quantization="awq", max_model_len=4096, gpu_memory_utilization=0.90, # Prefix caching — ключевое для нашего use-case enable_prefix_caching=True, # Continuous batching max_num_seqs=256, max_num_batched_tokens=8192, ) engine = AsyncLLMEngine.from_engine_args(engine_args) ``` ### RAG-пайплайн: что работает в игровом контексте Классический RAG с векторным поиском по всей базе знаний игры давал плохое качество — слишком много нерелевантных чанков попадало в контекст. Пришлось выстроить двухуровневую систему ретривала. - **Уровень 1 — структурированный контекст:** прогресс игрока, текущий квест, инвентарь. Это всегда присутствует в запросе и передаётся напрямую, без векторного поиска. - **Уровень 2 — семантический поиск:** только если вопрос выходит за рамки текущего контекста. Индекс в Qdrant (~180k чанков по игровой документации), re-ranking через cross-encoder. ### Мониторинг качества ответов Один из самых недооценённых аспектов RAG — evaluation в production. Мы настроили три уровня проверки: - **Online:** thumbs up/down от игроков (13% response rate) - **Async:** LLM-as-a-judge на 5% сэмпле запросов - **Offline:** еженедельный прогон по golden set из 800 вопросов Это позволило поймать регрессию при обновлении модели прежде, чем она попала бы в production. ### Как устроен кластер изнутри Четыре A10G-ноды за Ray Serve. Каждая нода — отдельный vLLM-процесс с prefix caching и continuous batching. Маршрутизатор смотрит на queue depth и шлёт запрос на наименее загруженную ноду. При деградации одной ноды Ray Serve автоматически перераспределяет трафик на оставшиеся три. Среднее время восстановления — менее 2 секунд. ### RAG pipeline: два уровня retrieval Первый уровень — всегда в контексте: персонаж, локация, инвентарь. Передаётся напрямую без векторного поиска. Второй уровень подключается только если вопрос выходит за рамки текущего игрового состояния. Qdrant + cross-encoder re-ranking дают precision@5 = 0.87 на нашем тестовом сете. > Самый дорогой урок: начинать с evaluation-фреймворка, а не с самой модели. Иначе не знаешь, стало ли лучше. > — из ретроспективы проекта ### Итоги и выводы Через три месяца в production мы получили систему, которая отвечает 400k запросов в день, держит P99 latency в 80мс и стоит ~$7.2k/месяц вместо прогнозируемых $28k. Что сработало лучше всего: - Prefix caching дал −40% к нагрузке на inference одним конфиг-параметром - Двухуровневый RAG поднял accuracy с 61% до 84% на golden set - LLM-as-a-judge автоматизировал evaluation почти полностью Что сделал бы иначе: начал бы с evaluation-фреймворка на день 1, а не строил его параллельно с системой. Это сэкономило бы 2 недели работы и один неловкий инцидент в production. #### Что дальше Смотрим на fine-tuning Llama-3 на игровых диалогах, чтобы убрать system-промпт полностью и освободить контекстное окно. Напишу отдельно, как пойдёт. ### Часто задаваемые вопросы (FAQ) **Вопрос: Почему не облачный API (OpenAI / Anthropic)?** *Ответ:* Три причины: стоимость при 2M DAU была бы в районе $80k/мес, latency облачных API на P99 не укладывалась в наш SLA 80мс, и мы не могли допустить передачу игровых данных пользователей на внешние серверы. **Вопрос: Какое железо нужно для inference на 2M DAU?** *Ответ:* У нас 4×A10G (24GB VRAM каждая). Llama-3 8B в Q4_K_M занимает ~5GB, остаток идёт под KV-cache. При пиковой нагрузке ~1200 запросов/мин утилизация GPU держалась на уровне 65–75%. **Вопрос: Как поддерживать качество ответов без ML-команды?** *Ответ:* LLM-as-a-judge на 5% трафика + golden set из 800 вопросов запускается еженедельно через CI. Если метрика падает — PR не проходит. **Вопрос: Подойдёт ли этот подход для игры с 100k DAU?** *Ответ:* При 100k DAU скорее всего хватит одной A10G. Но при таком масштабе облачный API будет дешевле — self-hosted inference окупается примерно от 500k DAU при активном использовании AI-фич. --- ## Статья: Self-hosted LLM inference стал доступен для команд без ML-инженера **Ссылка:** https://creex.team/publishing/news/llm-inference-2025/ **Дата публикации:** 2 июня 2025 **Тема:** AI / ML ### Что изменилось Ещё год назад запустить собственный LLM-сервер требовало ML-инженера, знакомого с CUDA, нескольких недель настройки и хорошего бюджета на GPU. Сейчас картина другая. - **vLLM 0.5** добавил упрощённый деплой через Docker с автоматическим определением GPU. - **llama.cpp** теперь использует Metal на Apple Silicon — на M2 Pro можно гонять 13B-модель с приемлемой скоростью. - **Meta** выпустила официальные Q4_K_M квантизированные веса для всей линейки Llama 3. ### Что это означает на практике Один DevOps-инженер с базовым пониманием Docker теперь может поднять inference-сервер за день. Без ML-команды, без глубокого знания PyTorch. #### Минимальный стек на 2025 Для команды без ML-инженера достаточно трёх компонентов: - **vLLM** — inference движок с batching - **Qdrant** — векторная БД для RAG - **Nginx** — балансировщик и rate limiting На одной A10G это держит ~200 RPS для 7B-модели с RAG. Стоимость — около $800/мес против $15k+ через облачный API. --- ## Кейс: AI-инфраструктура для мобильной RPG с 2M DAU **Ссылка:** https://creex.team/publishing/portfolio/game-studio-x/ **Дата публикации:** 1 мая 2025 **Тема:** AI / ML, Gamedev ### Задача Клиент — мобильная RPG с 2M DAU — хотел добавить AI-ассистента, который отвечает на вопросы игроков о механиках, квестах и предметах в контексте текущего состояния игры. Ограничения: latency не более 100мс на P99, budget на AI не более $15k/мес, данные пользователей не должны покидать их инфраструктуру. Облачные API не проходили ни по одному из этих параметров. ### Решение Self-hosted inference на базе vLLM с continuous batching, двухуровневый RAG (контекст игрока + семантический поиск по документации), мониторинг качества через LLM-as-a-judge. ### Стек - **Llama-3 8B Q4_K_M** — основная модель - **vLLM** — inference с prefix caching - **Ray Serve** — маршрутизация по queue depth - **Qdrant** — векторная БД, 180k чанков - **4×A10G** — GPU кластер ### Результаты За 6 месяцев от постановки задачи до production. Latency P99 — 78мс (план был 100мс). Стоимость инфраструктуры — $11.2k/мес вместо ожидаемых $43k через облачный API. Рейтинг удовлетворённости AI-ответами (thumbs up/down) — 81% позитивных. За первый месяц ассистент обработал 4.2M запросов без инцидентов. > Самый важный урок: начинать с evaluation-фреймворка, а не с выбора модели. Иначе не знаешь, стало ли лучше после каждого изменения. > — из ретроспективы проекта