การเลือกระหว่างการอนุมาน AI เฉพาะและแบบไร้เซิร์ฟเวอร์เพื่อปรับขนาดธุรกิจของคุณ

โดยส่วนใหญ่แล้ว นักพัฒนาเผชิญกับความท้าทายในการเลือกโครงสร้างพื้นฐาน AI ที่เหมาะสม และบทสนทนาหลักจะเกี่ยวกับคำถามง่ายๆ ว่าตัวเลือกใดที่เหมาะสมคือการสร้างระบบ AI ไร้เซิร์ฟเวอร์เพื่อความยืดหยุ่น มีไว้สำหรับการควบคุมโดยเฉพาะ ความสะดวกสบายเทียบกับประสิทธิภาพ

ในทางปฏิบัติ โครงสร้างพื้นฐานของการอนุมานไม่ใช่สิ่งที่คุณ "เลือกถูก" เพียงครั้งเดียว มันเป็นสิ่งที่ผิดพลาดอย่างเงียบๆ เมื่อเวลาผ่านไปเมื่อผลิตภัณฑ์ ปริมาณการเข้าชม และความคาดหวังของคุณพัฒนาไป

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

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

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

สิ่งที่น่าสนใจคือระบบไร้เซิร์ฟเวอร์ไม่ได้หายไป มันมักจะยังคงมีประโยชน์สำหรับ Edge Case การจัดการกับการเปลี่ยนแปลงที่ไม่คาดคิด การเรียกใช้ฟีเจอร์ทดลอง หรือการสนับสนุนงานที่มีความถี่ต่ำ โดยธรรมชาติแล้วมันจะกลายเป็นการผสมผสานของทั้งสองแนวทาง ซึ่งขับเคลื่อนโดยสิ่งที่ระบบต้องการมากกว่าแผนที่กำหนดตายตัว

ในบทความนี้ เราจะพยายามทำความเข้าใจว่าตัวเลือกระหว่างการอนุมานแบบไร้เซิร์ฟเวอร์และการอนุมานเฉพาะจะพัฒนาไปอย่างไรเมื่อระบบเติบโตขึ้น นอกจากนี้เรายังจะสำรวจแพลตฟอร์มยอดนิยมสองแพลตฟอร์ม เช่น Modal และ Together.ai เป็นตัวอย่างเพื่อทำความเข้าใจเมื่อการอนุมานแบบไร้เซิร์ฟเวอร์เริ่มพัง รูปแบบปริมาณงานกำหนดทางเลือกที่เหมาะสมอย่างไร และเหตุใดการก้าวไปสู่โครงสร้างพื้นฐานเฉพาะจึงเป็นสิ่งที่หลีกเลี่ยงไม่ได้เมื่อขนาดของระบบ

ระยะเริ่มต้น

ในช่วงวันแรกของการสร้างผลิตภัณฑ์ AI ข้อจำกัดที่ใหญ่ที่สุดไม่ใช่ประสิทธิภาพ โดยเฉพาะความสม่ำเสมอของเวลาแฝง (ความเร็วที่แต่ละคำขอตอบสนอง) และปริมาณการประมวลผล (จำนวนคำขอที่ได้รับการจัดการในคราวเดียว) แต่อยู่ที่ความเร็วที่คุณสามารถจัดส่ง ทำซ้ำ และเรียนรู้จากการใช้งานจริง

ในช่วงแรกๆ ยังไม่มีใครเข้าใจปริมาณงาน ปริมาณการใช้ข้อมูลไม่สอดคล้องกัน โมเดลกำลังเปลี่ยนแปลง และผลิตภัณฑ์ยังคงถูกสร้างเป็นรูปเป็นร่าง ในกรณีเช่นนี้ แพลตฟอร์มแบบไร้เซิร์ฟเวอร์รู้สึกว่าเกือบจะสมบูรณ์แบบสำหรับความต้องการของนักพัฒนา

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

ในขั้นตอนนี้ ความไร้ประสิทธิภาพไม่สำคัญเนื่องจากการใช้งานนั้นมีความไม่แน่นอน คุณกำลังเพิ่มประสิทธิภาพความเร็วในการทำซ้ำ ไม่ใช่ประสิทธิภาพของโครงสร้างพื้นฐาน

การเปลี่ยนแปลงแรก:เวลาแฝงกลายเป็นปัญหาของผลิตภัณฑ์

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

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

พิจารณาผู้ช่วย AI ที่ฝังอยู่ในเวิร์กโฟลว์การสนับสนุนลูกค้า หรือฟีเจอร์การสร้างโค้ดภายใน IDE ในทั้งสองกรณี ผู้ใช้คาดหวังว่าการตอบสนองจะรู้สึกได้ทันทีและคาดเดาได้ การตอบสนองช้าๆ เล็กน้อยไม่ได้อยู่ในระดับการรับรู้ แต่มีความโดดเด่น สิ่งที่ครั้งหนึ่งเคยเป็นรายละเอียดโครงสร้างพื้นฐานกลายเป็นข้อบกพร่องของผลิตภัณฑ์

การเปลี่ยนแปลงที่สอง:เมื่อต้นทุนเริ่มเพิ่มขึ้น

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

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

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

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

รูปแบบภาระงาน ไม่ใช่ตัวเลือกแพลตฟอร์ม เป็นตัวขับเคลื่อนผลลัพธ์

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

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

ระยะกลาง

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

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

ตามขนาด

เมื่อถึงจุดหนึ่ง ระบบของคุณก็ไม่สามารถคาดเดาได้ คุณทราบโดยประมาณว่ามีคำขอเข้ามากี่รายการ คุณทราบเมื่อถึงเวลาที่มีผู้คนหนาแน่น การคาดเดาหายไป
ตอนนี้ คุณจะจ่ายเงินต่อคำขอบนระบบที่ไม่เคยหยุดทำงาน การสตาร์ทในช่วงเย็นที่ครั้งหนึ่งเคยเกิดขึ้นเป็นครั้งคราว บัดนี้กลับกลายเป็นสิ่งที่ยอมรับไม่ได้ ผู้ใช้คาดหวังการตอบกลับที่รวดเร็วและสม่ำเสมอมากขึ้น และสังเกตเห็นความแปรปรวนใดๆ ก็ตาม โครงสร้างพื้นฐานที่ช่วยให้คุณดำเนินการได้อย่างรวดเร็วตั้งแต่เริ่มต้นตอนนี้เป็นสิ่งที่ทำให้คุณช้าลง การอนุมานเฉพาะจะแก้ปัญหานี้ได้อย่างหมดจด คุณจอง GPU โมเดลของคุณยังคงโหลดอยู่ และทุกคำขอจะได้รับประสบการณ์แบบเดียวกัน ไม่มีการแชร์ ไม่มีความล่าช้าในการหมุน ไม่มีเรื่องเซอร์ไพรส์
เศรษฐศาสตร์ก็เปลี่ยนเช่นกัน เมื่อระบบของคุณทำงานอยู่เสมอ การชำระค่าประมวลผลแบบสงวนจะมีราคาถูกกว่าการจ่ายต่อการใช้งาน ตัวอย่างเช่น อุปกรณ์ปลายทางเฉพาะของ Together.ai เริ่มต้นที่ประมาณ 3.99 ดอลลาร์ต่อชั่วโมงสำหรับ H100 ที่การรับส่งข้อมูลที่สม่ำเสมอ มักจะน้อยกว่าที่คุณใช้ไปกับระบบไร้เซิร์ฟเวอร์ พร้อมด้วยประสิทธิภาพที่ดีกว่า สิ่งที่คุณได้รับไม่ใช่แค่ต้นทุนที่ลดลงหรือการตอบกลับที่เร็วขึ้นเท่านั้น มันคือความมั่นคง คุณหยุดปรับแต่งโครงสร้างพื้นฐานของคุณและเริ่มเชื่อถือมัน นั่นคือเมื่อคุณสามารถมุ่งความสนใจไปที่การสร้างผลิตภัณฑ์ได้อย่างเต็มที่ โดยไม่ต้องจัดการเลเยอร์ที่อยู่ด้านล่าง ระบบไร้เซิร์ฟเวอร์ไม่ได้หายไปโดยสิ้นเชิง ยังคงรองรับกรณี Edge:การเพิ่มขึ้นอย่างฉับพลันที่ไม่คาดคิด คุณลักษณะทดลอง และงานความถี่ต่ำ แต่มันไม่ได้แบกภาระงานหลักของคุณอีกต่อไป โครงสร้างพื้นฐานเฉพาะทำสิ่งนั้นได้แล้ว

วิธีที่นักพัฒนาสัมผัสประสบการณ์จริงของแพลตฟอร์มการอนุมานแบบไร้เซิร์ฟเวอร์

วิธีที่ดีในการทำความเข้าใจว่าระบบเหล่านี้ทำงานอย่างไรคือการดูว่านักพัฒนาโต้ตอบกับแพลตฟอร์มที่ใช้กันทั่วไปสองแพลตฟอร์มอย่างไร:Modal และ Together.ai ทั้งสองเริ่มต้นจากแนวคิดที่คล้ายกันซึ่งทำให้โครงสร้างพื้นฐานเป็นนามธรรม แต่วิธีที่นามธรรมปรากฏขึ้นในทางปฏิบัติ (โดยเฉพาะการกำหนดราคาและการปรับขนาด) จะเผยให้เห็นว่าสิ่งใดทำงานได้ดีและจุดใดที่การแลกเปลี่ยนเริ่มต้นขึ้น

โมดอล

Modal ได้รับการออกแบบโดยใช้โมเดลไร้เซิร์ฟเวอร์ซึ่งคุณต้องจ่ายค่าเวลาประมวลผลอย่างเคร่งครัด ตัวอย่างเช่น การใช้งาน GPU จะเรียกเก็บเงินต่อวินาที ประมาณ 0.0002 USD/วินาทีสำหรับ GPU ขนาดเล็ก (เช่น L4) ไปจนถึงประมาณ 0.0011 USD/วินาทีสำหรับ GPU ระดับไฮเอนด์ เช่น H100 ซึ่งแปลเป็นประมาณ 0.8–4 USD ต่อชั่วโมง ขึ้นอยู่กับฮาร์ดแวร์ นอกจากนี้ยังมีรุ่นฟรีพร้อมเครดิตรายเดือนประมาณ $30 ซึ่งทำให้ง่ายต่อการเริ่มต้นโดยไม่ต้องจ่ายล่วงหน้า ในทางปฏิบัติ วิธีนี้ใช้ได้ผลดีมากกับปริมาณงานที่มีปริมาณมาก เช่น API การสร้างอิมเมจที่ได้รับการรับส่งข้อมูลเมื่อผู้ใช้ทริกเกอร์เท่านั้น หรืองานเบื้องหลังที่ทำงานสองถึงสามครั้งต่อวัน คุณไม่ต้องจ่ายเงินสำหรับ GPU ที่ไม่ได้ใช้งาน และการปรับขนาดจะเกิดขึ้นโดยอัตโนมัติ แต่เมื่อการใช้งานมีความต่อเนื่อง สมมติว่าคุณกำลังใช้งานโมเดลการตรวจจับวัตถุแบบเรียลไทม์ที่จัดการรูปภาพอย่างต่อเนื่องตลอดทั้งวัน โมเดลการกำหนดราคาจะเริ่มเปิดเผยข้อด้อยของมัน คุณจะไม่ได้รับประโยชน์จาก "จ่ายเฉพาะเมื่อใช้" อีกต่อไป เนื่องจากระบบมีการใช้งานอยู่เสมอ แต่คุณจะเช่า GPU ตัวเดิมซ้ำแล้วซ้ำเล่าอย่างมีประสิทธิภาพโดยเพิ่มทีละน้อย ซึ่งมักจะมีต้นทุนสะสมที่สูงกว่าการเช่า GPU เพียงอย่างเดียว ในเวลาเดียวกัน คุณลักษณะด้านประสิทธิภาพ เช่น การเริ่มเย็นและการนำคอนเทนเนอร์กลับมาใช้ซ้ำทำให้เกิดความแปรปรวนที่ยากต่อการเพิกเฉยในสภาพแวดล้อมการผลิต

Together.ai

Together.ai เริ่มต้นด้วย API แบบไร้เซิร์ฟเวอร์ แต่สิ่งที่ทำให้น่าสนใจสำหรับระบบที่กำลังเติบโตก็คือ มันไม่ได้บังคับให้คุณเปลี่ยนแพลตฟอร์มเมื่อความต้องการของคุณเปลี่ยนไป คุณสามารถย้ายจากการใช้งาน API พื้นฐานไปยังปลายทาง GPU เฉพาะโดยไม่ต้องเปลี่ยนวิธีโค้ดของคุณ

ในระดับเริ่มต้น คุณจะต้องจ่ายต่อโทเค็น ราคาแตกต่างกันไปตามรุ่น ประมาณ 0.10 ถึง 3 เหรียญสหรัฐต่อล้านโทเค็น ซึ่งทำงานได้ดีเมื่อมีการจราจรน้อยหรือคาดเดาไม่ได้ คุณจะได้รับการปรับขนาดอัตโนมัติและไม่มีโครงสร้างพื้นฐานให้จัดการ เป็นจุดเริ่มต้นที่สมเหตุสมผลสำหรับกรณีการใช้งานส่วนใหญ่

เมื่อการรับส่งข้อมูลเพิ่มขึ้นและเวลาแฝงเริ่มมีความสำคัญ Together.ai ช่วยให้คุณย้ายไปยังตำแหน่งข้อมูลเฉพาะได้ คุณเลือกฮาร์ดแวร์ของคุณ:H100 ราคาประมาณ 3.99 เหรียญต่อชั่วโมง หรือ H200 ราคาประมาณ 5.49 เหรียญต่อชั่วโมง และ GPU นั้นเป็นของคุณ ไม่มีการใช้คอมพิวเตอร์ร่วมกัน ไม่มีการรบกวนจากเวิร์คโหลดอื่นๆ โมเดลยังคงโหลดอยู่ และโปรไฟล์เวลาในการตอบสนองของคุณจะสอดคล้องกัน

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

สำหรับทีมที่กำลังขยายขนาด ข้อได้เปรียบเชิงปฏิบัติของ Together.ai ก็คือเส้นทางการย้ายข้อมูลนั้นเป็นเส้นทางภายใน คุณไม่ได้สร้างการบูรณาการใหม่เพื่อรับประสิทธิภาพเฉพาะ คุณเปลี่ยนการกำหนดค่าปลายทาง ซึ่งจะช่วยขจัดอุปสรรคที่แท้จริงประการหนึ่งต่อการเปลี่ยนแปลงในเวลาที่เหมาะสม แทนที่จะล่าช้าเพราะสวิตช์รู้สึกว่ารบกวนเกินไป

ตัวอย่างเช่น การใช้โมเดลขนาดกลางอาจมีราคาประมาณ 0.10–0.60 เหรียญสหรัฐฯ ต่อโทเค็นอินพุตหนึ่งล้านรายการ โดยบางครั้งโทเค็นเอาต์พุตจะสูงกว่านี้ขึ้นอยู่กับรุ่น ทำให้ใช้งานง่ายสำหรับกรณีการใช้งาน เช่น แชทบอทหรือ API การสร้างข้อความ ซึ่งต้นทุนจะปรับขนาดตามการใช้งาน ตัวอย่างเช่น บอทสนับสนุนลูกค้าที่สร้างโทเค็นสองสามล้านต่อวันอาจมีค่าใช้จ่ายหลายสิบถึงหลายร้อยดอลลาร์ต่อเดือน ขึ้นอยู่กับปริมาณ ในเวลาเดียวกัน Together.ai เสนออุปกรณ์ปลายทาง GPU เฉพาะโดยเริ่มต้นที่ประมาณ 3.99 ดอลลาร์ต่อชั่วโมงสำหรับ H100 เมื่อปริมาณงานคงที่ สิ่งนี้สะท้อนให้เห็นถึงรูปแบบทั่วไป:นักพัฒนาเริ่มต้นด้วยการใช้งาน API แบบธรรมดา แต่เมื่อการรับส่งข้อมูลมีความเสถียรและความคาดหวังด้านเวลาแฝงเพิ่มขึ้น พวกเขามักจะหันไปใช้การตั้งค่าเฉพาะเพื่อประสิทธิภาพและต้นทุนที่คาดการณ์ได้มากขึ้น

การเปลี่ยนแปลงที่สำคัญไม่ใช่แพลตฟอร์ม แต่เป็นวิธีการใช้งานของคุณเมื่อเวลาผ่านไป :

• ระยะเริ่มต้น → คุณใช้มันเหมือนกับ API ธรรมดา
• ระยะการเติบโต → คุณเริ่มกังวลเกี่ยวกับเวลาแฝงและต้นทุน
• ปรับขนาด → คุณย้ายไปยังปลายทางเฉพาะ ภายในแพลตฟอร์มเดียวกัน

ดังนั้นจึงไม่เหมือนกับแพลตฟอร์มไร้เซิร์ฟเวอร์ตรงที่คุณไม่จำเป็นต้องเปลี่ยนผู้ให้บริการ แต่คุณเปลี่ยนโหมดได้ .

ข้อควรพิจารณาก่อนตัดสินใจ

• ต้นทุนมีระดับแตกต่างไปจากที่คุณคาดหวัง: แพลตฟอร์มแบบไร้เซิร์ฟเวอร์จะเรียกเก็บเงินตามอัตราความต้องการคงที่สำหรับการประมวลผลทุก ๆ วินาที เมื่อระบบของคุณไม่ได้ใช้งาน โมเดลนั้นจะมีประสิทธิภาพ เมื่อระบบของคุณทำงานอย่างต่อเนื่อง อัตราเดียวกันนั้นจะทำงานตลอดเวลาโดยไม่มีการผ่อนปรน โครงสร้างพื้นฐานที่รองรับกำลังการผลิตแบบเหมาจ่ายสามารถลดต้นทุนรายชั่วโมงที่มีประสิทธิภาพลงอย่างมาก บางครั้งอาจมากกว่าครึ่งหนึ่ง ยิ่งสามารถคาดเดาภาระงานของคุณได้นานเท่าไร ความแตกต่างก็จะเพิ่มมากขึ้น
• ค่าเริ่มต้นที่มีการจัดการกลายเป็นข้อจำกัดเมื่อเวลาผ่านไป :บางครั้งแพลตฟอร์มการอนุมานที่ได้รับการจัดการ จะทำการตัดสินใจในการกำหนดค่าในนามของคุณ การเพิ่มประสิทธิภาพใดทำงาน วิธีจัดการหน่วยความจำ และวิธีแบทช์คำขอ ในระยะแรก ค่าเริ่มต้นเหล่านั้นจะช่วยประหยัดเวลา ต่อมา เมื่อคุณต้องการปรับแต่งเลเยอร์การอนุมานสำหรับปริมาณงานเฉพาะของคุณ ค่าเริ่มต้นเดียวกันนั้นจะเข้ามาขวางทาง ถ้าคุณไม่สามารถเข้าถึงการกำหนดค่าได้ คุณจะไม่สามารถเปลี่ยนแปลงได้ การเป็นเจ้าของโครงสร้างพื้นฐานหมายความว่าการตั้งค่าเหล่านั้นเป็นของคุณ
• การมองเห็นของคุณถูกจำกัดอยู่เพียงสิ่งที่แพลตฟอร์มแสดงให้คุณเห็น :บนแพลตฟอร์มที่มีการจัดการ เมื่อมีบางอย่างผิดพลาดหรือค่าใช้จ่ายพุ่งสูงขึ้นอย่างไม่คาดคิด ความสามารถในการตรวจสอบของคุณจะถูกจำกัดอยู่ที่แดชบอร์ดที่แพลตฟอร์มสร้างขึ้นสำหรับคุณ คุณจะเห็นว่าบางสิ่งบางอย่างช้าหรือมีราคาแพง แต่การติดตามว่าทำไมจึงเป็นเรื่องยากเมื่อชั้นโครงสร้างพื้นฐานอยู่ไกลเกินเอื้อม โครงสร้างพื้นฐานเฉพาะทำให้คุณสามารถสังเกตได้เต็มรูปแบบทั้งการประมวลผล เครือข่าย และพื้นที่จัดเก็บข้อมูล คุณเห็นทุกสิ่งและคุณสามารถดำเนินการได้
• การควบคุมที่มากขึ้นหมายถึงความรับผิดชอบที่มากขึ้น: การเป็นเจ้าของโครงสร้างพื้นฐานช่วยให้คุณมีต้นทุนที่ลดลง การควบคุมที่ลึกยิ่งขึ้น และการมองเห็นที่สมบูรณ์ แต่ยังหมายความว่าคุณต้องดำเนินการตั้งค่าและการปฏิบัติงานที่แพลตฟอร์มที่ได้รับการจัดการจัดการให้กับคุณ นั่นไม่ใช่การโทรที่ถูกต้องเสมอไป โดยเฉพาะอย่างยิ่งหากทีมของคุณมีขนาดเล็กหรือปริมาณงานของคุณยังคงเปลี่ยนแปลง อย่างไรก็ตาม แพลตฟอร์มที่เหมาะสมจะสร้างสมดุลที่เหมาะสมเสมอเพื่อลดช่องว่างระหว่างแพลตฟอร์มที่มีการจัดการและแพลตฟอร์มที่จัดการด้วยตนเอง ขณะนี้แพลตฟอร์มโครงสร้างพื้นฐานบางแพลตฟอร์มมาพร้อมกับอิมเมจการอนุมานที่กำหนดค่าไว้ล่วงหน้า การใช้งาน GPU เพียงคลิกเดียว และการสนับสนุน Kubernetes ทันที ซึ่งหมายความว่าคุณไม่ได้เริ่มต้นจากศูนย์ ค่าใช้จ่ายในการดำเนินงานเป็นเรื่องจริง แต่เบากว่าที่เคยเป็นมาก

บทสรุป

การอนุมานแบบไร้เซิร์ฟเวอร์ช่วยให้คุณเริ่มต้น ทดลอง และจัดส่งได้อย่างรวดเร็วโดยไม่มีข้อขัดแย้ง แต่เมื่อระบบของคุณเติบโตขึ้น สิ่งที่เป็นนามธรรมซึ่งครั้งหนึ่งเคยช่วยให้คุณดำเนินการได้เร็วขึ้นสามารถเริ่มซ่อนสิ่งที่สำคัญที่สุดได้ เช่น ความสอดคล้องของเวลาแฝง ปริมาณการประมวลผล และความคุ้มค่า แพลตฟอร์มอย่าง Modal และ Together.ai ทำให้ง่ายต่อการสร้างและปรับขนาดตั้งแต่เนิ่นๆ และในหลายกรณี แพลตฟอร์มเหล่านี้ยังคงเป็นส่วนหนึ่งของสถาปัตยกรรมในภายหลัง แต่เมื่อปริมาณงานสามารถคาดเดาได้และความคาดหวังก็เข้มงวดขึ้น ความจำเป็นในการควบคุมที่มากขึ้นจึงเป็นสิ่งที่หลีกเลี่ยงไม่ได้ ระบบในโลกแห่งความเป็นจริงไม่คงที่ พวกมันเปลี่ยนจากความไม่แน่นอนไปสู่การคาดเดาได้ จากการทดลองไปสู่การผลิต และเมื่อพวกเขาทำเช่นนั้น ตัวเลือกโครงสร้างพื้นฐานที่ "ถูกต้อง" ก็จะเปลี่ยนไปตามพวกเขา ข้อผิดพลาดที่แท้จริงที่ทีมทำคือการปฏิบัติต่อระบบไร้เซิร์ฟเวอร์เสมือนเป็นค่าเริ่มต้นระยะยาว แทนที่จะเป็นสิ่งที่เป็นจริง:ระยะหนึ่ง ยิ่งคุณชะลอการย้ายไปยังโครงสร้างพื้นฐานเฉพาะนานขึ้นเมื่อปริมาณงานของคุณเสถียรแล้ว คุณก็จะยิ่งต้องเสียค่าใช้จ่ายในด้านต้นทุน ประสิทธิภาพ หรือทั้งสองอย่างมากขึ้น

งานนี้ได้รับอนุญาตภายใต้ Creative Commons Attribution-NonCommercial- ShareAlike 4.0 International License