กำไร:
- ความสามารถในการประเมินการแลกเปลี่ยนระหว่าง API ที่มีการจัดการ, VPC และโฮสติ้งภายในองค์กร
- ความสามารถในการตัดสินใจเลือกโฮสติ้งตามอธิปไตยของข้อมูล ปริมาณ และความสามารถในการดำเนินงาน
- ความสามารถในการคำนวณต้นทุนรวมในการเป็นเจ้าของ (TCO) ด้วยรายการทั้งหมดและออกแบบสถาปัตยกรรมแบบไฮบริด
สำหรับบางองค์กร “การส่งข้อมูลไปยังผู้ให้บริการ” — ไม่ว่าจะปลอดภัยแค่ไหน — เป็นสิ่งที่ยอมรับไม่ได้ ในอุตสาหกรรมการป้องกันประเทศ สาธารณะ การธนาคาร และสถานการณ์ด้านสุขภาพบางสถานการณ์ ข้อมูลไม่ควรเกินขอบเขตของสถาบัน ณ จุดนี้ การโฮสต์โมเดลของคุณเองเป็นสิ่งสำคัญที่สุด: โมเดลแบบ open-weight ที่ทำงานบนเครือข่ายคลาวด์ (VPC) ของคุณเอง หรือบนเซิร์ฟเวอร์ของคุณเอง (ภายในองค์กร) ในหน่วยนี้ เราจะเรียนรู้ข้อดีข้อเสียระหว่าง API ที่มีการจัดการและการโฮสต์ด้วยตนเอง เมื่อสมเหตุสมผล และต้นทุนรวมในการเป็นเจ้าของ (TCO)
แนวคิด
- Managed API: ทำงานบนโครงสร้างพื้นฐานของผู้ให้บริการโมเดล คุณส่งคำขอและรับการตอบกลับ ค่าใช้จ่ายในการดำเนินงานมีน้อย แต่ข้อมูลจะตกเป็นของผู้ให้บริการ
- โมเดลน้ำหนักเปิด: สามารถดาวน์โหลดพารามิเตอร์โมเดล (น้ำหนัก) ได้ คุณสามารถรันบนฮาร์ดแวร์ของคุณเองได้ ไม่จำเป็นต้องเหมือนกับ "โอเพ่นซอร์ส" (ใบอนุญาตอาจแตกต่างกัน)
- โฮสติ้ง VPC (Virtual Private Cloud): การรันโมเดลในเครือข่ายคลาวด์แบบแยกของคุณเอง ข้อมูลยังคงอยู่ที่ขอบเขตเครือข่ายของคุณ แต่โครงสร้างพื้นฐานยังคงอยู่ในระบบคลาวด์
- ภายในองค์กร (ภายในองค์กร): การรันโมเดลทั้งหมดบนฮาร์ดแวร์ในศูนย์ข้อมูลของคุณเอง การควบคุมสูงสุด โหลดการปฏิบัติงานสูงสุด
ข้อควรระวัง: "โฮสติ้งของตัวเองปลอดภัยกว่าเสมอ" ถือเป็นความเข้าใจผิด การรักษาความปลอดภัยขึ้นอยู่กับว่าคุณเก็บข้อมูลไว้ที่ใด แต่ขึ้นอยู่กับว่าคุณจัดการข้อมูลได้ดีเพียงใด เซิร์ฟเวอร์ภายในองค์กรที่ไม่ได้รับการติดตั้งและกำหนดค่าไม่ดีมีความเสี่ยงมากกว่า API ที่มีการจัดการที่สมบูรณ์
แกนการตัดสินใจ: เมื่อไร?
คำถามสามข้อเป็นแนวทางในการตัดสินใจ:
- อธิปไตยของข้อมูล: กฎหมายหรือสัญญาห้ามไม่ให้ข้อมูลออกจากสถาบัน/ประเทศหรือไม่ หากใช่ คุณจะถูกผลักดันไปยัง VPC/ภายในองค์กร
- ปริมาณและต้นทุน: การใช้งานสูงมากและสามารถคาดเดาได้หรือไม่? การโฮสต์ด้วยตนเองในปริมาณที่สูงมากสามารถลดต้นทุนต่อหน่วยได้ API ที่จัดการที่ปริมาณต่ำ/ไม่แน่นอนมักจะมีราคาถูกเกือบทุกครั้ง
- ความสามารถในการดำเนินงาน: คุณมีทีมที่จะดูแลโครงสร้างพื้นฐาน GPU, การอัปเดตโมเดล, การปรับขนาด และแพตช์ความปลอดภัยหรือไม่? ไม่เช่นนั้นโฮสติ้งของคุณเองจะเป็นค่าใช้จ่ายแอบแฝง
ตารางการแลกเปลี่ยน
ขนาด
API ที่มีการจัดการ
วีพีซี
ออน-เปรม (โอเพ่นเวท)
อธิปไตยของข้อมูล
ไว้วางใจผู้ให้บริการ
สูง (ที่ขีดจำกัดเครือข่ายของคุณ)
สูงสุด (ไม่เคยเพิ่มขึ้น)
โหลดการดำเนินงาน
ต่ำเกินไป
ปานกลาง
สูง
ต้นทุนเริ่มต้น
ต่ำ (จ่ายตามที่คุณไป)
ปานกลาง
สูง (ฮาร์ดแวร์)
การปรับขนาด
อัตโนมัติ
จัดการ
ความรับผิดชอบของคุณ
คุณภาพโมเดล/สกุลเงิน
ใหม่ล่าสุดอัตโนมัติ
ขึ้นอยู่กับ
คุณอัปเดต
การควบคุม
ต่ำ
สูง
เต็ม
ทีละขั้นตอน: การตัดสินใจโฮสติ้ง
- กำหนดคลาสข้อมูล ข้อมูลจะถูกประมวลผลในระดับการรักษาความลับระดับใด?
- ตรวจสอบข้อจำกัดทางกฎหมาย ข้อมูลสามารถออกไปได้หรือไม่? (KVKK, กฎระเบียบภาคส่วน, สัญญา)
- ประมาณปริมาณ ปริมาณคำขอ/โทเค็นรายเดือนและกราฟการเติบโต
- คำนวณ TCO ไม่ใช่แค่ GPU เท่านั้น พลังงาน การบำรุงรักษา ทีม ความปลอดภัย ความซ้ำซ้อน
- คิดว่าไฮบริด โมเดลไฮบริดที่ประมวลผลข้อมูลที่ละเอียดอ่อนในองค์กร/VPC และข้อมูลที่ไม่ละเอียดอ่อนใน API ที่มีการจัดการมักจะมีเสถียรภาพมากที่สุด
เทมเพลตที่คัดลอกได้สี่แบบ
พร้อมท์การตัดสินใจโฮสติ้ง:
ตัดสินใจเลือกโฮสติ้งสำหรับการใช้งานต่อไปนี้: {{ สถานการณ์ }}คำถาม:- ระดับความเป็นส่วนตัวของข้อมูลที่จะประมวลผลคืออะไร? (สาธารณะ/ภายใน/ความลับ/ความลับสุดยอด)- กฎหมาย/สัญญาอนุญาตให้ข้อมูลออกไปนอกองค์กรหรือไม่- การคาดการณ์ปริมาณรายเดือนและความสามารถในการคาดการณ์ได้- มีการปฏิบัติงาน/ความสามารถของทีม GPU หรือไม่ คำแนะนำ: "Managed API / VPC / On-prem / Hybrid" + การให้เหตุผล
รายการรายการ TCO (สำหรับการโฮสต์ด้วยตนเอง):
คำนวณต้นทุนรวมในการเป็นเจ้าของโดย: - การซื้อ/เช่าฮาร์ดแวร์ (GPU) - พลังงานและการทำความเย็น - บุคคล: MLOps + เวลาของทีมรักษาความปลอดภัย - การอัปเดตโมเดลและการทดสอบกำลังคน - การสำรอง/การกู้คืนจากภัยพิบัติ - แพตช์ความปลอดภัยและการตรวจสอบ เปรียบเทียบสิ่งนี้กับการเรียกเก็บเงินรายเดือนสำหรับ API ที่มีการจัดการในช่วงระยะเวลา 12-24 เดือน
กฎการกำหนดเส้นทางแบบไฮบริด:
กำหนดเส้นทางคำขอแต่ละรายการตามคลาสข้อมูล:- ข้อมูล "ความลับ / ความลับสุดยอด" -> โมเดลภายในองค์กร/VPC- ข้อมูล "สาธารณะ / ภายใน" -> API ที่มีการจัดการ (มีประสิทธิภาพมากกว่า/ถูกกว่า) เขียนการตัดสินใจการส่งต่อและคลาสข้อมูลไปยังบันทึกการตรวจสอบ
เปิดพร้อมท์การตรวจสอบความปลอดภัยของน้ำหนัก:
ประเมินโมเดลที่โฮสต์เองของเรา:- ใบอนุญาตอนุญาตให้ใช้ในเชิงพาณิชย์และในสถานการณ์ของเราหรือไม่- น้ำหนักโมเดลจากแหล่งที่มาที่เชื่อถือได้ การตรวจสอบความสมบูรณ์ (แฮช) หรือไม่- มีการติดตั้งแพตช์เซิร์ฟเวอร์ การแยกเครือข่าย การควบคุมการเข้าถึงหรือไม่- การตรวจสอบและการบันทึกมีความสมบูรณ์เท่ากับ API ที่มีการจัดการหรือไม่ ทำเครื่องหมายรายการที่ขาดหายไปเป็น "เปิด"
พรอมต์ที่อ่อนแอ / พรอมต์ที่แข็งแกร่ง
วิธีการที่ไม่ดี
แนวทางที่แข็งแกร่ง
"ภายในองค์กรปลอดภัยกว่า ใช้มันเสมอ"
การตัดสินใจขึ้นอยู่กับอธิปไตยของข้อมูล + ปริมาณ + ความจุ
แค่ดูราคา GPU
TCO เต็มรูปแบบ (พลังงาน ลูกเรือ การอัปเดต ความปลอดภัย)
ถูกล็อคให้อยู่ในรูปแบบโฮสติ้งเดียว
ไฮบริด: การกำหนดเส้นทางตามคลาสข้อมูล
วิ่งโดยไม่ลดน้ำหนักเปิดและตรวจสอบ
ใบอนุญาต + ความสมบูรณ์ + แพตช์ + การควบคุมการติดตาม
มินิเคสสามอัน
กรณีที่ 1 — คำสั่งภายในองค์กรเป็นการตัดสินใจที่ถูกต้อง ผู้รับเหมาด้านการป้องกันจะต้องประมวลผลเอกสารที่เป็นความลับสูง สัญญาห้ามนำข้อมูลออกนอกประเทศ Managed API ถูกกำจัดตั้งแต่ต้น แบบจำลองน้ำหนักเปิดภายในองค์กรถูกสร้างขึ้น ค่าใช้จ่ายสูง แต่เป็นเพียงตัวเลือกเดียวที่เข้ากันได้
กรณีที่ 2 — การกลับคำตัดสิน TCO ที่เป็นความลับ สตาร์ทอัพวางแผนที่จะเปลี่ยนไปใช้การโฮสต์ด้วยตนเองเนื่องจาก “API มีราคาแพง” ในการคำนวณ TCO คุณไม่ได้รวมเฉพาะ GPU เท่านั้น เพิ่มวิศวกร MLOps แบบเต็มเวลา 2 คน อัปเดตโหลด และความซ้ำซ้อน และยอดรวม 24 เดือนเป็นสองเท่าของ API ที่มีการจัดการ พวกเขายังคงอยู่ใน API เนื่องจากมีปริมาณน้อยและเป็นระยะๆ
กรณีที่ 3 — ไฮบริดให้สิ่งที่ดีที่สุด ผู้ช่วยศูนย์บริการทางโทรศัพท์ของธนาคารกำลังประมวลผลข้อมูลสองประเภท: คำถามทั่วไปเกี่ยวกับผลิตภัณฑ์และข้อมูลบัญชีเฉพาะของลูกค้า ข้อมูลบัญชีจะถูกส่งไปยังโมเดลภายใน VPC คำถามทั่วไปจะถูกส่งไปยัง API ที่มีการจัดการที่มีประสิทธิภาพ ข้อมูลที่ละเอียดอ่อนไม่เคยถูกเปิดเผย คุณภาพของแบบจำลองที่แข็งแกร่งที่สุดถูกใช้สำหรับคำถามทั่วไป ต้นทุนและความพอดีได้รับการปรับให้เหมาะสมร่วมกัน
เคล็ดลับ: การตัดสินใจไม่จำเป็นต้องเป็นแบบไบนารี่ (ทั้งหมดหรือไม่มีเลย) สถาปัตยกรรมไฮบริด — การกำหนดเส้นทางข้อมูลตามคลาส — ช่วยแก้ปัญหาการปฏิบัติตามข้อกำหนดและต้นทุนในสถานการณ์องค์กรส่วนใหญ่ไปพร้อมๆ กัน
ข้อผิดพลาดทั่วไป
- สมมติว่า "โฮสติ้งของตัวเองปลอดภัยกว่าโดยอัตโนมัติ"; ในขณะที่ความปลอดภัยขึ้นอยู่กับคุณภาพของการจัดการ
- การคิดว่า TCO เป็นเพียงต้นทุน GPU ทีมงาน พลังงาน อัพเดทจนลืมเรื่องความปลอดภัย
- เปลี่ยนไปใช้การโฮสต์ด้วยตนเองในปริมาณน้อย/ไม่ปกติ และเพิ่มต้นทุนต่อหน่วย
- การใช้โมเดล Open Weight โดยไม่ต้องตรวจสอบใบอนุญาตและความสมบูรณ์ (แฮช)
- ไม่ติดตั้งการตรวจสอบ/การบันทึกที่ครบกำหนดเท่ากับ API ที่มีการจัดการบนเซิร์ฟเวอร์ภายในองค์กร
- ทำการตัดสินใจแบบไบนารี่โดยไม่คำนึงถึงตัวเลือกแบบไฮบริดเลย
โดยสรุป
- API ที่มีการจัดการเป็นวิธีการดำเนินงานที่ง่ายที่สุด แต่ข้อมูลจะถูกส่งไปยังผู้ให้บริการ VPC/on-prem เก็บข้อมูลไว้ที่ขอบเขตของคุณ
- คำถามสามข้อที่ขับเคลื่อนการตัดสินใจ ได้แก่ อธิปไตยของข้อมูล ความสามารถในการคาดการณ์ปริมาณ/ต้นทุน และความสามารถในการดำเนินงาน
- "การโฮสต์ด้วยตนเองมีความปลอดภัยมากกว่า" เป็นความเข้าใจผิด ความปลอดภัยไม่ได้ขึ้นอยู่กับว่าคุณเก็บข้อมูลไว้ที่ใด แต่ขึ้นอยู่กับว่าคุณจัดการข้อมูลได้ดีเพียงใด
- คำนวณ TCO ที่แน่นอน: พลังงาน ทีม การอัปเดต ความซ้ำซ้อนและความปลอดภัย รวมถึง GPU
- สถาปัตยกรรมไฮบริด (ข้อมูลการกำหนดเส้นทางตามคลาส) สร้างสมดุลระหว่างการปฏิบัติตามข้อกำหนดและต้นทุนในสถานการณ์องค์กรส่วนใหญ่ไปพร้อมๆ กัน
งานสมัคร
เลือกการใช้งาน AI และแยกข้อมูลที่จะประมวลผลเป็นระดับความเป็นส่วนตัว สร้างคำแนะนำโดยพร้อมท์การตัดสินใจเป็นเจ้าภาพ จากนั้นกรอกรายการ TCO สำหรับโฮสติ้งของคุณเอง และเปรียบเทียบยอดรวม 24 เดือนกับบิล API ที่มีการจัดการ สุดท้าย ให้เขียนกฎการกำหนดเส้นทางแบบไฮบริดแบบร่าง: ข้อมูลใดจะไปอยู่ที่ไหน
รายการตรวจสอบ
- [ ] ฉันได้กำหนดระดับการรักษาความลับและข้อจำกัดทางกฎหมายของข้อมูลที่จะประมวลผลแล้ว
- [ ] ฉันตัดสินใจเป็นเจ้าภาพโดยพิจารณาจากอำนาจอธิปไตย + ปริมาณ + ความจุ
- [ ] ฉันคำนวณ TCO ด้วยรายการทั้งหมด (รวมถึงรายการที่ไม่ใช่ GPU)
- [ ] ฉันตรวจสอบใบอนุญาต ความสมบูรณ์ การแพตช์ และการตรวจสอบการโฮสต์ด้วยตนเอง
- [ ] ฉันพิจารณาตัวเลือกเส้นทางแบบไฮบริด
- [ ] ฉันบันทึกการตัดสินใจและเหตุผลของการตัดสินใจไว้เป็นเอกสาร