Model Serving

TinyFish mede sucesso do agente web pela tarefa completa, não pela resposta isolada do modelo

A TinyFish pós-treina um modelo próprio especializado em tarefa de agente web usando Databricks AI Runtime (SFT indo pra DPO), avalia sucesso via MLflow com juiz de IA olhando o histórico de ação completo do agente, e serve em produção via Model Serving: 294 mil execuções e 6,4 milhões de passos de ferramenta em 15 dias.

ai_decide é rápido o suficiente para qualquer loop, mas isso não significa que deveria estar em todos

O Databricks MVP Sudhir Gajre analisou o ai_decide, a nova AI Function de decisão da Databricks compatível com a API da TypeSafe AI, e apontou dois antipadrões: substituir regra determinística por decisão probabilística, e colocar IA em todo loop em tempo real só porque a latência permite.

Nem toda decisão de IA precisa de um chat: rodando um modelo de decisão puro direto do SQL

Modelos de decisão como o Jev respondem a partir de um conjunto fechado de opções, mais rápido e mais barato que um LLM de raciocínio, e o Azure Databricks deixa consultar esse tipo de modelo direto do SQL via ai_query, sem montar interface de chat nem pipeline de inferência à parte.

Databricks Apps ou Model Serving pra hospedar seu agente? A resposta depende de três coisas

Databricks Apps virou o host recomendado pra agente novo, mas Model Serving ainda vence em cenário de baixo custo e alta escala, e a diferença de timeout entre os dois muda qual opção funciona pra que tipo de agente.

Priority pay-per-token: pagar mais caro pra garantir latência, sem reservar capacidade dedicada

O Unity AI Gateway ganhou um modo de prioridade que promete latência consistente pra aplicações de IA em tempo real, sem exigir capacidade reservada, um meio-termo entre pay-per-token comum e provisioned throughput.