CuteDSL, латентна телепортація та найкоротший шлях до швидшої генерації

Генеративні робочі навантаження часто описуються так, ніби модель є цілою системою. Насправді, повільною частиною може бути рух навколо моделі: завантаження ваг, перетворення форматів, копіювання тензорів, очікування працівника та викидання проміжного результату, який міг би бути використаний іншою стадією.

CuteDSL — це корисний спосіб мислення про цю межу. Невеликий, декларативний опис роботи може подорожувати системою, тоді як дороге представлення залишається близько до прискорювача. Мета — не розумний синтаксис; це збереження дешевої оркестровки та зайнятості висновку.

На що вказує «латентна телепортація»

Використовуйте цю фразу як ментальну модель: переміщуйте компактний латент або вже корисний проміжний стан між сумісними етапами замість того, щоб щоразу реконструювати всю проблему з пікселів або тексту. Якщо зміна розміру, стильовий прохід, часовий прохід або масштабування можуть безпосередньо споживати це представлення, конвеєр уникає непотрібних циклів декодування-кодування.

Три місця, де проявляється економія

1. Зберігайте "гарячий шлях" резидентним

Прогріті воркери та повторне використання завантажених ваг. Черга повинна вирішувати, що запускати далі, а не постійно перебудовувати середовище виконання.

2. Об'єднуйте сумісні завдання

Зображення з однаковою формою, моделлю та точністю можуть використовувати спільні налаштування. Об'єднання в пакети найбільш корисне, коли планувальник бачить достатньо роботи досить рано, щоб сформувати пакет.

3. Кешуйте правильну межу

Кешуйте детерміновану попередню обробку та багаторазове кондиціонування. Не кешуйте гігантський кінцевий артефакт, коли компактний проміжний результат може обслуговувати кількох подальших споживачів.

Компактний ескіз конвеєра

request -> normalize prompt + references
        -> choose model / shape / precision
        -> warm worker or form a compatible batch
        -> generate in latent space
        -> decode only at the delivery boundary
        -> durable result + usage record

Важлива межа – остання. Декодуйте, коли людині або зовнішньому API потрібні пікселі або кадри, а не щоразу, коли внутрішній етап хоче прийняти рішення.

Виміряйте весь шлях

Відстежуйте очікування в черзі, запуск воркера, завантаження моделі, інференс, декодування, завантаження та час до першого попереднього перегляду окремо. Швидше ядро – це добре, але прогрітий воркер, який усуває десятисекундний запуск, часто є більшою перемогою. Оптимізуйте найповільніший видимий сегмент, а потім знову виміряйте з реальними промптами та реальними формами виводу.