Розробка 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 дні. Зв'яжіться з нами, щоб обговорити деталі. Замовте аудит вашої поточної системи білінгу.