นักพัฒนาส่วนใหญ่เผชิญกับความท้าทายในการเลือกโครงสร้างพื้นฐาน AI ที่เหมาะสม โดยคำถามหลักมักหมุนรอบการตัดสินใจระหว่าง Serverless สำหรับความยืดหยุ่น และ Dedicated สำหรับการควบคุม ความสะดวกสบายเทียบกับประสิทธิภาพ
ในทางปฏิบัติ โครงสร้างพื้นฐานสำหรับ Inference ไม่ใช่สิ่งที่คุณ "เลือกถูกต้อง" เพียงครั้งเดียว แต่มันคือสิ่งที่เงียบๆ กลายเป็นไม่เหมาะสมตามเวลา เมื่อผลิตภัณฑ์ ปริมาณトラフィก และความคาดหวังของคุณพัฒนาไป
นำตัวอย่าง AI-powered meeting assistant มาพิจารณา ในเวอร์ชันแรกสุด ระบบประมวลผลการประชุมไม่กี่ครั้งต่อวัน ทำการถอดเสียงและสรุปเนื้อหาทีละครั้ง การใช้งานไม่สม่ำเสมอ และเป้าหมายหลักคือทำให้ฟีเจอร์ทำงานได้ Serverless inference จึงเป็นตัวเลือกที่เหมาะสมที่นี่
เมื่อผลิตภัณฑ์ได้รับความนิยม มันกลายเป็นส่วนหนึ่งของเวิร์กโฟลว์ประจำวัน ทีมพึ่งพามันในการประมวลผลการประชุมตลอดวัน และความคาดหวังเกี่ยวกับเวลาตอบสนองเริ่มเข้มข้นขึ้น ปัญหา latency spikes ที่เกิดขึ้นบ้างเริ่มมีความสำคัญ แม้ประสิทธิภาพโดยรวมจะยังพอใช้ได้
ในที่สุด ระบบจะถึงจุดที่จัดการปริมาณการประชุมสูงด้วยรูปแบบรายวันที่คาดเดาได้ ณ จุดนี้ ความต้องการเปลี่ยนไปสู่ความสม่ำเสมอและประหยัดต้นทุน Dedicated inference กลายเป็นพื้นฐานที่สมเหตุสมผล ไม่ใช่เพราะวิธีเดิมผิด แต่มันคือระบบที่เติบโตจนเกินกว่าที่ Serverless จะรองรับได้
น่าสนใจคือ Serverless ไม่ได้หายไป มันมักยังคงมีประโยชน์สำหรับกรณีขอบ (edge cases) การจัดการ traffic spikes ที่ไม่คาดคิด การรันฟีเจอร์ทดลอง หรืองานที่มีความถี่ต่ำ มันกลายเป็นการผสมผสานของทั้งสองแนวทางโดยอัตโนมัติ ขึ้นอยู่กับสิ่งที่ระบบต้องการ มากกว่าแผนที่ตายตัว
ในบทความนี้ เราจะพยายามเข้าใจว่าการเลือกระหว่าง Serverless และ Dedicated inference เปลี่ยนแปลงอย่างไรเมื่อระบบเติบโต เราจะสำรวจแพลตฟอร์มยอดนิยม 2 แห่งคือ Modal และ Together.ai เป็นตัวอย่าง เพื่อเข้าใจว่า Serverless inference เริ่มล้มเหลวเมื่อไหร่ รูปแบบ workload ทำให้เกิดการเลือกที่ถูกต้องอย่างไร และทำไมการย้ายไปสู่โครงสร้างพื้นฐาน Dedicated จึงเป็นเรื่องที่หลีกเลี่ยงไม่ได้เมื่อระบบขยายตัว
ช่วงเริ่มต้น
ในช่วงแรกๆ ของการสร้างผลิตภัณฑ์ AI ข้อจำกัดที่ใหญ่ที่สุดไม่ใช่ประสิทธิภาพ โดยเฉพาะ latency consistency (ความเร็วตอบสนองของแต่ละ request) และ throughput (จำนวน request ที่จัดการพร้อมกัน) แต่เป็นว่าคุณสามารถ ship, iterate และเรียนรู้จากการใช้งานจริงได้เร็วแค่ไหน
ในวันแรกๆ workload ยังไม่เข้าใจ traffic ไม่สม่ำเสมอ โมเดลเปลี่ยนแปลงบ่อย และผลิตภัณฑ์ยังกำลังถูกสร้างขึ้น ในกรณีเช่นนี้ แพลตฟอร์ม Serverless รู้สึกเกือบจะสมบูรณ์แบบสำหรับความต้องการของนักพัฒนา
มันกำจัดการตัดสินใจที่จะทำให้คุณช้าลง คุณไม่ต้องคิดเรื่อง GPU provisioning, scaling policies หรือ capacity planning คุณเขียนโค้ด deploy และระบบปรับตัวตามความต้องการที่เกิดขึ้น สำหรับแอปพลิเคชันช่วงต้น เช่น chatbot แบบ prototype, document summarizer หรือ internal AI tool นี่ไม่ใช่แค่สะดวก แต่มันคือความแตกต่างระหว่าง ship ได้หรือไม่ได้
ในขั้นนี้ ความไม่มีประสิทธิภาพไม่สำคัญ เพราะการใช้งานเองก็ไม่แน่นอน คุณกำลัง optimize สำหรับ iteration speed ไม่ใช่ infrastructure efficiency
การเปลี่ยนแปลงครั้งแรก: Latency กลายเป็นปัญหาของผลิตภัณฑ์
สัญญาณแรกที่บ่งชี้ว่าการเลือกโครงสร้างพื้นฐานเริ่มไม่ตรงกับความต้องการ ไม่ได้แสดงขึ้นใน billing dashboard มันแสดงขึ้นใน user experience เมื่อการใช้งานเพิ่มขึ้น แม้แค่เล็กน้อย latency หยุดเป็นแค่ตัวเลขทฤษฎี และเริ่มมองเห็นได้ชัดเจน
ระบบ Serverless สร้างรอบ elasticity ซึ่งมักมาพร้อมกับความผันผัน Request อาจตอบกลับทันทีถ้า environment ยัง warm อยู่ หรือใช้เวลานานมากถ้ากระตุ้น cold start หรือโหลดโมเดล แบบแยกต่างหากมันยอมรับได้ แต่ในระบบที่ติดต่อผู้ใช้ inconsistency นี้เด่นชัดกว่า average performance
พิจารณา AI assistant ที่ฝังอยู่ใน customer support workflow หรือ code generation feature ภายใน IDE ในทั้งสองกรณี ผู้ใช้คาดหวังให้ responsiveness รู้สึกทันทีและคาดเดาได้ ไม่กี่ครั้งที่ตอบช้า ไม่ได้ average ออกไปในการรับรู้ แต่พวกมันเด่นชัด สิ่งที่เคยเป็นรายละเอียด infrastructure กลายเป็น product flaw
การเปลี่ยนแปลงครั้งที่สอง: เมื่อต้นทุนเริ่มสะสม
เมื่อระบบของคุณเติบโต การใช้งานจะกลายเป็นประจำมากขึ้น สิ่งที่เคยเป็น request บ้างครั้ง กลายเป็น steady traffic และฟีเจอร์ที่เคยเป็นทดลองกลายเป็นส่วนหนึ่งของการใช้งานประจำวัน นี่คือจุดที่ serverless pricing เริ่มรู้สึกต่างออกไป
Serverless ทำงานดีเมื่อการใช้งาน unpredictable เพราะคุณจ่ายเฉพาะตอนที่มันรัน แต่เมื่อระบบของคุณ active ตลอดเวลา จัดการ continuous requests หรือรัน background jobs คุณจะจ่ายค่าใช้จ่ายสำหรับงานเดียวกันซ้ำๆ ตามเวลา ความสะดวกนั้นเริ่มแพงขึ้น
ในจุดนี้ Dedicated infrastructure การรันโมเดลบน GPU แบบ fixed เริ่มมีเหตุผลมากขึ้น คุณต้องการควบคุมต้นทุนมากขึ้น ซึ่งทำให้ performance สม่ำเสมอขึ้น ตราบใดที่คุณใช้ทรัพยากรอย่างมีประสิทธิภาพ
ไม่มีอะไรผิดปกติตรงนี้ แค่ระบบของคุณเติบโตถึงขนาดที่ setup เดิมไม่ใช่ตัวเลือกที่ cost-effective ที่สุดแล้ว
รูปทรง Workload ไใช่ Platform Choice ที่ตัดสินผลลัพธ์
สิ่งที่ชัดเจนขึ้นตามเวลาคือ การตัดสินใจไม่ได้เกี่ยวกับการเลือกระหว่างสองประเภทของแพลตฟอร์ม มันเกี่ยวกับการเข้าใจว่า workload ของคุณพฤติกรรมอย่างไร และมันเปลี่ยนแปลงอย่างไร
ข้อผิดพลาดที่ทีมหลายทีมทำคือ สมมติว่า workload shape ปัจจุบันเป็นถาวร ในความเป็นจริง ระบบส่วนใหญ่เคลื่อนผ่านหลาย state แอปพลิเคชันอาจเริ่มต้นด้วย highly spiky usage แล้ว transition สู่ semi-predictable daily cycles และสุดท้ายจบที่ steady high-throughput pattern แต่ละขั้นตอนชอบแนวทางที่ต่างกัน
ช่วงกลาง (The Middle Phase)
ขั้นที่ยากที่สุดไม่ใช่จุดเริ่มหรือจุดจบ แต่นี่คือการ transition ระหว่างพวกมัน นี่คือจุดที่ระบบมักรู้สึก "off" แม้ว่าจะไม่มีอะไรเสียหาย Latency issues ปรากฏบ้างครั้งแต่ไม่ consistent และต้นทุนเริ่มเพิ่ม แต่ยังไม่พอ justify การเปลี่ยน architecture ทั้งหมด นักพัฒนาเริ่มเพิ่ม workarounds เช่น caching responses, pre-warming environments หรือปรับ concurrency ให้ smooth ขึ้น การเปลี่ยนแปลงเหล่านี้ช่วยชั่วคราว แต่ก็ส่งสัญญาณว่าระบบถูกผลักดันเกินกว่าที่ออกแบบไว้ตั้งแต่แรก
ถ้าเรานำตัวอย่าง AI customer support assistant ที่เติบโตมาใช้อีกครั้ง ในช่วงเริ่มต้น มันจัดการ query จำนวนน้อยได้ แต่เมื่อ adoption เพิ่มขึ้น ระบบเริ่มจัดการร้อยๆ request ใน peak hours ส่วนใหญ่ตอบเร็วยังคงอยู่ แต่บางครั้งช้าประมาทเนื่องจาก cold starts หรือ scaling delays ทีมเพิ่ม caching สำหรับ repeated queries และลอง pre-warming เพื่อลด latency spikes ในเวลาเดียวกัน ต้นทุนรายเดือนเพิ่มขึ้นเพราะระบบรันสม่ำเสมอขึ้น แต่ traffic ยังไม่พอ stable ที่จะ justify การย้ายไป dedicated GPUs ซึ่งอาจนั่ง idle ใน off-hours สร้าง middle ground ที่รบกวน ระบบทำงานได้แต่ต้อง tuning ตลอดเวลา และไม่ serverless ไม่ dedicated รู้สึกเหมาะสม
ขนาดใหญ่ (At Scale)
มาถึงจุดหนึ่ง ระบบของคุณหยุดเป็น unpredictable คุณรู้ประมาณว่ามี request เข้ามาเท่าไหร่ คุณรู้ว่า busy hours คือเมื่อไหร่ การเดาเลขหายไป
ตอนนี้ คุณจ่าย per request บนระบบที่ไม่เคยหยุดรัน Cold starts ที่เคยเกิดบ้างครั้ง ตอนนี้รู้สึก unacceptable ผู้ใช้คุเคยกับ fast consistent responses และ variance ใดๆ ก็ถูกสังเกตเห็น โครงสร้างพื้นฐานที่ช่วยให้คุณเคลื่อนไหวเร็วในตอนแรก ตอนนี้กลายเป็นสิ่งที่ช้าคุณลง Dedicated inference แก้ปัญหานี้ได้สะอาด คุณ reserve GPU โมเดลคุณ stay loaded และทุก request ได้ประสบการณ์เหมือนกัน ไม่ sharing ไม่ spin-up delays ไม่ surprises
เศรษฐศาสตร์เปลี่ยนไปด้วย เมื่อระบบ active ตลอดเวลา การจ่ายสำหรับ reserved compute จะถูกกว่า pay-per-use Together.ai dedicated endpoints ตัวอย่าง เริ่มที่ $3.99 ต่อชั่วโมงสำหรับ H100 ที่ steady traffic นี่มักถูกกว่าที่คุณจ่ายสำหรับ serverless พร้อม performance ที่ดีกว่า สิ่งที่คุณได้ไม่ใช่แค่ต้นทุนต่ำหรือ response เร็ว มันคือ stability คุณหยุด tuning infrastructure และเริ่ม trust มัน นั่นคือจุดที่คุณ focus สร้างผลิตภัณฑ์เต็มที่ ไม่ใช่จัดการ layer ใต้ Serverless ไม่ได้หายไปหมด มันยังจัดการ edge cases: unexpected spikes, experimental features, low-frequency jobs แต่ไม่ได้ carry core workload อีกต่อไป Dedicated infrastructure ทำหน้าที่นั้นตอนนี้
นักพัฒนาสัมผัส Serverless Inference Platforms อย่างไรจริงๆ
วิธีที่ดีในการเข้าใจระบบเหล่านี้คือดูว่า developers interact กับสองแพลตฟอร์มที่ใช้กันทั่วไป: Modal และ Together.ai ทั้งคู่เริ่มจาก idea เหมือนกันคือ abstract away infrastructure แต่อย่างที่ abstraction แสดงออกในทางปฏิบัติ (โดยเฉพาะ pricing และ scaling) เปิดเผยว่าสิ่งต่างๆ ทำงานดีแค่ไหน และ trade-offs เริ่มที่ไหน
Modal
Modal ออกแบบรอบ serverless model ที่คุณจ่ายค่า compute time อย่างเคร่งครัด GPU usage เช่น ถูก bill ต่อวินาที ประมาณ $0.0002/sec สำหรับ GPU ขนาดเล็ก (เช่น L4) จนถึง $0.0011/sec สำหรับ high-end GPU เช่น H100 ซึ่งแปลเป็นประมาณ $0.8–$4 ต่อชั่วโมงขึ้นอยู่กับ hardware มี free tier ประมาณ $30 credits ต่อเดือน ทำให้เริ่มต้นง่ายโดยไม่มี upfront cost ในทางปฏิบัติ นี่ทำงานได้ดีมากสำหรับ bursty workloads เช่น image generation API ที่ได้ traffic เฉพาะเมื่อ user trigger หรือ background job ที่รันวันละไม่กี่ครั้ง คุณไม่จ่าย idle GPUs และ scaling เกิดขึ้นอัตโนมัติ แต่เมื่อ usage กลายเป็น continuous สมมติว่าคุณรัน real-time object detection model ที่จัดการ images ตลอดวัน pricing model เริ่มเปิดเผย trade-offs คุณไม่ได้รับประโยชน์จาก "pay only when used" อีกต่อไป เพราะระบบถูกใช้ตลอดเวลา แทนที่จะเป็นเช่นนั้น คุณเช่า GPU เดียวกันซ้ำๆ ในชิ้นเล็กๆ สะสมค่าใช้จ่ายสูงกว่าการเก็บ GPU ไว้รันตลอดเวลา ในเวลาเดียวกัน performance characteristics เช่น cold starts และ container reuse นำเสนอความผันผันที่ยากต่อการมองข้ามใน production environments
Together.ai
Together.ai เริ่มด้วย serverless API แต่สิ่งที่น่าสนใจสำหรับระบบที่เติบโตคือ มันไม่บังคับให้คุณสลับแพลตฟอร์มเมื่อความต้องการเปลี่ยน คุณย้ายจาก basic API usage ไป dedicated GPU endpoints ได้โดยไม่เปลี่ยนโค้ด
ระดับเริ่มต้น คุณจ่ายต่อ token Pricing แตกต่างตามโมเดล ประมาณ $0.10 ถึง $3 ต่อล้าน tokens ทำงานดีเมื่อ traffic เบาหรือ unpredictable คุณได้ auto-scaling และไม่มี infrastructure ที่ต้องจัดการ เป็นจุดเริ่มต้นที่สมเหตุสมผลสำหรับ use cases ส่วนใหญ่
เมื่อ traffic เติบโตและ latency เริ่มสำคัญ Together.ai ให้คุณย้ายไป dedicated endpoints คุณเลือก hardware: H100 ประมาณ $3.99 ต่อชั่วโมง หรือ H200 ประมาณ $5.49 ต่อชั่วโมง และ GPU นั้นเป็นของคุณ ไม่ shared compute ไม่ interference จาก workload อื่น โมเดล stay loaded และ latency profile ของคุณกลายเป็น consistent
Trade-off เหมือนกับ dedicated setup ใดๆ หาก traffic ตกใน off-hours GPU นั้นยังคงรัน คุณจ่าย capacity ไม่ว่าจะใช้หรือไม่ เรื่องนี้โอเคเมื่อ workload ของคุณ steady
สำหรับทีมที่กำลัง scale ข้อได้เปรียบทางปฏิบัติของ Together.ai คือ migration path เป็น internal คุณไม่ต้อง rebuild integration เพื่อได้ dedicated performance คุณเปลี่ยน endpoint configuration เท่านั้น นี่เอาอุปสรรคหนึ่งที่จริงออกไป คือการ delay การเปลี่ยนแปลงเพราะ switch 感じ disruptive
ตัวอย่าง การรัน mid-sized model อาจใช้ประมาณ $0.10–$0.60 ต่อล้าน input tokens โดย output tokens บางครั้งสูงกว่านี้ขึ้นอยู่กับโมเดล ทำให้ intuitive สำหรับ use cases เช่น chatbots หรือ text generation APIs ที่ต้นทุน scale กับ usage ตัวอย่าง customer support bot ที่ generate ไปไม่กี่ล้าน tokens ต่อวัน อาจใช้ต้นทุนสิบๆ ถึงร้อยๆ ดอลลาร์ต่อเดือน ขึ้นอยู่กับ volume ในเวลาเดียวกัน Together.ai เสนอ dedicated GPU endpoints เริ่ม $3.99/ชั่วโมงสำหรับ H100 เมื่อ workloads กลายเป็น steady นี่สะท้อน pattern ที่พบบ่อย: developers เริ่มด้วย API-based usage 簡単 แต่เมื่อ traffic stable และ latency expectations เพิ่ม พวกเขามักย้ายไป dedicated setups เพื่อ performance และ cost ที่คาดเดาได้มากขึ้น
การเปลี่ยนแปลงที่สำคัญไม่ใช่แพลตฟอร์ม—แต่ คุณใช้มันอย่างไรตามเวลา:
- Early stage → ใช้เหมือน simple API
- Growth stage → เริ่มกังวล latency และ cost
- Scale → ย้ายไป dedicated endpoints ภายในแพลตฟอร์มเดียวกัน
แตกต่างจาก pure serverless platforms คุณไม่จำเป็นต้องสลับ providers—คุณ เปลี่ยนโหมด
จุดที่ควรพิจารณาก่อนตัดสินใจ
- Cost scales ต่างจากที่คุณคาด: Serverless platforms คิดค่าบริการ fixed on-demand rate สำหรับทุกวินาทีของ compute เมื่อระบบ idle โมเดลนี้ efficient แต่เมื่อระบบรันต่อเนื่อง rate เดียวนี้รันตลอด 24 ชม. ไม่มีการลดราคา Infrastructure ที่รองรับ reserved capacity สามารถลด effective hourly cost ลงได้มากกว่าครึ่งหนึ่ง ยิ่ง workload predictable นาน ยิ่งความต่างสะสมมากขึ้น
- Managed defaults กลายเป็น constraints ตามเวลา: แพลตฟอร์ม managed inference บางครั้งตัดสินใจ configuration ให้คุณ เรื่อง optimizations ใดที่รัน memory ยังไง request batching ยังไง ในช่วงต้น defaults นี้ประหยัดเวลา ต่อมาเมื่อคุณต้อง tune inference layer สำหรับ workload เฉพาะ defaults เดียวกันกลายเป็นอุปสรรค หากคุณเข้าถึง configuration ไม่ได้ คุณเปลี่ยนมันไม่ได้ การ擁有 infrastructure หมายถึง settings นั้นเป็นของคุณ
- Visibility ของคุณจำกัดเฉพาะสิ่งที่ platform แสดง: บน managed platform เมื่อสิ่งผิดปกติเกิดขึ้นหรือ cost spike อย่างไม่คาดคิด ความสามารถในการสืบสวนจำกัดอยู่ที่ dashboard ที่ platform สร้างให้ คุณเห็นว่ามันช้าหรือแพง แต่มหากลับไล่หาที่มาที่ยาก เพราะ infrastructure layer อยู่นอกมือ Dedicated infrastructure ให้ full observability ครอบ compute, networking, storage คุณเห็นทุกอย่าง และ act ได้
- Control มากขึ้น = Responsibility มากขึ้น: การ擁有 infrastructure ให้ lower costs, deeper control, full visibility แต่ก็หมายถึงคุณรับ setup และ operational work ที่ managed platforms จัดการให้ นี่ไม่ใช่ right call เสมอไป โดยเฉพาะถ้าทีมเล็กหรือ workload ยังเปลี่ยนแปลง แต่ platform ที่ถูกต้องจะ strike balance ที่เหมาะสม ปลายทางระหว่าง managed และ self-managed บาง infrastructure platforms ตอนนี้ ship พร้อม pre-configured inference images, one-click GPU deployment, Kubernetes support out of the box หมายถึงคุณไม่เริ่มจากศูนย์ Operational overhead จริง แต่เบามากกว่าเดิมมาก
สรุป
Serverless inference ให้คุณ speed ในการเริ่มต้น ทดลอง และ ship โดยไม่มี friction แต่เมื่อระบบเติบโต abstraction ที่เคยช่วยคุณเร็วขึ้น อาจเริ่มซ่อนสิ่งที่สำคัญที่สุด: latency consistency, throughput และ cost efficiency แพลตฟอร์มอย่าง Modal และ Together.ai ทำให้ build และ scale ได้ง่ายในช่วงต้น และในหลายกรณี ยังคงเป็นส่วนหนึ่งของ architecture มาโดยตลอด แต่เมื่อ workloads กลายเป็น predictable และ expectations เข็มข้นขึ้น ความจำเป็นในการควบคุมมากขึ้นกลายเป็น unavoidable ระบบจริงไม่คงอยู่กับที่ เคลื่อนจาก uncertainty สู่ predictability จาก experimentation สู่ production และเมื่อพวกมันทำเช่นนั้น "correct" infrastructure choice เปลี่ยนไปด้วย ข้อผิดพลาดจริงที่ทีมทำคือ ถือ serverless เป็น long-term default แทนที่จะเป็นสิ่งที่มันจริงๆ: a phase ยิ่งคุณ delay การย้ายไป dedicated infrastructure เมื่อ workload stable ยิ่งคุณจ่ายใน cost, performance หรือทั้งคู่
งานนี้ได้รับอนุญาตภายใต้ Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International License.
