Code Velocity
AI ระดับองค์กร

วงจรชีวิตโมเดล Amazon Bedrock: ทำความเข้าใจการเปลี่ยนผ่าน

·4 นาทีอ่าน·AWS·แหล่งที่มา
แชร์
แผนภาพแสดงสถานะวงจรชีวิตทั้งสามของโมเดล Amazon Bedrock: Active (ใช้งาน), Legacy (รุ่นเก่า) และ End-of-Life (EOL – สิ้นสุดการสนับสนุน)

title: "วงจรชีวิตโมเดล Amazon Bedrock: ทำความเข้าใจการเปลี่ยนผ่าน" slug: "understanding-amazon-bedrock-model-lifecycle" date: "2026-04-10" lang: "th" source: "https://aws.amazon.com/blogs/machine-learning/understanding-amazon-bedrock-model-lifecycle/" category: "AI ระดับองค์กร" keywords:

  • Amazon Bedrock
  • วงจรชีวิตโมเดล
  • โมเดลพื้นฐาน
  • โมเดล EOL
  • โมเดลเก่า
  • AWS AI
  • การจัดการแอปพลิเคชัน AI
  • การโยกย้ายโมเดล
  • การเข้าถึงแบบขยาย
  • ปริมาณงานที่จัดเตรียมไว้
  • โควต้าบริการ
  • การพัฒนา AI meta_description: "ทำความเข้าใจวงจรชีวิตโมเดลของ Amazon Bedrock รวมถึงสถานะ Active, Legacy และ EOL เรียนรู้การวางแผนการโยกย้าย การจัดการการเปลี่ยนผ่าน และการรับรองการทำงานของแอปพลิเคชัน AI อย่างต่อเนื่องด้วยแนวปฏิบัติที่ดีที่สุด" image: "/images/articles/understanding-amazon-bedrock-model-lifecycle.png" image_alt: "แผนภาพแสดงสถานะวงจรชีวิตทั้งสามของโมเดล Amazon Bedrock: Active (ใช้งาน), Legacy (รุ่นเก่า) และ End-of-Life (EOL – สิ้นสุดการสนับสนุน)" quality_score: 94 content_score: 93 seo_score: 95 companies:
  • AWS schema_type: "NewsArticle" reading_time: 4 faq:
  • question: "สถานะหลักสามประการของโมเดล Amazon Bedrock คืออะไรและมีความหมายอย่างไร?" answer: "โมเดล Amazon Bedrock เปลี่ยนผ่านสถานะวงจรชีวิตที่สำคัญสามสถานะ ได้แก่ Active (ใช้งาน), Legacy (รุ่นเก่า) และ End-of-Life (EOL – สิ้นสุดการสนับสนุน) โมเดล 'Active' ได้รับการบำรุงรักษาอย่างต่อเนื่อง อัปเดต และแก้ไขข้อผิดพลาด และได้รับการสนับสนุนอย่างเต็มที่สำหรับการอนุมาน การปรับแต่ง (ถ้ามี) และการเพิ่มโควต้า เมื่อโมเดลเปลี่ยนไปสู่สถานะ 'Legacy' หมายความว่ามีเวอร์ชันใหม่กว่าหรือทางเลือกอื่นพร้อมใช้งาน และลูกค้าควรวางแผนการโยกย้าย ในช่วงเวลานี้ ผู้ใช้ปัจจุบันสามารถใช้งานต่อไปได้ แต่การเข้าถึงใหม่ๆ อาจถูกจำกัด และความสามารถในการปรับแต่งอาจถูกจำกัด สถานะ 'EOL' หมายความว่าโมเดลไม่สามารถเข้าถึงได้โดยสมบูรณ์ในทุก AWS Region ซึ่งจำเป็นต้องมีการโยกย้ายล่วงหน้าเพื่อหลีกเลี่ยงการหยุดชะงักของแอปพลิเคชัน การทำความเข้าใจสถานะเหล่านี้เป็นสิ่งสำคัญสำหรับการจัดการแอปพลิเคชัน AI บน Amazon Bedrock อย่างมีประสิทธิภาพ"
  • question: "สถานะ 'Legacy' ส่งผลกระทบต่อผู้ใช้ Amazon Bedrock อย่างไร โดยเฉพาะอย่างยิ่งเกี่ยวกับช่วง 'Public Extended Access'?" answer: "เมื่อโมเดล Amazon Bedrock เข้าสู่สถานะ 'Legacy' ผู้ใช้จะได้รับแจ้งล่วงหน้าอย่างน้อยหกเดือนก่อนวัน End-of-Life (EOL) ซึ่งเป็นเวลาสำคัญสำหรับการวางแผนการโยกย้าย ในช่วงเวลานี้ ลูกค้าปัจจุบันสามารถใช้งานโมเดลต่อไปได้ตามปกติ แม้ว่าลูกค้าใหม่หรือบัญชีที่ไม่มีการใช้งานอาจเผชิญกับข้อจำกัดในการเข้าถึง สำหรับโมเดลที่มีวัน EOL หลังวันที่ 1 กุมภาพันธ์ 2026 สถานะ 'Legacy' จะรวมถึงช่วง 'Public Extended Access' ซึ่งกินเวลาอย่างน้อยสามเดือนหลังจากช่วงเริ่มต้นในสถานะ Legacy อย่างน้อยสามเดือน ในช่วงเวลาขยายนี้ ผู้ใช้ที่ใช้งานอยู่ยังคงเข้าถึงได้ แต่คำขอเพิ่มโควต้าอาจไม่ได้รับการอนุมัติ และราคาอาจมีการปรับเปลี่ยน ลูกค้าจะได้รับแจ้งการเปลี่ยนแปลงเหล่านี้เสมอเพื่ออำนวยความสะดวกในการเปลี่ยนผ่านจากโมเดลรุ่นเก่าอย่างราบรื่น"
  • question: "เกิดอะไรขึ้นเมื่อโมเดลพื้นฐานของ Amazon Bedrock ถึงวัน End-of-Life (EOL)?" answer: "เมื่อถึงวัน End-of-Life (EOL) โมเดลพื้นฐานของ Amazon Bedrock จะไม่สามารถเข้าถึงได้โดยสมบูรณ์ในทุก AWS Region สำหรับลูกค้าส่วนใหญ่ คำขอ API ใดๆ ที่กำหนดเป้าหมายโมเดล EOL จะล้มเหลว ทำให้แอปพลิเคชันที่ยังคงพึ่งพามันไม่สามารถทำงานได้ AWS ไม่โยกย้ายแอปพลิเคชันโดยอัตโนมัติ ลูกค้ามีหน้าที่รับผิดชอบแต่เพียงผู้เดียวในการอัปเดตโค้ดแอปพลิเคชันเพื่อใช้โมเดลทางเลือกที่รองรับ ก่อน วันที่ EOL แม้ว่าอาจมีข้อตกลงพิเศษสำหรับการเข้าถึงอย่างต่อเนื่องระหว่างลูกค้าและผู้ให้บริการบางราย แต่โดยทั่วไปแล้วจะไม่ใช่กรณีสำหรับผู้ใช้ทั่วไป การโยกย้ายเชิงรุกจึงเป็นขั้นตอนสำคัญเพื่อให้แน่ใจว่าแอปพลิเคชัน AI ที่สร้างขึ้นบน Amazon Bedrock ทำงานได้อย่างต่อเนื่อง"
  • question: "AWS สื่อสารการเปลี่ยนแปลงวงจรชีวิตโมเดล Amazon Bedrock ไปยังผู้ใช้อย่างไร?" answer: "AWS ใช้กลยุทธ์การสื่อสารหลายช่องทางเพื่อแจ้งให้ลูกค้าทราบเกี่ยวกับการเปลี่ยนแปลงสถานะโมเดล Amazon Bedrock โดยเฉพาะอย่างยิ่งเมื่อโมเดลเปลี่ยนไปสู่สถานะ 'Legacy' (หกเดือนก่อน EOL) การแจ้งเตือนจะถูกส่งผ่านอีเมล แสดงบน AWS Health Dashboard และนำเสนอเป็นการแจ้งเตือนภายในคอนโซล Amazon Bedrock นอกจากนี้ยังมีการเข้าถึงข้อมูลวงจรชีวิตโมเดลแบบโปรแกรมผ่าน API เพื่อให้แน่ใจว่าได้รับข้อมูลอัปเดตที่สำคัญเหล่านี้ ลูกค้าต้องตรวจสอบและกำหนดค่าที่อยู่อีเมลติดต่อของบัญชี รวมถึงผู้ใช้รูทและผู้ติดต่อสำรอง (การดำเนินงาน, ความปลอดภัย, การเรียกเก็บเงิน) นอกจากนี้ คอนโซล AWS User Notifications ยังช่วยให้สามารถเพิ่มผู้รับหรือช่องทางการจัดส่งเพิ่มเติม เช่น Slack หรือรายชื่ออีเมล เพื่อให้แน่ใจว่าการรับรู้ถึงการเปลี่ยนแปลงที่กำลังจะมาถึงเป็นไปอย่างทันท่วงทีและครอบคลุม"
  • question: "กลยุทธ์และแนวปฏิบัติที่ดีที่สุดที่แนะนำสำหรับการโยกย้ายแอปพลิเคชันไปยังโมเดล Amazon Bedrock ใหม่คืออะไร?" answer: "การโยกย้ายแอปพลิเคชันไปยังโมเดล Amazon Bedrock ใหม่ต้องมีการวางแผนเชิงรุกและแนวทางที่เป็นระบบ แนวปฏิบัติที่ดีที่สุดรวมถึงการเริ่มต้นวางแผนทันทีที่โมเดลเข้าสู่สถานะ 'Legacy' เริ่มต้นด้วย 'ขั้นตอนการประเมิน' เพื่อระบุแอปพลิเคชันทั้งหมดที่พึ่งพาโมเดลรุ่นเก่า วิเคราะห์รูปแบบคำขอ และทำความเข้าใจพฤติกรรมการส่งออกที่สำคัญ ตามด้วย 'ขั้นตอนการวิจัย' เพื่อตรวจสอบโมเดลทดแทนที่แนะนำอย่างละเอียด ประเมินความสามารถ ความแตกต่าง คุณสมบัติใหม่ และความพร้อมใช้งานในภูมิภาค สิ่งสำคัญคือการอัปเดตโค้ดแอปพลิเคชัน ตรวจสอบประสิทธิภาพ และยืนยันว่าโควต้าบริการสามารถรองรับปริมาณที่คาดการณ์ไว้ด้วยโมเดลใหม่ได้ แนวทางที่เป็นระบบนี้ช่วยให้การเปลี่ยนผ่านเป็นไปอย่างราบรื่นโดยมีการหยุดชะงักน้อยที่สุด โดยใช้ประโยชน์จากความสามารถที่ได้รับการปรับปรุงของโมเดลพื้นฐานใหม่"
  • question: "มีการพิจารณาเรื่องราคาในช่วงการเข้าถึงแบบขยายสำหรับโมเดล Amazon Bedrock หรือไม่?" answer: "ใช่ ราคาอาจมีการปรับเปลี่ยนโดยผู้ให้บริการโมเดลในช่วงการเข้าถึงแบบขยายสำหรับโมเดล Amazon Bedrock อย่างไรก็ตาม AWS รับรองความโปร่งใสโดยการแจ้งให้ลูกค้าทราบในการประกาศ Legacy ครั้งแรกและก่อนที่การเปลี่ยนแปลงราคาใดๆ จะมีผล เพื่อป้องกันการเพิ่มขึ้นย้อนหลังที่ไม่คาดคิด ลูกค้าที่มีข้อตกลงราคาแบบส่วนตัวกับผู้ให้บริการโมเดลโดยตรง หรือผู้ที่ใช้ปริมาณงานที่จัดเตรียมไว้ จะยังคงดำเนินการภายใต้เงื่อนไขราคาที่กำหนดไว้ตลอดช่วงการเข้าถึงแบบขยาย นโยบายนี้ออกแบบมาเพื่อปกป้องผู้ที่ได้ทำการจัดเตรียมทางการเงินเฉพาะเจาะจงหรือการลงทุนในความจุที่ทุ่มเท เพื่อให้มั่นใจถึงความสามารถในการคาดการณ์และความเสถียรแม้ว่าโมเดลจะเปลี่ยนผ่านไปสู่ End-of-Life"

## การจัดการวงจรชีวิต AI: การสำรวจการเปลี่ยนผ่านโมเดล Amazon Bedrock

วิวัฒนาการอย่างรวดเร็วของปัญญาประดิษฐ์หมายความว่าโมเดลพื้นฐาน (FMs) ได้รับการอัปเดตอย่างต่อเนื่องด้วยความสามารถที่ได้รับการปรับปรุง ความแม่นยำที่ดีขึ้น และคุณลักษณะด้านความปลอดภัยที่แข็งแกร่งขึ้น สำหรับนักพัฒนาและองค์กรที่สร้างแอปพลิเคชันที่ขับเคลื่อนด้วย AI บน Amazon Bedrock การทำความเข้าใจและจัดการวงจรชีวิตโมเดลเป็นสิ่งสำคัญอย่างยิ่งเพื่อให้มั่นใจว่าการทำงานจะต่อเนื่องและใช้ประโยชน์จากความก้าวหน้าล่าสุด การวางแผนเชิงรุกไม่ได้เป็นเพียงประโยชน์เท่านั้น แต่ยังจำเป็นอย่างยิ่งเพื่อป้องกันการหยุดชะงักและรักษาโซลูชัน AI ของคุณให้อยู่ในแนวหน้า

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

### การทำความเข้าใจสถานะวงจรชีวิตโมเดลของ Amazon Bedrock

โมเดลพื้นฐานทุกรุ่นที่นำเสนอใน Amazon Bedrock มีอยู่ในหนึ่งในสามสถานะวงจรชีวิตที่แตกต่างกัน: Active (ใช้งาน), Legacy (รุ่นเก่า) หรือ End-of-Life (EOL – สิ้นสุดการสนับสนุน) สถานะเหล่านี้ซึ่งมองเห็นได้ทั้งในคอนโซล Amazon Bedrock และผ่านการตอบสนองของ API (เช่น ผ่านการเรียกใช้ `GetFoundationModel` หรือ `ListFoundationModels`) กำหนดระดับการสนับสนุน ความพร้อมใช้งาน และอายุการใช้งานที่คาดไว้ของโมเดล การทำความเข้าใจแต่ละสถานะเป็นรากฐานสำคัญของการจัดการแอปพลิเคชัน AI ที่มีประสิทธิภาพ

นี่คือรายละเอียดของสิ่งที่แต่ละสถานะหมายถึง:

| สถานะ | คำอธิบาย | ผลกระทบหลัก |
| :----------- | :---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | :--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **ACTIVE (ใช้งาน)** | โมเดลได้รับการบำรุงรักษา อัปเดต และแก้ไขข้อผิดพลาดอย่างต่อเนื่องจากผู้ให้บริการ เป็นตัวแทนของโมเดลพื้นฐาน (FMs) ที่ได้รับการสนับสนุนในปัจจุบัน | การสนับสนุนเต็มรูปแบบสำหรับการอนุมานผ่าน API (InvokeModel, Converse), การปรับแต่ง (หากรองรับ) และคุณสมบัติในการเพิ่มโควต้าผ่าน AWS Service Quotas |
| **LEGACY (รุ่นเก่า)** | ผู้ให้บริการโมเดลได้เปลี่ยนผ่านโมเดล ซึ่งเป็นสัญญาณของการยกเลิกในที่สุด ลูกค้าจะได้รับการแจ้งเตือนล่วงหน้าอย่างน้อย 6 เดือนก่อน EOL | ผู้ใช้ปัจจุบันสามารถใช้งานต่อไปได้ แต่การเข้าถึงใหม่ๆ อาจถูกจำกัดสำหรับลูกค้าใหม่หรือบัญชีที่ไม่มีการใช้งาน การสร้างปริมาณงานที่จัดเตรียมไว้ใหม่จะไม่สามารถใช้ได้ และการปรับแต่งอาจเผชิญกับข้อจำกัด รวมถึงช่วง 'Public Extended Access' สำหรับโมเดลที่มี EOL หลังวันที่ 1 กุมภาพันธ์ 2026 |
| **END-OF-LIFE (EOL – สิ้นสุดการสนับสนุน)** | โมเดลได้มาถึงขั้นตอนสุดท้ายและไม่สามารถเข้าถึงได้โดยสมบูรณ์ การสนับสนุนทั้งหมดสิ้นสุดลง และไม่สามารถใช้สำหรับการอนุมานได้อีกต่อไป | คำขอ API ไปยังโมเดล EOL จะล้มเหลว จำเป็นต้องมีการโยกย้ายลูกค้าเชิงรุกไปยังโมเดลทางเลือกก่อนวันที่ EOL AWS ไม่มีการโยกย้ายอัตโนมัติ |

โมเดล **Active** เป็นหัวใจสำคัญสำหรับการพัฒนาต่อเนื่องและปริมาณงานการผลิต ได้รับการสนับสนุนอย่างเต็มที่ ได้รับการปรับปรุงล่าสุดทั้งหมด และเป็นตัวเลือกที่แนะนำสำหรับการใช้งานใหม่ๆ

สถานะ **Legacy** เป็นช่วงเวลาสำคัญสำหรับการวางแผน มันทำหน้าที่เป็นสัญญาณที่ชัดเจนในการเริ่มประเมินและเตรียมการสำหรับการโยกย้าย AWS รับรองว่าลูกค้ามีเวลาอย่างน้อยหกเดือนในการวางแผนการเปลี่ยนผ่านจากโมเดล Legacy ก่อนที่จะถึง EOL ซึ่งให้เวลาเพียงพอในการทดสอบและใช้งานโซลูชันใหม่ สำหรับโมเดลที่มีวัน EOL หลังวันที่ 1 กุมภาพันธ์ 2026 จะมีการแนะนำช่วงเพิ่มเติมที่เรียกว่า **Public Extended Access** ภายในช่วง Legacy หลังจากอยู่ในสถานะ Legacy อย่างน้อยสามเดือน โมเดลจะเข้าสู่ช่วงการเข้าถึงแบบขยายนี้ ทำให้ผู้ใช้ที่ใช้งานอยู่สามารถใช้งานต่อไปได้อีกอย่างน้อยสามเดือนจนกว่าจะถึง EOL อย่างไรก็ตาม ในช่วงเวลานี้ คำขอเพิ่มโควต้าสำหรับโมเดล Legacy โดยทั่วไปจะไม่ได้รับการอนุมัติ ซึ่งเน้นย้ำถึงความสำคัญของการวางแผนความจุล่วงหน้า

สุดท้าย สถานะ **End-of-Life (EOL)** เป็นขั้นสุดท้าย เมื่อโมเดลถึง EOL จะไม่สามารถใช้งานได้โดยสมบูรณ์ แอปพลิเคชันที่ยังคงพึ่งพาโมเดล EOL จะประสบความล้มเหลวทันที ซึ่งเน้นย้ำถึงความจำเป็นอย่างยิ่งในการดำเนินการโยกย้ายให้เสร็จสิ้นก่อนวันที่นี้ AWS ไม่ได้ให้การโยกย้ายอัตโนมัติ โดยวางความรับผิดชอบทั้งหมดไว้ที่ลูกค้าในการอัปเดตโค้ดแอปพลิเคชันของตน

### การวางแผนการโยกย้ายเชิงกลยุทธ์พร้อมการเข้าถึงแบบขยาย

การจัดการวงจรชีวิตโมเดล Amazon Bedrock อย่างมีประสิทธิภาพขึ้นอยู่กับการวางแผนการโยกย้ายเชิงกลยุทธ์ โดยเฉพาะอย่างยิ่งในเรื่องสถานะ Legacy และคุณสมบัติการเข้าถึงแบบขยาย กำหนดการเปลี่ยนผ่านที่เป็นโครงสร้าง — ความพร้อมใช้งานอย่างน้อย 12 เดือนหลังการเปิดตัวและอยู่ในสถานะ Legacy อย่างน้อย 6 เดือนก่อน EOL — ได้รับการออกแบบมาเพื่อให้สามารถคาดการณ์ได้และลดการหยุดชะงักสำหรับองค์กรที่ใช้ประโยชน์จากโมเดลพื้นฐาน

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

การพิจารณาเรื่องราคาก็เข้ามาเกี่ยวข้องในช่วงการเข้าถึงแบบขยายเช่นกัน ผู้ให้บริการโมเดลอาจปรับราคาสำหรับโมเดลในระยะนี้ AWS มุ่งมั่นที่จะโปร่งใส โดยรับรองว่าการเปลี่ยนแปลงราคาที่วางแผนไว้จะได้รับการสื่อสารในการประกาศ Legacy ครั้งแรกและก่อนที่จะมีผลบังคับใช้ เพื่อป้องกันค่าใช้จ่ายที่ไม่คาดคิด ลูกค้าที่มีข้อตกลงราคาแบบส่วนตัวหรือผู้ที่ใช้ปริมาณงานที่จัดเตรียมไว้จะยังคงใช้เงื่อนไขปัจจุบันของตนต่อไป ซึ่งเป็นการปกป้องการลงทุนและข้อตกลงตามสัญญาที่มีอยู่ แนวทางแบบหลายชั้นนี้สำหรับสถานะ `Legacy` ให้ความยืดหยุ่นในขณะที่ส่งเสริมการโยกย้ายอย่างทันท่วงทีเพื่อให้แน่ใจว่าแอปพลิเคชันจะได้รับประโยชน์จากโมเดลล่าสุดที่ได้รับการสนับสนุนอย่างเต็มที่ สำหรับองค์กรที่ต้องการเพิ่มประสิทธิภาพต้นทุนการดำเนินงานและประสิทธิภาพบน Bedrock การทำความเข้าใจความแตกต่างเหล่านี้เป็นสิ่งสำคัญ สำหรับข้อมูลเชิงลึกเพิ่มเติมเกี่ยวกับการจัดการต้นทุนใน AI โปรดสำรวจ [การจัดการต้นทุน AI ด้วยโปรเจกต์ Amazon Bedrock](/th/manage-ai-costs-with-amazon-bedrock-projects)

### การรับรองการเปลี่ยนผ่านที่ราบรื่น: การสื่อสารและแนวปฏิบัติที่ดีที่สุด

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

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

*   **การแจ้งเตือนทางอีเมล:** ส่งไปยังอีเมลผู้ใช้รูทของบัญชีของคุณและผู้ติดต่อสำรองที่กำหนด (การดำเนินงาน, ความปลอดภัย, การเรียกเก็บเงิน)
*   **AWS Health Dashboard:** ให้มุมมองแบบรวมศูนย์ของการเปลี่ยนแปลงที่กำหนดไว้ทั้งหมดและผลกระทบที่อาจเกิดขึ้น
*   **การแจ้งเตือนคอนโซล Amazon Bedrock:** การแจ้งเตือนโดยตรงภายในส่วนต่อประสานบริการ
*   **การเข้าถึง API แบบโปรแกรม:** ช่วยให้สามารถตรวจสอบสถานะวงจรชีวิตโมเดลได้โดยอัตโนมัติ

จำเป็นอย่างยิ่งที่จะต้องตรวจสอบและกำหนดค่าที่อยู่อีเมลติดต่อบัญชี AWS ของคุณเป็นประจำผ่าน [หน้าบัญชี AWS](https://console.aws.amazon.com/billing/home#/account) นอกจากนี้ [คอนโซล AWS User Notifications](https://console.aws.amazon.com/notifications) ช่วยให้คุณสามารถเพิ่มผู้รับหรือกำหนดค่าช่องทางการจัดส่งทางเลือก เช่น Slack หรือรายชื่อผู้รับอีเมลภายในองค์กร เพื่อให้แน่ใจว่าจะไม่พลาดข้อมูลสำคัญใดๆ การตรวจสอบว่าอีเมลจาก `health@aws.com` ไม่ถูกกรองก็เป็นขั้นตอนสำคัญเช่นกัน

เมื่อพูดถึง **กลยุทธ์การโยกย้ายและแนวปฏิบัติที่ดีที่สุด** การวางแผนล่วงหน้าเป็นสิ่งที่ไม่สามารถต่อรองได้ ทันทีที่โมเดลเข้าสู่สถานะ 'Legacy' ให้เริ่มกระบวนการโยกย้ายของคุณ:

1.  **ขั้นตอนการประเมิน:** ประเมินการพึ่งพาโมเดลรุ่นเก่าของคุณอย่างละเอียด ระบุแอปพลิเคชัน เวิร์กโฟลว์ และการผสานรวมทั้งหมดที่ขึ้นอยู่กับโมเดลนั้น วิเคราะห์รูปแบบคำขอทั่วไป ตัวชี้วัดประสิทธิภาพ และพฤติกรรมหรือผลลัพธ์เฉพาะที่แอปพลิเคชันของคุณพึ่งพาอาศัยอยู่ ความเข้าใจอย่างลึกซึ้งนี้จะเป็นรากฐานสำหรับการโยกย้ายของคุณ
2.  **ขั้นตอนการวิจัย:** ศึกษาโมเดลทดแทนที่แนะนำหรือโมเดลพื้นฐาน (FMs) ทางเลือกที่มีอยู่ใน Amazon Bedrock ทำความเข้าใจความสามารถของโมเดลเหล่านั้น ความแตกต่างจากโมเดลรุ่นเก่า และคุณสมบัติใหม่ๆ ที่อาจช่วยปรับปรุงแอปพลิเคชันของคุณ ให้ความสนใจเป็นพิเศษกับความพร้อมใช้งานในภูมิภาคและการเปลี่ยนแปลงใดๆ ในปลายทาง API หรือรูปแบบอินพุต/เอาต์พุต
3.  **การทดสอบและการตรวจสอบ:** ก่อนการนำไปใช้งานจริง ให้ทดสอบโมเดลใหม่ด้วยข้อมูลและกรณีการใช้งานที่มีอยู่ของคุณอย่างเข้มงวด ประเมินประสิทธิภาพ ความแม่นยำ และความปลอดภัยเมื่อเทียบกับเกณฑ์มาตรฐานที่กำหนดไว้ในระหว่างการประเมินของคุณ หากเป็นไปได้ ให้ทำการทดสอบ A/B เพื่อเปรียบเทียบประสิทธิภาพของโมเดลใหม่กับโมเดลรุ่นเก่า
4.  **การอัปเดตและผสานรวมโค้ด:** ปรับเปลี่ยนโค้ดแอปพลิเคชันของคุณเพื่อผสานรวมโมเดลใหม่ ซึ่งอาจเกี่ยวข้องกับการอัปเดตการเรียกใช้ API กลยุทธ์การออกแบบพรอมต์ หรือตรรกะการประมวลผลภายหลัง ตรวจสอบให้แน่ใจว่าโครงสร้างพื้นฐานของคุณสามารถรองรับข้อกำหนดของโมเดลใหม่ได้ และ [โควต้าบริการ](https://docs.aws.amazon.com/general/latest/gr/aws_service_limits.html) ของคุณได้รับการปรับตามความเหมาะสม
5.  **การนำไปใช้งานทีละน้อยและการตรวจสอบ:** ใช้กลยุทธ์การนำไปใช้งานทีละน้อยสำหรับโมเดลใหม่ เริ่มต้นด้วยปริมาณการใช้งานในสัดส่วนน้อยหรือแอปพลิเคชันที่ไม่สำคัญ ค่อยๆ เพิ่มการเปิดเผยในขณะที่ตรวจสอบประสิทธิภาพ อัตราข้อผิดพลาด และข้อเสนอแนะของผู้ใช้อย่างต่อเนื่อง

ด้วยการปฏิบัติตามแนวปฏิบัติที่ดีที่สุดเหล่านี้ คุณสามารถอำนวยความสะดวกในการเปลี่ยนผ่านที่ราบรื่นและควบคุมได้ ลดการหยุดชะงักที่อาจเกิดขึ้น และรับประกันว่าแอปพลิเคชัน AI ของคุณยังคงสร้างมูลค่าต่อไป การใช้ประโยชน์จากการทำงานร่วมกันเชิงกลยุทธ์ เช่น ระหว่าง [AWS และ NVIDIA ยังสามารถเร่งการนำ AI ไปใช้](/th/aws-and-nvidia-deepen-strategic-collaboration-to-accelerate-ai-from-pilot-to-production) ตลอดวงจรชีวิตได้อีกด้วย

### การจัดการเชิงรุกเพื่อการดำเนินงาน AI อย่างต่อเนื่อง

ลักษณะพลวัตของโมเดล AI หมายความว่าวงจรชีวิตของโมเดลพื้นฐานเป็นสิ่งคงที่ในภูมิทัศน์ของนักพัฒนา สำหรับองค์กรที่สร้างบน Amazon Bedrock การทำความเข้าใจและจัดการการเปลี่ยนผ่านเหล่านี้อย่างแข็งขันไม่ได้เป็นเพียงงานทางเทคนิคเท่านั้น แต่เป็นสิ่งจำเป็นเชิงกลยุทธ์ ด้วยการทำความเข้าใจความแตกต่างของสถานะ Active, Legacy และ End-of-Life และการใช้ประโยชน์จากการสื่อสารที่มีโครงสร้างและช่วงเวลาการเข้าถึงแบบขยายที่ AWS ให้มา องค์กรสามารถรับรองได้ว่าแอปพลิเคชัน AI ของตนจะยังคงมีความยืดหยุ่น มีประสิทธิภาพ และได้รับการอัปเดตอย่างต่อเนื่อง

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

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

What are the three main states of an Amazon Bedrock model and what do they signify?
Amazon Bedrock models transition through three crucial lifecycle states: Active, Legacy, and End-of-Life (EOL). An 'Active' model receives continuous maintenance, updates, and bug fixes, and is fully supported for inference, customization (if applicable), and quota increases. When a model moves to 'Legacy,' it signifies that a newer version or alternative is available, and customers are advised to plan migration. During this period, existing users can continue, but new access might be restricted, and customization capabilities can be limited. The 'EOL' state means the model is completely inaccessible across all AWS Regions, requiring prior migration to avoid application disruption. Understanding these states is vital for managing AI applications effectively on Amazon Bedrock.
How does the 'Legacy' state impact Amazon Bedrock users, especially regarding the 'Public Extended Access' period?
When an Amazon Bedrock model enters the 'Legacy' state, users are given at least six months' notice before its End-of-Life (EOL) date, providing critical time for migration planning. During this period, existing customers can typically continue using the model, though new customers or inactive accounts might face access restrictions. For models with EOL dates after February 1, 2026, the 'Legacy' state includes a 'Public Extended Access' phase, lasting at least three months after an initial minimum of three months in Legacy. During this extended period, active users retain access, but quota increase requests may not be approved, and pricing might be adjusted. Customers are always notified of these changes to facilitate a smooth transition away from the legacy model.
What happens when an Amazon Bedrock foundation model reaches its End-of-Life (EOL) date?
Upon reaching its End-of-Life (EOL) date, an Amazon Bedrock foundation model becomes entirely inaccessible across all AWS Regions for most customers. Any API requests targeting an EOL model will fail, rendering applications that still rely on it non-functional. AWS does not automatically migrate applications; customers are solely responsible for updating their application code to use alternative, supported models *before* the EOL date. While special arrangements for continued access might exist between specific customers and providers, this is generally not the case for the broader user base. Proactive migration is therefore a critical step to ensure the uninterrupted operation of AI applications built on Amazon Bedrock.
How does AWS communicate changes in the Amazon Bedrock model lifecycle to its users?
AWS employs a multi-channel communication strategy to inform customers about Amazon Bedrock model state changes, particularly when a model transitions to 'Legacy' status (six months before EOL). Notifications are sent via email, displayed on the AWS Health Dashboard, and presented as alerts within the Amazon Bedrock console. Programmatic access to model lifecycle information is also available through the API. To ensure receipt of these critical updates, customers must verify and configure their account contact email addresses, including root user and alternate contacts (operations, security, billing). Additionally, the AWS User Notifications console allows for adding more recipients or delivery channels like Slack or email distribution lists, ensuring timely and comprehensive awareness of upcoming changes.
What are the recommended strategies and best practices for migrating applications to newer Amazon Bedrock models?
Migrating applications to newer Amazon Bedrock models requires proactive planning and a structured approach. Best practices include starting planning as soon as a model enters the 'Legacy' state. Begin with an 'Assessment Phase' to identify all applications dependent on the legacy model, analyze request patterns, and understand critical output behaviors. Follow this with a 'Research Phase' to thoroughly investigate the recommended replacement model, assessing its capabilities, differences, new features, and regional availability. It's crucial to update application code, validate performance, and confirm that service quotas can handle the expected volume with the new model. This systematic approach ensures a smooth transition with minimal disruption, leveraging the enhanced capabilities of newer foundation models.
Are there any pricing considerations during the extended access period for Amazon Bedrock models?
Yes, pricing may be adjusted by the model provider during the extended access period for Amazon Bedrock models. However, AWS ensures transparency by notifying customers in the initial legacy announcement and before any subsequent price changes take effect, preventing surprise retroactive increases. Customers with existing private pricing agreements directly with model providers or those utilizing provisioned throughput will continue operating under their established pricing terms throughout the extended access period. This policy is designed to protect those who have made specific financial arrangements or investments in dedicated capacity, ensuring predictability and stability despite the model's transition toward End-of-Life.

อัปเดตข่าวสาร

รับข่าว AI ล่าสุดในกล่องจดหมายของคุณ

แชร์