Modelos de pesos abertos nas suas próprias GPUs

As tabelas de classificação dos modelos de fronteira são genuinamente úteis de ler. Em raciocínio puro, programação e memória de contexto longo, as melhores APIs fechadas dos grandes laboratórios continuam no topo, e para muito trabalho a resposta honesta é chamar uma delas e seguir em frente.

Só que, numa empresa regulada, a tabela responde a uma pergunta que não fez. A pergunta que decide a sua arquitetura não é "que modelo pontua mais alto num benchmark público?". É "que modelo posso correr sobre o dossiê regulado de um cliente sem que esse dossiê saia do meu perímetro?". Nessa pergunta, um modelo de pesos abertos — Llama, Mistral, Qwen ou um dos seus descendentes — a correr em GPUs que controla, ganha frequentemente. Não por ser mais inteligente. Porque está lá, dentro de casa, onde a API de fronteira não está.

É um eixo de comparação diferente daquele que o mercado o treina a usar. A capacidade é um eixo. O local de execução é outro. Num negócio não regulado, o primeiro domina. Num regulado, o segundo sobrepõe-se muitas vezes.

O que "pesos abertos" lhe dá de facto

Comece pelo termo, porque é usado com ligeireza. Um modelo de pesos abertos é aquele cujos parâmetros treinados pode descarregar e correr no seu próprio hardware. Não é necessariamente open-source em sentido pleno: os dados e o código de treino podem ser fechados, e a licença pode ter condições. O que recebe é o artefacto que importa operacionalmente, os pesos, para os poder carregar nas suas GPUs e correr inferência sem uma chamada de rede a ninguém.

Essa única propriedade, inferência debaixo do seu próprio teto, é o que muda o retrato de compliance.

Quando chama uma API de fronteira, o prompt e o seu conteúdo saem do seu perímetro e são processados em infraestrutura que não é sua nem homologou. Garantias contratuais de não retenção e não treino ajudam, e contam, mas são promessas sobre os sistemas de outra pessoa. Quando corre um modelo de pesos abertos nas suas GPUs, não há saída sobre a qual prometer. Os dados regulados são lidos, raciocinados e descartados dentro de uma fronteira que a sua função de segurança já controla. A residência de dados deixa de ser uma cláusula que audita no contrato de um fornecedor e passa a ser um facto físico sobre onde os eletrões andaram.

Para trabalho sobre dados pessoais, processos de crédito, registos clínicos, ou o que o seu regulador trate como dados de categoria especial, essa distinção não é uma nuance. É frequentemente a decisão toda.

A diferença de capacidade é real, e está a fechar onde importa

Ser honesto sobre o compromisso é a única forma de este argumento valer a pena.

No raciocínio geral mais difícil, os melhores modelos de fronteira fechados continuam à frente dos melhores pesos abertos, e fingir o contrário condena um projeto. Mas duas coisas atenuam essa diferença num contexto regulado.

Primeiro, a diferença está a estreitar-se, e estreita-se mais depressa exatamente nas tarefas que um back office regulado corre: extração estruturada, classificação contra uma política, sumarização com citação, raciocínio condicionado sobre um conjunto documental delimitado. Não são tarefas criativas em aberto onde a escala de fronteira se exibe. São estreitas, repetíveis e avaliáveis, e é aí que um modelo de pesos abertos afinado ou bem instruído fecha quase toda a distância.

Segundo, em produção o modelo nunca é o sistema todo. Um modelo de pesos abertos de gama média, embrulhado em recuperação, validação e um gate humano nos casos difíceis, supera muitas vezes um modelo de fronteira chamado a nu, porque a exatidão que sobrevive até produção vem da arquitetura à volta do modelo, e não da pontuação bruta do modelo. O reenquadramento vindo do terreno aplica-se aqui: estrutura mais um modelo suficientemente bom bate um modelo excelente sem estrutura.

Por isso a pergunta prática não é "o modelo aberto é tão inteligente como o de fronteira?". É "o modelo aberto é suficientemente bom nesta tarefa específica e delimitada, assim que fica dentro de um sistema que apanha os seus erros?". Para uma fatia grande do trabalho regulado, a resposta é sim.

A fatura que paga mesmo: peso operacional e capacidade de GPU

Correr os seus próprios pesos não é grátis, e o custo não é sobretudo a licença. É operacional.

Passa a ser dono de uma stack de inferência. Isso significa planeamento de capacidade de GPU, serviço de modelos, batching e quantização para caber nos orçamentos de memória, gestão de versões à medida que saem novos pesos abertos, e o endurecimento de segurança das máquinas onde os pesos correm. A API de fronteira escondia tudo isso atrás da equipa de SRE de outra pessoa. Traga o modelo para casa e esse trabalho é seu.

A capacidade de GPU, em particular, é uma restrição real, não uma nota de rodapé. As APIs de fronteira dão-lhe débito praticamente elástico a pedido. Um cluster on-premise tem um teto fixo, e um pico de carga que uma API teria absorvido em silêncio passa a ser uma fila que tem de planear. É um custo de engenharia genuíno, e qualquer construção honesta contabiliza-o à partida em vez de o descobrir no primeiro fecho de mês.

Nada disto é argumento contra modelos em GPU próprias. É argumento contra fingir que são uma caixa a assinalar. As organizações que têm sucesso tratam a stack de inferência como infraestrutura a operar com a mesma disciplina de qualquer outro sistema regulado, e as que falham tratam um modelo descarregado como um produto acabado.

Agnóstico quanto ao fornecedor é o que lhe permite encaminhar, não escolher

Aqui está a parte que resolve a tensão. A escolha não é pesos abertos contra fronteira. É uma decisão de encaminhamento tomada carga a carga, e o que torna o encaminhamento possível é um gateway agnóstico quanto ao fornecedor.

Um gateway de modelos é uma única interface interna que todos os agentes invocam, atrás da qual os modelos são intercambiáveis. Um modelo de pesos abertos nas suas GPUs, uma API de fronteira e um modelo alojado em região europeia ficam todos atrás da mesma porta, e o agente não sabe qual respondeu. O valor dessa porta é deixar que uma política, e não o hábito de quem desenvolve, decida onde cada carga corre.

A regra que a política aplica é encaminhamento por sensibilidade dos dados, e falha fechada. Um passo que lê um dossiê regulado fica fixado ao modelo em GPU própria e não consegue fisicamente alcançar uma API externa. Um passo que redige um resumo genérico a partir de material não sensível, ou raciocina sobre informação já pública, pode ser encaminhado para uma API de fronteira pela capacidade extra, mas apenas porque uma política permitiu explicitamente que essa classe de dados saísse. Quando a classificação é incerta, os dados são tratados como sensíveis e ficam em casa. A omissão protege-o; relaxá-la exige uma decisão deliberada e registada.

É isso que torna a diferença de capacidade gerível em vez de fatal. Não tem de abdicar do raciocínio de fronteira em todo o lado para manter dados regulados dentro de casa. Encaminha as cargas sensíveis para o modelo que vive no seu perímetro, e as não sensíveis para o que for melhor para o trabalho, ao abrigo de uma regra que a sua função de compliance escreveu e consegue provar.

A pergunta que vale a pena levar à próxima revisão de arquitetura não é, portanto, "que modelo é melhor?". É quais das nossas cargas de trabalho nunca podem sair do edifício, e temos um modelo suficientemente bom para as servir dentro de portas? Responda a isso classe de dados a classe de dados, e o debate fronteira contra aberto dissolve-se numa tabela de encaminhamento. Salte-o, e estará a uma chamada de API conveniente de enviar um dossiê regulado para um sítio onde nunca foi permitido ir.

Se quiser mapear que cargas suas pertencem às suas próprias GPUs e quais podem ser encaminhadas em segurança para outro lado, marque uma reunião e traga-nos a mais sensível.