AI Model รันบนเครื่อง vs. API: เลือกแบบไหนดี

Ashley Innocent

Ashley Innocent

16 April 2026

AI Model รันบนเครื่อง vs. API: เลือกแบบไหนดี

สรุปย่อ

AI ภายในเครื่องทำงานบนฮาร์ดแวร์ของคุณ ไม่มีค่าใช้จ่ายต่อคำขอ และรักษาข้อมูลให้เป็นส่วนตัว AI ที่ใช้ API เริ่มต้นได้เร็วกว่า มีความสามารถมากกว่า และปรับขนาดได้โดยไม่ต้องมีโครงสร้างพื้นฐาน ทีมส่วนใหญ่ต้องการทั้งสองอย่าง คู่มือนี้จะกล่าวถึงว่าแต่ละแนวทางมีข้อดีเมื่อใด พร้อมตัวเลขที่เป็นรูปธรรม

บทนำ

Gemma 4 ทำงานบน iPhone โดยตรง ส่วนขยายเบราว์เซอร์ที่ฝังโมเดลภาษาเต็มรูปแบบโดยไม่ต้องใช้ API key สิ่งเหล่านี้เป็นไปไม่ได้เมื่อ 18 เดือนที่แล้ว แต่วันนี้กลับมีให้เห็นบน HackerNews

การตัดสินใจเคยง่าย: โมเดลล้ำสมัยใช้ได้เฉพาะ API เท่านั้น ส่วนที่เหลืออ่อนแอเกินกว่าจะนำมาพิจารณาได้ นั่นเปลี่ยนไปแล้ว โมเดลภายในเครื่องเช่น Qwen2.5-72B, Gemma 4 และ DeepSeek-V3 ตอนนี้สามารถแข่งขันได้จริงบนเกณฑ์มาตรฐาน นักพัฒนาที่เคยใช้ API ของ OpenAI เป็นค่าเริ่มต้นกำลังพิจารณาใหม่ โดยเฉพาะอย่างยิ่งสำหรับแอปพลิเคชันที่คำนึงถึงความเป็นส่วนตัว หรืองานที่มีปริมาณมากซึ่งค่าใช้จ่ายต่อโทเค็นสะสมอย่างรวดเร็ว

บทความนี้จะเจาะลึกถึงข้อมูลจริง คุณจะได้รับตัวเลขที่ชัดเจนเกี่ยวกับต้นทุน เวลาแฝง และความสามารถ เพื่อให้คุณตัดสินใจได้อย่างถูกต้องสำหรับกรณีการใช้งานของคุณ

💡
หากคุณกำลังทดสอบการผสานรวม AI API ไม่ว่าโมเดลจะเป็นแบบภายในเครื่องหรือบนคลาวด์ ฟังก์ชัน Test Scenarios ของ Apidog ก็สามารถใช้งานได้ทั้งสองแบบ คุณสามารถชี้ไปที่ local llama-server endpoint หรือที่ /v1/chat/completions ของ OpenAI และเรียกใช้การยืนยันเดียวกันได้ รายละเอียดเพิ่มเติมจะกล่าวถึงภายหลัง ดู [internal: api-testing-tutorial] สำหรับแนวทางการทดสอบพื้นฐาน
ปุ่ม

การ "รัน AI ภายในเครื่อง" หมายถึงอะไรกันแน่

AI ภายในเครื่องไม่ใช่สิ่งเดียว แต่มีสามรูปแบบที่แตกต่างกัน:

การอนุมานบนอุปกรณ์ (On-device inference): โมเดลทำงานทั้งหมดบนอุปกรณ์ โดยไม่มีเซิร์ฟเวอร์ เช่น Gemma Gem ในแท็บเบราว์เซอร์, Gemma 4 บน Neural Engine ของ iPhone หรือโมเดล Ollama บน MacBook ของคุณ ไม่ต้องใช้อินเทอร์เน็ตหลังจากดาวน์โหลด

เซิร์ฟเวอร์แบบโฮสต์เอง (Self-hosted server): คุณรันโมเดลบนฮาร์ดแวร์ของคุณเอง (เวิร์คสเตชัน, คลาวด์ VM ที่คุณควบคุม หรือเซิร์ฟเวอร์ภายในองค์กร) และเปิดเผย API โมเดลไม่ได้ทำงานบนอุปกรณ์ของผู้ใช้ปลายทาง แต่ก็ไม่ได้อยู่ที่ OpenAI ด้วยเช่นกัน เครื่องมืออย่าง llama-server, Ollama และ vLLM จัดการเรื่องนี้

คลาวด์ส่วนตัว (Private cloud): คุณปรับใช้โมเดลบนโครงสร้างพื้นฐานคลาวด์ของคุณเอง (โมเดลที่กำหนดเองของ AWS Bedrock, private endpoints ของ Azure, โมเดลที่กำหนดเองของ GCP Vertex AI) ควบคุมได้มากกว่า API สาธารณะ และยุ่งยากน้อยกว่าการโฮสต์เองทั้งหมด

การเปรียบเทียบในบทความนี้มุ่งเน้นไปที่การโฮสต์เองเทียบกับ API สาธารณะ เนื่องจากเป็นการตัดสินใจที่นักพัฒนาส่วนใหญ่ต้องเผชิญ

การเปรียบเทียบต้นทุน

นี่คือจุดที่ AI ภายในเครื่องชนะอย่างชัดเจนสำหรับงานที่มีปริมาณมาก

ราคา API สาธารณะ (เมษายน 2026):

โมเดล อินพุต (ต่อ 1 ล้านโทเค็น) เอาต์พุต (ต่อ 1 ล้านโทเค็น)
GPT-4o $2.50 $10.00
Claude 3.5 Sonnet $3.00 $15.00
Gemini 1.5 Pro $1.25 $5.00
GPT-4o mini $0.15 $0.60
Claude 3 Haiku $0.25 $1.25

ประมาณการต้นทุนการโฮสต์เอง (Qwen2.5-72B บน A100 80GB หนึ่งตัว):

A100 80GB จาก Lambda Labs มีค่าใช้จ่ายประมาณ 1.99 ดอลลาร์สหรัฐฯ ต่อชั่วโมงแบบ On-demand Qwen2.5-72B ที่การควอนไทซ์แบบ INT4 สามารถใส่ใน A100 หนึ่งตัวและให้บริการประมาณ 200 โทเค็นต่อวินาที

ที่ 200 โทเค็นต่อวินาทีพร้อมการใช้งาน 100% จะเท่ากับ 720,000 โทเค็นต่อชั่วโมง หรือประมาณ 0.0028 ดอลลาร์สหรัฐฯ ต่อ 1,000 โทเค็นทั้งหมด (อินพุต + เอาต์พุต) สำหรับการเปรียบเทียบ GPT-4o คิดค่าบริการ 0.01 ดอลลาร์สหรัฐฯ ต่อ 1,000 โทเค็นสำหรับเอาต์พุตเพียงอย่างเดียว

จุดคุ้มทุน (Break-even point): หากคุณประมวลผลเอาต์พุตมากกว่า ~70,000 โทเค็นต่อวันอย่างสม่ำเสมอ การโฮสต์เองจะประหยัดกว่า GPT-4o ในด้านต้นทุน หากน้อยกว่านั้น API จะได้เปรียบเนื่องจากคุณไม่ต้องจ่ายเงินสำหรับเวลา GPU ที่ไม่ได้ใช้งาน

สำหรับโมเดลที่เบากว่า: Gemma 4 (12B) แบบควอนไทซ์ 4 บิต สามารถทำงานบน RTX 4090 หนึ่งตัว (600-800 ดอลลาร์สหรัฐฯ มือสอง) ที่ 0.40 ดอลลาร์สหรัฐฯ ต่อชั่วโมงสำหรับเวลา GPU บนคลาวด์ที่เทียบเท่า การโฮสต์เองจะถึงจุดคุ้มทุนเมื่อเทียบกับ GPT-4o mini ที่ประมาณ 15,000 โทเค็นเอาต์พุตต่อวัน

การเปรียบเทียบเวลาแฝง

นี่คือจุดที่ความละเอียดอ่อนมากขึ้น

เวลาในการได้โทเค็นแรก (Time to first token - TTFT): บน A100 โดยเฉพาะ TTFT สำหรับข้อความพร้อมท์ 1,000 โทเค็นด้วยโมเดล 72B จะอยู่ที่ประมาณ 800ms-1.5s โดยทั่วไป API ของ OpenAI จะส่งคืนโทเค็นแรกภายใน 300-800ms สำหรับอินพุตที่คล้ายกันภายใต้โหลดปกติ

สำหรับการอนุมานบนอุปกรณ์ (iPhone Neural Engine, Apple Silicon) TTFT สำหรับ Gemma 4 อยู่ที่ 200-400ms เนื่องจากไม่มีค่าใช้จ่ายเครือข่ายเลย นี่คือจุดที่อุปกรณ์ชนะอย่างชัดเจน

ปริมาณงาน (Throughput): A100 หนึ่งตัวที่รันโมเดล 72B ที่ INT4 ให้บริการผู้ใช้รายเดียวได้ดี แต่จะลดลงภายใต้โหลดพร้อมกันหากไม่มีการแบตช์ API สาธารณะจัดการการประมวลผลพร้อมกันได้อย่างโปร่งใส

การสตรีม (Streaming): ทั้งสองแนวทางรองรับการสตรีม สำหรับโมเดลบนอุปกรณ์ การสร้างทั้งหมดจะเกิดขึ้นในเครื่อง จึงไม่มีความล่าช้าของเครือข่าย สำหรับโมเดล API คุณต้องพึ่งพาสภาพเครือข่าย

สรุป: อุปกรณ์ชนะเลิศสำหรับเวลาแฝงต่ำสุด (ไม่มีเครือข่าย) โฮสต์เองชนะเลิศสำหรับปริมาณงานที่ปรับขนาดได้ (ด้วยการแบตช์ที่เหมาะสมผ่าน vLLM) API สาธารณะชนะเลิศสำหรับความสามารถในการรองรับโหลดสูงสุดและความเรียบง่าย

การเปรียบเทียบความสามารถ

นี่คือจุดที่ API สาธารณะยังคงได้เปรียบสำหรับงานที่ต้องการความสามารถสูงส่วนใหญ่

การให้เหตุผลและงานที่ซับซ้อน: GPT-4o และ Claude 3.5 Sonnet ยังคงนำหน้าโมเดลแบบ open-weight ใน MMLU, HumanEval และการให้เหตุผลแบบหลายขั้นตอนที่ซับซ้อน ช่องว่างแคบลงอย่างมีนัยสำคัญด้วย Qwen2.5-72B และ DeepSeek-V3 แต่ก็ยังคงมีอยู่จริง

การสร้างโค้ด: ใกล้เคียงกัน DeepSeek-Coder-V2 และ Qwen2.5-Coder-32B มีประสิทธิภาพเทียบเท่า GPT-4o ในเกณฑ์มาตรฐานโค้ดหลายรายการ สำหรับงานที่เกี่ยวข้องกับโค้ดโดยเฉพาะในการตั้งค่าแบบโฮสต์เอง คุณสามารถใช้โมเดลโค้ดเฉพาะทางแทนโมเดลทั่วไปได้

ความยาวของบริบท (Context length): โมเดล API ชั้นนำรองรับบริบท 128K-1M โทเค็น โมเดลที่โฮสต์เองส่วนใหญ่สูงสุดอยู่ที่ 32K-128K ในทางปฏิบัติ (บริบทที่ยาวขึ้นต้องการหน่วยความจำที่มากขึ้นตามสัดส่วน)

มัลติโมดอล (Multimodal): GPT-4o และ Gemini 1.5 Pro สามารถจัดการอินพุตที่เป็นรูปภาพ เสียง และวิดีโอได้ โมเดลมัลติโมดอลแบบ open-weight ก็มีอยู่ (LLaVA, Qwen-VL) แต่ยังตามหลังอยู่

การเรียกใช้ฟังก์ชัน / การใช้เครื่องมือ (Function calling / tool use): OpenAI และ Anthropic มีการสนับสนุนการใช้เครื่องมือที่น่าเชื่อถือที่สุด โมเดลแบบ open-weight ที่มีการใช้เครื่องมือสามารถทำงานได้ แต่มีความสอดคล้องน้อยกว่าในสายโซ่เครื่องมือที่ซับซ้อน ดู [internal: how-ai-agent-memory-works] สำหรับข้อมูลว่าสิ่งนี้ส่งผลต่อสถาปัตยกรรมเอเจนต์อย่างไร

ความเป็นส่วนตัวและการควบคุมข้อมูล

นี่คือจุดที่ภายในเครื่องชนะโดยไร้ข้อโต้แย้ง

เมื่อใช้ API สาธารณะ: - ข้อความพร้อมท์ของคุณจะออกจากเครือข่ายของคุณ - นโยบายการเก็บรักษาข้อมูลของผู้ให้บริการมีผลบังคับใช้ (OpenAI เก็บอินพุตไว้ 30 วันตามค่าเริ่มต้น เว้นแต่คุณจะยกเลิกผ่าน API) - คุณต้องอยู่ภายใต้เงื่อนไขการให้บริการของผู้ให้บริการเกี่ยวกับเนื้อหาที่ละเอียดอ่อน - ในอุตสาหกรรมที่มีการควบคุม (การดูแลสุขภาพ, การเงิน, กฎหมาย) สิ่งนี้อาจเป็นอุปสรรคในการปฏิบัติตามข้อกำหนด

เมื่อใช้โมเดลที่โฮสต์เอง: - ข้อความพร้อมท์จะอยู่ในโครงสร้างพื้นฐานของคุณ - ไม่มีการเก็บรักษาข้อมูลโดยบุคคลที่สาม - ควบคุมได้อย่างเต็มที่ว่าโมเดลสามารถและไม่สามารถประมวลผลอะไรได้บ้าง - การปฏิบัติตาม GDPR/HIPAA ทำได้ง่ายขึ้น

สำหรับแอปพลิเคชันที่จัดการข้อมูลสุขภาพส่วนบุคคล เอกสารทางกฎหมาย หรือโค้ดที่เป็นกรรมสิทธิ์ การโฮสต์เองมักจะไม่ใช่ทางเลือกเสริม

วิธีทดสอบการผสานรวม AI ไม่ว่าโมเดลจะทำงานที่ใดก็ตาม

ไม่ว่าคุณจะเรียกใช้ https://api.openai.com/v1/chat/completions หรือ http://localhost:11434/api/chat (Ollama) หรือ http://localhost:8080/v1/chat/completions (llama-server) พื้นผิว API นั้นเข้ากันได้กับ OpenAI สิ่งนี้สำคัญเพราะ Test Scenarios ของ Apidog สามารถทำงานกับ HTTP endpoint ใดก็ได้

Test Scenario เพียงหนึ่งเดียวสามารถรันได้ทั้งสองแบบ:

{
  "scenario": "Chat completion smoke test",
  "environments": {
    "local": {"base_url": "http://localhost:11434"},
    "production": {"base_url": "https://api.openai.com"}
  },
  "steps": [
    {
      "name": "Basic completion",
      "method": "POST",
      "url": "{{base_url}}/v1/chat/completions",
      "body": {
        "model": "{{model_name}}",
        "messages": [{"role": "user", "content": "Say 'test passed' and nothing else"}],
        "max_tokens": 20
      },
      "assertions": [
        {"field": "status", "operator": "equals", "value": 200},
        {"field": "response.choices[0].message.content", "operator": "contains", "value": "test passed"},
        {"field": "response.usage.total_tokens", "operator": "less_than", "value": 50}
      ]
    }
  ]
}

รัน scenario นี้กับ Ollama instance ภายในเครื่องของคุณระหว่างการพัฒนา และกับ OpenAI API ใน CI หากโค้ดของคุณทำงานกับโมเดลภายในเครื่องได้ ก็ควรจะทำงานกับ API ได้เช่นกัน หากไม่ได้ ความแตกต่างมักจะอยู่ที่: - รูปแบบชื่อโมเดล (Ollama ใช้ qwen2.5:72b, OpenAI ใช้ gpt-4o) - โครงสร้างการตอบสนองของการเรียกใช้ฟังก์ชัน (ความแตกต่างเล็กน้อยระหว่างผู้ให้บริการ) - รูปแบบเหตุการณ์การสตรีม (data vs. delta vs. full response objects)

Smart Mock ของ Apidog มีประโยชน์สำหรับการจำลองพฤติกรรมโมเดลภายในเครื่องใน CI โดยไม่จำเป็นต้องมี GPU ออนไลน์ กำหนดค่า mock ที่ส่งคืนการตอบสนองที่เข้ากันได้กับ OpenAI และรัน Test Scenarios ของคุณกับมัน ดู [internal: how-to-build-tiny-llm-from-scratch] สำหรับข้อมูลเบื้องหลังว่าทำไมโครงสร้างการตอบสนองจึงแตกต่างกันในระดับโมเดล

การตั้งค่าเซิร์ฟเวอร์โมเดลภายในเครื่องใน 10 นาที

หากคุณต้องการลองใช้แบบโฮสต์เองก่อนที่จะตัดสินใจ Ollama คือทางที่เร็วที่สุด:

# Install Ollama
curl -fsSL https://ollama.com/install.sh | sh

# Pull a model (Gemma 4 12B, fits in 10GB VRAM)
ollama pull gemma4:12b

# Start the server (OpenAI-compatible API on port 11434)
ollama serve

# Test it
curl http://localhost:11434/v1/chat/completions \
  -H "Content-Type: application/json" \
  -d '{
    "model": "gemma4:12b",
    "messages": [{"role": "user", "content": "Hello"}]
  }'

สำหรับการโฮสต์เองเพื่อใช้งานจริงที่รองรับผู้ใช้พร้อมกันหลายคน vLLM เป็นทางเลือกที่ดีกว่า:

pip install vllm
python -m vllm.entrypoints.openai.api_server \
  --model Qwen/Qwen2.5-72B-Instruct-AWQ \
  --quantization awq \
  --max-model-len 32768

สิ่งนี้จะเปิดเผย OpenAI-compatible API บนพอร์ต 8000 ชี้ Apidog ไปที่ http://your-server:8000 และรัน Test Scenarios ของคุณได้โดยตรง

ควรเลือกใช้แนวทางใดเมื่อไหร่

สถานการณ์ ภายในเครื่อง API
การประมวลผลแบบแบตช์ปริมาณมาก (>100K โทเค็น/วัน) ถูกกว่า แพง
ข้อมูลที่ละเอียดอ่อนด้านความเป็นส่วนตัว (สุขภาพ, กฎหมาย, การเงิน) จำเป็น เสี่ยง
เวลาแฝงต่ำสุดบนอุปกรณ์ ดีที่สุด เป็นไปไม่ได้
ต้องการความสามารถของโมเดลล้ำสมัย ไม่เพียงพอ จำเป็น
ปริมาณงานที่มาเป็นระลอกพร้อมทราฟฟิกที่ผันผวน ซับซ้อนในการปรับขนาด จัดการได้อัตโนมัติ
ไม่มี GPU ให้ใช้งาน ยาก ง่าย
สภาพแวดล้อมการพัฒนา/ทดสอบ ดีเยี่ยม (Ollama) มีค่าใช้จ่าย
งานมัลติโมดอล จำกัด รองรับเต็มที่
การปฏิบัติตามกฎระเบียบของอุตสาหกรรม ง่ายกว่า ต้องใช้ DPA

คำตอบที่ซื่อสัตย์สำหรับทีมส่วนใหญ่: ใช้ public API สำหรับการใช้งานจริง (Claude หรือ GPT-4o สำหรับงานที่เน้นคุณภาพ, Haiku หรือ 4o-mini สำหรับงานปริมาณมากและราคาถูกกว่า) และ Ollama ในเครื่องสำหรับการพัฒนาและทดสอบ สิ่งนี้จะช่วยให้คุณได้ประโยชน์จากทั้งสองอย่าง: คุณภาพระดับแนวหน้าในการใช้งานจริง ไม่มีค่าใช้จ่ายในการพัฒนา และพื้นผิว API ที่เข้ากันได้กับ OpenAI อย่างสม่ำเสมอในทุกส่วน

ดู [internal: open-source-coding-assistants-2026] สำหรับข้อมูลว่าผู้ช่วยเขียนโค้ดแบบโอเพนซอร์สเข้ากับภาพรวมของ AI ภายในเครื่องได้อย่างไร

บทสรุป

การตัดสินใจเลือกระหว่าง AI ภายในเครื่องกับ API ไม่ใช่เรื่องขาวดำ คำตอบที่ถูกต้องขึ้นอยู่กับปริมาณงาน ข้อกำหนดด้านความเป็นส่วนตัว ความต้องการด้านเวลาแฝง และระดับความสามารถที่คุณต้องการ

สำหรับนักพัฒนาส่วนใหญ่ที่สร้างแอปพลิเคชันที่ขับเคลื่อนด้วย AI: เริ่มต้นด้วย public API ย้ายไปใช้แบบโฮสต์เองเมื่อค่าใช้จ่ายรายเดือนของคุณเกิน 200-300 ดอลลาร์สหรัฐฯ และใช้ Ollama ในสภาพแวดล้อมภายในเครื่องของคุณตั้งแต่วันแรก ทำให้โค้ดของคุณไม่ขึ้นกับผู้ให้บริการโดยใช้พื้นผิว API ที่เข้ากันได้กับ OpenAI ทุกที่

ทดสอบสภาพแวดล้อมทั้งสองอย่างสม่ำเสมอด้วย Apidog เพื่อตรวจจับความแตกต่างเล็กน้อยระหว่างพฤติกรรมโมเดลภายในเครื่องและโมเดลบนคลาวด์ก่อนที่จะกลายเป็นข้อผิดพลาดในการผลิต

ปุ่ม

คำถามที่พบบ่อย

GPU ขั้นต่ำที่จำเป็นในการรันโมเดลภายในเครื่องที่มีประโยชน์คืออะไร? RTX 3060 (VRAM 12GB) สามารถรัน Qwen2.5-7B หรือ Gemma 4 4B ได้ที่คุณภาพเต็มที่ RTX 4090 (VRAM 24GB) สามารถจัดการโมเดล 14B-20B ส่วนใหญ่ที่การควอนไทซ์ INT4 และโมเดล 34B ที่ INT2 สำหรับโมเดล 72B คุณต้องใช้ GPU 24GB สองตัว หรือ A100/H100 หนึ่งตัว

ฉันสามารถรัน AI ภายในเครื่องบน Apple Silicon ได้หรือไม่? ได้ Ollama รองรับ Apple Silicon โดยตรงและใช้ Neural Engine ในการเร่งความเร็ว M3 Pro (หน่วยความจำรวม 18GB) สามารถรัน Qwen2.5-14B ได้อย่างสบาย M4 Max (128GB) สามารถจัดการโมเดล 70B ได้

คุณภาพเอาต์พุตของโมเดลภายในเครื่องดีพอสำหรับการใช้งานจริงหรือไม่? ขึ้นอยู่กับงาน สำหรับการสร้างโค้ด การสรุป และการแยกข้อมูลที่มีโครงสร้าง: ใช่ หากใช้โมเดล 32B+ สำหรับการให้เหตุผลที่ซับซ้อน การเขียนที่ละเอียดอ่อน หรืองานที่ต้องการความรู้รอบด้าน: โมเดล API ชั้นนำยังคงได้เปรียบอย่างชัดเจน

โมเดลภายในเครื่องรองรับการเรียกใช้ฟังก์ชันหรือไม่? รองรับ แต่ไม่สม่ำเสมอ Llama 3.1, Qwen2.5 และ Mistral ล้วนรองรับการใช้เครื่องมือ ความน่าเชื่อถือจะต่ำกว่า GPT-4o หรือ Claude 3.5 Sonnet ในสายโซ่เครื่องมือที่ซับซ้อน ทดสอบอย่างละเอียดด้วย Apidog Test Scenarios ก่อนที่จะพึ่งพาการใช้เครื่องมือของโมเดลภายในเครื่องในการใช้งานจริง ดู [internal: claude-code] สำหรับข้อมูลว่าโมเดลชั้นนำจัดการการใช้เครื่องมือในบริบทการเขียนโค้ดอย่างไร

การโฮสต์โมเดล 70B บน AWS มีค่าใช้จ่ายเท่าไหร่? p4d.24xlarge (8x A100 40GB) มีค่าใช้จ่าย 32.77 ดอลลาร์สหรัฐฯ ต่อชั่วโมงแบบ On-demand รันโมเดล 70B INT8 ได้ด้วยปริมาณงานสูง g5.2xlarge (1x A10G 24GB) ที่ 1.21 ดอลลาร์สหรัฐฯ ต่อชั่วโมง รันโมเดล 14B INT4 สำหรับงานที่เบากว่า การใช้ Reserved instances ช่วยลดค่าใช้จ่ายเหล่านี้ได้ 30-40%

Ollama กับ llama.cpp แตกต่างกันอย่างไร? llama.cpp คือเอนจิ้นการอนุมานที่อยู่เบื้องหลัง Ollama ห่อหุ้ม llama.cpp ด้วย REST API, การจัดการโมเดล (ดึง, รายการ, ลบ) และ CLI แบบง่าย ใช้ Ollama สำหรับการพัฒนา ใช้ llama.cpp โดยตรง (ผ่าน llama-server) หากคุณต้องการควบคุมรูปแบบการควอนไทซ์หรือการกำหนดค่าฮาร์ดแวร์ได้มากขึ้น

ฉันสามารถสลับระหว่างโมเดลภายในเครื่องและโมเดล API โดยไม่ต้องเปลี่ยนโค้ดได้หรือไม่? ได้ หากคุณใช้ไคลเอ็นต์ที่เข้ากันได้กับ OpenAI ใน Python: openai.OpenAI(base_url='http://localhost:11434/v1', api_key='ollama') เชื่อมต่อกับ Ollama เปลี่ยน base_url เป็น https://api.openai.com/v1 และอัปเดต api_key เพื่อเปลี่ยนไปใช้คลาวด์ กำหนดค่าเหล่านี้ผ่าน environment variables และโค้ดของคุณจะไม่เปลี่ยนแปลง

ฝึกการออกแบบ API แบบ Design-first ใน Apidog

ค้นพบวิธีที่ง่ายขึ้นในการสร้างและใช้ API