Ollama의 OpenAI 호환성

(ollama.ai)

1P by GN⁺ 2024-02-09 | ★ favorite | 댓글 1개

Ollama가 OpenAI Chat Completions API 초기 호환성을 내장해, OpenAI용 도구와 애플리케이션을 로컬 모델에 그대로 연결할 수 있게 됨
설치 후 llama2나 mistral 같은 모델을 내려받고, OpenAI 요청 형식을 유지한 채 호스트만 ` 바꾸면 호출 가능함
OpenAI Python·JavaScript 라이브러리는 base_url/baseURL을 지정하고, 필수지만 사용되지 않는api_key` 값을 넣어 동작함
Vercel AI SDK 스트리밍 채팅 앱과 Microsoft Autogen 멀티 에이전트 프레임워크를 Ollama에 연결하는 예제가 제공됨
현재 지원은 초기 실험적 지원 단계이며, Embeddings API, 함수 호출, 비전 지원, Logprobs 개선은 향후 검토 대상임

OpenAI API 형식으로 Ollama 호출

Ollama는 OpenAI Chat Completions API와 호환되는 엔드포인트를 제공해, 로컬 모델을 기존 OpenAI 기반 도구에서 사용할 수 있게 함
시작하려면 Ollama를 설치하고 Llama 2 또는 Mistral 같은 모델을 내려받음

ollama pull llama2

cURL에서는 OpenAI 요청 형식을 그대로 두고 호스트를 http://localhost:11434로 변경함

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!"
}
]
}'

OpenAI Python 라이브러리는 base_url을 Ollama 로컬 엔드포인트로 지정함
- api_key='ollama'는 필수지만 사용되지 않음

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)

OpenAI JavaScript 라이브러리는 baseURL을 http://localhost:11434/v1로 설정함
- apiKey: 'ollama'도 필수지만 사용되지 않음

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)

예제 통합과 향후 계획

Vercel AI SDK는 대화형 스트리밍 애플리케이션을 만들기 위한 오픈소스 라이브러리이며, Next.js OpenAI 예제를 Ollama로 바꿔 사용할 수 있음

npx create-next-app --example https://github.com/vercel/ai/tree/main/examples/next-openai example
cd example

app/api/chat/route.ts에서 OpenAI 클라이언트 설정을 Ollama 로컬 엔드포인트로 바꿈

const openai = new OpenAI({
baseURL: 'http://localhost:11434/v1',
apiKey: 'ollama',
});

채팅 완료 요청은 llama2 모델과 stream: true를 사용함

const response = await openai.chat.completions.create({
model: 'llama2',
stream: true,
messages,
});

앱은 npm run dev로 실행하고 브라우저에서 http://localhost:3000을 열어 확인함

npm run dev

Autogen은 Microsoft의 멀티 에이전트 애플리케이션용 오픈소스 프레임워크이며, 예제는 Code Llama를 사용함

ollama pull codellama
pip install pyautogen

Autogen 설정에는 model: "codellama", base_url: "http://localhost:11434/v1";, api_key: "ollama"가 들어감

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.")

예제는 python example.py로 실행하며, 어시스턴트가 차트를 그리는 코드를 작성하게 함

python example.py

OpenAI API 지원은 초기 실험적 지원 단계에 있음
- 향후 개선 검토 항목은 Embeddings API, 함수 호출, 비전 지원, Logprobs임
- GitHub 이슈를 받을 수 있으며, 자세한 정보는 OpenAI 호환성 문서에서 확인 가능함

GN⁺ 2024-02-09 [-]

Hacker News 의견들

최근 몇 달 사이 로컬 LLM 호스팅의 사용성이 좋아진 속도가 놀라움. 몇 시간 전만 해도 https://github.com/Mozilla-Ocho/llamafile이 얼마나 쉬운지 떠들고 있었는데[1], 이제는 뭘 써야 할지 고민됨
[1] 말 그대로 몇 시간 전: https://euri.ca/blog/2024-llm-self-hosting-is-easy-now/
- 지금은 회사가 기본적인 RAG 지원 추론 서버를 자체 호스팅하기가 더 쉬워졌다고 봄. Mac Mini나 Mac Studio를 사고, ollama serve를 실행하고, Docker에서 ollama web-ui를 띄우고, 웹 UI로 OllamaHub의 코딩 보조 모델을 추가한 뒤 문서를 올리면 됨
  코드 없이도 문서를 문맥으로 삼아 답하는 자체 호스팅 LLM이 생김. 우리 쪽은 64GB RAM Mac Studio에서 deepseek coder 33b가 충분히 빠르고, 내부 코딩 문서를 바탕으로 꽤 괜찮은 제안을 해줌
- 개인적으로는 Ollama를 추천함. 모델 관리 방식이 Docker 비슷하게 잘 잡혀 있고, API도 더 넓게 지원됨
  단일 모델 파일 안에서 여러 모델을 섞을 수도 있는데, 요즘 실험 중인 기능임. 꼭 Ollama의 모델 라이브러리에 의존할 필요는 없고 직접 만든 모델도 쓸 수 있음. 새 모델 지원은 llama.cpp 바인딩을 통해 들어옴
- 이 분야의 발전 속도가 정말 놀라움. llamafile을 띄우기 쉬운 점은 좋았지만, 기능이 충분한 채팅 인터페이스가 아쉬워서 그 위에 https://recurse.chat/을 만들었음
  아직 일부 작업에는 GPT-4가 필요하지만, 일상 사용에서는 ChatGPT 사용의 상당 부분을 대체했고 특히 ChatGPT 채팅 기록을 전부 가져올 수 있어서 좋음. 사람들이 로컬 AI로 뭘 하고 싶어 하는지도 궁금함
- MBP에서 로컬 개발용으로 Ollama와 Mixtral-7B를 쓰고 있는데 아주 만족스러움
- 항상 llamacpp -m -p 만 써왔고, MacBook에서 Mixtral 8x7b + CodeLlama 70b를 일상 도구처럼 잘 쓰고 있음. Llama.cpp 대안들이 가진 결정적 기능이 있는지 궁금하고, 멋진 새 흐름을 놓치고 싶지 않음
경영학 교수인데 학생들이 Ollama와 web-ui를 써보게 하려고 Google Cloud에서 실행하는 안내서를 만들었음[1]. 스팟 인스턴스를 쓰면 시간당 18센트로 돌릴 수 있음
[1] https://docs.google.com/document/d/1OpZl4P3d0WKH9XtErUZib5_2...
- 이렇게 설정하면 학생들이 관리자 권한을 선점당해 인스턴스를 탈취당할 수 있음. 매우 안전하지 않음. git-bash에서 SSH 키를 쓰게 하는 걸 강력히 권함. 이미 안내한 것들보다 더 기술적으로 어렵지도 않음
- Google Colab에서도 많은 것을 무료로 돌릴 수 있음. KoboldCPP는 웹사이트에 미리 만들어진 실행 환경이 잘 되어 있고, 다른 모델도 불러올 수 있음
OpenAI API 호환성이 커뮤니티 표준이 되어가는 걸 내심 불편해하는 사람들을 몇 명 알고 있음. data.choices.text.response 같은 어색함이나 스키마의 불필요하게 방어적인 중첩을 빼면 딱히 불만은 없음
API가 표준이 되는 과정에서 어떤 고통점이 있는지, 고려할 만한 대안 표준을 시도한 사람이 있는지 궁금함
- 문서화가 필요함
  커뮤니티 표준으로 자리 잡는 건 괜찮지만, 커뮤니티가 말하는 OpenAI API 호환이 무엇인지에 대한 매우 탄탄한 명세가 있어야 함. 특히 OpenAI가 오늘 아침 새 기능을 냈더라도 그 표준은 안정적으로 유지되어야 함
  원하는 것은 오류 조건까지 포함한 견고한 API 명세, 새 구현이 명세를 따르는지 확인할 수 있는 테스트 모음, 그리고 이름임. 예를 들어 소프트웨어가 OpenAI-API-Spec v3와 호환된다고 할 때 그 의미를 알고 싶음. 지금처럼 “OpenAI API 호환”이라고만 하면 정보가 부족함. API의 어느 부분인지, 어느 시점의 API에 맞춘 것인지 알 수 없음
- 솔직히 이걸 추가하기 전 내부에서 많이 논의했음. 남의 API에 묶여서 우리 프로젝트에 어떤 기능을 넣어야 하는지, 혹은 넣지 말아야 하는지를 그쪽 API가 좌우할 수 있다는 점이 이상함
  Ollama에 멋지고 새롭고 다른 기능을 추가해도 OpenAI API에 대응물이 없으면 사람들이 그걸 쓸 수 있을지 모르겠음
- 그래서 선택지로 제공되는 건 좋음. 마찰을 줄이고 OpenAI의 해자에 대한 종속을 낮출 수 있음
- 표준이 없는 것보다는 불완전한 표준이 언제나 낫다고 봄
- 원하는 언어의 바인딩으로 llama.cpp 함수를 직접 호출하는 웹 서버를 만드는 건 아주 쉬워서 크게 중요하지 않음. 제어가 더 필요하면 약간의 작업만 더 하면 되고, 꼭 이런 플러그 앤 플레이 도구가 필요하진 않음
직장에서 Copilot보다 나은 버전을 만들고 있고, 사용자가 자기 LLM을 가져오는 방식도 지원함. 최근에는 OpenAI 호환 백엔드를 추가하고 있는데, OpenAI 호환 API 엔드포인트와 어떤 모델처럼 다룰지만 알려주면 그 모델의 의미론에 맞춰 프롬프트, 중단 시퀀스, 최대 토큰 등을 포맷할 수 있음
로컬 개발 환경에서 테스트하려고 정확히 이런 게 필요했음. Ollama가 이걸 지원하면 우리가 지원해야 하는 수많은 LLM에 대한 테스트가 훨씬 쉬워짐. OpenLLM 등 여러 도구도 같은 API를 구현하는 걸 보면 모두 OpenAI API 호환성으로 모이는 듯함
지금 AI 스타트업을 만드는 느낌이 정말 좋음
처음에는 토큰 제한으로 고생했지만 해결됐고, 일관된 JSON 출력 문제도 해결됐고, 대형 서드파티 모델의 속도 제한과 성능 문제도 해결됐고, 작고 중간 정도 복잡도의 작업을 위해 오픈소스 모델을 자체 호스팅해 비용을 줄이고 싶던 것도 해결됨
주요 LLM 발전이 나올 때마다 제품이 자동으로 더 싸지고, 더 안정적이고, 더 확장 가능해지는 느낌임. 물론 방어력을 만들고 “AI가 아닌” 모든 것에서 차별화하는 데 집중해야 함
- 토큰 제한이 해결됐다는 건 어떤 의미인지 궁금함. 최근 버전들의 컨텍스트 한도가 훨씬 커졌지만 비용도 훨씬 비싸진 걸 말하는 건가?
OpenAI와 호환된다고 말하면 함수 호출이나 도구 호출까지 기대하게 되므로 약간 오해를 부를 수 있다고 봄
역할과 내용 구조가 있는 건 좋지만, 그건 원래 구현이 꽤 단순했음. 에이전트로 가면 실제 액션 실행이 필요함. 내가 시작한 에이전트 호스팅 시스템에는 스크립팅 엔진을 넣었고, 그래서 보안과 권한을 잡은 뒤 에이전트가 그냥 코드를 실행하게 해야 하는 게 아닌가 싶었음. 실제로 그렇게 시작했음
그래서 함수/도구 호출이 꼭 필요한지는 확신이 없음. 하지만 많은 사람이 도구 호출을 표준화하고 있다면, 임의 스크립트 실행이 있더라도 내 프레임워크에 넣어야 할 수도 있음
- 문서에서 제외된 기능을 명확히 밝히고 있음: https://github.com/ollama/ollama/blob/main/docs/openai.md
  함수 호출/도구 선택은 애플리케이션 수준에서 처리되며 현재 표준 형식이 없음. 널리 쓰이는 것들도 사실상 비효율적인 맞춤형 시스템 프롬프트에 가까움: https://github.com/langchain-ai/langchain/blob/master/libs/l...
- Gemini Pro가 함수/도구 호출을 지원해서 끌렸지만, 실제로는 형편없이 동작함. Gemini Ultra는 아직 안 써봤고 API로 가능한지도 불분명함
  어쨌든 동작하지 않는 지원을 내놓지 않은 편이 더 나을 수 있음
- OpenAI API를 써본 사람에게는 당연히 이해되는 선택임
참고로 Ollama의 Linux 설치 스크립트는 요즘 도구에서 흔한 “표준” 방식으로 동작함:
curl https://ollama.ai/install.sh | sh
다만 마지막으로 확인했을 때 이 스크립트는 sudo로 루트 권한을 요구했음. 도구를 쓰고 싶다면 스크립트를 내려받아 살펴보거나 필요에 맞게 수정하는 게 좋음
- 수동 설치 안내가 있음[0]. 그걸 보면 시작 시 자동 실행되는 SystemD 서비스를 설정하는 듯함. 단순히 시험해보려는 목적이라면 [1]을 내려받고 실행 가능하게 만든 뒤(chmod +x ollama-linux-amd64) 실행하는 것만으로도 잘 됐음. 루트 권한은 필요 없었음
  [0] https://github.com/ollama/ollama/blob/main/docs/linux.md#man...
  [1] https://ollama.ai/download/ollama-linux-amd64
- ollama 바이너리는 /usr/bin에 들어가는데 꼭 그래야 하는 건 아니지만 편리함. 그 밖에 무엇이 루트 접근을 필요로 하는지는 확인해보지 않았음
- 요즘 시대에는 패키지 관리자가 있음
호환 계층은 라이브러리 안에 만들 수도 있음. 예를 들어 LangChain의 llm()은 여러 LLM 백엔드와 함께 동작할 수 있음. 어느 쪽을 선호하는지 궁금함
- 라이브러리 안에 있는 편을 선호하지만 현재는 문제가 꽤 있음. 가장 큰 문제는 생태계가 너무 빨리 움직여서 라이브러리 래퍼들이 따라가지 못한다는 점임
  또 하나는 세상이 LangChain 같은 형편없는 라이브러리로 표준화해버리면, 균일하지 않은 백엔드의 유지보수 비용 때문에 후발 주자가 죽고 오래 묶이게 된다는 점임. 그래서 지금은 균일한 API가 편의상 나은 선택처럼 보임
- 그렇게 하면 각 라이브러리가 각 LLM을 지원해야 함. 이는 객체 스토리지에서 결국 거의 모두가 S3 호환 API를 지원하게 된 것과 같은 문제라고 봄
  완벽하지 않더라도 표준 API가 있는 건 좋음. 동시에 Backblaze의 B2처럼 전체 잠재력을 쓰게 해주는 두 번째 API가 있어도 괜찮음. 하나로 모든 모델에 맞추는 방식은 없고, 모델에 다른 능력이 있다면 두 옵션을 모두 제공하는 게 좋다고 생각함
- OpenAI가 앱을 내기 전에는 내가 만든 시스템에서 LangChain을 쓰고 있었음. LLM에 붙인 아주 단순한 SMS 인터페이스였고, GPT-4 API와 직접 맞붙는 것보다 LangChain의 추상화로 작업하는 쪽을 선호했음
Python에서 오픈소스 모델(HF, VLLM 경유)과 상용 모델(OpenAI, Google, Anthropic, Together)을 쉽게 바꿔 끼울 수 있는 프로젝트를 만들고 있음: https://github.com/datadreamer-dev/DataDreamer
HTTP API 없이 Python에서 직접 쓰고 싶다면 조금 더 쉬운 방식임
Ollama의 사용처가 뭔지 궁금함. 왜 llama.cpp를 직접 쓰면 안 되는가?
- LLM용 Docker/패키지 관리자 같은 것임. 표준화되고 단순한 CLI로 쉽게 설치하고, 새 모델을 찾고, 업데이트할 수 있음. 자동 업데이트도 부담 없이 됨
- 같은 의문이 있음. Ollama가 홍보도 많이 되고 반응도 좋은 것 같은데, 요즘은 OpenAI 호환 내장 서버도 있는 llama.cpp를 직접 쓰는 것과 비교해 정확히 어떤 장점이 있는지 궁금함

답변달기

Ollama의 OpenAI 호환성

OpenAI API 형식으로 Ollama 호출

예제 통합과 향후 계획

함께 보면 좋은 글 β

댓글과 토론

Hacker News 의견들