- O Ollama passou a incluir compatibilidade inicial com a Chat Completions API da OpenAI, permitindo conectar ferramentas e aplicações feitas para OpenAI diretamente a modelos locais
- Após a instalação, é possível baixar modelos como
llama2 ou mistral e chamá-los mantendo o formato de requisição da OpenAI, trocando apenas o host
- As bibliotecas Python e JavaScript da OpenAI funcionam ao definir
base_url/baseURL e fornecer um valor obrigatório, mas não utilizado, para api_key
- São fornecidos exemplos de conexão do app de chat com streaming do Vercel AI SDK e do framework multiagente Autogen da Microsoft ao Ollama
- No momento, o suporte está em fase de suporte experimental inicial; Embeddings API, chamada de funções, suporte a visão e melhorias em Logprobs ficam para avaliação futura
Chamando o Ollama no formato da API da OpenAI
- O Ollama fornece um endpoint compatível com a Chat Completions API da OpenAI, permitindo usar modelos locais em ferramentas existentes baseadas na OpenAI
- Para começar, instale o Ollama e baixe um modelo como Llama 2 ou Mistral
ollama pull llama2
curl http://localhost:11434/v1/chat/completions \
-H "Content-Type: application/json" \
-d '{
"model": "llama2",
"messages": [
{
"role": "system",
"content": "You are a helpful assistant."
},
{
"role": "user",
"content": "Hello!"
}
]
}'
- A biblioteca Python da OpenAI define
base_url para o endpoint local do Ollama
api_key='ollama' é obrigatório, mas não é usado
from openai import OpenAI
client = OpenAI(
base_url = 'http://localhost:11434/v1',
api_key='ollama',
)
response = client.chat.completions.create(
model="llama2",
messages=[
{"role": "system", "content": "You are a helpful assistant."},
{"role": "user", "content": "Who won the world series in 2020?"},
{"role": "assistant", "content": "The LA Dodgers won in 2020."},
{"role": "user", "content": "Where was it played?"}
]
)
print(response.choices[0].message.content)
- A biblioteca JavaScript da OpenAI define
baseURL como http://localhost:11434/v1
apiKey: 'ollama' também é obrigatório, mas não é usado
import OpenAI from 'openai'
const openai = new OpenAI({
baseURL: 'http://localhost:11434/v1',
apiKey: 'ollama',
})
const completion = await openai.chat.completions.create({
model: 'llama2',
messages: [{ role: 'user', content: 'Why is the sky blue?' }],
})
console.log(completion.choices[0].message.content)
Integrações de exemplo e planos futuros
- O Vercel AI SDK é uma biblioteca open source para criar aplicações interativas com streaming, e é possível adaptar o exemplo OpenAI para Next.js para usar o Ollama
npx create-next-app --example https://github.com/vercel/ai/tree/main/examples/next-openai example
cd example
- Em
app/api/chat/route.ts, altere a configuração do cliente OpenAI para o endpoint local do Ollama
const openai = new OpenAI({
baseURL: 'http://localhost:11434/v1',
apiKey: 'ollama',
});
- A requisição de chat completion usa o modelo
llama2 com stream: true
const response = await openai.chat.completions.create({
model: 'llama2',
stream: true,
messages,
});
npm run dev
- O Autogen é o framework open source da Microsoft para aplicações multiagente, e o exemplo usa Code Llama
ollama pull codellama
pip install pyautogen
from autogen import AssistantAgent, UserProxyAgent
config_list = [
{
"model": "codellama",
"base_url": "http://localhost:11434/v1";,
"api_key": "ollama",
}
]
assistant = AssistantAgent("assistant", llm_config={"config_list": config_list})
user_proxy = UserProxyAgent("user_proxy", code_execution_config={"work_dir": "coding", "use_docker": False})
user_proxy.initiate_chat(assistant, message="Plot a chart of NVDA and TESLA stock price change YTD.")
- O exemplo é executado com
python example.py, fazendo o assistente escrever código para gerar o gráfico
python example.py
- O suporte à API da OpenAI está em fase de suporte experimental inicial
- Itens em avaliação para melhorias futuras incluem Embeddings API, chamada de funções, suporte a visão e Logprobs
- Eles aceitam issues no GitHub, e mais detalhes estão disponíveis na documentação de compatibilidade com a OpenAI
1 comentários
Comentários do Hacker News
É impressionante a velocidade com que a usabilidade de hospedagem local de LLMs melhorou nos últimos meses. Até poucas horas atrás eu estava falando de como https://github.com/Mozilla-Ocho/llamafile é fácil[1], e agora já fico em dúvida sobre o que usar
[1] Literalmente algumas horas atrás: https://euri.ca/blog/2024-llm-self-hosting-is-easy-now/
ollama serve, subirollama web-uino Docker, adicionar pela interface web um modelo de assistência de código do OllamaHub e então enviar os documentosVocê passa a ter um LLM self-hosted que responde usando documentos como contexto, sem precisar escrever código. Aqui, no nosso Mac Studio com 64GB de RAM, o deepseek coder 33b é rápido o suficiente e faz sugestões bem decentes com base na nossa documentação interna de código
Também dá para misturar vários modelos dentro de um único arquivo de modelo, algo que estão experimentando recentemente. Você não precisa depender da biblioteca de modelos do Ollama e também pode usar modelos próprios. O suporte a novos modelos entra por meio dos bindings de
llama.cppllamafile, mas senti falta de uma interface de chat com recursos suficientes, então criei o https://recurse.chat/ em cima deleAinda preciso do GPT-4 para algumas tarefas, mas no uso diário isso já substituiu boa parte do meu uso do ChatGPT, e é especialmente bom poder importar todo o histórico de conversas do ChatGPT. Também tenho curiosidade sobre o que as pessoas querem fazer com IA local
llamacpp -m -pe estou usando Mixtral 8x7b + CodeLlama 70b no MacBook como ferramentas do dia a dia sem problemas. Fico curioso se as alternativas ao Llama.cpp têm algum recurso decisivo, e não quero perder essa nova onda interessanteSou professor de administração e fiz um guia para que os alunos experimentem Ollama e web-ui rodando no Google Cloud[1]. Usando instâncias spot, dá para rodar por 18 centavos de dólar por hora
[1] https://docs.google.com/document/d/1OpZl4P3d0WKH9XtErUZib5_2...
git-bash. Não é tecnicamente mais difícil do que o que você já explicouConheço algumas pessoas que ficam meio incomodadas, no fundo, com a compatibilidade com a API da OpenAI estar virando o padrão de fato da comunidade. Tirando coisas estranhas como
data.choices.text.responsee o aninhamento desnecessariamente defensivo do schema, não tenho grandes reclamaçõesTenho curiosidade sobre quais são os pontos dolorosos nesse processo de uma API virar padrão e se alguém já tentou algum padrão alternativo que valha considerar
Tudo bem virar um padrão da comunidade, mas precisa haver uma especificação muito sólida do que a comunidade quer dizer com compatível com a API da OpenAI. Em especial, esse padrão precisa continuar estável mesmo que a OpenAI lance um recurso novo hoje de manhã
O que eu quero é uma especificação robusta da API, incluindo condições de erro, uma suíte de testes para verificar se uma nova implementação segue a especificação e um nome. Por exemplo, quando um software diz ser compatível com
OpenAI-API-Spec v3, eu quero saber o que isso significa. Se ficar só em “compatível com a API da OpenAI”, como agora, falta informação. Não dá para saber com que parte da API é compatível nem com qual momento da API isso está alinhadoMesmo que o Ollama adicione um recurso legal, novo e diferente, se não houver equivalente na API da OpenAI, as pessoas talvez nem consigam usar isso
llama.cppcom bindings na linguagem que você quiser, então isso não é algo tão importante. Se você precisar de mais controle, basta um pouco mais de trabalho, e você não precisa necessariamente dessas ferramentas plug and playNo trabalho, estamos criando uma versão melhor que o Copilot e também damos suporte a um modelo em que o usuário traz o próprio LLM. Recentemente estamos adicionando backends compatíveis com OpenAI; se você informar um endpoint de API compatível com OpenAI e disser como o modelo deve ser tratado, conseguimos formatar prompts, sequências de parada, tokens máximos etc. de acordo com a semântica daquele modelo
Era exatamente disso que eu precisava para testar no ambiente local de desenvolvimento. Se o Ollama oferece isso, testar os inúmeros LLMs que precisamos suportar fica muito mais fácil. Vendo várias ferramentas, como OpenLLM, implementando a mesma API, parece que todo mundo está convergindo para a compatibilidade com a API da OpenAI
A sensação de criar uma startup de IA agora é realmente muito boa
No começo houve sofrimento com o limite de tokens, mas isso foi resolvido; o problema de saída JSON consistente também foi resolvido; os limites de velocidade e problemas de desempenho de grandes modelos de terceiros também foram resolvidos; e a vontade de reduzir custos hospedando modelos open source por conta própria para tarefas pequenas e de média complexidade também foi atendida
Parece que, a cada grande avanço em LLMs, o produto automaticamente fica mais barato, mais estável e mais escalável. Claro, é preciso criar defesas e focar em se diferenciar em tudo que “não é IA”
Dizer que é compatível com OpenAI pode gerar um pouco de confusão, porque isso faz esperar também function calling ou tool calling
É bom ter a estrutura de papéis e conteúdo, mas isso já era uma implementação originalmente bem simples. Quando se vai para agentes, é preciso executar ações de fato. No sistema de hospedagem de agentes que comecei, coloquei um mecanismo de scripting, então fiquei pensando se, depois de resolver segurança e permissões, não seria melhor simplesmente deixar o agente executar código. Foi assim que comecei na prática
Então não tenho certeza se function/tool calling é realmente necessário. Mas, se muita gente estiver padronizando tool calling, talvez eu precise colocar isso no meu framework, mesmo havendo execução de scripts arbitrários
Function calling/tool choice é tratado no nível da aplicação e atualmente não há um formato padrão. Até os mais usados na prática são quase sistemas de prompt personalizados e ineficientes: https://github.com/langchain-ai/langchain/blob/master/libs/l...
De todo modo, talvez seja melhor não lançar um suporte que não funciona
Só para constar, o script de instalação do Ollama no Linux funciona daquele jeito “padrão” comum em ferramentas hoje em dia:
curl https://ollama.ai/install.sh | shPorém, da última vez que verifiquei, esse script exigia privilégios de root com
sudo. Se você quiser usar a ferramenta, vale a pena baixar o script para inspecioná-lo ou adaptá-lo às suas necessidadeschmod +x ollama-linux-amd64) e rodá-lo. Não foi necessário privilégio de root[0] https://github.com/ollama/ollama/blob/main/docs/linux.md#man...
[1] https://ollama.ai/download/ollama-linux-amd64
ollamavai para/usr/bin; não é obrigatório, mas é conveniente. Fora isso, não verifiquei o que mais exigiria acesso rootA camada de compatibilidade também pode ser feita dentro da biblioteca. Por exemplo, o
llm()do LangChain pode funcionar com vários backends de LLM. Tenho curiosidade sobre qual abordagem vocês preferemOutro é que, se o mundo acabar se padronizando em uma biblioteca horrível como o LangChain, os concorrentes tardios acabam morrendo e ficando presos por muito tempo por causa do custo de manutenção de backends não uniformes. Por isso, por conveniência, uma API uniforme parece a melhor escolha agora
Mesmo não sendo perfeita, é bom ter uma API padrão. Ao mesmo tempo, tudo bem existir uma segunda API que permita usar todo o potencial, como o B2 da Backblaze. Não existe uma abordagem única que sirva para todos os modelos, e, se os modelos têm capacidades diferentes, acho bom oferecer as duas opções
Estou criando um projeto em Python para alternar facilmente entre modelos open source (via HF e VLLM) e modelos comerciais (OpenAI, Google, Anthropic, Together): https://github.com/datadreamer-dev/DataDreamer
Se você quiser usar diretamente em Python, sem API HTTP, é uma forma um pouco mais fácil
Tenho curiosidade sobre o caso de uso do Ollama. Por que não usar
llama.cppdiretamente?llama.cppdiretamente, que atualmente também já tem servidor embutido compatível com OpenAI