Чому multi-tenant
Кожен клієнт на власній dedicated інфраструктурі, це марнування. Більшість агентів idle більшість часу. Multi-tenant означає драматично нижчу вартість на клієнта, і ці economiї перетікають у прайсинг.
Але multi-tenant має складні проблеми: ізоляція даних, fair scheduling, cost attribution. Помилитесь у будь-якій, отримаєте customer fire.
Ізоляція даних
Ми використовуємо schema-per-tenant у Postgres для всіх клієнтських даних. Query layer enforce-ить tenant scoping на рівні connection, немає API-шляху, що може прочитати дані іншого тенанта, крапка.
Vector stores використовують namespaces на tenant. LLM-контекст ніколи не перетинає tenants. Agent memories tenant-scoped на рівні зберігання.
Справедливий графік
Проблема noisy neighbor: один клієнт запускає величезну кампанію, усі інші голодують щодо inference-бюджету. Ми використовуємо weighted fair queuing на inference, з вагами, привʼязаними до тарифу і недавнього usage.
Burst-и абсорбуються spillover-потужністю, що коштує трохи більше, біллиться burst-клієнту, а не платформі.