ความเข้ากันได้ของ Ollama กับ OpenAI

 (ollama.ai)
1 คะแนน โดย GN⁺ 2024-02-09 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • Ollama ได้ฝังความเข้ากันได้เบื้องต้นกับ Chat Completions API ของ OpenAI ทำให้สามารถเชื่อมต่อเครื่องมือและแอปพลิเคชันที่สร้างมาสำหรับ OpenAI เข้ากับโมเดลแบบโลคัลได้โดยตรง
  • หลังติดตั้ง สามารถดาวน์โหลดโมเดลอย่าง llama2 หรือ mistral แล้วเรียกใช้งานได้โดยคงรูปแบบคำขอของ OpenAI ไว้เหมือนเดิมและเปลี่ยนเฉพาะโฮสต์
  • ไลบรารี OpenAI สำหรับ Python และ JavaScript สามารถใช้งานได้โดยกำหนด base_url/baseURL และใส่ค่า api_key ที่จำเป็นแต่ไม่ได้ถูกใช้งานจริง
  • มีตัวอย่างการเชื่อมต่อ Vercel AI SDK สำหรับแอปแชตแบบสตรีมมิง และเฟรมเวิร์กมัลติเอเจนต์ Autogen ของ Microsoft เข้ากับ Ollama
  • ขณะนี้การรองรับยังอยู่ในขั้น รองรับเบื้องต้นเชิงทดลอง โดย Embeddings API, function calling, การรองรับ vision และการปรับปรุง Logprobs เป็นสิ่งที่อาจพิจารณาในอนาคต

เรียกใช้ Ollama ด้วยรูปแบบ OpenAI API

  • Ollama มีเอ็นด์พอยต์ที่เข้ากันได้กับ Chat Completions API ของ OpenAI ทำให้สามารถใช้โมเดลแบบโลคัลในเครื่องมือเดิมที่อิง 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 เป็นไลบรารีโอเพนซอร์สสำหรับสร้างแอปพลิเคชันสตรีมมิงแบบโต้ตอบ และสามารถปรับตัวอย่าง OpenAI ของ Next.js ให้ใช้กับ 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 client ไปใช้เอ็นด์พอยต์แบบโลคัลของ Ollama
const openai = new OpenAI({
baseURL: 'http://localhost:11434/v1',
apiKey: 'ollama',
});
  • คำขอ chat completions ใช้โมเดล 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

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, function calling, การรองรับ vision และ Logprobs
    • สามารถรับ GitHub issue ได้ และดูรายละเอียดเพิ่มเติมได้ในเอกสาร ความเข้ากันได้กับ OpenAI

บทความที่เกี่ยวข้อง

1 ความคิดเห็น

 
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/

    • ตอนนี้ผมมองว่าบริษัทต่าง ๆ สามารถโฮสต์ เซิร์ฟเวอร์ inference ที่รองรับ RAG ขั้นพื้นฐาน เองได้ง่ายขึ้นแล้ว ซื้อ Mac Mini หรือ Mac Studio, รัน ollama serve, เปิด ollama web-ui ใน Docker, เพิ่มโมเดลช่วยเขียนโค้ดจาก OllamaHub ผ่านเว็บ UI แล้วอัปโหลดเอกสารเข้าไปก็พอ
      ก็จะได้ LLM แบบโฮสต์เองที่ตอบโดยใช้เอกสารเป็นบริบทโดยไม่ต้องเขียนโค้ดเลย ฝั่งเราใช้ deepseek coder 33b บน Mac Studio RAM 64GB ได้เร็วพอ และให้คำแนะนำที่ค่อนข้างดีโดยอิงจากเอกสารโค้ดภายใน
    • ส่วนตัวผมแนะนำ Ollama วิธีจัดการโมเดลวางมาดีคล้าย Docker และรองรับ API ได้กว้างกว่า
      ยังสามารถผสมหลายโมเดลไว้ในไฟล์โมเดลเดียวได้ด้วย ซึ่งเป็นฟีเจอร์ที่กำลังทดลองอยู่ช่วงนี้ ไม่จำเป็นต้องพึ่งไลบรารีโมเดลของ Ollama เสมอไป จะใช้โมเดลที่ทำเองก็ได้ การรองรับโมเดลใหม่ ๆ เข้ามาผ่าน binding ของ llama.cpp
    • ความเร็วในการพัฒนาของวงการนี้น่าทึ่งจริง ๆ จุดที่ llamafile เปิดใช้งานได้ง่ายนั้นดีมาก แต่ยังขาดอินเทอร์เฟซแชตที่มีฟีเจอร์ครบพอ เลยทำ https://recurse.chat/ ขึ้นมาบนมัน
      งานบางอย่างยังต้องใช้ GPT-4 อยู่ แต่ในการใช้งานประจำวัน มันทดแทนการใช้ ChatGPT ได้ไม่น้อยแล้ว และชอบเป็นพิเศษตรงที่นำเข้าประวัติแชตของ ChatGPT ได้ทั้งหมด อยากรู้เหมือนกันว่าผู้คนอยากทำอะไรกับ AI ในเครื่องบ้าง
    • ผมใช้ Ollama และ Mixtral-7B สำหรับพัฒนาในเครื่องบน MBP อยู่ และพอใจมาก
    • ที่ผ่านมาผมใช้แค่ llamacpp -m -p มาตลอด และใช้ Mixtral 8x7b + CodeLlama 70b บน MacBook เป็นเครื่องมือประจำวันได้ดี อยากรู้ว่าทางเลือกอื่น ๆ ของ Llama.cpp มีฟีเจอร์เด็ดอะไรหรือเปล่า และไม่อยากพลาดกระแสใหม่ ๆ เจ๋ง ๆ

  • ผมเป็นอาจารย์บริหารธุรกิจ และทำคู่มือสำหรับรันบน Google Cloud เพื่อให้นักศึกษาลองใช้ Ollama กับ web-ui[1] ถ้าใช้สปอตอินสแตนซ์จะรันได้ในราคา 18 เซนต์ต่อชั่วโมง
    [1] https://docs.google.com/document/d/1OpZl4P3d0WKH9XtErUZib5_2...

    • ตั้งค่าแบบนี้ นักศึกษาอาจถูกแย่งสิทธิ์ผู้ดูแลระบบและทำให้อินสแตนซ์ถูกยึดได้ ไม่ปลอดภัยอย่างยิ่ง ขอแนะนำอย่างหนักแน่นให้ใช้ SSH key ใน git-bash ซึ่งก็ไม่ได้ยากทางเทคนิคไปกว่าสิ่งที่แนะนำไปแล้ว
    • บน 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 โดยตรงผ่าน binding ของภาษาที่ต้องการนั้นง่ายมาก เลยไม่ได้สำคัญเท่าไร ถ้าต้องการการควบคุมมากขึ้น ก็แค่ทำงานเพิ่มอีกนิด และไม่จำเป็นต้องมีเครื่องมือแบบ plug-and-play แบบนี้เสมอไป

  • ที่ทำงานกำลังสร้างเวอร์ชันที่ดีกว่า Copilot และรองรับวิธีให้ผู้ใช้นำ LLM ของตัวเอง มาใช้ด้วย ช่วงหลังเรากำลังเพิ่ม backend ที่เข้ากันได้กับ OpenAI โดยแค่บอก endpoint ของ API ที่เข้ากันได้กับ OpenAI และให้จัดการเหมือนโมเดลใด เราก็สามารถฟอร์แมต prompt, stop sequence, จำนวน token สูงสุด ฯลฯ ให้ตรงกับ semantics ของโมเดลนั้นได้
    เราต้องการของแบบนี้พอดีเพื่อทดสอบในสภาพแวดล้อมพัฒนาในเครื่อง ถ้า Ollama รองรับสิ่งนี้ การทดสอบ LLM จำนวนมากที่เราต้องรองรับจะง่ายขึ้นมาก เห็นเครื่องมือหลายตัวอย่าง OpenLLM ก็ implement API เดียวกัน ดูเหมือนทุกอย่างกำลังมารวมที่ ความเข้ากันได้กับ OpenAI API

  • ตอนนี้ความรู้สึกของการสร้าง สตาร์ทอัพ AI ดีมากจริง ๆ
    ตอนแรกเคยลำบากกับข้อจำกัดโทเคน แต่ก็แก้ได้แล้ว ปัญหาเอาต์พุต JSON ที่สม่ำเสมอก็แก้ได้แล้ว ปัญหาเรื่อง rate limit และประสิทธิภาพของโมเดลขนาดใหญ่จากบุคคลที่สามก็แก้ได้แล้ว และความต้องการโฮสต์โมเดลโอเพนซอร์สเองเพื่อลดต้นทุนสำหรับงานขนาดเล็กและซับซ้อนปานกลางก็แก้ได้แล้ว
    ทุกครั้งที่มีความก้าวหน้าสำคัญของ LLM ออกมา รู้สึกเหมือนผลิตภัณฑ์จะถูกลง เสถียรขึ้น และขยายระบบได้มากขึ้นโดยอัตโนมัติ แน่นอนว่าต้องมุ่งสร้างความสามารถในการป้องกันตัว และสร้างความแตกต่างในทุกอย่างที่ “ไม่ใช่ AI”

    • สงสัยว่าที่บอกว่าข้อจำกัดโทเคนแก้ได้แล้วหมายความว่าอย่างไร หมายถึง ขีดจำกัดคอนเท็กซ์ ของเวอร์ชันใหม่ ๆ ใหญ่ขึ้นมาก แต่ค่าใช้จ่ายก็แพงขึ้นมากด้วยหรือเปล่า?

  • ถ้าพูดว่าเข้ากันได้กับ OpenAI ก็อาจทำให้เข้าใจผิดได้เล็กน้อย เพราะคนจะคาดหวังไปถึง function calling หรือ tool calling ด้วย
    การมีโครงสร้างบทบาทและเนื้อหานั้นดี แต่จริง ๆ แล้วเดิมทีมันก็เป็นสิ่งที่ทำได้ค่อนข้างง่ายอยู่แล้ว พอไปถึงเอเจนต์ ก็ต้องมีการรันแอ็กชันจริง ในระบบโฮสต์เอเจนต์ที่ผมเริ่มทำ ผมใส่ scripting engine เข้าไปด้วย เลยคิดว่าหลังจากจัดการเรื่องความปลอดภัยและสิทธิ์แล้ว คงควรให้เอเจนต์รันโค้ดไปเลยหรือไม่ อันที่จริงก็เริ่มทำแบบนั้นไปแล้ว
    ดังนั้นจึงยังไม่มั่นใจว่าจำเป็นต้องมี function/tool calling จริง ๆ หรือไม่ แต่ถ้าหลายคนกำลังทำให้ tool calling เป็นมาตรฐาน แม้จะมีการรันสคริปต์ตามอำเภอใจก็ตาม ผมก็อาจต้องใส่มันเข้าไปในเฟรมเวิร์กของตัวเองด้วย

    • ในเอกสารระบุฟีเจอร์ที่ถูกตัดออกไว้อย่างชัดเจน: https://github.com/ollama/ollama/blob/main/docs/openai.md
      function calling/tool selection ถูกจัดการในระดับแอปพลิเคชัน และตอนนี้ยังไม่มีรูปแบบมาตรฐาน สิ่งที่ใช้กันแพร่หลายจริง ๆ ก็แทบจะเป็น system prompt แบบปรับแต่งเองที่ไม่มีประสิทธิภาพ: https://github.com/langchain-ai/langchain/blob/master/libs/l...
    • Gemini Pro รองรับ function/tool calling เลยดูน่าสนใจ แต่ในทางปฏิบัติทำงานได้แย่มาก ยังไม่ได้ลอง Gemini Ultra และก็ไม่ชัดเจนว่าทำผ่าน API ได้หรือไม่
      ไม่ว่าจะอย่างไร การไม่ปล่อยการรองรับที่ใช้งานไม่ได้ออกมาอาจจะดีกว่า
    • สำหรับคนที่เคยใช้ OpenAI API นี่เป็นตัวเลือกที่เข้าใจได้แน่นอน

  • อนึ่ง สคริปต์ติดตั้ง Linux ของ Ollama ทำงานด้วยวิธี “มาตรฐาน” ที่พบได้ทั่วไปในเครื่องมือยุคนี้:
    curl https://ollama.ai/install.sh | sh
    อย่างไรก็ตาม ตอนที่ตรวจสอบล่าสุด สคริปต์นี้ต้องการ สิทธิ์ root ผ่าน sudo หากต้องการใช้เครื่องมือนี้ แนะนำให้ดาวน์โหลดสคริปต์มาตรวจดู หรือแก้ไขให้เหมาะกับความต้องการก่อน

    • มีคำแนะนำสำหรับการติดตั้งแบบแมนนวล[0] จากที่ดูเหมือนจะตั้งค่า บริการ SystemD ให้รันอัตโนมัติเมื่อเริ่มระบบ หากเพียงต้องการทดลองใช้งาน การดาวน์โหลด [1] แล้วทำให้รันได้ (chmod +x ollama-linux-amd64) จากนั้นเรียกใช้งานก็เพียงพอแล้ว และไม่จำเป็นต้องมีสิทธิ์ root
      [0] https://github.com/ollama/ollama/blob/main/docs/linux.md#man...
      [1] https://ollama.ai/download/ollama-linux-amd64
    • ไบนารี ollama จะถูกวางไว้ใน /usr/bin ซึ่งไม่จำเป็นต้องเป็นแบบนั้นเสมอไป แต่ก็สะดวกดี ส่วนอย่างอื่นที่ต้องใช้สิทธิ์ root ยังไม่ได้ตรวจสอบ
    • ยุคนี้มี แพ็กเกจเมเนเจอร์ อยู่แล้ว

  • เลเยอร์ความเข้ากันได้สามารถทำไว้ในไลบรารีก็ได้ ตัวอย่างเช่น llm() ของ LangChain สามารถทำงานกับแบ็กเอนด์ LLM หลายแบบได้ อยากรู้ว่าชอบแบบไหนมากกว่า

    • ส่วนตัวชอบให้อยู่ในไลบรารี แต่ตอนนี้ยังมีปัญหาอยู่พอสมควร ปัญหาใหญ่ที่สุดคืออีโคซิสเต็มเคลื่อนที่เร็วเกินไปจน library wrapper ตามไม่ทัน
      อีกอย่างคือถ้าโลกไปสร้างมาตรฐานบนไลบรารีแย่ ๆ อย่าง LangChain ผู้เล่นที่มาทีหลังจะตายและถูกผูกติดอยู่นานเพราะต้นทุนการบำรุงรักษาแบ็กเอนด์ที่ไม่สม่ำเสมอ ดังนั้นตอนนี้ API ที่สม่ำเสมอดูเหมือนเป็นตัวเลือกที่ดีกว่าในแง่ความสะดวก
    • ถ้าทำแบบนั้น แต่ละไลบรารีก็ต้องรองรับ LLM แต่ละตัว ผมมองว่านี่เป็นปัญหาเดียวกับ object storage ที่สุดท้ายแทบทุกเจ้าต้องรองรับ S3-compatible API
      การมี API มาตรฐานนั้นดี แม้จะไม่สมบูรณ์แบบก็ตาม ขณะเดียวกัน จะมี API ที่สองแบบ Backblaze B2 ที่ช่วยใช้ศักยภาพทั้งหมดได้ก็ไม่เป็นไร ไม่มีวิธีเดียวที่เหมาะกับทุกโมเดล และถ้าโมเดลมีความสามารถต่างกัน ผมคิดว่าการให้ทั้งสองตัวเลือกเป็นเรื่องดี
    • ก่อนที่ OpenAI จะออกแอป ผมใช้ LangChain ในระบบที่ทำเอง มันเป็น อินเทอร์เฟซ SMS ที่เรียบง่ายมากสำหรับ LLM และผมชอบทำงานผ่าน abstraction ของ LangChain มากกว่าการชนกับ GPT-4 API โดยตรง

  • กำลังทำโปรเจกต์ที่ช่วยให้สลับใช้โมเดลโอเพนซอร์ส (ผ่าน HF, VLLM) และโมเดลเชิงพาณิชย์ (OpenAI, Google, Anthropic, Together) ใน Python ได้ง่าย: https://github.com/datadreamer-dev/DataDreamer
    ถ้าอยากใช้ โดยตรงใน Python โดยไม่ผ่าน HTTP API นี่เป็นวิธีที่ง่ายกว่าเล็กน้อย

  • สงสัยว่า Ollama ใช้ทำอะไร ทำไมถึงไม่ใช้ llama.cpp โดยตรง?

    • มันเหมือน Docker/แพ็กเกจเมเนเจอร์สำหรับ LLM ติดตั้ง ค้นหาโมเดลใหม่ และอัปเดตได้ง่ายด้วย CLI ที่เป็นมาตรฐานและเรียบง่าย การอัปเดตอัตโนมัติก็ทำได้แบบไม่ต้องกังวล
    • มีคำถามเดียวกัน ดูเหมือน Ollama จะถูกโปรโมตเยอะและได้รับการตอบรับดี แต่ทุกวันนี้เมื่อเทียบกับการใช้ llama.cpp โดยตรง ซึ่งมีเซิร์ฟเวอร์ในตัวที่เข้ากันได้กับ OpenAI อยู่แล้ว อยากรู้ว่ามีข้อดีอะไรแน่ ๆ