Token Counting и бюджетирование LLM-запросов: управление расходами

Как не потерять бюджет на LLM: token counting и бюджетирование

Представьте: команда разработчиков интегрировала GPT-4 для обработки запросов клиентов, а спустя месяц счёт за API вырос до $5000 вместо ожидаемых $500. Причина — каждый запрос уходил с системным промптом на 2000 токенов, а дублирующиеся запросы не кэшировались. Token counting и бюджетирование — это не опция, а необходимость для любого продакшена, работающего с LLM. Без них вы рискуете получить счёт, в 5–10 раз превышающий ожидания.

Мы внедрили систему управления расходами для SaaS-платформы с 10 000 ежедневных запросов к GPT-4 и Claude. Результат: снижение затрат на 35% за первый месяц. Как мы это сделали и как повторить успех — разберём ниже.

Почему важно бюджетировать запросы LLM?

LLM-запросы непредсказуемы по стоимости: длина выходного токена варьируется, а системные промпты часто раздуваются без контроля. Без бюджетирования легко получить счёт, в 5–10 раз превышающий ожидания. Бюджетирование решает три задачи:

• Предотвращение перерасхода: алерты при превышении дневного или месячного лимита.
• Оптимизация стоимости: выявление неэффективных промптов и моделей.
• Прозрачность для команд: дашборды с детализацией по пользователям, функциям и моделям.

Принципы работы token counting в продакшне

Token counting — это оценка количества токенов запроса до отправки. Для OpenAI используем библиотеку tiktoken (OpenAI Tokenizer documentation), для Anthropic — встроенный счётчик. Пример подсчёта:

import tiktoken

def count_tokens_openai(text: str, model: str = "gpt-4") -> int:
    enc = tiktoken.encoding_for_model(model)
    return len(enc.encode(text))

def estimate_request_cost(prompt: str, max_completion: int = 1000, model: str = "gpt-4-turbo") -> dict:
    input_tokens = count_tokens_openai(prompt, model)
    total_tokens = input_tokens + max_completion
    prices = {
        "gpt-4-turbo": {"input": 10.0, "output": 30.0},
        "gpt-4o": {"input": 5.0, "output": 15.0},
        "gpt-4o-mini": {"input": 0.15, "output": 0.60},
        "claude-3-5-sonnet": {"input": 3.0, "output": 15.0},
    }
    price = prices.get(model, {"input": 10.0, "output": 30.0})
    estimated_cost = (input_tokens / 1_000_000 * price["input"] + max_completion / 1_000_000 * price["output"])
    return {"input_tokens": input_tokens, "max_output_tokens": max_completion, "estimated_cost_usd": estimated_cost}

Оценка стоимости позволяет отклонять запросы, превышающие лимит пользователя или команды.

Методы снижения расходов на LLM

Один из эффективных методов — автоматический роутинг моделей. Например, для простых задач (извлечение данных, базовая классификация) используем GPT-4o-mini, который в 10 раз дешевле GPT-4-turbo, но даёт сравнимые результаты. Для сложных генераций оставляем топовые модели. В нашем кейсе это снизило среднюю стоимость запроса с $0.03 до $0.008.

Также внедряем кэширование: дублирующиеся запросы (например, повторные вопросы от пользователей) обслуживаем из Redis-кэша, что экономит до 40% бюджета. Используем LRU-кэш с TTL 24 часа.

Система бюджетирования с Redis и Middleware

Для хранения лимитов используем Redis — он быстр и поддерживает атомарные операции. Структура бюджета:

from dataclasses import dataclass, field
import threading

@dataclass
class TokenBudget:
    daily_limit_usd: float
    monthly_limit_usd: float
    per_user_daily_limit_usd: float = 1.0
    spent_today: float = field(default=0.0)
    spent_month: float = field(default=0.0)
    _lock: threading.Lock = field(default_factory=threading.Lock)

class LLMBudgetManager:
    def __init__(self, redis_client, budget: TokenBudget):
        self.redis = redis_client
        self.budget = budget

    def check_and_reserve(self, user_id: str, estimated_cost: float) -> bool:
        """Проверка бюджета перед запросом"""
        daily_spent = float(self.redis.get(f"budget:daily") or 0)
        if daily_spent + estimated_cost > self.budget.daily_limit_usd:
            raise BudgetExceededError(f"Daily budget ${self.budget.daily_limit_usd} exceeded")
        user_spent = float(self.redis.get(f"budget:user:{user_id}:daily") or 0)
        if user_spent + estimated_cost > self.budget.per_user_daily_limit_usd:
            raise BudgetExceededError(f"User daily budget ${self.budget.per_user_daily_limit_usd} exceeded")
        pipe = self.redis.pipeline()
        pipe.incrbyfloat(f"budget:daily", estimated_cost)
        pipe.expire(f"budget:daily", 86400)
        pipe.incrbyfloat(f"budget:user:{user_id}:daily", estimated_cost)
        pipe.expire(f"budget:user:{user_id}:daily", 86400)
        pipe.execute()
        return True

    def record_actual_cost(self, user_id: str, actual_cost: float, estimated_cost: float):
        correction = actual_cost - estimated_cost
        if abs(correction) > 0.001:
            self.redis.incrbyfloat("budget:daily", correction)

import functools

def track_llm_cost(model: str = "gpt-4o"):
    def decorator(func):
        @functools.wraps(func)
        async def wrapper(*args, **kwargs):
            result = await func(*args, **kwargs)
            if hasattr(result, 'usage'):
                cost = compute_cost(result.usage.prompt_tokens, result.usage.completion_tokens, model)
                analytics.record(function=func.__name__, model=model, cost=cost, input_tokens=result.usage.prompt_tokens, output_tokens=result.usage.completion_tokens)
            return result
        return wrapper
    return decorator

Типичный результат внедрения: снижение расходов на LLM на 20–40% за счёт выявления неэффективных запросов (длинные ненужные системные промпты, дублирующиеся запросы без кэширования) и правильного выбора модели для каждой задачи.

Практические результаты token counting

Без подсчёта токенов вы не знаете, сколько тратите на каждый запрос. Мы внедрили дашборды в Grafana, где видна стоимость по пользователям, моделям и функциям. Это позволило заказчику выявить, что 30% запросов — это повторения с одними и теми же промптами. После включения кэша — экономия $1500 в месяц. Хотите такую же экономию? Свяжитесь с нами.

Сравнение моделей по стоимости

Разница в стоимости между GPT-4-turbo и GPT-4o-mini может достигать 66 раз по входным токенам и 50 раз по выходным. Это делает выбор модели ключевым фактором экономии. Для простых задач (классификация, извлечение) используйте лёгкие модели, для сложных — топовые. Роутинг запросов по сложности — стандартная практика.

Типичные ошибки при бюджетировании LLM

Мы часто сталкиваемся с одинаковыми ошибками: игнорирование системных промптов, отсутствие кэширования, использование дорогой модели для простых задач, отсутствие лимитов на пользователя и мониторинга. Каждая из них может увеличить расходы в 10–50 раз. Решение — внедрить token counting, алерты и роутинг моделей.

Пошаговая настройка token counting

1. Подключите библиотеку tiktoken.
2. Реализуйте функцию подсчёта токенов для вашей модели.
3. Оцените стоимость запроса по ценам модели.
4. Добавьте проверку бюджета перед вызовом API.
5. Настройте логирование и дашборды.

Состав работ по внедрению системы бюджетирования

Мы предлагаем внедрение системы token counting и бюджетирования под ключ. В рамках проекта:

• Аудит текущей архитектуры и профиля запросов.
• Интеграция tiktoken и Anthropic SDK в ваш код.
• Настройка Redis для хранения лимитов и статистики.
• Реализация middleware для автоматического учёта.
• Дашборды мониторинга (Grafana + Prometheus).
• Обучение команды и документация.

Наш опыт в MLOps — более 5 лет, мы реализовали системы бюджетирования для компаний с нагрузкой до 1 млн запросов в день. Сроки внедрения: 2–4 недели для базовой системы, до 6 недель для сложных архитектур. Свяжитесь с нами для оценки вашего проекта. Закажите аудит текущих расходов на LLM.

MLOps: инфраструктура для обучения, деплоя и мониторинга ML-моделей

Модель обучена, метрики — F1 0.94 на валидации. Через три месяца в продакшене качество падает на 12%. Никто не знает, когда именно — нет мониторинга. Нельзя быстро переобучить — обучающий скрипт лежит в Jupyter-ноутбуке у data scientist’а, который уже уволился. Данные для ретрейна собирают руками из трёх разрозненных систем. Примерно половина проектов приходят к нам с этой болью. Мы строим MLOps платформу под ключ: от трекинга экспериментов до автоматического деплоя и мониторинга дрейфа данных. Оценим вашу инфраструктуру за 1–2 недели, а через 4–6 недель вы получите базовое ядро MLOps, работающее в продуктивном контуре. Наша команда — 10+ лет опыта в ML-инфраструктуре, более 50 внедрений.

Experiment tracking и воспроизводимость

Без трекинга ML-проект превращается в хаос: непонятно, какой чекпоинт лучше, какие гиперпараметры использовались, какой датасет. Воспроизвести результат через месяц — квест.

MLflow — open source стандарт для трекинга. Логирует параметры, метрики, артефакты (модели, графики) и код. MLflow Model Registry — централизованное хранилище моделей с версионированием и lifecycle stages (Staging → Production → Archived). Деплой через MLflow Serving или интеграция с внешними системами.

Типичная инициализация в коде:

import mlflow

mlflow.set_experiment("fraud-detection-v2")
with mlflow.start_run():
    mlflow.log_params({"learning_rate": 3e-4, "batch_size": 64, "epochs": 10})
    mlflow.log_metric("val_f1", val_f1, step=epoch)
    mlflow.pytorch.log_model(model, "model")

Это минимум. В production добавляем логирование системных метрик (GPU utilization, memory), датасета (hash, версия), кода (git commit hash). Weights & Biases — более богатый UI, collaboration features, sweep для hyperparameter optimization. MLflow — для on-premise deployment без внешних зависимостей.

DVC (Data Version Control) — версионирование данных и моделей поверх git. Данные хранятся в S3/GCS/Azure Blob, в git — только метаданные (хэши). dvc repro воспроизводит весь пайплайн от сырых данных до метрик.

Как обеспечить воспроизводимость обучения? Фиксируйте random seeds (torch.manual_seed, numpy.random.seed, random.seed) и записывайте их в метаданные эксперимента. Без этого дебаггинг нерегулярных результатов — боль. Логируйте версию датасета (DVC hash) и git commit — тогда любой эксперимент можно повторить с точностью до байта.

Оркестрация пайплайнов: Kubeflow, Airflow, Prefect

Когда нужен оркестратор пайплайнов? Скрипт обучения на 100 строк в cron — нормально для простых задач. Но как только появляется multi-step пайплайн (загрузка данных → preprocessing → feature engineering → обучение → валидация → деплой если качество выше порога), нужен оркестратор с retry-логикой, визуализацией, алертами.

Kubeflow — Kubernetes-native оркестратор для ML (см. Wikipedia). Каждый шаг — Docker-контейнер. Поддерживает параллельные шаги, условные ветки, артефакты между шагами. Интегрируется с Katib (AutoML), KServe (serving), Feast (feature store).

Apache Airflow — более общий DAG-оркестратор. Широкая экосистема операторов (S3, Spark, DBT, Kubernetes). Проще развернуть, если уже есть Airflow в компании.

Prefect / Metaflow — меньше boilerplate. Prefect 2.x с декораторами @flow и @task — быстрый старт для небольших команд.

Типичная архитектура обучающего пайплайна на Kubeflow:

1. Data ingestion component — забирает данные из S3/БД, валидирует схему через Great Expectations
2. Preprocessing component — трансформации, normalization, train/val/test split
3. Training component — обучение на GPU, логирование в MLflow
4. Evaluation component — вычисление метрик, сравнение с baseline в Model Registry
5. Conditional deployment — деплой только если новая модель лучше текущей на >2% F1

Каждый component — отдельный Docker-образ. Пайплайн версионируется в git. Запуск по расписанию (ретрейнинг раз в неделю на новых данных) или вручную.

Model Registry и управление жизненным циклом

Model Registry — не просто хранилище чекпоинтов. Это централизованная система, которая знает:

• Какая модель сейчас в продакшене (и с какими метриками)
• История всех версий с параметрами обучения
• Метаданные: датасет, git commit, результаты валидации
• Lifecycle stage: None → Staging → Production → Archived

MLflow Model Registry — стандарт. Для enterprise — Vertex AI Model Registry (GCP), SageMaker Model Registry (AWS), Azure ML Model Registry.

Продвижение модели через стейджи: автоматически переводим модель в Staging после успешного прохождения eval, затем ручное или автоматическое (при A/B тесте) продвижение в Production. Rollback — переключение на предыдущую Production-версию за секунды.

Serving: от FastAPI до Triton Inference Server

Простой случай. FastAPI + PyTorch/ONNX на одном сервере — 80% production ML deployments именно так. Достаточно для большинства задач с нагрузкой до 100 req/s.

from fastapi import FastAPI
import onnxruntime as ort

app = FastAPI()
session = ort.InferenceSession("model.onnx", providers=["CUDAExecutionProvider"])

@app.post("/predict")
async def predict(request: PredictRequest):
    inputs = preprocess(request.text)
    outputs = session.run(None, {"input_ids": inputs})
    return {"label": postprocess(outputs)}

Triton Inference Server — production-стандарт для высоких нагрузок (500+ req/s). Dynamic batching, concurrent model execution, model ensemble. Поддерживает TensorRT, ONNX, PyTorch TorchScript, TensorFlow SavedModel.

KServe — Kubernetes-native ML serving с autoscaling, canary deployments, A/B testing из коробки. Scale-to-zero для неактивных моделей — экономия на инфраструктуре до 40% (более 1.2 млн рублей в год для проекта с 10 моделями).

Мониторинг: data drift, model drift, инфраструктурные метрики

Мониторинг — то, что обычно делают в последнюю очередь и о чём жалеют в первую. Три уровня.

Инфраструктурный мониторинг. Latency (P50/P95/P99), throughput (req/s), error rate (4xx, 5xx), GPU/CPU utilization. Prometheus + Grafana — стандарт. Алерт при P99 latency > threshold или error rate > 1%.

Data drift мониторинг. Распределение входных данных меняется со временем. Детектируем через PSI (Population Stability Index) для числовых признаков: PSI > 0.2 — сильный дрейф. Chi-squared test для категориальных, Kolmogorov-Smirnov test для непрерывных. Evidently AI — open source библиотека с готовыми дрейф-тестами.

Model drift мониторинг. Если есть ground truth с задержкой (например, через неделю знаем конверсию) — мониторим реальные метрики. Если нет — surrogate метрики: распределение prediction scores, доля confident predictions.

Alerting. Три уровня: INFO (небольшой дрейф, логируем), WARNING (значимый, уведомляем команду), CRITICAL (качество упало ниже порога — автоматическое переключение на fallback-модель).

Почему важен мониторинг дрейфа данных? Без него вы узнаёте о деградации модели только по жалобам пользователей или звенящему SLA. Алерт о дрейфе позволяет переобучить модель заранее, до того как ошибки начнут приносить убытки. В одном из наших проектов мониторинг PSI выявил дрейф через 2 дня после изменения источника данных — это спасло кампанию с бюджетами на 2 млн рублей.

Feature Store

Feature Store решает проблему training-serving skew. Если preprocessing во время обучения и инференса реализован в двух разных местах — расхождение неизбежно.

Когда нужен Feature Store?

• Несколько моделей используют одни и те же признаки
• Признаки вычисляются из потоковых данных (real-time)
• Большая команда с разными людьми на feature engineering и model training

Feast — open source Feature Store. Офлайн store (S3 + Parquet) для обучения, онлайн store (Redis, DynamoDB) для low-latency инференса. Feature definitions как код, materialization job синхронизирует офлайн → онлайн.

Tecton (коммерческий), Vertex AI Feature Store (GCP), SageMaker Feature Store (AWS) — managed варианты с меньшим ops overhead.

CI/CD для ML

ML CI/CD — обычный CI/CD плюс специфичные ML-шаги.

ML-специфичные checks в CI:

• Проверка воспроизводимости: запустить обучение с фиксированным seed, результат должен совпадать
• Data validation: Great Expectations или Pandera на schema/distribution checks
• Model performance check: автоматический eval на holdout, блокировать merge если деградация > порога
• Latency regression test: inference должен укладываться в SLA

GitOps для деплоя. Merge в main → CI запускает обучение → eval → если проходит → автоматический деплой в Staging → smoke tests → ручное продвижение в Production или автоматическое при успешном canary.

Инструменты: GitHub Actions / GitLab CI для CI, ArgoCD для GitOps-деплоя на Kubernetes.

Что входит в разработку MLOps-платформы

Мы предоставляем полный цикл работ, документацию и обучение команды.

Итоговый срок от аудита до полноценной MLOps-платформы: 3–5 месяцев. Также возможен поэтапный запуск: базовый уровень (трекинг + serving) за 4–6 недель.

Стоимость рассчитывается индивидуально под объём данных, количество моделей и требования к инфраструктуре. Закажите аудит MLOps-инфраструктуры — получите roadmap за 1–2 недели. Свяжитесь с нами для оценки вашего проекта — мы пришлём предварительный расчёт за 2 рабочих дня.

Обратите внимание: гарантия на архитектурные решения — 12 месяцев. Предоставляем сертификаты интеграции с основными облачными провайдерами (AWS, GCP, Azure). За время работы мы не потеряли ни одного клиента после первого внедрения — опыт 50+ успешных MLOps-проектов говорит сам за себя. Получите консультацию по построению MLOps платформы уже сегодня.