Open Source vs Open Weights vs Open API

Por que “aberto” é ambíguo em IA

No software tradicional, “código aberto (open source)” tem um significado amplamente entendido: o código-fonte é publicado sob uma licença que concede direitos amplos de uso, modificação e redistribuição. Na IA moderna—especialmente com modelos de grande porte (large models)—há múltiplos “artefatos (artifacts)” que importam:

  • Código de treinamento (training code) (o software que define o modelo e executa o treinamento)
  • Código de inferência/serving (inference/serving code) (como o modelo é executado em produção)
  • Pesos do modelo (model weights) (os parâmetros aprendidos—frequentemente o artefato mais valioso)
  • Dados de treinamento (training data) (ou ao menos a proveniência dos dados (data provenance))
  • Receita de treinamento (training recipe) (hiperparâmetros (hyperparameters), tokenizador (tokenizer), pré-processamento (preprocessing), configuração de computação (compute setup))
  • Relatórios de avaliação (evaluation) e segurança
  • Mecanismo de distribuição (distribution mechanism) (download vs API hospedada)

Quando um provedor de modelos diz “aberto”, ele pode estar se referindo a qualquer um desses itens. Este artigo esclarece três ofertas comuns—Código Aberto, Pesos Abertos e API Aberta—e explica o que está de fato aberto, quais direitos você obtém e por que isso importa para uso no mundo real e redistribuição. Para detalhes e padrões de licenciamento, consulte Licenças de Modelos (Model Licenses).

As três categorias em um relance

Código Aberto (o código é aberto)

O que está aberto: tipicamente o código-fonte (código de treinamento, código de inferência, ferramentas).
O que pode não estar aberto: pesos, dados, logs de treinamento ou ativos completos de reprodutibilidade.

Código aberto no sentido da OSI (Open Source Initiative) normalmente significa que o código está sob uma licença aprovada pela OSI (por exemplo, Apache-2.0, MIT). Essas licenças são projetadas para software, não para pesos de modelos.

Consequência prática: você pode inspecionar, modificar e redistribuir o código, mas ainda pode ser incapaz de executar o “modelo real” se os pesos não forem liberados (ou forem restritos).

Cenário de exemplo: Um laboratório libera uma implementação de treinamento da Arquitetura Transformer (Transformer Architecture) sob Apache-2.0, mas não libera o ponto de verificação (checkpoint) treinado. Você pode treinar seu próprio modelo (se tiver dados e computação), mas não consegue reproduzir exatamente os resultados deles.

Pesos Abertos (os pesos podem ser baixados)

O que está aberto: os pesos do modelo (e geralmente um tokenizador + código básico de inferência).
O que pode não estar aberto: dados de treinamento, receita completa de treinamento ou direitos comparáveis aos de código aberto.

“Pesos abertos” significa que você pode obter os parâmetros treinados e executar inferência localmente. Isso é extremamente valioso operacionalmente (implantação no local, controle de latência, uso off-line), mas não significa automaticamente que você pode redistribuí-los ou usá-los para qualquer finalidade. Muitos modelos de “pesos abertos” são distribuídos sob licenças personalizadas que pouco se parecem com licenças padrão de software de código aberto.

Consequência prática: muitas vezes você pode executar e fazer ajuste fino (fine-tuning) do modelo, mas deve verificar se a licença restringe uso comercial, certos domínios, redistribuição ou criação de derivados.

Cenário de exemplo: Uma empresa libera para download o ponto de verificação de um modelo de linguagem robusto, mas a licença proíbe usá-lo para construir um modelo de base concorrente ou restringe casos de uso específicos.

API Aberta (as capacidades são acessíveis via um serviço)

O que está aberto: uma interface (API HTTP, SDK (Software Development Kit)) para chamar o modelo.
O que não está aberto: pesos, código de treinamento e, normalmente, a maioria dos detalhes internos.

Com um modelo apenas via API, você não recebe os pesos; você aluga acesso à inferência. Seus direitos vêm dos Termos de Serviço (Terms of Service), não de licenças de código aberto ou de pesos abertos.

Consequência prática: tempo rápido até gerar valor e nenhuma necessidade de hospedar infraestrutura, mas você aceita aprisionamento a fornecedor (vendor lock-in), políticas de uso, mudanças de preços e auditabilidade limitada.

Cenário de exemplo: Você integra um modelo de linguagem de grande porte (LLM) hospedado em um produto de suporte ao cliente. Você consegue lançar globalmente em dias, mas não consegue executar off-line, não consegue inspecionar os pesos e deve cumprir as regras de conteúdo e uso do provedor.

O que está realmente “aberto”? Pense em camadas

Um modelo mental útil é tratar a abertura em IA como camadas, cada uma com implicações diferentes:

  1. Interface aberta: documentação da API, SDKs, às vezes bibliotecas de cliente abertas.
  2. Código de inferência aberto: implementação para executar o modelo.
  3. Pesos abertos: parâmetros baixáveis + tokenizador.
  4. Código de treinamento aberto: scripts para treinar ou fazer ajuste fino.
  5. Receita de treinamento aberta: hiperparâmetros, pré-processamento, configuração de hardware, sementes aleatórias (random seeds).
  6. Dados abertos (ou proveniência): conjuntos de dados, fontes, licenças, etapas de filtragem.
  7. Avaliação e segurança abertas: benchmarks (benchmarks), resultados de red teaming (red-teaming), mitigações.

Um modelo pode ser “aberto” na camada 3 (pesos) enquanto é fechado nas camadas 5–6 (receita e dados). Por isso, “aberto” em IA é mais um espectro do que um rótulo binário.

Código Aberto: o que você pode fazer (e o que não pode)

O que você normalmente recebe

  • Código-fonte completo para:
    • Implementação da arquitetura do modelo
    • Laços de treinamento e otimização (por exemplo, Descida do Gradiente (Gradient Descent))
    • Pipelines de inferência
    • Ferramentas para avaliação, logging e implantação
  • Termos de licença que concedem direitos amplos sobre software:
    • Usar para qualquer finalidade
    • Modificar
    • Redistribuir
    • Frequentemente inclui concessões de patentes (patent grants) (por exemplo, Apache-2.0)

O que ainda pode faltar

  • Pesos: sem pesos, você não tem o modelo treinado.
  • Dados: sem dados, você não consegue replicar o treinamento.
  • Computação: treinar modelos de fronteira (frontier models) pode ser economicamente inviável para a maioria das equipes.
  • Reprodutibilidade exata: mesmo com código + receita, não determinismo e diferenças de infraestrutura podem importar.

Aplicações práticas de código de IA de código aberto

  • Infraestrutura e ferramentas: frameworks de treinamento, runtimes de inferência, harnesses de avaliação.
  • Pesquisa e prototipagem personalizadas: mais fácil alterar componentes da arquitetura.
  • Auditorias de segurança: o código pode ser revisado em busca de riscos na cadeia de suprimentos (supply-chain).

Implicações para redistribuição

Se você redistribuir código de código aberto, deve cumprir a licença do código (por exemplo, incluir atribuição, preservar avisos, fornecer o código-fonte quando exigido por licenças copyleft (copyleft)). Mas, se você também empacotar pesos, a licença dos pesos pode impor obrigações adicionais além da licença do código.

Pesos Abertos: o “modelo aberto” mais comum na prática

Pesos abertos são atraentes porque habilitam inferência local e customização sem exigir execuções massivas de treinamento. Mas “pesos abertos” pode significar direitos muito diferentes dependendo da licença.

O que você normalmente recebe

  • Um ponto de verificação (checkpoint) (pesos) + tokenizador
  • Scripts básicos de inferência ou integração via bibliotecas populares
  • Às vezes receitas de ajuste fino (scripts de LoRA/QLoRA etc.)

O que você pode não receber

  • Dados de treinamento ou proveniência completa
  • Receita completa de treinamento e logs
  • Direitos de redistribuição irrestritos
  • Permissão para uso em todas as finalidades comerciais

Exemplo prático: executando um modelo de pesos abertos localmente

Abaixo está um fluxo de trabalho técnico típico. Se você tem permissão para fazer isso em produção depende da licença dos pesos.

from transformers import AutoTokenizer, AutoModelForCausalLM
import torch

model_id = "provider/model-name"  # example placeholder

tokenizer = AutoTokenizer.from_pretrained(model_id)
model = AutoModelForCausalLM.from_pretrained(
    model_id,
    torch_dtype=torch.float16,
    device_map="auto"
)

prompt = "Explain the difference between open weights and open source."
inputs = tokenizer(prompt, return_tensors="pt").to(model.device)

with torch.no_grad():
    output = model.generate(**inputs, max_new_tokens=120)

print(tokenizer.decode(output[0], skip_special_tokens=True))

Isso é operacionalmente poderoso: você pode implantar nas suas próprias GPUs, controlar a latência e manter os dados no local.

Redistribuição e obras derivadas

É aqui que pesos abertos frequentemente diferem de forma acentuada de código aberto:

  • Redistribuição: Algumas licenças permitem que você compartilhe livremente os pesos originais; outras limitam a redistribuição ou exigem que você distribua sob os mesmos termos.
  • Derivados: Ajustes finos, versões quantizadas (quantized), adaptadores (adapters) mesclados ou modelos destilados podem ser considerados obras derivadas—os termos da licença podem restringir como você os publica.
  • Restrições por caso de uso: Algumas licenças no estilo “IA responsável” restringem certos domínios (por exemplo, vigilância, armas ou tomada de decisão sensível). Essas restrições fazem com que a licença não seja “código aberto” no sentido de software da OSI, mesmo que os pesos sejam baixáveis.

Para uma discussão mais aprofundada desses padrões, consulte Licenças de Modelos.

Por que pesos abertos importam na prática

  • Implantação no local / off-line: crítica para ambientes regulados (saúde, finanças, governo).
  • Previsibilidade de custos: trade-offs de capex/opex vs precificação por token.
  • Customização: ajuste fino para linguagem de domínio, estilo, ferramentas ou política.
  • Auditoria e governança: mais observabilidade do que uma API opaca (embora ainda limitada sem dados abertos).

API Aberta: “acesso aberto” não é abertura

Um modelo de API aberta é melhor entendido como capacidade hospedada. A superfície da API pode estar bem documentada e ser amplamente utilizável, mas o modelo em si permanece fechado.

O que você normalmente recebe

  • Endpoints de API para chat/completions/incorporações (embeddings)
  • Acordos de nível de serviço (SLA), escalabilidade e disponibilidade gerenciada
  • Camadas de segurança do provedor e aplicação de políticas
  • Recursos opcionais (chamada de ferramentas (tool calling), saída estruturada (structured output), cache (caching))

O que você não recebe

  • Pesos ou a capacidade de executar localmente
  • Transparência total sobre dados de treinamento, filtragem ou avaliações internas
  • Controle sobre atualizações do modelo (o comportamento pode mudar)

Exemplo prático: chamando um modelo hospedado

curl https://api.example.com/v1/chat/completions \
  -H "Authorization: Bearer $API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "example-chat-model",
    "messages": [
      {"role": "user", "content": "Summarize our refund policy in 3 bullets."}
    ]
  }'
  • Integração rápida: não exige MLOps (ML ops).
  • Forte desempenho de base: acesso a sistemas de nível de fronteira (frontier-grade systems).
  • Simplicidade operacional: o provedor cuida de escalabilidade, GPUs e atualizações.

Riscos e limitações

  • Aprisionamento a fornecedor: custos de troca (prompts, ferramentas, dependências de comportamento).
  • Governança de dados: o que o provedor registra/retém e como os dados são usados.
  • Restrições de política: restrições de uso podem bloquear certas aplicações.
  • Reprodutibilidade: o comportamento do modelo pode mudar sem aviso.
  • Redistribuição: normalmente você não pode “redistribuir o modelo”, apenas seu aplicativo que o chama, e deve garantir que seus usuários também cumpram os termos do provedor.

Por que a distinção importa: uso, modificação e redistribuição

1) Direitos legais são diferentes entre código, pesos e acesso via API

  • Licenças de código de código aberto concedem direitos sobre software.
  • Licenças de pesos regem parâmetros do modelo (frequentemente tratados como dados ou um artefato compilado, dependendo da jurisdição e dos termos contratuais).
  • Termos de API regem uso de serviço e frequentemente incluem:
    • limites de taxa, preços, uso aceitável
    • retenção de dados e políticas de treinamento
    • restrições a engenharia reversa ou benchmarking

Você pode estar totalmente em conformidade com um codebase Apache-2.0 e ainda assim estar em não conformidade se distribuir pesos sob termos incompatíveis.

2) Controle operacional e opções de implantação

  • API Aberta: implantação mais fácil, menor controle.
  • Pesos abertos: controle mais prático (executar em qualquer lugar onde você consiga hospedar inferência).
  • Somente código aberto: máxima flexibilidade, mas potencialmente enorme ônus de treinamento se os pesos estiverem ausentes.

3) Transparência, auditoria e segurança

  • Código de código aberto melhora a auditabilidade da implementação.
  • Pesos abertos permitem testar certos comportamentos e robustez.
  • Sem dados abertos e detalhes de treinamento, ainda é difícil avaliar:
    • riscos de copyright e consentimento de dados
    • vieses de conjunto de dados e proveniência
    • memorização oculta de dados sensíveis

Se seu modelo de risco exige proveniência forte, “pesos abertos” pode não ser suficiente.

4) Efeitos no ecossistema: competição e inovação

  • Ferramentas de código aberto aceleram pesquisa e reduzem barreiras de entrada.
  • Pesos abertos reduzem barreiras de implantação e permitem ampla experimentação de ajuste fino.
  • Apenas API concentra poder: a inovação acontece “por cima”, mas a capacidade central permanece centralizada.

Equívocos comuns

“Pesos abertos significa código aberto”

Não necessariamente. Uma licença de pesos pode restringir quem pode usar o modelo, para quais finalidades e se derivados podem ser distribuídos. Isso é fundamentalmente diferente das liberdades do software de código aberto.

“Se eu posso baixar, eu posso redistribuir”

Permissão para download não é permissão para redistribuição. Redistribuição (especialmente redistribuição comercial) é frequentemente onde as restrições aparecem.

“Acesso por API é aberto porque qualquer um pode se cadastrar”

Isso é disponibilidade, não abertura. O provedor pode alterar preços, termos, limites de taxa ou comportamento do modelo unilateralmente.

“Código aberto garante reprodutibilidade”

Reprodutibilidade frequentemente exige mais do que código: dados, pré-processamento, receita de treinamento e, às vezes, pilhas específicas de hardware/software.

Escolhendo entre Código Aberto, Pesos Abertos e API Aberta

Um checklist de decisão (prático)

Pergunte isto antes de se comprometer:

  • Requisitos de implantação
    • Precisa rodar off-line ou no local?
    • Você tem permissão para enviar dados a terceiros?
  • Necessidades de customização
    • Você precisa de ajuste fino ou adaptação ao domínio?
    • Engenharia de prompts (prompt engineering) é suficiente?
  • Plano de redistribuição
    • Você entregará o modelo/pesos aos clientes (por exemplo, dispositivos de borda)?
    • Você publicará um ponto de verificação ajustado?
  • Conformidade e governança
    • Você precisa de trilhas de auditoria, proveniência de dados ou uma versão previsível do modelo?
    • Há domínios restritos na licença/ToS que se sobrepõem ao seu uso?
  • Custos e escalabilidade
    • Precificação por token é aceitável?
    • Você tem capacidade de GPU e expertise de MLOps?

Padrões típicos

  • Startups prototipando rapidamente: API aberta primeiro, depois migram para pesos abertos se custos ou privacidade exigirem.
  • Empresas reguladas: pesos abertos (ou totalmente auto-hospedado) costuma ser obrigatório.
  • Pesquisa e customização profunda: código de treinamento de código aberto + pesos abertos (quando disponíveis) é o ideal.
  • Implantação em borda (edge deployment) (celulares/embarcados): pesos abertos com direitos de redistribuição são cruciais (modelos quantizados, inferência off-line).

Fundamento teórico: por que modelos borram a fronteira do software

Sistemas de IA misturam características de software e dados:

  • O código é um conjunto de instruções escritas por humanos (software tradicional).
  • Os pesos são aprendidos a partir de dados e computação; eles se comportam como um artefato compilado, mas também codificam estrutura estatística da distribuição de treinamento.
  • Os dados de treinamento podem incorporar direitos de terceiros, restrições de privacidade e obrigações contratuais.

Essa mistura é por que o licenciamento de IA evoluiu de forma diferente do código aberto clássico: stakeholders tentam governar não apenas a cópia de código, mas resultados de uso, derivados a jusante e dinâmicas de competição. Se essas restrições são desejáveis é debatido, mas elas são comuns no panorama atual de “modelos abertos”.

Também há um esforço em andamento para definir de forma mais rigorosa o que “IA de código aberto” deveria significar (incluindo expectativas sobre dados e receitas de treinamento). Os detalhes e a adoção ainda estão evoluindo, então trate alegações de “aberto” como marketing até verificar os artefatos e a licença reais.

Orientação prática: como verificar o que está aberto

Ao avaliar o lançamento de um modelo, procure:

  1. Artefatos fornecidos
    • Pesos? tokenizador? código de inferência? código de treinamento? harness de avaliação?
  2. Licença para cada artefato
    • A licença do código pode diferir da licença dos pesos.
  3. Termos de redistribuição
    • Você pode espelhar os pesos? entregá-los em um produto? distribuir ajustes finos?
  4. Restrições por campo de uso
    • Há aplicações proibidas?
  5. Regras de derivados
    • Quantização, adaptadores, destilação ou mesclas são permitidas?
  6. Exigências de atribuição e avisos
    • Você deve incluir avisos específicos em UIs ou documentação?
  7. Política de atualização do modelo
    • Para APIs: fixação de versão, prazos de descontinuação (deprecation), termos de logging e retenção.

Se você quiser uma visão estruturada de cláusulas comuns e suas implicações, consulte Licenças de Modelos.

Resumo: o que está “de fato aberto” e por que isso importa

  • Código Aberto significa principalmente que o código é aberto sob uma licença de software. Ótimo para transparência e modificação, mas pode não incluir pesos utilizáveis.
  • Pesos Abertos significa que os parâmetros treinados estão disponíveis para rodar localmente, mas os direitos variam amplamente; muitas licenças não são “código aberto” e podem restringir redistribuição, derivados ou casos de uso.
  • API Aberta significa acesso a um modelo hospedado via uma interface. Otimiza conveniência e desempenho, mas oferece o menor controle e a menor capacidade de redistribuição.

A chave é tratar abertura em IA como específica por artefato: sempre pergunte quais partes estão abertas, sob quais termos e se esses termos correspondem ao seu uso pretendido e ao seu plano de redistribuição.