การ self-host LLM แบบ open-weight vs API การคำนวณต้นทุนจริง

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

คำถามเรื่องต้นทุนการ self-host LLM มีคำตอบ แต่มันไม่ใช่ตัวเลขเดียวที่ผลการค้นหาอันดับต้นและ AI Overviews พูดซ้ำอยู่เรื่อยๆ มันขึ้นอยู่กับสามสิ่งที่บทความเหล่านั้นทำให้แบนราบ นั่นคือ คุณกำลังเทียบกับ API ตัวไหน GPU ของคุณยุ่งแค่ไหน และต้นทุน ops ที่ไม่มีใครใส่ในสเปรดชีต

นี่คือเวอร์ชันสั้นก่อนรายละเอียด สำหรับ solo builder ส่วนใหญ่ การ self-host ไม่ได้ชนะเรื่องต้นทุนในตอนนี้ แต่มีเส้นเฉพาะที่มันพลิก และคุณคำนวณมันบนบิลของคุณเองได้ในราวสองนาที ด้านล่างคือการคำนวณของปี 2026 (ราคาปัจจุบัน ตัวเลข VRAM ตามโมเดล และสูตรที่คุณรันได้)

เวอร์ชันสั้น

• จุดคุ้มทุนไม่ใช่ตัวเลขเดียว มันคือสามตัว ขึ้นอยู่กับว่าคุณกำลังเทียบกับ API ตัวไหน เทียบกับ API ระดับแนวหน้า (GPT-5.x, Claude Sonnet 5 / Opus 4.8, Gemini Pro) การ self-host คุ้มทุนเร็วที่สุด เทียบกับ API แบบ open-weight ราคาประหยัด (DeepSeek, DeepInfra, Together ที่ราวๆ $0.14–$0.50 ต่อล้านโทเคน) มันแทบไม่เคยชนะเรื่องต้นทุนเพียงอย่างเดียว
• Utilization คือตัวคูณที่ฆ่ากรณี solo GPU ที่เช่ามีต้นทุนเท่ากันตอนไม่ทำงานกับตอนทำงานเต็มที่ ดังนั้น GPU ที่รันที่ utilization 10% มีต้นทุนต่อโทเคนราวๆ 10× ของตอนทำงานเต็มที่ เวิร์กโหลด solo ที่เป็นกระจุกๆ นั่งอยู่ที่ utilization ต่ำโดยค่าเริ่มต้น
• ต่ำกว่าจุดคุ้มทุน การชนะเรื่องต้นทุนมักคือการเปลี่ยนไปใช้ API แบบ open-weight ราคาประหยัด ไม่ใช่การ self-host การ self-host คุ้มค่าเมื่อปริมาณที่ต่อเนื่องเทียบกับราคาระดับแนวหน้าผ่านเส้นที่ utilization 60%+ หรือเมื่อคุณมีเหตุผลที่ไม่ใช่เรื่องต้นทุน (ความเป็นส่วนตัว latency การควบคุม fine-tuning)
• รันสูตรบนตัวเลขของคุณเองก่อนที่คุณจะเช่าอะไร โทเคนจุดคุ้มทุน ≈ ต้นทุน GPU VPS รายเดือน ÷ ราคา API เฉลี่ยต่อโทเคนของคุณ

สิ่งที่บทความนี้ไม่ครอบคลุม

• คลัสเตอร์ GPU แบบหลายโหนดหรือระดับดาต้าเซ็นเตอร์ นี่คือการตัดสินใจเรื่องต้นทุนแบบ solo ไม่ใช่ฟลีต
• เศรษฐศาสตร์ของ fine-tuning ในเชิงลึก (การคำนวณแยกต่างหากที่มีข้อแลกเปลี่ยนของตัวเอง)
• ทูทอเรียลการตั้งค่า Ollama-vs-vLLM แบบทีละขั้นตอน ขอบเขตตรงนี้คือคำถามเรื่องเงิน ไม่ใช่การติดตั้ง
• ฮาร์ดแวร์ที่เป็นเจ้าของเป็นวิธีหลักของคุณ สมมติฐานตลอดทั้งบทความคือ GPU ที่เช่า เพราะนั่นคือเส้นทางที่สมจริงสำหรับ builder ที่ยังไม่มี GPU วางอยู่บนโต๊ะ

อะไรเป็นตัวขับต้นทุน (และตัวเลขยอดนิยมผิดตรงไหน)

ค้นหา "self host LLM vs API cost" แล้วคุณจะเจอตัวเลขจุดคุ้มทุนที่เรียบร้อย บางอย่างเช่น 11 พันล้านโทเคนต่อเดือน หรือราวๆ $4,200 ในค่าใช้จ่าย API รายเดือน อ้างอิงโดย การวิเคราะห์ต้นทุนของ braincuber และสะท้อนแทบจะคำต่อคำใน AI Overview ที่ด้านบนของหน้า มันคือตัวเลขที่สะอาด และมันแทบไร้ประโยชน์ในตัวมันเอง เพราะมันซ่อนตัวแปรสองตัวที่ตัดสินคำตอบของคุณ

เหตุผลที่มันลื่นไหลคือ สองด้านของการเปรียบเทียบมีรูปร่างต้นทุนต่างกัน บิล API คือต้นทุนแบบผันแปร คุณจ่ายต่อโทเคน ดังนั้นบิลขึ้นลงตามปริมาณที่คุณใช้ GPU ที่เช่าคือต้นทุนคงที่ คุณจ่ายอัตรารายเดือนเท่ากันไม่ว่าคุณจะดันพันล้านโทเคนผ่านมันหรือปล่อยให้มันนั่งเฉยๆ การเปรียบเทียบต้นทุนผันแปรกับต้นทุนคงที่ด้วยตัวเลขเดียวต้องแสร้งว่าคุณรู้แน่นอนว่าจะมีกี่โทเคนไหลผ่าน และที่ระดับ solo คุณมักจะไม่รู้

นั่นเหลือคันโยกสามตัวที่ขยับจุดคุ้มทุน

• คุณกำลังเทียบกับ API ตัวไหน API ระดับแนวหน้าและ API แบบ open-weight ราคาประหยัดห่างกันราวๆ สองอันดับขนาดในเรื่องราคา จุดคุ้มทุนเทียบกับแต่ละตัวต่างกันมหาศาล
• Utilization ของ GPU ของคุณ ต้นทุนคงที่จ่ายคุ้มก็ต่อเมื่อ GPU ยุ่ง เวลาที่ไม่ทำงานคือเงินที่คุณจ่ายไปเปล่าๆ
• ต้นทุน ops ที่ซ่อนอยู่ ชั่วโมงของคุณ การเปลี่ยนแปลงจากการอัปเดตโมเดล และเซอร์ไพรส์เรื่อง VRAM ที่ไม่โผล่มาจนกว่าคุณจะอยู่ใน production

ตีราคาแต่ละตัวเหล่านั้นแล้วหมอกจะจางลง นั่นคือส่วนที่เหลือของบทความนี้

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

จุดคุ้มทุนสามทาง API ระดับแนวหน้า vs ระดับกลาง vs ราคาประหยัด

การ self-host LLM แบบ open-weight บน GPU VPS เอาชนะ API ระดับแนวหน้า (คลาส GPT-5, Claude Sonnet 5 / Opus 4.8, Gemini Pro) ที่ราวๆ ไม่กี่ล้านโทเคนต่อวัน โดยมีเงื่อนไขว่าคุณต้องรักษา GPU ให้อยู่ที่ utilization ที่ดีต่อสุขภาพ (สมมติว่า 60% ขึ้นไป) เทียบกับ API แบบ open-weight ราคาประหยัดที่ราวๆ $0.14–$0.50 ต่อล้านโทเคน มันแทบไม่เคยชนะเรื่องต้นทุนเลย ความแตกต่างนั้นคือเรื่องราวทั้งหมด และเป็นเหตุผลว่าทำไมตัวเลขจุดคุ้มทุนเดียวจึงถูกต้องไม่ได้

นี่คือรูปร่างของมันในทั้งสามทายเออร์ ปฏิบัติกับเกณฑ์เหล่านี้ในฐานะช่วงบอกทิศทาง ไม่ใช่เส้นตายตัว พวกมันมาจากการประเมินของชุมชนและราคาปี 2026 ซึ่งทั้งคู่เคลื่อนไหวเร็ว

ราคาจากหน้าราคา OpenAI, Anthropic, Google, DeepInfra, Together, และ DeepSeek ณ July 2026 ทุกตัวเลขเหล่านี้มีอายุการใช้งานวัดเป็นเดือน ดังนั้นตรวจสอบหน้าราคาปัจจุบันก่อนที่คุณจะตัดสินใจ

ทีนี้ประเด็นแย้ง เพราะมันคือประเด็นที่เปลี่ยนการตัดสินใจ มีข้อโต้แย้งที่ดังและถูกต้องแพร่หลายอยู่ว่า API ราคาประหยัดฆ่าจุดคุ้มทุนของการ self-host แล้ว API แบบ open-weight อย่าง DeepInfra และ Together ตอนนี้ให้บริการโมเดล Llama และ Qwen ในราคาเศษเสี้ยวของราคาระดับแนวหน้า และราคาระดับแนวหน้าเองก็ลดลงอย่างมากตั้งแต่ปี 2025 เทียบกับอัตราราคาประหยัดเหล่านั้น จุดคุ้มทุนต่อโทเคนวิ่งไปถึงพันล้านโทเคนต่อเดือน solopreneur ไม่ได้ดันพันล้านโทเคนต่อเดือน ดังนั้นถ้าเป้าหมายเดียวของคุณคือบิลที่ต่ำกว่า ก้าวแรกมักจะไม่ใช่ "เช่า GPU" แต่คือ "เปลี่ยนไปใช้ API แบบ open-weight ราคาประหยัดและไม่มี ops เลย"

กรณีเรื่องต้นทุนของการ self-host อยู่รอดในสองที่ คือ การเทียบกับราคาระดับแนวหน้าที่แพงที่ปริมาณสูงต่อเนื่องอย่างแท้จริง และเหตุผลที่ไม่ใช่ต้นทุน (ความเป็นส่วนตัว latency การควบคุม fine-tuning) ซึ่งครอบคลุมด้านล่าง ที่อื่นทุกที่ API ราคาประหยัดชนะข้อโต้แย้งเรื่องเงิน

สูตรจุดคุ้มทุน

break-even tokens per month ≈ GPU VPS monthly cost ÷ your blended API price per token

ตัวอย่างการคำนวณ ระดับ solopreneur สมมติว่า GPU VPS ระดับสูงตัวเดียวรันที่ประมาณ $1,000/เดือน (ช่วงแคตตาล็อกปี 2026 สำหรับทายเออร์ single-GPU ระดับสูง) และคุณอยู่บน API ระดับแนวหน้าด้วยอัตราเฉลี่ยราวๆ $6 ต่อล้านโทเคน (ราวๆ $0.000006 ต่อโทเคน) นั่นคือ ~$1,000 ÷ $0.000006 ≈ 167 ล้านโทเคน/เดือนก่อนที่ GPU จะจ่ายคืนตัวมันเองบนกระดาษ ทีนี้ทำใหม่เทียบกับ API แบบ open-weight ราคาประหยัดที่ $0.40 ต่อล้าน ($0.0000004/โทเคน) ~$1,000 ÷ $0.0000004 = 2.5 พันล้านโทเคน/เดือน GPU ตัวเดียวกัน ต้นทุนคงที่เดียวกัน และจุดคุ้มทุนขยับมากกว่า 10× ขึ้นอยู่กับล้วนๆ ว่าคุณใส่ API ตัวไหนในตัวหาร นี่คือก่อน utilization ซึ่งทำให้ตัวเลขแย่ลง

ประเด็นสรุปของหัวข้อ API ที่คุณเทียบด้วยสามารถขยับจุดคุ้มทุนของคุณได้ 10× หรือมากกว่า ดังนั้น "รันตัวเลข" หมายถึงการรันมันเทียบกับ API เฉพาะที่คุณจะแทนที่จริงๆ

Utilization ทำอะไรกับต้นทุนต่อโทเคน

เอาจุดคุ้มทุนระดับแนวหน้าที่ ~167 ล้านโทเคนนั้นมา แล้วเพิ่มตัวแปรที่สูตรแอบสมมติทิ้งไป นั่นคือ GPU ของคุณยุ่งตลอดเวลา มันไม่ได้เป็นแบบนั้น GPU ที่เช่าคิดเงินเท่ากันไม่ว่ามันจะอิ่มตัวหรือนั่งเฉยๆ ดังนั้นต้นทุน GPU VPS LLM ต่อโทเคนที่มีผลของคุณเปลี่ยนแปลงแบบผกผันกับ utilization รันที่โหลด 10% แล้วแต่ละโทเคนที่คุณให้บริการแบกต้นทุนราวๆ 10× ของตอนทำงานเต็มที่ เพราะคุณจ่ายค่ากำลังการผลิต 90% ที่คุณไม่ได้ใช้ การประเมินของชุมชนและบันทึกของผู้ปฏิบัติวางพื้นในทางปฏิบัติไว้ที่ราวๆ utilization ต่อเนื่อง 50–60% ก่อนที่ตัวเลขจะเลิกทำให้คุณอับอาย (ตัวเลขบอกทิศทาง ไม่ใช่ค่าคงที่ในห้องแล็บ)

สำหรับเวิร์กโหลด solo ที่เป็นกระจุกๆ (ทราฟฟิกที่พุ่งขึ้นระหว่างวันและราบเรียบตอนกลางคืน) utilization ต่อเนื่อง 60% นั้นตีให้ถึงยาก นั่นคือกับดัก นี่คือสิ่งที่มันทำกับต้นทุนต่อล้านโทเคนในจุดที่เป็นรูปธรรมไม่กี่จุด โดยใช้ราคา GPU แคตตาล็อกปี 2026 หารด้วย throughput รายเดือนคร่าวๆ ที่แต่ละระดับ utilization

จำนวนเซนต์ต่อโทเคนที่แท้จริงขึ้นอยู่กับโมเดลของคุณ quantization และจำนวนคำขอพร้อมกันที่คุณอัดลงบนการ์ดได้ ดังนั้นปฏิบัติกับคอลัมน์ในฐานะที่แสดง รูปร่าง ของบทลงโทษ มากกว่าที่จะเป็นราคาที่เสนอ ประเด็นคือตัวคูณ ตกจากโหลดเต็มไปสู่โหลดหนึ่งในสี่แล้วต้นทุนต่อโทเคนของคุณเพิ่มขึ้นราวๆ สี่เท่า นั่นคือสิ่งที่มักฆ่ากรณี self-host แบบ solo ไม่ใช่ราคาป้ายของ GPU

มีทางออกฉุกเฉินเชิงโครงสร้างหนึ่งทาง และมันคือเหตุผลที่การเช่าเอาชนะการเป็นเจ้าของได้สำหรับความต้องการที่พุ่งเป็นกระจุก คุณสามารถหยุด instance ที่เช่าเมื่อมันไม่ทำงาน เป็นเจ้าของฮาร์ดแวร์แล้วมันเสื่อมราคาและดึงพลังงานไม่ว่าคุณจะใช้มันหรือไม่ก็ตาม บนการเช่าแบบรายชั่วโมงหรือแบบ on-demand คุณสามารถหยุดหรือรื้อ instance เมื่องานเสร็จและหลีกเลี่ยงการจ่ายค่าชั่วโมงที่ไม่ทำงาน บนแผนรายเดือนแบบคงที่ บิลยังคงคงที่สำหรับรอบการเรียกเก็บ ดังนั้น utilization ยังคงเป็นปัญหาต้นทุนหลัก มันไม่ได้แก้เวิร์กโหลดที่ utilization ต่ำจริงๆ ตลอดวัน แต่สำหรับความต้องการที่ยุ่งเป็นกระจุกและตายในช่วงระหว่างนั้น ความสามารถในการปิดมิเตอร์คือคันโยกเดียวที่ทำให้การเทียบเช่ากับเป็นเจ้าของเอียงไปทางเช่า

ประเด็นสรุปของหัวข้อ utilization ไม่ใช่ราคารายเดือนของ GPU มักเป็นสิ่งที่ตัดสินว่าการ self-host คุ้มค่าหรือไม่ และมันคือตัวแปรที่ตัวเลขจุดคุ้มทุนยอดนิยมทิ้งไว้ข้างนอกทั้งหมด

โมเดลไหนพอดีกับ GPU ไหน ความจริงเรื่อง VRAM

แผนที่พังก่อนคือ "ผมจะรัน 70B บน 4090 เอง" คุณทำไม่ได้ โมเดล 70B ที่ quantization Q4_K_M ต้องการ VRAM ราวๆ 40–46 GB และ RTX 4090 24 GB หรือ RTX 5090 32 GB ก็ไม่มีที่ว่างเลย บังคับมันลงบนการ์ด 24 GB แล้วคุณจะเหลือ quantization Q2_K (ราวๆ 21 GB) พร้อมการสูญเสียคุณภาพที่เห็นได้ หรือโมเดลล้นไปสู่ RAM ระบบและความเร็วการสร้างข้อความล่มสลาย VRAM คือกำแพงแข็งที่ตัดสินว่าโมเดลไหนแม้แต่จะอยู่บนโต๊ะสำหรับ GPU ตัวหนึ่ง

นี่คือสิ่งที่พอดีตรงไหน ตัวเลข VRAM เป็นค่าประมาณ พวกมันได้มาจากเลขคณิตมาตรฐานไบต์ต่อพารามิเตอร์ (FP16 ≈ params × 2 พร้อม overhead ~15%; Q4_K_M ≈ params × ~0.55 พร้อม overhead) ดังนั้นปฏิบัติกับพวกมันในฐานะแนวทางการปรับขนาด ไม่ใช่การรับประกัน

ตัวเลข VRAM ถูกตรวจสอบไขว้กับหน้าสเปก GPU อย่างเป็นทางการของ NVIDIA สำหรับการ์ดแต่ละใบ A100 ให้พื้นที่เหลือที่สบายกว่าสำหรับ 70B แบบ quantized ส่วน RTX 6000 Ada ใช้ได้กับการตั้งค่า Q4 ที่คับกว่า ในขณะที่การ์ดผู้บริโภค 24 GB และ 32 GB ไม่มี VRAM พอสำหรับการ deploy 70B Q4 แบบปกติ ถ้าคุณอยากได้รายละเอียดเต็มว่ารูปแบบ GGUF, GPTQ, AWQ และ EXL2 กินหน่วยความจำอย่างไร นั่นคือหลุมกระต่ายที่คุ้มค่ากับการอ่านของตัวเอง GGUF, GPTQ, AWQ, EXL2 รูปแบบ quantization ของ LLM ใช้หน่วยความจำจริงๆ อย่างไร.

จุดหวานของชุมชนสำหรับการ์ด 24 GB ตัวเดียวคือโมเดล 24B ถึง 32B (Mistral Small 3.1 หรือ Qwen 3 32B ที่ Q4) นั่นคือขนาดที่ให้ solo builder มีโมเดลที่ใช้ได้บนทายเออร์ GPU ที่ถูกที่สุดโดยไม่ต้องสู้กับ VRAM ตลอดทาง ถ้าคุณกำลังชั่งน้ำหนักว่าจะเช่าการ์ดไหนตั้งแต่แรก เบนช์มาร์ก H100 vs RTX 4090 สำหรับเวิร์กโหลด AI ของเราเปรียบเทียบทายเออร์เหล่านั้นในเรื่อง throughput

เคล็ดลับ วางงบสำหรับ KV cache ไม่ใช่แค่ weights เซอร์ไพรส์ตอน deploy ครั้งแรกที่พบบ่อยที่สุด คุณปรับขนาด GPU สำหรับ weights ของโมเดล โหลดมัน และมันพอดี จากนั้นคำขอเข้ามา KV cache โตขึ้นตามความยาว context และ concurrency แล้วคุณก็ VRAM หมดตอนให้บริการผู้ใช้ไม่กี่คนแรก เมื่อ VRAM ล้นและโมเดลล้นไปสู่ CPU ความเร็วการสร้างข้อความตกลง 10–100× เหลือพื้นที่เหนือตัวเลข weight ในตารางไว้สำหรับ cache โดยเฉพาะถ้าคุณกำลังให้บริการ context ยาวหรือผู้ใช้หลายคนพร้อมกัน

ต้นทุนที่ซ่อนอยู่ซึ่งลบล้างการประหยัดแบบไร้เดียงสา

สเปรดชีตที่บอกว่าการ self-host ถูกกว่ามักมีบรรทัดเดียวเสมอ นั่นคือราคารายเดือนของ GPU บิลที่คุณจ่ายมีบรรทัดมากกว่านั้น มีเวลาของคุณ (ทุกชั่วโมงที่คุณใช้แพตช์ รีสตาร์ตเซิร์ฟเวอร์ inference ที่ค้าง หรือไล่ตาม out-of-memory crash คือชั่วโมงที่คุณไม่ได้ใช้กับผลิตภัณฑ์) มีการเปลี่ยนแปลงจากการอัปเดตโมเดล โมเดล open-weight ที่คุณ deploy ถูกแทนที่ และการ re-benchmark และ re-deploy คืองานที่เกิดซ้ำ ไม่ใช่การตั้งค่าครั้งเดียว มีเซอร์ไพรส์เรื่อง VRAM และ KV-cache จากหัวข้อที่แล้ว และมีของเสียจากการไม่ทำงาน ชั่วโมงที่ GPU นั่งคิดเงินขณะที่ไม่มีอะไรรัน

ผู้ปฏิบัติที่นับสิ่งเหล่านี้วางต้นทุนจริงไว้ที่ราวๆ 1.3–2× ของราคา GPU ดิบเมื่อรวมเวลา ops เข้าไป และบางคนไปสูงกว่า ถึง 3–5× บนการตั้งค่าที่ยุ่งเหยิงกว่า นั่นคือตัวคูณบอกทิศทางจากบันทึกของชุมชน ไม่ใช่ตัวเลขที่ตรวจสอบแล้ว แต่ทิศทางคือประเด็น อย่างที่กรอบการมองที่ถูกอ้างกันแพร่หลายพูดไว้ GPU ที่ไม่ทำงานไม่ใช่สินทรัพย์ แต่เป็นหนี้สินที่คิดเงินเป็นรายชั่วโมง สำหรับ solo builder วิธีที่ถูกในการตีราคาสิ่งนี้ไม่ใช่บรรทัดเงินเดือน MLOps แต่คือชั่วโมงของคุณเอง ซึ่งเป็นสิ่งที่หายากที่สุดที่คุณมี ถ้าการ self-host ประหยัด $200 ต่อเดือนบนกระดาษแต่ทำให้คุณเสียเวลา ops หกชั่วโมงที่คุณคงใช้ในการส่งผลิตภัณฑ์ นั่นไม่ใช่ชัยชนะที่ชัดเจน

เมื่อการ self-host ชนะอยู่ดี ความเป็นส่วนตัว latency และ fine-tuning

ต้นทุนไม่ใช่เหตุผลเดียวที่จะรันโมเดลของตัวเอง และสำหรับ builder บางคนมันไม่ใช่เหตุผลหลักด้วยซ้ำ ต่ำกว่าจุดคุ้มทุนเรื่องต้นทุน ที่ซึ่งเงินบอกว่า "อยู่บน API ต่อ" มีสามเหตุผลที่จะ self-host อยู่ดี อธิปไตยของข้อมูล การเก็บพรอมป์ต์และข้อมูลของผู้ใช้ของคุณให้ออกจากไปป์ไลน์ของผู้ให้บริการ AI ภายนอก ซึ่งสำคัญสำหรับบางผลิตภัณฑ์ไม่ว่าตัวเลขจะบอกอะไร latency ที่คาดการณ์ได้ ไม่มีคิวแบบ shared-tenant ไม่มี rate limit ที่คุณไม่ได้ตั้ง ไม่มีการช้าลงแบบเซอร์ไพรส์ระหว่างที่ทราฟฟิกของคนอื่นพุ่ง และการควบคุมเต็มที่ อิสระในการ fine-tune, quantize, สลับโมเดล และ pin เวอร์ชันโดยไม่ต้องรอผู้ขาย

มีข้อควรระวังในประเด็นความเป็นส่วนตัว และการข้ามมันไปจะไม่ซื่อสัตย์ GPU VPS ที่เช่ายังคงรันบนฮาร์ดแวร์ของคนอื่นในดาต้าเซ็นเตอร์ของคนอื่น นั่นคืออธิปไตยที่มีความหมาย จากไปป์ไลน์การฝึกและการบันทึกล็อกของผู้ให้บริการ AI (พรอมป์ต์ของคุณไม่ไหลผ่านระบบของผู้ขายโมเดล) แต่มันไม่เหมือนกับอุปกรณ์ on-premises ที่คุณควบคุมทางกายภาพ ถ้าข้อกำหนดของคุณคือการแยกตัวแบบ on-prem จริงๆ VPS ที่เช่าจะพาคุณไปถึงจุดนั้นไม่ได้ ถ้าข้อกำหนดของคุณคือ "เก็บข้อมูลของเราออกจากมือของผู้ให้บริการโมเดลบุคคลที่สาม" มันทำได้ รู้ว่าคุณต้องการอันไหน

สำหรับเวิร์กโหลดที่รันในสภาพแวดล้อมเครือข่ายที่จำกัด โมเดลแบบ self-hosted บนโครงสร้างพื้นฐานที่คุณควบคุมยังสามารถหลบเลี่ยงการพึ่งพา endpoint ภายนอกที่อาจเข้าถึงไม่ได้ ซึ่งเป็นความสามารถที่สำคัญโดยไม่ขึ้นกับว่าคุณ deploy มันที่ไหน

แล้วคุณควร self-host ไหม คำตอบตรงๆ ตามสถานการณ์

ทุกอย่างข้างต้นจัดเรียงเป็นการตัดสินใจสั้นๆ คุณมีบิล มีความรู้สึกคร่าวๆ เกี่ยวกับปริมาณโทเคนรายเดือนของคุณ และตอนนี้มีทายเออร์จุดคุ้มทุนสามตัว บทลงโทษเรื่อง utilization และตัวคูณต้นทุนที่ซ่อนอยู่ จับคู่สถานการณ์ของคุณกับหนึ่งในเหล่านี้

• คุณอยู่ต่ำกว่าจุดคุ้มทุนระดับแนวหน้าและต้นทุนเป็นกังวลเดียวของคุณ อยู่บน API ต่อ และตีราคา API แบบ open-weight ราคาประหยัด (DeepSeek, DeepInfra, Together) อย่างจริงจังก่อนอย่างอื่น นั่นมักคือชัยชนะเรื่องต้นทุน ไม่ใช่การ self-host การเปลี่ยน API คือการเปลี่ยน config การ self-host คืองานที่สอง
• คุณมีปริมาณสูงต่อเนื่องเทียบกับราคาระดับแนวหน้าและสามารถรักษา GPU ไว้ที่ utilization 60%+ นี่คือที่ที่การ self-host จ่ายคุ้ม รันสูตรเทียบกับอัตราระดับแนวหน้าของคุณ ยืนยันว่าคุณผ่านเกณฑ์ด้วย utilization ต่อเนื่อง (ไม่ใช่จุดสูงสุด) แล้ว GPU VPS ที่เช่าเริ่มชนะ
• คุณมีตัวขับที่ไม่ใช่ต้นทุน ความเป็นส่วนตัว latency หรือการควบคุม fine-tuning self-host ต่ำกว่าจุดคุ้มทุนอย่างจงใจ โดยเปิดตาว่าคุณกำลังจ่ายเพื่อการควบคุม แค่อย่าหลอกตัวเองว่ามันถูกกว่าถ้ามันไม่ได้ถูกกว่า
• คุณอยู่ตรงกลาง ดูรูปแบบไฮบริดที่ผู้ปฏิบัติส่วนใหญ่ลงเอยในปี 2026 โมเดล self-hosted ขนาดเล็กสำหรับงานปริมาณสูงที่เรียบง่าย บวกกับ API ระดับแนวหน้าสำหรับการให้เหตุผลที่ยากซึ่งโมเดลโลคัลของคุณทำได้ 85–90% ของทาง (เบนช์มาร์กของชุมชน ไม่ได้ตรวจสอบในห้องแล็บ และช่วงสุดท้ายมักคือที่ที่คุณต้องการคุณภาพมากที่สุด)

ในคำถาม "ผมจะได้ GPU มาอย่างไร" คำตอบสำหรับ solo builder แทบจะเป็นเช่า ไม่ใช่ซื้อ เสมอ การเป็นเจ้าของฮาร์ดแวร์ระดับดาต้าเซ็นเตอร์คือการเดิมพันแบบ capex ที่สมเหตุสมผลเฉพาะที่ระดับที่คุณยังไม่มี Serverless inference สามารถลดของเสียจากการไม่ทำงาน โดยการปรับขนาดลงเหลือศูนย์และคิดเงินเฉพาะการประมวลผลที่ทำงานอยู่ แต่มันมักแลกสิ่งนั้นกับอัตราต่อ GPU-ชั่วโมงที่สูงกว่าและ cold-start latency GPU VPS ที่เช่านั่งอยู่ตรงกลาง ไม่มี capex บิลรายเดือนที่คาดการณ์ได้ root access และความสามารถในการหยุด instance เมื่อมันไม่ทำงาน

ถ้าคุณรันสูตรแล้ว ผ่านจุดคุ้มทุน และต้องการเซิร์ฟเวอร์ inference ที่ทุ่มเทให้ เป็นส่วนตัว เข้าถึงแบบ root โดยไม่ต้องซื้อการ์ด นั่นคือสิ่งที่กล่อง GPU ที่เช่ามีไว้เพื่อนั้นพอดี แผน GPU VPS ของ Cloudzy ครอบคลุมช่วงตั้งแต่โมเดล 8B บนการ์ดใบเดียวไปจนถึง 70B แบบ quantized และ แอป Ollama แบบคลิกเดียวในมาร์เก็ตเพลส deploy ในราวหนึ่งนาทีด้วย REST API ที่เข้ากันได้กับไคลเอนต์ OpenAI ดังนั้นการเปลี่ยนจาก API แบบเสียเงินไปสู่เซิร์ฟเวอร์ของคุณเองอาจใกล้เคียงกับการเปลี่ยนแบบ drop-in ในโค้ดของคุณ โดยไม่มีต้นทุนต่อโทเคนหลังจากค่าธรรมเนียมรายเดือนคงที่ ตรวจสอบหน้าเว็บสำหรับราคาปัจจุบัน อัตรา GPU เคลื่อนไหว

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

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

การ self-host LLM ถูกกว่าหรือใช้ API ถูกกว่า

มันขึ้นอยู่กับว่าเป็น API ตัวไหน การ self-host โมเดล open-weight บน GPU VPS สามารถเอาชนะ API ระดับแนวหน้า (คลาส GPT-5, Claude Sonnet 5 / Opus 4.8) ที่ปริมาณสูงต่อเนื่องพร้อม utilization ของ GPU ที่ดี มันแทบไม่เคยเอาชนะ API แบบ open-weight ราคาประหยัด (DeepSeek, DeepInfra, Together ที่ราวๆ $0.14–$0.50 ต่อล้านโทเคน ณ July 2026) ในเรื่องต้นทุนเพียงอย่างเดียว จุดคุ้มทุนนั้นวิ่งไปถึงพันล้านโทเคนต่อเดือน ซึ่ง solo builder ส่วนใหญ่ไม่มีวันถึง

ผมต้องการ GPU อะไรในการรันโมเดล 70B

โมเดล 70B ที่ quantization Q4_K_M ต้องการ VRAM ราวๆ 40–46 GB แค่สำหรับ weights แบบ quantized A100 80 GB คือตัวเลือก single-GPU ที่ปลอดภัยกว่าเพราะมันเหลือที่สำหรับ KV cache, runtime overhead และพรอมป์ต์ที่ยาวขึ้น RTX 6000 Ada 48 GB ใช้ได้กับการตั้งค่า Q4 ที่คับกว่า แต่ความยาว context และ concurrency ต้องจัดการอย่างระมัดระวัง

Utilization ของ GPU ส่งผลต่อต้นทุนต่อโทเคนอย่างไร

GPU ที่เช่ามีต้นทุนเท่ากันไม่ว่ามันจะไม่ทำงานหรือโหลดเต็มที่ ดังนั้นต้นทุนต่อโทเคนที่มีผลของคุณเปลี่ยนแปลงแบบผกผันกับ utilization ที่โหลด 10% แต่ละโทเคนที่คุณให้บริการมีต้นทุนราวๆ 10× ของตอนทำงานเต็มที่ เพราะคุณจ่ายค่ากำลังการผลิตที่ไม่ได้ใช้ พื้นในทางปฏิบัติสำหรับการ self-host ให้สมเหตุสมผลคือราวๆ utilization ต่อเนื่อง 50–60%

กี่โทเคนต่อเดือนก่อนที่การ self-host จะคุ้มค่า

เทียบกับ API ระดับแนวหน้า ราวๆ 160–256 ล้านโทเคนต่อเดือนที่ utilization ที่ดีต่อสุขภาพคือเกณฑ์บอกทิศทาง (ณ July 2026) เทียบกับ API แบบ open-weight ราคาประหยัดมันคือพันล้านต่อเดือน แทบเอื้อมไม่ถึงในแบบ solo ตัวเลขที่แน่นอนขึ้นอยู่กับต้นทุน GPU และอัตรา API เฉลี่ยของคุณ ดังนั้นรันสูตร โทเคนจุดคุ้มทุน ≈ ต้นทุน GPU VPS รายเดือน ÷ ราคา API ต่อโทเคนของคุณ แล้วลดมันลงสำหรับ utilization ต่อเนื่อง

ผมรัน LLM แบบ open-weight บน VPS ได้ไหม

ได้ บน GPU VPS ที่ปรับขนาดให้ตรงกับ VRAM ของโมเดล เครื่องมืออย่าง Ollama รันโมเดล open-weight (Llama, Qwen, Mistral และอื่นๆ) ด้วยการ deploy แบบคลิกเดียวและ OpenAI-compatible REST API ดังนั้นโค้ดที่เรียกใช้ API ที่มีอยู่ของคุณสามารถชี้ไปที่เซิร์ฟเวอร์ของคุณเองด้วยการเปลี่ยนแปลงน้อยที่สุด จับคู่ทายเออร์ GPU ให้ตรงกับโมเดลของคุณ 8B พอดีกับการ์ด 24 GB อย่างสบาย 70B แบบ quantized ต้องการ 48–80 GB