สรุปย่อ
AI ภายในเครื่องทำงานบนฮาร์ดแวร์ของคุณ ไม่มีค่าใช้จ่ายต่อคำขอ และรักษาข้อมูลให้เป็นส่วนตัว AI ที่ใช้ API เริ่มต้นได้เร็วกว่า มีความสามารถมากกว่า และปรับขนาดได้โดยไม่ต้องมีโครงสร้างพื้นฐาน ทีมส่วนใหญ่ต้องการทั้งสองอย่าง คู่มือนี้จะกล่าวถึงว่าแต่ละแนวทางมีข้อดีเมื่อใด พร้อมตัวเลขที่เป็นรูปธรรม
บทนำ
Gemma 4 ทำงานบน iPhone โดยตรง ส่วนขยายเบราว์เซอร์ที่ฝังโมเดลภาษาเต็มรูปแบบโดยไม่ต้องใช้ API key สิ่งเหล่านี้เป็นไปไม่ได้เมื่อ 18 เดือนที่แล้ว แต่วันนี้กลับมีให้เห็นบน HackerNews
การตัดสินใจเคยง่าย: โมเดลล้ำสมัยใช้ได้เฉพาะ API เท่านั้น ส่วนที่เหลืออ่อนแอเกินกว่าจะนำมาพิจารณาได้ นั่นเปลี่ยนไปแล้ว โมเดลภายในเครื่องเช่น Qwen2.5-72B, Gemma 4 และ DeepSeek-V3 ตอนนี้สามารถแข่งขันได้จริงบนเกณฑ์มาตรฐาน นักพัฒนาที่เคยใช้ API ของ OpenAI เป็นค่าเริ่มต้นกำลังพิจารณาใหม่ โดยเฉพาะอย่างยิ่งสำหรับแอปพลิเคชันที่คำนึงถึงความเป็นส่วนตัว หรืองานที่มีปริมาณมากซึ่งค่าใช้จ่ายต่อโทเค็นสะสมอย่างรวดเร็ว
บทความนี้จะเจาะลึกถึงข้อมูลจริง คุณจะได้รับตัวเลขที่ชัดเจนเกี่ยวกับต้นทุน เวลาแฝง และความสามารถ เพื่อให้คุณตัดสินใจได้อย่างถูกต้องสำหรับกรณีการใช้งานของคุณ
/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 และโค้ดของคุณจะไม่เปลี่ยนแปลง
