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

การอนุมาน AI (AI inference) ไม่จำเป็นต้อง “ใช้พื้นที่จัดเก็บข้อมูลมากกว่า” การฝึกฝนโมเดล (training) เสมอไป แต่มีลักษณะต่อเนื่องกว่า มีการแบ่งชั้นมากกว่า และเชื่อมโยงกับระบบธุรกิจจริงอย่างใกล้ชิดกว่า การฝึกฝนโมเดลโดยทั่วไปต้องใช้ชุดข้อมูลขนาดใหญ่ ไฟล์ checkpoint ของโมเดล และไปป์ไลน์ข้อมูลความเร็วสูง ในทางกลับกัน การอนุมานจะทำงานแบบออนไลน์ต่อเนื่องเป็นระยะเวลานาน ซึ่งต้องโหลดน้ำหนักโมเดล (model weights) รักษา KV cache รองรับคำขอพร้อมกันจำนวนมาก เรียกใช้ฐานความรู้ RAG และเก็บรักษา log และข้อมูลผลตอบรับ เมื่อคุณประเมินความต้องการเซิร์ฟเวอร์ AI คุณไม่สามารถมองเฉพาะ GPU เท่านั้น คุณยังต้องแยกพิจารณา HBM, DRAM, NVMe SSD, HDD, object storage และระบบจัดเก็บข้อมูลระดับองค์กรด้วย

ประเด็นสำคัญ

• การเทรน (Training) มีลักษณะคล้ายภาระงานที่กระจุกตัวเป็นช่วงพีคมากกว่า ในขณะที่การอินเฟอเรนซ์ (Inference) เป็นบริการออนไลน์ที่ทำงานต่อเนื่องระยะยาว
• แรงกดดันด้านหน่วยความจำของการอินเฟอเรนซ์มาจากน้ำหนักโมเดล (model weights), KV cache, หน้าต่างบริบทยาว (long context windows) และการทำงานพร้อมกัน (concurrency)
• RAG นำข้อมูลส่วนตัวขององค์กร ดัชนีเวกเตอร์ (vector indexes) และบันทึกสิทธิ์การเข้าถึง เข้าสู่ระบบจัดเก็บข้อมูล
• ความต้องการพื้นที่จัดเก็บข้อมูลของเซิร์ฟเวอร์ AI ควรได้รับการทำความเข้าใจในทุกชั้น ตั้งแต่ HBM, DRAM, SSD และ HDD
• การวิเคราะห์การลงทุนควรมองข้ามฉลาก "AI storage" และตรวจสอบด้านราคา ความจุ และโครงสร้างลูกค้า

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

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

ทำไมการฝึกโมเดลจึงต้องใช้พื้นที่จัดเก็บข้อมูลมากมาย? เพราะการฝึกโมเดลพื้นฐาน (foundation model) ต้องอ่านชุดข้อมูลขนาดใหญ่ซ้ำ ๆ และบันทึกจุดตรวจสอบ (checkpoint) ของการฝึกหลายรายการ จุดตรวจสอบคือภาพรวมของสถานะโมเดลในระหว่างการฝึก ซึ่งใช้สำหรับดำเนินการฝึกต่อ เปรียบเทียบการทดลอง หรือย้อนกลับไปยังเวอร์ชันก่อนหน้า การฝึกโมเดลขนาดใหญ่ยังสร้างเวอร์ชันข้อมูลที่ผ่านการทำความสะอาด ผลการประเมิน บันทึกการทำงาน (logs) และไฟล์น้ำหนักโมเดล ซึ่งทั้งหมดนี้ต้องการระบบไฟล์แบบ throughput สูง ที่เก็บข้อมูลแบบออบเจ็กต์ (object storage) หรือระบบจัดเก็บข้อมูลแบบขนาน

ทำไมการอนุมาน (inference) จึงสร้างความต้องการพื้นที่จัดเก็บข้อมูลที่ยั่งยืนด้วย? เพราะหลังจากที่โมเดลเริ่มให้บริการแล้ว มันไม่ได้แค่ "โหลดน้ำหนัก (weights) ครั้งเดียว" แล้วหยุดลง แต่ละคำขอ (request) อาจสร้างพรอมป์ (prompt), เอาต์พุต, ข้อเสนอแนะจากผู้ใช้, บันทึกข้อผิดพลาด, บันทึกการตรวจสอบ และสถานะระหว่างกลาง การอนุมานระดับองค์กรยังมักถูกผสมผสานกับ RAG อีกด้วย ซึ่งนำเอกสารภายใน, ฐานความรู้, ดัชนีเวกเตอร์, บันทึกสิทธิ์การเข้าถึง และไฟล์ต้นฉบับเข้าสู่ระบบ ในขณะที่การอนุมานขยายจากแชทบอตไปสู่งานบริการลูกค้า, การค้นหา, ผู้ช่วยเขียนโค้ด, ระบบอัตโนมัติสำนักงาน และเวิร์กโฟลว์ของเอเจนต์ วัตถุที่จัดเก็บก็ขยายจาก "ไฟล์โมเดล" ไปเป็น "ข้อมูลการดำเนินงานของธุรกิจ"

ที่สำคัญกว่านั้น HBM, DRAM, SSD และ HDD ไม่ควรถูกมองว่าเป็น "ที่จัดเก็บข้อมูล" ชนิดเดียวกันทั้งหมด HBM และ DRAM เป็นหน่วยความจำสำหรับใช้งานขณะรัน (runtime memory) ซึ่งส่งผลต่อการโหลดโมเดล ความจุหน่วยความจำ GPU แคช และ throughput ของการอนุมาน (inference) ส่วน SSD และ HDD มีความเกี่ยวข้องกับการเก็บรักษาข้อมูลถาวรมากกว่า โดยส่งผลต่อการอ่านโมเดล การดึงข้อมูล การเก็บรักษา log และการจัดเก็บข้อมูลเย็น (cold-data archiving) การที่การอนุมานต้องการพื้นที่จัดเก็บมากกว่าการฝึกโมเดลหรือไม่นั้น ขึ้นอยู่กับว่าคุณกำลังถามถึง "หน่วยความจำที่ใช้ระหว่างการคำนวณ" หรือ "ข้อมูลที่จัดเก็บในระยะยาว"

สรุป: การอนุมาน (inference) ของ AI ไม่จำเป็นต้องมีขนาดข้อมูลฝึกฝนดิบมากกว่าการฝึกฝน (training) แต่ทำให้ความต้องการพื้นที่จัดเก็บข้อมูลมีความต่อเนื่องมากขึ้น ออนไลน์มากขึ้น และมีการแบ่งชั้นมากขึ้น การฝึกฝนเปรียบเสมือนโครงการก่อสร้างขนาดใหญ่ ที่ต้องมีการจัดตารางข้อมูลและทรัพยากรการคำนวณจำนวนมากอย่างเข้มข้นในช่วงเวลาสั้น ๆ ส่วนการอนุมานเปรียบเสมือนโครงสร้างพื้นฐานที่ทำงานตลอด 24 ชั่วโมง ตอบสนองคำขออย่างต่อเนื่อง ดูแลแคช ค้นหาฐานความรู้ จัดเก็บบันทึก (log) และสนับสนุนการเล่นซ้ำของข้อมูลธุรกิจ เมื่อคุณประเมินความต้องการเซิร์ฟเวอร์ AI ให้แบ่งประเด็นออกเป็นสองชั้น: HBM และ DRAM ซึ่งทำหน้าที่เป็นหน่วยความจำขณะทำงาน ที่กำหนดเวลาแฝง (latency) และอัตราการประมวลผล (throughput); และ SSD, HDD, ระบบจัดเก็บแบบออบเจ็กต์ (object storage) และระบบจัดเก็บข้อมูลระดับองค์กร ที่กำหนดว่าข้อมูลสามารถถูกเก็บรักษาไว้ในระยะยาวได้อย่างมีต้นทุนต่ำและควบคุมได้หรือไม่

การแยกวิเคราะห์ชั้นความจำของ AI Server: HBM, DRAM, SSD และ HDD แต่ละอย่างช่วยแก้ปัญหาอะไร

“หน่วยจัดเก็บข้อมูล” ภายใน AI server ไม่ใช่แนวคิดเดียว HBM อยู่ใกล้กับ GPU และให้การสนับสนุนการคำนวณแบบแบนด์วิดท์สูง DRAM ของ CPU รองรับหน่วยความจำของโฮสต์ การจัดตารางงาน และการแคชข้อมูล NVMe SSD ดูแลข้อมูลร้อน การอ่านที่รวดเร็ว การโหลดโมเดล และการดึงข้อมูลล่วงหน้า HDD หรือ object storage ดูแลการเก็บรักษาข้อมูลจำนวนมหาศาลในต้นทุนต่ำ ความต้องการการอนุมาน (inference) ที่เพิ่มขึ้นส่งผลกระทบต่อทุกชั้นเหล่านี้ แต่แต่ละชั้นมีตรรกะของห่วงโซ่อุปทานที่แตกต่างกัน จึงไม่ควรรวมทั้งหมดเข้าเป็นหมวดหมู่เดียวกันอย่างกว้าง ๆ ว่า “ความต้องการหน่วยจัดเก็บข้อมูลสำหรับ AI”

NVIDIA GB200 NVL72 เชื่อมต่อ CPU Grace 36 ตัวและ GPU Blackwell 72 ตัวเข้าด้วยกันในระบบระดับแร็คที่ระบายความร้อนด้วยของเหลว โดยเน้นย้ำถึงโดเมน NVLink ของ GPU จำนวน 72 ตัวและความสามารถในการอนุมาน LLM แบบเรียลไทม์ ระบบประเภทนี้แสดงให้เห็นว่าเซิร์ฟเวอร์ AI ระดับไฮเอนด์ได้เปลี่ยนจากการแข่งขันด้านประสิทธิภาพระดับการ์ดเดี่ยว มาเป็นการประสานงานระดับแร็คที่ครอบคลุมด้านหน่วยความจำ ระบบเชื่อมต่อ พลังงาน และการระบายความร้อน สำหรับงานอนุมาน ยิ่งโมเดลมีขนาดใหญ่ บริบทยาวนาน และความพร้อมกันสูงเท่าใด แบนด์วิดท์และความจุของหน่วยความจำรอบๆ GPU ก็ยิ่งมีความสำคัญมากขึ้นเท่านั้น

ทำไม HBM จึงเป็นคอขวดที่ใช้ร่วมกันทั้งในการเทรนและการอนุมานระดับไฮเอนด์? เพราะมันส่งผลโดยตรงต่อประสิทธิภาพการอ่านของน้ำหนักโมเดล ค่าการกระตุ้น (activations) และ KV cache ยิ่งโมเดลมีขนาดใหญ่ขึ้น ก็ยิ่งต้องวางน้ำหนักและสถานะระหว่างกลางมากขึ้นในหน่วยความจำความเร็วสูง เอกสารผลิตภัณฑ์ AI data center ของ Micron รวมทั้งการเทรน AI และการอนุมานไว้ในโซลูชันหน่วยความจำและที่จัดเก็บข้อมูล ซึ่งครอบคลุม HBM, DRAM และ SSD สำหรับศูนย์ข้อมูล นี่แสดงให้เห็นว่าเซิร์ฟเวอร์ AI ไม่ได้เป็นเพียงการซื้อ GPU อีกต่อไป แต่เป็นการอัปเกรดทั้งระบบในด้านหน่วยความจำ ที่จัดเก็บข้อมูล และสถาปัตยกรรมระบบ

ทำไม DRAM ของ CPU และ SSD แบบ NVMe จึงมีความสำคัญมากขึ้นระหว่างการอนุมาน (inference)? เพราะบริการอนุมานต้องจัดการกับการกำหนดตารางคำขอของผู้ใช้ การสลับโมเดล การแคชผลลัพธ์การค้นคืน การอ่าน embedding และการเขียน log ในสถานการณ์ที่มีการทำงานพร้อมกันสูง GPU ไม่ใช่คอขวดเพียงจุดเดียว หน่วยความจำของโฮสต์ เครือข่าย การอ่านและเขียน SSD และการ orchestrate บริการ ล้วนส่งผลต่อ latency แบบ end-to-end โดยเฉพาะ RAG ระดับองค์กร AI search และ code assistant ที่ต้องพึ่งพาชั้นข้อมูลร้อน (hot-data layer) เป็นอย่างมาก เนื่องจากเอกสารที่เกี่ยวข้อง ดัชนีเวกเตอร์ และข้อมูลเมตาด้านสิทธิ์การเข้าถึง ต้องถูกเข้าถึงอย่างรวดเร็ว

ทำไม HDD จึงยังคงได้ประโยชน์จากการเติบโตของข้อมูล AI? เพราะข้อมูลที่สร้างโดย AI ไม่ใช่ทั้งหมดที่เป็น "ข้อมูลร้อน" วิดีโอต้นฉบับ คลังข้อมูลสำหรับการฝึกฝน บันทึก log คำตอบในอดีต ชุดข้อมูลสำหรับการประเมิน ไฟล์จดหมายเหตุเพื่อการปฏิบัติตามกฎระเบียบ และการสำรองข้อมูลแบบเย็น ล้วนพึ่งพาความจุที่มีต้นทุนต่ำมากขึ้นเมื่อเวลาผ่านไป เมื่อ Seagate เปิดตัวฮาร์ดดิสก์ Exos M ความจุ 30TB บริษัทได้เชื่อมโยงความจุสูง ประสิทธิภาพการใช้พลังงาน และความต้องการจัดเก็บข้อมูลในศูนย์ข้อมูล AI เข้าไว้ในเรื่องราวเดียวกัน สิ่งนี้แสดงให้เห็นว่า HDD ยังคงเป็นชั้นที่สำคัญในวงจรชีวิตของข้อมูล AI

สรุป: ความต้องการเซิร์ฟเวอร์ AI ไม่ควรถูกประเมินผ่าน GPU เพียงอย่างเดียว และ "หน่วยจัดเก็บข้อมูล" ทุกรูปแบบก็ไม่ควรถูกรวมเข้าด้วยกัน HBM เป็นตัวกำหนดประสิทธิภาพในการส่งมอบข้อมูลระหว่างการคำนวณของโมเดล DRAM รองรับการจัดตารางและแคชฝั่งโฮสต์ NVMe SSD ดูแลข้อมูลที่ใช้งานหนัก (hot data) และการอ่านที่รวดเร็ว ส่วน HDD และ object storage ดูแลการเก็บรักษาระยะยาวและการควบคุมต้นทุนด้านความจุ งานฝึกฝนโมเดล (Training) เน้นไปป์ไลน์ข้อมูลความเร็วสูงและ checkpoints ขณะที่งานอนุมาน (inference) เน้นการที่โมเดลอยู่ประจำในระบบ การเข้าถึงที่มีความหน่วงต่ำ การจัดการแคช และการเก็บรักษาบันทึก log เมื่อวิเคราะห์ห่วงโซ่อุปทานของเซิร์ฟเวอร์ AI ให้ระบุก่อนว่าความต้องการตกอยู่ในเลเยอร์ใด จากนั้นจึงพิจารณาว่าความต้องการนั้นส่งผ่านไปยัง HBM, DRAM, NAND, SSD, HDD, ระบบจัดเก็บข้อมูล หรือผู้ให้บริการคลาวด์

เหตุใดการอนุมาน (Inference) จึงเป็นตัวขับเคลื่อนความต้องการหน่วยความจำ: KV Cache, Long Context, High Concurrency และเวิร์กโฟลว์ของเอเจนต์

แรงกดดันด้านหน่วยความจำของการอนุมาน AI มาจาก KV cache หน้าต่างบริบทที่ยาว การทำงานพร้อมกันสูง และเวิร์กโฟลว์ของเอเจนต์เป็นหลัก เมื่อการฝึกโมเดลเสร็จสิ้นแล้ว การอนุมานไม่ได้เป็นเพียงเรื่องของการอ่านน้ำหนัก (weights) เพียงครั้งเดียว โมเดลภาษาขนาดใหญ่สร้างข้อความทีละโทเคน และแต่ละคำขอจะต้องเก็บรักษาสถานะ attention ระดับกลางสำหรับโทเคนในอดีต ยิ่งบริบทยาว ยิ่งมีการทำงานพร้อมกันสูง และยิ่งมีการเรียกใช้เอเจนต์มากเท่าไร แรงกดดันต่อหน่วยความจำ GPU หน่วยความจำ CPU และระบบแคชก็ยิ่งมากขึ้นเท่านั้น เมื่อทำงานในระดับใหญ่ การจัดการหน่วยความจำจะเป็นตัวกำหนดปริมาณงาน (throughput) ความหน่วง (latency) และต้นทุนโดยตรง

ทำไม KV cache จึงกลายเป็นตัวแปรสำคัญ? เพราะการสร้างแบบ autoregressive ต้องอ้างอิงถึง token ที่สร้างไว้ก่อนหน้าทุกครั้งที่สร้าง token ใหม่ เพื่อหลีกเลี่ยงการคำนวณซ้ำทั้งบริบทประวัติศาสตร์ ระบบจึงจัดเก็บสถานะระหว่างกลางแบบ key/value นั่นคือ KV cache บทความ PagedAttention ชี้ให้เห็นว่า KV cache ในการให้บริการ LLM มีขนาดใหญ่และมีการขยายตัวและหดตัวแบบไดนามิกตามคำขอ หากจัดการอย่างไม่มีประสิทธิภาพ การกระจายตัว (fragmentation) และการคัดลอกที่ซ้ำซ้อนอาจจำกัดขนาด batch การจัดการแบบแบ่งหน้า (paged) ของ vLLM ช่วยลดการสูญเสีย KV cache ซึ่งสะท้อนบทบาทสำคัญกลางของแรงกดดันด้านหน่วยความจำในการอนุมาน (inference)

เหตุใดบริบทยาวจึงเปลี่ยนงานอนุมาน (inference) จากปัญหาด้านการคำนวณให้กลายเป็นปัญหาด้านหน่วยความจำ? เพราะเมื่อหน้าต่างบริบทขยายออกไป โมเดลจะต้องเก็บรักษาสถานะระดับกลางสำหรับโทเคนประวัติศาสตร์ที่มากขึ้น การศึกษา IceCache ปี 2026 ยังเน้นย้ำว่าพื้นที่หน่วยความจำของ KV cache เติบโตเป็นเชิงเส้นตรงตามความยาวของลำดับ ทำให้การอนุมานลำดับยาวกลายเป็นคอขวดด้านหน่วยความจำอย่างรุนแรง กล่าวอีกนัยหนึ่ง บริบทยาวไม่ได้เป็นเพียงแค่ “การอ่านข้อความมากขึ้น” เท่านั้น แต่มันผลักดันให้แคช แบนด์วิดท์ ความจุหน่วยความจำ GPU และความซับซ้อนในการจัดกำหนดการเพิ่มขึ้นพร้อมกันทั้งหมด

Agentic AI ยิ่งเพิ่มแรงกดดันต่อหน่วยความจำและข้อมูลมากขึ้นไปอีก ในการวิเคราะห์เรื่องความต้องการหน่วยความจำของ Agentic AI TrendForce ระบุว่าคำขอการอนุมาน (inference) กำลังวิวัฒน์จากการสืบค้นครั้งเดียวไปสู่ลูปวนซ้ำต่อเนื่อง และความจุของ KV cache จะขยายตัวตามขนาดหน้าต่างบริบท (context window) ที่ใหญ่ขึ้น หมายความว่าเอเจนต์ทำมากกว่าการตอบคำถาม พวกมันวางแผน เรียกใช้เครื่องมือ ดึงข้อมูล สร้างโค้ด ตรวจสอบผลลัพธ์ และปรับแก้อีกครั้ง แต่ละขั้นตอนอาจสร้างสถานะระหว่างกลางและบันทึกที่สามารถเรียกดูซ้ำได้

สรุป: ยิ่งการทำ inference แพร่หลายมากเท่าไร ระบบหน่วยความจำและแคชก็ยิ่งมีความสำคัญมากขึ้นเท่านั้น ในความคิดแบบดั้งเดิม การฝึกฝน (training) ถือเป็นขั้นตอนที่ใช้ทรัพยากรมากที่สุด อย่างไรก็ตาม ในระบบธุรกิจจริง การทำ inference ต้องทำงานออนไลน์อยู่ตลอด รองรับการทำงานพร้อมกันอย่างต่อเนื่อง และตอบสนองด้วยความหน่วงต่ำ KV cache จะขยายตัวตามความยาวของ context และปริมาณคำขอ Long context ยิ่งเพิ่มแรงกดดันต่อหน่วยความจำของ GPU เวิร์กโฟลว์ของ Agent สร้างสถานะระหว่างกาลและบันทึก (logs) จำนวนมากขึ้น เมื่อพิจารณาความต้องการเซิร์ฟเวอร์ AI ควรให้ความสำคัญเป็นพิเศษกับสามคำถามนี้: โมเดลมีขนาดใหญ่ขึ้นหรือไม่? คำขอจากผู้ใช้เพิ่มขึ้นหรือไม่? หน้าต่าง context และจำนวนขั้นตอนของ agent ยาวขึ้นหรือไม่? หากตัวแปรทั้งสามนี้ยังคงเพิ่มขึ้นต่อเนื่อง ความต้องการฝั่ง inference สำหรับ HBM, DRAM, SSD และการจัดการแคชก็จะยังคงเติบโตต่อไป

วิเคราะห์ความต้องการการเก็บรักษาข้อมูล: RAG, ฐานข้อมูลเวกเตอร์, Logs, ข้อมูลฟีดแบ็ก และไฟล์จัดเก็บเพื่อการปฏิบัติตามข้อกำหนด

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

คำอธิบายเรื่อง RAG ของ Google Cloud เน้นย้ำว่า RAG โดยทั่วไปใช้ระบบดึงข้อมูล (retrieval system) เพื่อค้นหาข้อเท็จจริง และการดึงข้อมูลยุคใหม่มักใช้ฐานข้อมูลเวกเตอร์ (vector database) เพื่อจัดเก็บ embeddings เพื่อให้ค้นหาเอกสารที่เกี่ยวข้องได้อย่างรวดเร็วผ่านความคล้ายคลึงเชิงความหมาย (semantic similarity) สิ่งนี้แสดงให้เห็นว่าการอนุมาน (inference) AI ระดับองค์กรไม่ได้เป็นเพียงการเรียกใช้ model API เท่านั้น แต่ต้องการห่วงโซ่การประมวลผลข้อมูลที่ครบวงจร: ไฟล์ต้นฉบับเข้าสู่ระบบ ถูกแบ่งเป็น chunks แปลงเป็น embeddings เขียนลงดัชนีเวกเตอร์ (vector index) และถูกดึงข้อมูลตามสิทธิ์การเข้าถึงระหว่างการอนุมาน

ทำไม RAG จึงเพิ่มความต้องการข้อมูลร้อน (hot data) ระดับองค์กร? เพราะ RAG ต้องการให้ระบบค้นหาข้อมูลที่เกี่ยวข้องได้อย่างรวดเร็วระหว่างกระบวนการอนุมาน (inference) ยิ่งคลังความรู้ (knowledge base) มีการอัปเดตบ่อย มีเอกสารมาก และมีโครงสร้างสิทธิ์การเข้าถึงที่ซับซ้อนมากเท่าไร ระบบจัดเก็บข้อมูลก็ยิ่งต้องรองรับการค้นหาที่มีความหน่วงต่ำ การอัปเดตแบบเพิ่มทีละส่วน และการแยกข้อมูลระหว่างผู้เช่าหลายราย (multi-tenant isolation) มากขึ้นเท่านั้น สถาปัตยกรรม generative AI RAG architecture ของ Google Cloud แบ่ง RAG ออกเป็นการนำเข้าข้อมูล การสร้าง embedding การค้นคืนข้อมูล การสร้างผลลัพธ์ และการกำกับดูแล ซึ่งแสดงให้เห็นว่าแท้จริงแล้ว RAG คือระบบวิศวกรรมที่ผสมผสานระหว่างโมเดล ฐานข้อมูล ระบบค้นคืนข้อมูล และการควบคุมสิทธิ์การเข้าถึงเข้าด้วยกัน

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

ควรเข้าใจข้อมูลร้อนและข้อมูลเย็นแยกจากกันด้วย ข้อมูลร้อนสนับสนุนการอนุมานในปัจจุบัน รวมถึงดัชนีเวกเตอร์ เอกสารยอดนิยม บันทึกล่าสุด และไฟล์โมเดลที่มีการใช้งานความถี่สูง ส่วนข้อมูลเย็นสนับสนุนการจัดเก็บถาวรระยะยาว รวมถึงคลังข้อมูลต้นฉบับ บันทึกในอดีต เวอร์ชันโมเดลเก่า ข้อเสนอแนะที่หมดอายุ และบันทึกเพื่อการปฏิบัติตามกฎระเบียบ ข้อมูลร้อนต้องพึ่งพา SSD หน่วยความจำ และฐานข้อมูลประสิทธิภาพสูงมากกว่า ส่วนข้อมูลเย็นต้องพึ่งพา HDD, object storage และคลังข้อมูลต้นทุนต่ำมากกว่า ยิ่งการอนุมานมีขนาดใหญ่ขึ้น การแบ่งชั้นข้อมูลร้อน/เย็นก็ยิ่งมีความสำคัญมากขึ้น การวางข้อมูลทั้งหมดไว้ในชั้นประสิทธิภาพสูงจะเพิ่มต้นทุน ในขณะที่การวางทุกอย่างไว้ในชั้นเย็นจะทำให้การอนุมานช้าลง

สรุป: การอนุมานด้วย AI ไม่เพียงแต่ใช้หน่วยความจำเท่านั้น แต่ยังสร้างความต้องการใหม่ด้านการเก็บรักษาข้อมูลอีกด้วย RAG นำเอกสารต้นทาง embeddings ดัชนีเวกเตอร์ และข้อมูลเมตาด้านสิทธิ์การเข้าถึงเข้ามา ระบบที่ใช้งานจริงในระดับ production สร้าง prompt การตอบกลับ ผลตอบรับ บันทึกข้อผิดพลาด และระเบียนการตรวจสอบ การดำเนินงานระยะยาวยังสร้างเวอร์ชันของโมเดล ผลการประเมิน และไฟล์จัดเก็บเพื่อการปฏิบัติตามกฎระเบียบ เมื่อคุณประเมินว่าการอนุมานขับเคลื่อนความต้องการด้านที่เก็บข้อมูลหรือไม่ อย่าถามเพียงว่าโมเดลมีขนาดใหญ่แค่ไหน แต่ให้ถามว่าองค์กรกำลังเชื่อมต่อ AI เข้ากับฐานความรู้ เวิร์กโฟลว์ทางธุรกิจ และระบบการปฏิบัติตามกฎระเบียบหรือไม่ ยิ่งการอนุมานเปลี่ยนจาก "ฟีเจอร์แชท" ไปสู่ "เวิร์กโฟลว์ระดับองค์กร" มากเท่าใด ความต้องการด้านที่เก็บข้อมูลก็ยิ่งขยายจากไฟล์โมเดลไปสู่การจัดการวงจรชีวิตข้อมูลแบบครบวงจรมากขึ้นเท่านั้น

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

Training และ inference ต่างดึงดูดห่วงโซ่อุปทานอุปกรณ์จัดเก็บข้อมูลไปในทิศทางที่แตกต่างกัน การฝึกโมเดลพื้นฐาน (foundation model) สร้างความต้องการ HBM ระบบไฟล์แบบขนานความเร็วสูง ท่อส่งข้อมูลสำหรับการฝึก (training data pipelines) และพื้นที่จัดเก็บสำหรับ checkpoint ส่วนการอนุมานขนาดใหญ่สร้างความต้องการ HBM/DRAM, NVMe SSDs, ฐานข้อมูลเวกเตอร์, อุปกรณ์จัดเก็บข้อมูลระดับองค์กร, การจัดเก็บ log ในระยะยาว และความจุ HDD ในระยะสั้น training สร้างยอดความต้องการที่พุ่งเฉียบพลันกว่า แต่ในระยะยาว inference มีความต่อเนื่องมากกว่า คุณไม่สามารถระบุได้ว่าบริษัทใดจะได้ประโยชน์โดยใช้เพียงคำว่า "training" หรือ "inference" เท่านั้น

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

ความต้องการพื้นที่จัดเก็บข้อมูลจากการอนุมาน (inference) ในระดับใหญ่มีความต่อเนื่องมากกว่า นั่นไม่ใช่กระบวนการครั้งเดียวที่จบลงหลังการฝึกโมเดล แต่ต้องประมวลผลคำขอทุกวัน ทุกชั่วโมง และทุกวินาที ในบทความ AI inference drives memory demand TrendForce ได้แบ่งความต้องการฮาร์ดแวร์สำหรับการอนุมานออกเป็น QPS ที่สูงขึ้น หน้าต่างบริบท (context window) ที่ยาวขึ้น และขั้นตอนการอนุมานที่มากขึ้น ตัวแปรทั้งสามนี้ล้วนผลักดันแรงกดดันต่อหน่วยความจำ แคช และระบบข้อมูลให้สูงยิ่งขึ้น เมื่อเวิร์กโฟลว์ของเอเจนต์ (agent workflows) กลายเป็นกระแสหลัก คำขอการอนุมานจะเปลี่ยนจากการถาม-ตอบรอบเดียวไปสู่การทำซ้ำอย่างต่อเนื่อง ซึ่งเปลี่ยนแรงกดดันต่อพื้นที่จัดเก็บข้อมูลให้กลายเป็นความท้าทายในการดำเนินงานระยะยาว

แต่ละส่วนของห่วงโซ่อุปทานได้รับประโยชน์ด้วยเหตุผลที่แตกต่างกัน HBM ส่วนใหญ่เกี่ยวข้องกับแพลตฟอร์ม GPU ระดับไฮเอนด์และการอนุมานโมเดลขนาดใหญ่ DRAM เกี่ยวข้องกับหน่วยความจำหลักของเซิร์ฟเวอร์ แคช และการจัดตารางงาน NAND/SSD เกี่ยวข้องกับข้อมูลที่ใช้งานบ่อย การโหลดโมเดล การทำดัชนี และไฟล์บันทึก (logs) HDD เกี่ยวข้องกับข้อมูลที่ไม่ค่อยถูกเรียกใช้ ชุดข้อมูลต้นฉบับ วิดีโอ และคลังข้อมูลระยะยาว ระบบจัดเก็บข้อมูลระดับองค์กรได้รับประโยชน์จากธรรมาภิบาลข้อมูล โครงการ RAG และสถาปัตยกรรมคลาวด์แบบไฮบริด NetworkWorld อ้างอิงจาก Dell'Oro ระบุว่า ตลาดไดรฟ์จัดเก็บข้อมูล ซึ่งรวมถึง HDD และ SSD คาดว่าจะเติบโตด้วยอัตราการเติบโตเฉลี่ยต่อปี (CAGR) มากกว่า 20% ในช่วงห้าปีข้างหน้า โดยเทคโนโลยีทั้งสองจะยังคงมีบทบาทที่แตกต่างกันในแต่ละชั้นของโครงสร้างพื้นฐาน AI

สรุป: ทั้งการเทรนและการอินเฟอเรนซ์ต่างขับเคลื่อนห่วงโซ่อุปทานอุปกรณ์จัดเก็บข้อมูล แต่ด้วยวิธีที่แตกต่างกัน การเทรนมีความเข้มข้นกว่าและพึ่งพาการส่งผ่านข้อมูลขนาดใหญ่ครั้งเดียวและ checkpoints มากกว่า ส่วนการอินเฟอเรนซ์มีความต่อเนื่องกว่าและพึ่งพาหน่วยความจำออนไลน์, KV cache, ข้อมูลร้อนของ RAG, การเก็บรักษา log และการจัดเก็บข้อมูลเย็นมากกว่า เมื่อประเมินโอกาสในห่วงโซ่อุปทาน ให้ระบุสถานการณ์ให้ชัดเจนก่อน: การเทรนโมเดลรากฐาน, RAG ระดับองค์กร, AI search, ฝ่ายบริการลูกค้า, ผู้ช่วยเขียนโค้ด หรือการสร้างงานมัลติโมเดีย สถานการณ์ที่ต่างกันชี้ไปยังชั้นต่างกัน HBM, DRAM, NAND, SSD, HDD และระบบจัดเก็บข้อมูลระดับองค์กรไม่ควรถูกรวมเข้าเป็นแนวคิดกว้างเดียวกัน

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

หากคุณกำลังติดตามดีมานด์เซิร์ฟเวอร์ AI คุณไม่ควรมองเพียงยอดจัดส่ง GPU เท่านั้น แต่ยังต้องเฝ้าติดตามความจุ HBM การกำหนดค่า DRAM ของเซิร์ฟเวอร์ การจัดซื้อ SSD ระดับองค์กร ยอดจัดส่ง HDD ในหน่วยเอ็กซาไบต์ การลงทุนด้านทุนของคลาวด์ และปริมาณการเรียกใช้งาน API สำหรับการอนุมาน ดีมานด์ด้านการอนุมานที่เพิ่มขึ้นอาจช่วยหนุนห่วงโซ่อุปทานด้านการจัดเก็บข้อมูล แต่ไม่ได้หมายความว่าทุกบริษัทด้านการจัดเก็บข้อมูลจะได้รับประโยชน์เท่ากัน คำถามที่แท้จริงคือ: ดีมานด์ตกอยู่ที่ชั้นใด ราคายั่งยืนหรือไม่ กำลังการผลิตกำลังขยายตัวเร็วเกินไปหรือไม่ และลูกค้ากำลังก่อรูปแบบการจัดซื้อระยะยาวหรือไม่?

การวิเคราะห์ห่วงโซ่อุปทานไม่ควรหยุดอยู่แค่วลี “AI storage” HBM เกี่ยวข้องกับการแนบ GPU ระดับไฮเอนด์และกำลังการผลิตการบรรจุขั้นสูง DRAM เกี่ยวข้องกับการอัปเกรดแพลตฟอร์มเซิร์ฟเวอร์และความต้องการแคช NAND/SSD เกี่ยวข้องกับข้อมูลร้อน การโหลดโมเดล และการจัดซื้อจัดเก็บข้อมูลระดับองค์กร HDD เกี่ยวข้องกับปริมาณการจัดส่งระดับเอกซะไบต์ ความต้องการ nearline และการเก็บถาวรข้อมูลเย็น ระบบจัดเก็บข้อมูลผูกพันกับ RAG ขององค์กร การกำกับดูแลข้อมูล และการปรับใช้ไฮบริดคลาวด์ งานวิจัยของ Dell’Oro เกี่ยวกับ ส่วนประกอบเซิร์ฟเวอร์และที่เก็บข้อมูลในศูนย์ข้อมูล คาดการณ์ว่ารายได้จากส่วนประกอบหลักของเซิร์ฟเวอร์และที่เก็บข้อมูลจะเติบโตในอัตรา CAGR 25% ในช่วงห้าปีข้างหน้าและเข้าใกล้ระดับ 1 ล้านล้านดอลลาร์สหรัฐ ซึ่งแสดงให้เห็นว่าโครงสร้างพื้นฐาน AI ได้ขยายจากชิปไปสู่ส่วนประกอบระดับระบบแล้ว

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

ความเสี่ยงของการลงทุนในหน่วยจัดเก็บข้อมูล AI ควรได้รับการกล่าวถึงเป็นอันดับแรกเช่นกัน ประการแรก งบลงทุนด้านโครงสร้างพื้นฐานคลาวด์อาจชะลอตัวเป็นบางช่วง ประการที่สอง HBM, DRAM, NAND และ HDD ต่างมีวงจรกำลังการผลิตของตนเอง และราคาที่สูงขึ้นอาจกระตุ้นให้เกิดการขยายกำลังการผลิต ประการที่สาม เทคโนโลยีการปรับปรุงประสิทธิภาพการอนุมาน (inference) อาจลดปริมาณหน่วยความจำที่จำเป็นต่อคำขอแต่ละรายการ ประการที่สี่ โครงการ RAG ระดับองค์กรและโครงการเอเจนต์ (agent) อาจได้รับผลกระทบจากความปลอดภัยของข้อมูล การปฏิบัติตามกฎระเบียบ และผลตอบแทนจากการลงทุน (ROI) จึงทำให้การนำไปใช้อาจไม่เพิ่มขึ้นอย่างเป็นเส้นตรง ประการที่ห้า มูลค่าหุ้นที่เกี่ยวข้องอาจสะท้อนความคาดหวังที่มองไปข้างหน้าไว้ล่วงหน้าแล้ว หากราคา คำสั่งซื้อ หรืออัตรากำไรขั้นต้นไม่เป็นไปตามคาด ความผันผวนอาจถูกขยายตัวออกไป

สรุป: นักลงทุนทั่วไปควรแปลงดีมานด์เซิร์ฟเวอร์ AI ให้เป็นตัวชี้วัดที่สังเกตได้ แทนที่จะหยุดอยู่แค่ระดับแนวคิด คุณสามารถติดตามสเปกแพลตฟอร์ม GPU ความจุ HBM, DRAM ของเซิร์ฟเวอร์, SSD สำหรับองค์กร, ปริมาณการจัดส่ง HDD หน่วยเอ็กซะไบต์, การใช้จ่ายด้านทุนของคลาวด์, ปริมาณการเรียกใช้งานการอนุมาน (inference) และอัตรากำไรขั้นต้นของบริษัทสตอเรจได้ การเติบโตของการอนุมานสามารถทำให้ห่วงโซ่สตอเรจมีความสำคัญมากขึ้นจริง แต่ระดับของประโยชน์ที่ได้รับขึ้นอยู่กับชั้นของผลิตภัณฑ์ โครงสร้างลูกค้า วงจรราคา และภูมิทัศน์การแข่งขัน ก่อนทำการซื้อขาย คุณควรเข้าใจประเภทคำสั่งซื้อขาย โครงสร้างค่าธรรมเนียม กฎของแพลตฟอร์ม และข้อกำหนดด้านกำกับดูแลในท้องถิ่นด้วย แทนที่จะมองแนวโน้มของอุตสาหกรรมเป็นการรับประกันผลตอบแทน

หากคุณติดตามเซิร์ฟเวอร์ AI, HBM, DRAM, NAND, SSD, HDD และบริษัทเทคโนโลยีของสหรัฐฯ เป็นประจำ คุณสามารถนำตัวชี้วัดทางเทคนิค ผลประกอบการบริษัท ความผันผวนของตลาด และค่าธรรมเนียมการซื้อขาย มารวมไว้ในกรอบการวิเคราะห์เดียวกันได้ Biya เป็นกระเป๋าเงินสำหรับเทรดสินทรัพย์หลายประเภทระดับโลกที่รองรับการซื้อขายหุ้นสหรัฐฯ หุ้นฮ่องกง และคริปโต คุณยังสามารถใช้ ค้นหาข้อมูลหุ้นสหรัฐฯ เพื่อติดตามหุ้นชิปหน่วยความจำ เซิร์ฟเวอร์ AI และคลาวด์คอมพิวติ้งได้ หากภูมิภาคของคุณ ผลการตรวจสอบยืนยันตัวตน และกฎระเบียบที่ใช้บังคับตรงตามเงื่อนไขการให้บริการที่เกี่ยวข้อง คุณยังสามารถดาวน์โหลดแอป เพื่อจัดการข้อมูลตลาด รายการเฝ้าดู และขั้นตอนการซื้อขายได้อีกด้วยข้อมูลข้างต้นเป็นเพียงการแนะนำข้อมูลตลาดสาธารณะ ตรรกะทางเทคนิค และโครงสร้างค่าธรรมเนียมเท่านั้น ไม่ถือเป็นคำแนะนำในการลงทุน

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

การอนุมานด้วย AI ต้องการพื้นที่จัดเก็บมากกว่าการฝึกฝนหรือไม่?

การอนุมานด้วย AI ไม่จำเป็นต้องใช้ข้อมูลดิบมากกว่าการฝึกฝนเสมอไป แต่ขึ้นอยู่กับหน่วยความจำและการจัดเก็บแบบชั้นข้อมูลอย่างต่อเนื่องมากกว่า การฝึกฝนต้องการชุดข้อมูลขนาดใหญ่ checkpoint และท่อประมวลผลข้อมูลความเร็วสูง ส่วนการอนุมานต้องการน้ำหนักโมเดลแบบถาวร KV cache ฐานข้อมูล RAG บันทึกคำขอ และข้อมูลผลตอบรับ การเปรียบเทียบที่เหมาะสมควรแยกหน่วยความจำระหว่างการทำงานออกจากการเก็บรักษาข้อมูลระยะยาว แทนที่จะเปรียบเทียบขนาดข้อมูลครั้งเดียวเพียงอย่างเดียว

ทำไม KV Cache ในการอนุมาน LLM จึงใช้หน่วยความจำเซิร์ฟเวอร์มากมาย?

KV cache เก็บสถานะระดับกลาง key/value ที่เกิดขึ้นระหว่างการอนุมานของโมเดล เพื่อให้โมเดลไม่จำเป็นต้องคำนวณ token ในอดีตซ้ำอีกครั้ง ยิ่งบริบทยาวและยิ่งมีคำขอพร้อมกันมากเท่าไร KV cache ก็ยิ่งใช้หน่วยความจำ GPU และหน่วยความจำระบบมากขึ้นเท่านั้น มันช่วยเพิ่มประสิทธิภาพการอนุมาน แต่ก็อาจจำกัดขนาด batch, throughput และ latency ได้ ทำให้มันเป็นตัวแปรหน่วยความจำหลักในการให้บริการ LLM ขนาดใหญ่

ความแตกต่างระหว่าง HBM, DRAM และ SSD ในเซิร์ฟเวอร์ AI คืออะไร?

HBM ติดตั้งอยู่ใกล้กับ GPU และช่วยให้การคำนวณโมเดลมีแบนด์วิดท์สูง ส่วน DRAM อยู่ฝั่งโฮสต์และรองรับการจัดตารางงาน แคชชิ่ง และการเตรียมข้อมูล ขณะที่ SSD ทำหน้าที่โหลดโมเดล อ่านข้อมูลที่ใช้บ่อย ดัชนีเวกเตอร์ และเขียน log ทั้งสามอย่างนี้สนับสนุนเซิร์ฟเวอร์ AI แต่แตกต่างกันในด้านความเร็ว ความจุ ต้นทุน และตำแหน่งในระบบ การวิเคราะห์ห่วงโซ่อุปทานควรพิจารณาความต้องการ HBM หน่วยความจำเซิร์ฟเวอร์ และ SSD ระดับองค์กรแยกจากกัน

เหตุใดแอปพลิเคชัน RAG ระดับองค์กรจึงเพิ่มความต้องการการเก็บรักษาข้อมูล?

Enterprise RAG นำเอกสารภายในองค์กร ฐานความรู้ embeddings ดัชนีเวกเตอร์ บันทึกสิทธิ์การเข้าถึง และบันทึกการค้นหาข้อมูล เข้าสู่ระบบ AI เมื่อโมเดลตอบคำถาม จำเป็นต้องดึงข้อมูลเหล่านี้มาใช้ ในขณะเดียวกันระบบยังต้องจัดเก็บพรอมต์ คำตอบ ข้อเสนอแนะ และข้อมูลการตรวจสอบ ยิ่ง RAG ถูกฝังลึกเข้าไปในเวิร์กโฟลว์มากเท่าไร องค์กรก็ยิ่งต้องการชั้นข้อมูลร้อน ฐานข้อมูลเวกเตอร์ ออบเจ็กต์สตอเรจ และคลังเก็บข้อมูลแบบ cold archive มากขึ้นเท่านั้น

นักลงทุนทั่วไปจะประเมินได้อย่างไรว่าความต้องการ Storage สำหรับ AI นั้นเป็นความต้องการจริงหรือไม่?

นักลงทุนทั่วไปสามารถติดตามการใช้จ่ายด้านโครงสร้างพื้นฐานคลาวด์ (capex), ปริมาณการส่งมอบเซิร์ฟเวอร์ AI, กำลังการผลิต HBM, การกำหนดค่า DRAM ของเซิร์ฟเวอร์, การจัดซื้อ SSD ระดับองค์กร, ปริมาณการส่งมอบ HDD ในหน่วยเอกซะไบต์ และอัตรากำไรขั้นต้นของบริษัทด้านอุปกรณ์จัดเก็บข้อมูล ความต้องการที่แท้จริงมักปรากฏให้เห็นในคำสั่งซื้อ อัตราการใช้กำลังการผลิต ส่วนผสมของผลิตภัณฑ์ และการเปลี่ยนแปลงของราคา กระแสความตื่นเต้นในตลาดเชิงมโนทัศน์เพียงอย่างเดียวไม่เพียงพอที่จะพิสูจน์ความต้องการในระยะยาว ดังนั้นรายงานทางการเงินและการเปิดเผยข้อมูลความเสี่ยงยังคงมีความสำคัญ

การเติบโตของความต้องการอุปกรณ์จัดเก็บข้อมูลจาก AI หมายความว่าหุ้นกลุ่มอุปกรณ์จัดเก็บข้อมูลจะได้ประโยชน์แน่นอนหรือไม่?

การเติบโตของความต้องการการจัดเก็บข้อมูลจาก AI ไม่ได้หมายความว่าหุ้นกลุ่มอุปกรณ์จัดเก็บข้อมูลทุกตัวจะได้รับประโยชน์เท่ากัน HBM, DRAM, NAND, SSD, HDD และระบบจัดเก็บข้อมูลระดับองค์กร ต่างก็มีปัจจัยขับเคลื่อนความต้องการที่แตกต่างกัน วงจรราคา การขยายกำลังการผลิต ความเข้มข้นของลูกค้า และการแข่งขัน ล้วนส่งผลกระทบต่อความสามารถในการทำกำไร ก่อนทำการซื้อขาย นักลงทุนควรพิจารณามูลค่าหลักทรัพย์ โครงสร้างค่าธรรมเนียม กฎของแพลตฟอร์ม และข้อกำหนดด้านกฎระเบียบในท้องถิ่นด้วย แทนที่จะมองว่าแนวโน้มของอุตสาหกรรมเป็นการรับประกันผลตอบแทนการลงทุน