CuteDSL, teletransporte latente e o caminho mais curto para uma geração mais rápida

As cargas de trabalho generativas são frequentemente descritas como se o modelo fosse o sistema inteiro. Na prática, a parte lenta pode ser o movimento em torno do modelo: carregar pesos, traduzir formatos, copiar tensores, esperar por um trabalhador e descartar um intermediário que outro estágio poderia ter reutilizado.

CuteDSL é uma maneira útil de pensar sobre essa fronteira. Uma pequena descrição declarativa do trabalho pode viajar por um sistema enquanto a representação cara permanece próxima ao acelerador. O objetivo não é uma sintaxe inteligente; é manter a orquestração barata e a inferência ocupada.

O que o “teletransporte latente” aponta

Use a frase como um modelo mental: mova um latente compacto ou um intermediário já útil entre estágios compatíveis, em vez de reconstruir todo o problema a partir de pixels ou texto a cada vez. Se um redimensionamento, passagem de estilo, passagem temporal ou upscaling puder consumir essa representação diretamente, o pipeline evita loops desnecessários de decodificação-codificação.

Três lugares onde as economias aparecem

1. Mantenha o caminho quente residente

Trabalhadores aquecidos e pesos carregados reutilizados. Uma fila deve decidir o que será executado em seguida, não reconstruir repetidamente o ambiente de execução.

2. Lote de trabalho compatível

Imagens com a mesma forma, modelo e precisão podem compartilhar a configuração. O agrupamento é mais útil quando o agendador vê trabalho suficiente cedo o suficiente para formar um lote.

3. Armazene em cache o limite correto

Armazene em cache o pré-processamento determinístico e o condicionamento reutilizável. Não armazene em cache um artefato final gigante quando um intermediário compacto pode atender a vários consumidores downstream.

Um esboço de pipeline compacto

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

O limite importante é o último. Decodifique quando um humano ou uma API externa precisar de pixels ou quadros, não toda vez que um estágio interno quiser tomar uma decisão.

Meça o caminho completo

Acompanhe separadamente a espera na fila, inicialização do trabalhador, carregamento do modelo, inferência, decodificação, upload e tempo até a primeira visualização. Um kernel mais rápido é bom, mas um trabalhador aquecido que remove uma inicialização de dez segundos é frequentemente o maior ganho. Otimize o segmento visível mais lento e, em seguida, meça novamente com prompts reais e formas de saída reais.