O time quer fazer fine tuning de um modelo aberto em vez de chamar uma API hospedada. Como você decidiria?

Decida em quatro eixos: qualidade na sua tarefa específica, custo no seu volume real, requisitos de latência e controle, e restrições de dados ou de conformidade. Comece pela API hospedada com prompting e recuperação para estabelecer uma barra de qualidade de forma barata. Faça fine tuning quando você tem uma tarefa estável com bons dados rotulados, volume alto o bastante para a economia virar, ou uma exigência de manter os dados dentro do seu próprio ambiente.

Eu empurraria para responder isso com números em vez de preferência. Primeiro, construa a baseline hospedada: um bom prompt, recuperação se a tarefa precisa de contexto, e um conjunto de avaliação. Isso costuma levar dias e nos diz qual qualidade é alcançável, e muitas vezes ela já é boa o bastante, ponto em que fine tuning vira uma solução procurando um problema. Se a qualidade realmente está aquém, eu pergunto se a lacuna é de conhecimento, que recuperação resolve, ou de comportamento e formato, que fine tuning resolve. Depois a economia. O custo hospedado escala linearmente com tokens; self hosting é majoritariamente custo fixo de acelerador, então existe um volume de cruzamento, e eu calculo isso com projeções reais de tráfego em vez de esperanças. Abaixo do cruzamento, self hosting perde antes mesmo de você contar o tempo de um engenheiro. O custo que as pessoas esquecem é a posse: serving, autoscaling, upgrades, reavaliação quando você troca de modelo base, alguém de plantão. Isso é um compromisso permanente. Onde a coisa se decide sozinha é conformidade. Se os dados não podem sair do nosso ambiente, a decisão já está tomada e a discussão é só sobre qual modelo aberto, não sobre se.