Більшість LLM-функцій у продакшені веде команди, які трактують місячний рахунок як питання для ескалації у фінансовий відділ. CFO ставить питання, хтось пересилає панель, інженери знизують плечима й обіцяють подивитися наступного кварталу. Поки хтось береться серйозно, рахунок уже в кілька разів більший, ніж мав би бути, а система занадто заплутана, щоб виправити її дешево.
Вартість — це інженерна задача. У неї є інженерні важелі. Це одна з найбільш важливих речей, яку варто проєктувати з першого дня, а не виявляти на третьому місяці. Різниця між командою, яка проєктує під вартість, і командою, яка цього не робить, зазвичай вимірюється порядком величини на рахунку, а не кількома відсотками.
Ось набір важелів, до яких ми тягнемось, приблизно в порядку важливості.
1. Стеля на один запит, встановлена на старті
Перше, що ми робимо на будь-якому LLM-проєкті, — називаємо стелю на один запит. Не бюджет. Стелю: значення, вище якого один користувацький виклик вважається дефектом, а не витратою.
Стеля виводиться назад із даних оцінювання, а не вперед із припущення фінансового відділу. Ви берете свій набір для оцінювання, запускаєте найдешевшу модель, що проходить планку якості, вимірюєте фактичний розподіл вхідних і вихідних токенів на реалістичних вхідних даних і ставите стелю на здоровому коефіцієнті від p95 — достатньо запасу для нетипових вхідних даних, достатньо щільно, щоб некерована підказка або вибух контекстного вікна спрацьовував тривогою, а не десятьма тисячами тихих викликів.
Щойно стеля існує, кожне проєктне рішення зіставляється з нею. Додаєте крок пошуку? Покажіть найгірший випадок за кількістю токенів. Дозволяєте моделі написати цілий документ? Жорстко обмежте вихідні токени та м'яко деградуйте, коли впираєтеся в обмеження. Стеля — це те, від чого команда проєктує назад. Без неї ви робите розвідувальні покупки з корпоративною карткою.
2. Місячна стеля на одного клієнта, конфігурована, з плавним переходом
Стеля на один запит зупиняє один некерований виклик. Місячна стеля на одного клієнта зупиняє одного некерованого користувача.
Кожна багатокористувацька LLM-система, яку ми бачили на масштабі, мала принаймні одного клієнта, який із цілком законних причин споживав у десять чи двадцять разів більше за медіану. Іноді це потужний користувач. Іноді скрипт. Іноді інтеграція, про яку всі забули. Правильна реакція — не сюрпризне відключення. Правильна реакція — плавно переходити на дешевшу або локальну модель, щойно вичерпано здорову частку місячної стелі.
Поріг важить більше за абсолютне число. Переходити на запасний варіант на останньому токені — вороже. Переходити на першому — театр. Десь посередині — суттєво нижче за стелю, але суттєво вище за медіану — є поріг, що дає користувачеві деградований, але функціональний досвід, а команді — час на те, щоб або запропонувати тариф вище, або розібратися. Число має бути конфігурованим на клієнта, бо відповідь для корпоративного тарифу інша, ніж для безкоштовного, і бо першого дня число буде неправильним.
3. Агресивне кешування двох конкретних речей
Кешування — найважливіший важіль у цьому списку, і майже ніхто не робить його добре.
Ембедінги — кешуйте безстроково. Embedding ідемпотентний: той самий вхід і та сама модель дають той самий вектор завжди. Немає жодної причини обчислювати його повторно. Хешуєте нормалізований вхід, зберігаєте вектор, ніколи не дивитеся той самий рядок двічі. На скільки-небудь значному корпусі це сама по собі різниця між адекватним рахунком і абсурдним.
Відповіді — кешуйте з короткими TTL. Кешування відповідей складніше, бо вихідні дані недетерміновані, а вхідні відрізняються в дрібницях. Але на навантаженнях, переважно орієнтованих на читання — «коротко переказати цю сторінку», «пояснити концепцію», «відповісти на питання у форматі FAQ», — TTL у хвилинах або годинах дає непропорційно високий відсоток влучень. Реальний продакшн-трафік не розподілений рівномірно: невелика частка запитів припадає на велику частку обсягу, а заплатити моделі треба лише за один з них.
Поверхня ключа кешу потребує уваги. Ключ має включати модель, версію шаблону підказки, релевантний контекст пошуку та нормалізовану форму користувацького вводу — в нижньому регістрі, з підібганими пробілами, з очевидними PII, або вирізаними, або хешованими до того, як вони торкнуться ключа. SHA-256 над нормалізованим кортежем — нормально: однобічний, чисто комбінується, нічого не зливає тому, хто згодом загляне в кеш. Зробіть поверхню ключа правильно один раз — і кеш виплатить себе протягом усього життя системи.
4. Вибір моделі як вправа з ярусування
Не існує єдиної найкращої моделі. Існує найкраща модель для конкретної задачі за конкретною планкою якості, і це майже ніколи не фронтирна модель.
Ми ярусуємо навантаження. Дешеві, малі моделі — для некритичного видобування й класифікації: витягти структуровані поля з документа, віднести запит до одного з трьох кошиків, нормалізувати користувацький ввід. Фронтирні моделі — для кроків, що справді потребують міркування: синтез з кількох джерел, багатокрокове планування, будь-що, де неправильна відповідь дорого коштує. Дотреновані або дистильовані моделі — для вузьких високоємних випадків, де у вас достатньо даних для навчання, а задача достатньо чітко окреслена, щоб універсальність фронтирної моделі була зайвою.
Правило просте: брати найдешевшу модель, що проходить планку оцінювання, і це зазвичай на ярус нижче від фронтиру. Фронтирні моделі правильно використовуються як запасний варіант, коли з'являється щось складніше, а не як значення за замовчуванням. Система, що використовує фронтирну модель на кожному кроці, майже завжди переплачує в кратність, від якої стає ніяково, коли її нарешті виміряти.
5. На основі оцінювання, а не на відчуттях
Усе вище працює лише тоді, коли можна виміряти якість. Без набору для оцінювання максимум, що можна сказати, — «рахунок зменшився, скарг від користувачів не побільшало, наскільки ми знаємо, поки що». Перша половина цього речення — інженерія. Друга — надія.
Набір для оцінювання не мусить бути складним. Кілька сотень репрезентативних вхідних даних із заздалегідь відомими хорошими відповідями, оцінених автоматично, де можливо, і переглянутих людиною, де ні, — цього достатньо, щоб кожен ціновий важіль вище став прозорим. Змінили модель — оцінка зрушилася? Додали кеш — оцінка зрушилася? Скоротили підказку — оцінка зрушилася? Без цього циклу ви здогадуєтеся на публіці.
Це робота, яку сам ШІ пропускає найбільш надійно. Майже кожна успадкована LLM-система, яку ми аудитували, не мала ані набору для оцінювання, ані регресійних тестів, ані базової лінії якості. Додати їх — зазвичай кілька днів роботи, і це розблоковує всі інші важелі зі списку.
Що це насправді дає
На успадкованих системах ми скорочували LLM-рахунки у значні рази — впевнено більш ніж удвічі, часто набагато сильніше — без вимірюваних регресій якості. Хитрість не в якійсь хитрості. Вона в тому, щоб дбати рано, вимірювати чесно і проєктувати назад від стелі, а не вперед від значень за замовчуванням.
Робота не ефектна. Це читати логи підказок, будувати оснащення для оцінювання, маркувати ключі кешу, налаштовувати запасні варіанти на клієнта. Це операційний шар під демонстрацією, і це саме той шар, якого в демонстрації ніколи немає.
Чому це має робити інженер, а не модель
Є приваблива симетрія в ідеї, що ШІ має допомогти посадити ШІ-вартість на повідець. Здебільшого не допомагає, і причина структурна. Модель не може надійно міркувати про власну вартість, бо вона і є тим, що бюджетується. Вона радо порекомендує більш потужну модель там, де дешевша впоралася б. Вона радо розширить підказку там, де коротша набрала б ту саму оцінку. Вона не побудує сама собі набір для оцінювання, який сказав би, що один із цих кроків був неправильним.
Інженерне судження має приходити ззовні системи. Це й є робота. Зроблена як слід, вона — різниця між LLM-функцією, що окуповує себе, і тією, що тихо з'їдає маржу продукту, який вона мала покращити.