Разработка pay-per-inference биллинга для AI-моделей

Представьте: ваш AI-сервис обрабатывает 10 000 запросов в минуту. Клиенты жалуются на расхождения в счетах — кто-то недоплатил, кто-то переплатил. Без точного учёта инференсов вы теряете до 15% выручки — для проекта с оборотом $100,000 в месяц это $15,000 потерь. Мы — команда AI/ML инженеров с 7+ лет опыта в построении биллинговых систем для AI-платформ. За это время мы реализовали 50+ проектов с нагрузкой от 1000 до 1 млн запросов/день. Мы разрабатываем системы pay-per-inference биллинга под ключ, которые корректно измеряют использование моделей, предотвращают фрод и выдают прозрачные счета в реальном времени. Внедрение pre-authorization снижает потери от фрода на 40% — типичная экономия составляет $5,000–$10,000 в месяц при нагрузке 100k запросов/день. При этом потенциальные потери от ошибок биллинга могут превышать $20,000 в месяц. Мы специализируемся на MLOps биллинге и реализуем гибкое ценообразование через tiered pricing и volume discounts.

Основные проблемы, которые решаем

• Неточный учёт использования. Простые метрики (количество запросов) не отражают реальную нагрузку. LLM потребляют разные объёмы токенов, а генерация изображений — GPU-часы. Если не измерять правильно, клиенты переплачивают или недоплачивают.
• Сложное ценообразование. Большинству клиентов нужны volume discounts и tiered pricing. Например, при 10M токенов цена за миллион может падать с $10 до $6. Без автоматизации таких расчётов ошибки неизбежны.
• Fraud и аномалии. Злоумышленники могут генерировать десятки тысяч запросов за минуту, чтобы истощить prepaid баланс. Нужна система, которая блокирует подозрительную активность в реальном времени.

Как мы строим систему биллинга

На примере одного из проектов: клиент — AI-платформа с 5 моделями (GPT-4, Claude, LLaMA, две кастомные). Нагрузка — 5000 запросов/мин. Мы реализовали архитектуру с pre-authorization и settlement, используя Redis для балансов и PostgreSQL для аудита. Pre-authorization резервирует средства до инференса, а settlement возвращает разницу или доначисляет. Это снизило потери от фрода на 40% и исключило negative balance. Такой подход является отраслевым стандартом, описанным в документации Stripe.

Ключевой компонент — функция compute_actual_cost, которая учитывает токены, GPU-секунды и custom compute units. Для одного клиента мы добавили метрику "время инференса × множитель модели", что позволило выровнять цены для разных архитектур.

from decimal import Decimal import asyncio class InferenceBillingSystem: def __init__(self, redis_client, db, stripe_client): self.redis = redis_client self.db = db self.stripe = stripe_client async def pre_authorize(self, customer_id: str, model_id: str, request: dict) -> str: """Проверка баланса и резервирование средств перед инференсом""" model_pricing = await self.get_pricing(model_id) estimated_cost = self.estimate_cost(model_pricing, request) # Проверка баланса в Redis (быстро) balance_key = f"balance:{customer_id}" balance = Decimal(await self.redis.get(balance_key) or '0') if balance < estimated_cost: raise InsufficientBalanceError( f"Balance ${balance} < estimated ${estimated_cost}" ) # Временная блокировка средств reservation_id = str(uuid.uuid4()) pipe = self.redis.pipeline() pipe.decrby(balance_key, int(estimated_cost * 100)) # Центы pipe.setex(f"reservation:{reservation_id}", 300, str(estimated_cost)) await pipe.execute() return reservation_id async def settle(self, reservation_id: str, model_id: str, actual_usage: dict): """Финальный расчёт по факту использования""" model_pricing = await self.get_pricing(model_id) actual_cost = self.compute_actual_cost(model_pricing, actual_usage) estimated_cost = Decimal(await self.redis.get(f"reservation:{reservation_id}")) # Возврат переплаты или доначисление delta = estimated_cost - actual_cost customer_id = await self.get_customer_by_reservation(reservation_id) if delta > 0: await self.redis.incrbyfloat(f"balance:{customer_id}", float(delta)) # Запись в БД для аудита await self.db.insert_usage_record({ 'customer_id': customer_id, 'model_id': model_id, 'reservation_id': reservation_id, 'actual_cost': float(actual_cost), 'usage_details': actual_usage, 'timestamp': datetime.utcnow() }) await self.redis.delete(f"reservation:{reservation_id}") def compute_actual_cost(self, pricing: dict, usage: dict) -> Decimal: cost = Decimal('0') if 'input_tokens' in usage: cost += Decimal(str(usage['input_tokens'])) / 1_000_000 * \ Decimal(str(pricing['input_token_price'])) if 'output_tokens' in usage: cost += Decimal(str(usage['output_tokens'])) / 1_000_000 * \ Decimal(str(pricing['output_token_price'])) if 'gpu_seconds' in usage: cost += Decimal(str(usage['gpu_seconds'])) * \ Decimal(str(pricing['gpu_second_price'])) return cost 

Volume Discounts и Pricing Tiers

Скидки за объём реализованы через tiered pricing. Ниже пример для модели класса GPT-4.

PRICING_TIERS = { "gpt4-equivalent": { "tiers": [ {"up_to_tokens": 1_000_000, "input_price": 10.0, "output_price": 30.0}, {"up_to_tokens": 10_000_000, "input_price": 8.0, "output_price": 24.0}, {"up_to_tokens": 100_000_000, "input_price": 6.0, "output_price": 18.0}, {"up_to_tokens": None, "input_price": 5.0, "output_price": 15.0}, ] } } def compute_tiered_price(total_tokens: int, pricing_key: str) -> Decimal: """Вычисление цены с учётом volume discounts""" tiers = PRICING_TIERS[pricing_key]['tiers'] remaining = total_tokens total_cost = Decimal('0') for tier in tiers: if tier['up_to_tokens'] is None or remaining <= tier['up_to_tokens']: total_cost += Decimal(str(remaining)) / 1_000_000 * \ Decimal(str(tier['input_price'])) break else: tier_tokens = tier['up_to_tokens'] total_cost += Decimal(str(tier_tokens)) / 1_000_000 * \ Decimal(str(tier['input_price'])) remaining -= tier_tokens return total_cost 

Как защититься от fraud в high-load API?

Fraud-детектор анализирует аномалии: если за 5 минут число запросов превышает среднее за 24 часа в 10 раз и порог в 1000 запросов — система блокирует запрос и уведомляет службу безопасности. Redis позволяет делать это с latency < 10 мс.

class FraudDetector: async def check_request(self, customer_id: str, model_id: str) -> bool: # Аномальный spike: > 10x среднего использования за последние 5 мин recent_usage = await self.get_recent_usage(customer_id, minutes=5) avg_usage = await self.get_average_usage(customer_id, hours=24) if recent_usage > avg_usage * 10 and recent_usage > 1000: await self.flag_for_review(customer_id, "usage_spike") await self.notify_security(customer_id, recent_usage) return False # Блокировка до проверки return True 

Система автоматически генерирует ежемесячные счета через Stripe, поддерживает prepaid balance и auto-recharge при достижении минимального порога.

Почему pre-authorization критичен для high-load API?

Без pre-authorization клиент может отправить запрос, превышающий баланс, и вы понесёте убытки. Мы используем двухфазную модель: резервирование средств перед инференсом и финальный расчёт после. Это стандарт для всех крупных AI-провайдеров (OpenAI, Anthropic). Наш опыт показывает, что pre-authorization в 10 раз точнее постоплатного биллинга. Также pre-authorization с Redis обрабатывает запросы в 10 раз быстрее, чем синхронные проверки баланса через PostgreSQL.

Выбор метрики биллинга

Выбор метрики зависит от типа модели. Для LLM точнее всего токены, для генерации изображений — GPU-секунды. Мы помогаем подобрать оптимальную метрику под вашу модель, калибруя веса. В гетерогенных системах используем compute units как единую валюту, что упрощает биллинг.

Процесс работы

1. Аналитика — изучаем вашу модель, нагрузку, требования к биллингу.
2. Проектирование — выбираем метрики, архитектуру (Redis + PostgreSQL + Stripe).
3. Реализация — пишем код, включая pre-authorization, settlement, tiered pricing, fraud detection.
4. Тестирование — нагрузочное тестирование с p99 latency, проверка корректности расчётов.
5. Деплой — интеграция с вашим API, настройка мониторинга.

Мы гарантируем точность расчётов и надёжность системы. Получите консультацию — оценим ваш проект за 2 дня. Свяжитесь с нами, чтобы обсудить детали. Закажите аудит вашей текущей системы биллинга.