17 de maio de 2026. Um endpoint de modelo local acessível não é evidência suficiente de que a classificação está pronta para ser executada. O classificador da VALESKA tem uma dependência específica: o modelo esperado precisa estar selecionado, carregado e disponível com recursos suficientes de unidade de processamento gráfico (GPU) antes de uma solicitação de classificação ser enviada. Este trabalho introduz uma verificação prévia de ambiente para essa dependência. A afirmação não é que todo modelo local agora iniciará com êxito. A afirmação é que o classificador pode perguntar se seu perfil de ambiente exigido está pronto e recusar a classificação quando ele não está.
A pergunta de trabalho
A classificação local pode falhar de modo compreensível, em vez de tratar qualquer endpoint que responde como o modelo correto? Uma simples sondagem de endpoint pode confirmar que algo está escutando. Ela não pode estabelecer qual modelo está carregado, se a máquina reservou a memória gráfica (VRAM) necessária ou se uma tarefa concorrente mudou o estado do ambiente. Esses são fatos operacionais, não detalhes que o classificador deva adivinhar. A verificação prévia cria um lugar para declará-los antes que um documento seja classificado.
Evidências de 16 e 17 de maio
Em 16 de maio, o auxiliar do lado da Valeska foi acrescentado para solicitar um perfil de ambiente nomeado antes que o classificador de IA, o avaliador de treinamento e o gerador de conjunto de dados de treinamento usem inferência local. O auxiliar lê uma configuração de perfil de classificação e oferece controles explícitos para o perfil, um modo de ambiente obrigatório e o desvio da verificação prévia quando isso for apropriado para um ambiente definido. Se o gerenciador de ambiente informa que o perfil não está pronto, o classificador registra a falha e não prossegue como se o modelo tivesse sido verificado. A alteração torna a prontidão parte do contrato do classificador, em vez de deixá-la como condição presumida pelos chamadores.
Hoje, 17 de maio, esse auxiliar aponta para o repositório independente do árbitro de GPU. Esta é uma decisão de posicionamento: a seleção de modelo, as reivindicações de VRAM, o carregamento pelo LM Studio e o comportamento de liberação são administrados pelo gerenciador baseado em perfis do árbitro, em vez de serem recriados dentro da VALESKA. O perfil nomeado para classificação de repositórios identifica a configuração de modelo pretendida. O classificador continua responsável por decidir se realiza a classificação; o árbitro detém a solicitação de preparação do ambiente. Separar essas responsabilidades torna a dependência mais fácil de inspecionar quando a classificação não está disponível.
O que isto estabelece e o que não estabelece
A implementação estabelece uma rota de controle. Antes de contatar um modelo local, o classificador pode chamar o auxiliar de ambiente e receber informações de prontidão ou uma razão para desativar a operação. Ela também dá aos chamadores orientados a lotes a mesma rota, para que o trabalho de treinamento não use silenciosamente um estado local diferente da classificação interativa. Isso é útil porque a inferência local é infraestrutura compartilhada: seus limites são afetados pelo tamanho do modelo, pela VRAM, pelo estado de inicialização e por outros consumidores.
Ela não estabelece que o perfil nomeado sempre possa ser carregado nesta máquina, que toda reivindicação de VRAM será concedida ou que um resultado de classificação seja preciso. Essas são perguntas separadas. O projeto mantém deliberadamente visível a distinção. Um ambiente pronto é uma pré-condição para classificação, não prova da qualidade da classificação. Da mesma forma, uma falha clara da verificação prévia é preferível a uma alegação sem suporte de que um modelo estava pronto.
Próximo teste
O próximo teste é exercer o perfil real sob as condições compartilhadas de GPU que ele enfrentará em uso. A verificação deve mostrar o perfil selecionado, o resultado de disponibilidade e o comportamento do classificador nas duas rotas: classificar somente após preparação bem-sucedida e permanecer desativado com um registro compreensível quando a preparação falhar. O mesmo teste deve ser executado por um chamador em lote, porque o contrato compartilhado é o objetivo da alteração. Os resultados desse teste operacional pertencem a uma entrada posterior; a evidência de hoje é a integração da verificação prévia e sua transferência para o ambiente gerenciado pelo árbitro.
Base histórica: commits de 16–17 de maio de 2026 346b2d9 e 75e0ba4.