Marvell และซิลิคอนที่ขับเคลื่อนโครงสร้างพื้นฐานคลาวด์อย่างเงียบๆ

สิ่งที่ Marvell ทำในศูนย์ข้อมูลคลาวด์สมัยใหม่

คนส่วนใหญ่มักคิดว่า “คลาวด์” คือแคร์เซิร์ฟเวอร์ แต่ในความจริง ศูนย์ข้อมูลคลาวด์คือระบบขนาดใหญ่สำหรับการเคลื่อนย้าย เก็บ และปกป้องข้อมูลด้วยความเร็วสูง ซิลิคอนโครงสร้างพื้นฐานข้อมูล คือชุดชิปเฉพาะทางที่จัดการงานหนักด้านข้อมูลเหล่านั้นเพื่อให้ CPU หลักไม่ต้องรับภาระ

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

ตำแหน่งของ Marvell ในสแต็กคลาวด์ทั่วไป

ถ้าคุณจินตนาการแร็คคลาวด์จากบนลงล่าง อุปกรณ์ของ Marvell มักอยู่:

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

สิ่งเหล่านี้ไม่ใช่ “แอป” และไม่ใช่ “เซิร์ฟเวอร์” ในความหมายปกติ—แต่เป็นบล็อกฮาร์ดแวร์ที่ทำให้เซิร์ฟเวอร์นับพันทำงานร่วมกันเหมือนบริการเดียว

ทำไมงานส่วนใหญ่จึงมองไม่เห็นโดยผู้ใช้ปลายทาง

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

แผนที่ด่วน: เครือข่าย สตอเรจ การเร่งความเร็ว

บทบาทของ Marvell แบ่งง่ายเป็นสามกลุ่ม:

• เครือข่าย: เคลื่อนย้ายแพ็กเก็ตอย่างรวดเร็วและคาดเดาได้
• สตอเรจ: อ่าน/เขียนข้อมูลอย่างปลอดภัยในระดับใหญ่
• การเร่งความเร็ว: คอมพิวต์เฉพาะทางสำหรับงานโครงสร้างพื้นฐานที่ซ้ำซ้อน

นี่คือซิลิคอน “ที่ทำงานเงียบ” ที่ช่วยให้บริการคลาวด์ดูเรียบง่ายบนพื้นผิว

ทำไมคลาวด์ต้องการชิปโครงสร้างพื้นฐานเฉพาะ

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

ปริมาณทราฟฟิกเติบโตเร็วกว่าพื้นที่ว่างของ CPU

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

ทราฟฟิก east–west ครองพื้นที่ภายในดาต้าเซ็นเตอร์

ทราฟฟิกส่วนใหญ่ไม่ออกสู่สาธารณะ แต่เดินทาง “แบบ east–west” ระหว่างบริการ: การเรียกไมโครเซอร์วิส, อ่านฐานข้อมูล, อัปเดตแคช, การจำลองสตอเรจ และงาน AI กระจาย ทราฟฟิกภายในต้องการความหน่วงที่คาดเดาได้และแบนด์วิดท์สูง ซึ่งผลักให้ฮาร์ดแวร์เครือข่ายและสตอเรจทำการประมวลผลใกล้กับเส้นทางข้อมูลมากขึ้น

ประสิทธิภาพกลายเป็นข้อกำหนดอันดับหนึ่ง

พลังงานและพื้นที่ไม่ใช่สิ่งไม่จำกัด หากผู้ให้บริการคลาวด์สามารถ offload งานเช่น การประมวลผลแพ็กเก็ต การเข้ารหัส การบีบอัด หรือการตรวจสอบสตอเรจไปยังซิลิคอนเฉพาะ CPU จะใช้เวลาน้อยลงกับงานโอเวอร์เฮด ซึ่งช่วยให้:\n

• งานต่อวัตต์ดีขึ้น (งานมากขึ้นต่อพลังงานเท่าเดิม)\n- ความหนาแน่นของเซิร์ฟเวอร์เพิ่มขึ้น (คอมพิวต์ที่ใช้งานได้ต่อแร็คมากขึ้น)\n- ต้นทุนการดำเนินงานลดลง (พลังงานและการระบายความร้อนต่ำลงสำหรับ throughput เดิม)

จาก “CPU เดียวตัวใหญ่” สู่ผู้ช่วยเฉพาะทาง

แทนที่จะขยายด้วยการเพิ่มคอร์ทั่วไป แพลตฟอร์มคลาวด์ใช้ชิปที่ออกแบบมาเฉพาะงานมากขึ้น—Smart NIC/DPU, ซิลิคอนสวิตช์, ตัวควบคุมสตอเรจ และตัวเร่ง—เพื่อจัดการงานโครงสร้างพื้นฐานซ้ำซ้อน ปริมาณสูง ผลลัพธ์คือคลาวด์ที่เร็วขึ้นและถูกลงในการรัน แม้ภาระงานจะต้องการข้อมูลมากขึ้นเรื่อยๆ

การ offload เครือข่าย: อธิบาย Smart NIC และ DPU แบบเข้าใจง่าย

เซิร์ฟเวอร์คลาวด์ใช้เวลามากกับ “งานโครงสร้างพื้นฐาน” แทนที่จะรันแอปของคุณ ทุกแพ็กเก็ตต้องถูกย้าย ตรวจสอบ บันทึก และบางครั้งก็เข้ารหัส—งานเหล่านี้มักถูกทำโดย CPU หลัก การ offload เครือข่ายย้ายงานเหล่านั้นไปยังฮาร์ดแวร์เฉพาะ ซึ่งเป็นที่มาของ Smart NIC และ DPU ที่ปรากฏในดาต้าเซ็นเตอร์สมัยใหม่ (รวมถึงระบบที่ใช้ซิลิคอนของ Marvell)

Smart NIC กับ DPU (คำนิยามแบบง่าย)

Smart NIC คือการ์ดอินเทอร์เฟซเครือข่ายที่ทำมากกว่าแค่ส่ง/รับ นอกจากพอร์ตอีเธอร์เน็ตแล้ว ยังมีการประมวลผลเพิ่มเติม (มักเป็นคอร์ Arm และ/หรือลอจิกที่โปรแกรมได้) เพื่อรันฟีเจอร์เครือข่ายบนการ์ด

DPU (Data Processing Unit) ไปไกลกว่านั้น: ถูกออกแบบให้ทำหน้าที่เหมือน “คอมพิวเตอร์โครงสร้างพื้นฐาน” ภายในเซิร์ฟเวอร์ DPU มักรวมเครือข่ายประสิทธิภาพสูง คอร์ CPU หลายตัว ตัวเร่งฮาร์ดแวร์ (crypto, packet processing) และฟีเจอร์แยกโดเมนที่ทำให้มันจัดการการเคลื่อนย้ายข้อมูลและความปลอดภัยโดยไม่ต้องพึ่งพาโฮสต์มาก

แบบจำลองง่ายๆ ในหัว:\n

• Smart NIC: NIC ที่มีสมองช่วยเหลือ\n- DPU: NIC บวกระบบเฉพาะสำหรับงานโครงสร้างพื้นฐาน

งานอะไรบ้างที่ถูกย้ายออกจาก CPU

เป้าหมายของ offload คืองานที่ทำซ้ำและมีปริมาณมากซึ่งจะดึงรอบ CPU จากแอป ตัวอย่างทั่วไปได้แก่:

• เส้นทางข้อมูลเครือข่าย: สวิตชิ่งเสมือน, กฎการเราท์, encap/decap (เช่น overlays), การปรับทราฟฟิก\n- ความปลอดภัย: การเข้ารหัส TLS/IPsec, การบังคับใช้ไฟร์วอล, การแบ่งส่วนจุลภาค, secure boot และ attestation\n- การเร่งทราฟฟิกสตอเรจ: ช่วยชี้ทิศทางแพ็กเก็ตสตอเรจอย่างมีประสิทธิภาพ บางออกแบบช่วยการไหลของสตอเรจบนเครือข่าย\n- เทเลเมทรี: บันทึกโฟลว์, การสุ่มแพ็กเก็ต, เคาน์เตอร์, การวัดความหน่วง—จับที่ความเร็วสาย

ทำไมจึงสำคัญ: ประสิทธิภาพคาดเดาได้และภาระ CPU ต่ำลง

เมื่อ CPU ต้องคอย “ดูแล” เครือข่าย ประสิทธิภาพแอปอาจแกว่งเมื่อมีสไปก์ทราฟฟิก เพื่อนร่วมงานดัง (noisy neighbors) หรือการทำงานด้านความปลอดภัยที่กระทันหัน Offload ช่วยโดย:\n

• ปล่อยคอร์ CPU ให้แอปหลัก (เว็บเซอร์วิส, ฐานข้อมูล, งาน AI)\n- ทำให้ความหน่วงคงที่กว่า เพราะการจัดการแพ็กเก็ตเกิดในทางเดินฮาร์ดแวร์เฉพาะ\n- เพิ่มความหนาแน่นโฮสต์: ใช้ CPU น้อยลงกับงานโครงสร้างพื้นฐาน ทำให้มีงานที่ใช้ประโยชน์ได้มากขึ้นต่อเซิร์ฟเวอร์\n- ปรับปรุงการแยกโดเมน: การควบคุมโครงสร้างพื้นฐานสามารถรันแยกจากโหลดของผู้เช่า

ตำแหน่งของ DPU ในเซิร์ฟเวอร์ (และสิ่งที่มันเชื่อมต่อ)

ทางกายภาพ DPU มักมาในรูปแบบ การ์ด PCIe หรือโมดูล OCP NIC เชื่อมต่อกับ:

• เครือข่ายท็อป-ออฟ-แร็ค ผ่านพอร์ตอีเธอร์เน็ตความเร็วสูง\n- โฮสต์เซิร์ฟเวอร์ผ่าน PCIe ทำหน้าที่เป็นเกตเวย์สำหรับทราฟฟิกเครือข่ายไปยัง CPU และหน่วยความจำ

เชิงแนวคิด DPU กลายเป็น “นายตำแหน่งทราฟฟิก” ระหว่างเครือข่ายและเซิร์ฟเวอร์—จัดการนโยบาย การเข้ารหัส และสวิตชิ่งเพื่อให้ OS โฮสต์และ CPU มุ่งไปที่การรันแอป

ภายในเครือข่ายคลาวด์: การสวิตช์อีเธอร์เน็ตและการประมวลผลแพ็กเก็ต

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

ข้อมูลเคลื่อนที่ระหว่างเซิร์ฟเวอร์อย่างไร: ToR และ spine

ศูนย์ข้อมูลส่วนใหญ่ใช้การออกแบบ “leaf-spine":

• สวิตช์ Top-of-rack (ToR) / leaf อยู่ที่แต่ละแร็คและเชื่อมต่อกับเซิร์ฟเวอร์ในแร็คนั้นโดยตรง\n- Spine switches เชื่อม ToR ทุกตัวเข้าด้วยกัน เพื่อให้เซิร์ฟเวอร์ใดก็ได้เข้าถึงอีกเครื่องในจำนวนฮ็อปที่คาดเดาได้

การออกแบบนี้ทำให้เส้นทางสั้นและคงที่ ซึ่งสำคัญสำหรับประสิทธิภาพในระดับใหญ่

ทำไมความหน่วงต่ำและแบนด์วิดท์สูงจึงสำคัญ

มีสองตัวเลขที่กำหนดประสบการณ์ผู้ใช้และต้นทุน:\n

• ความหน่วง (เวลาที่แพ็กเก็ตใช้) มีผลกับงานโต้ตอบ—API, ฐานข้อมูล, ไมโครเซอร์วิส และการวิเคราะห์เรียลไทม์\n- แบนด์วิดท์ (ปริมาณข้อมูลต่อวินาที) มีผลกับการย้ายข้อมูลจำนวนมาก—การทำซ้ำสตอเรจ, สำรองข้อมูล, สตรีมมิ่ง และชุดข้อมูล AI ขนาดใหญ่

ผู้ปฏิบัติการคลาวด์มุ่งรักษาความหน่วงให้คงที่แม้ลิงก์จะหนาแน่น ในขณะเดียวกันยังคงผลักดันปริมาณทราฟฟิกมหาศาล

ฟังก์ชันสำคัญ: การสวิตช์, การประมวลผลแพ็กเก็ต, QoS

ชิปสวิตช์อีเธอร์เน็ตทำมากกว่าการ “ส่งต่อแพ็กเก็ต” ต้อง:\n

• ค้นหาปลายทาง (MAC, VLAN และบ่อยครั้ง header สำหรับเราท์/overlay) ที่อัตราไลน์เรต\n- บัฟเฟอร์และจัดตารางทราฟฟิก เพื่อหลีกเลี่ยงการแพร่กระจายของคอขวดในผ้าเครือข่าย\n- ใช้ QoS (Quality of Service) ให้ฟลูที่ต้องการความหน่วงต่ำไม่ถูกกลบด้วยการโอนย้ายพื้นหลัง\n- รองรับเทเลเมทรีและการควบคุมคอขวดที่ช่วยให้ผู้ปฏิบัติการปรับจูนประสิทธิภาพ

ผู้ขายเช่น Marvell ผลิตซิลิคอนที่มุ่งทำงานเหล่านี้อย่างคาดเดาได้ที่ความเร็วสูงมาก

สิ่งที่ “ความเร็วสูงขึ้น” ทำได้

การย้ายจาก 25/100G ไปสู่ 200/400/800G ไม่ใช่แค่ตัวเลข:\n

• เพิ่มจำนวน VM ต่อแร็ค โดยไม่โอเวอร์ซับสวิตช์เกินไป\n- เข้าถึงสตอเรจได้เร็วขึ้น โดยเฉพาะกับ NVMe แบบกระจาย\n- รอบการเทรน AI สั้นลง โดยให้ GPU ได้รับข้อมูลอย่างสม่ำเสมอมากขึ้น

ผลคือเครือข่ายดาต้าเซ็นเตอร์ที่รู้สึกไม่เหมือน “สาย” แต่เป็นโครงสร้างพื้นฐานที่ใช้ร่วมกันสำหรับทุกงาน

ซิลิคอนสตอเรจ: คอนโทรลเลอร์, NVMe และการปกป้องข้อมูล

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

ตัวควบคุมสตอเรจทำอะไรจริงๆ

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

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

NVMe: ทำไมถึงแพร่หลาย

NVMe (Non-Volatile Memory Express) เป็นโปรโตคอลออกแบบมาสำหรับแฟลชที่รวดเร็ว มันเป็นที่นิยมเพราะลดโอเวอร์เฮดและรองรับคิวขนานหลายชุด—หมายความว่าสามารถมีคำขอหลายรายการพร้อมกันได้ เหมาะกับเวิร์กโหลดคลาวด์ที่มีการอ่าน/เขียนเล็กๆ จำนวนมากพร้อมกัน

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

ฟีเจอร์ในตัว: การเข้ารหัส การบีบอัด และการปกป้องแบบ RAID

คอนโทรลเลอร์สมัยใหม่มักมีฟีเจอร์ฮาร์ดแวร์ที่ถ้าไม่มีก็จะกินรอบ CPU เช่น:\n

• การเข้ารหัส/ถอดรหัส เพื่อปกป้องข้อมูลขณะพักโดยมีผลกระทบต่อประสิทธิภาพน้อย\n- การบีบอัด เพื่อเก็บมากขึ้นและย้ายน้อยลง (มีประโยชน์เมื่อแบนด์วิดท์คือคอขวด)\n- parity/erasure coding แบบช่วยเหลือ เพื่อทนต่อความล้มเหลวและสร้างข้อมูลคืนได้เร็วขึ้น

ทำไมประสิทธิภาพสตอเรจเปลี่ยนพฤติกรรมแอป

สตอเรจไม่ใช่ระบบย่อยแยกตัว—มันกำหนดพฤติกรรมแอป:\n

• ฐานข้อมูล ขึ้นกับการเขียนที่เร็วและคงที่สำหรับธุรกรรมและล็อกที่ทนทาน\n- ท่อการวิเคราะห์ อาจติดขัดเมื่อการอ่านชุดข้อมูลใหญ่กลายเป็นคิว\n- การสำรองและกู้คืน เป็นปัญหาต่อเนื่องทางธุรกิจเมื่อ throughput ถูกจำกัด

สรุปคือ ซิลิคอนสตอเรจเปลี่ยนแฟลชดิบให้เป็นโครงสร้างพื้นฐานคลาวด์ที่เชื่อถือได้และให้ throughput สูง

รากฐานการเชื่อมต่อ: PCIe และ CXL แบบเข้าใจง่าย

เมื่อผู้ให้บริการคลาวด์อัพเกรดเซิร์ฟเวอร์ พวกเขาไม่ได้แค่เปลี่ยน CPU แต่ยังต้องการ “เนื้อเยื่อเชื่อมต่อ” ที่ให้ CPU คุยกับการ์ดเครือข่าย สตอเรจ และตัวเร่ง โดยไม่ต้องออกแบบใหม่ทั้งหมด นั่นคือเหตุผลที่มาตรฐานอย่าง PCIe และ CXL สำคัญ: ทำให้ชิ้นส่วนทำงานร่วมกันได้ ลดความเสี่ยงการอัพเกรด และช่วยให้ดาต้าเซ็นเตอร์ขยายได้อย่างคาดเดาได้

PCIe: ทางด่วนความเร็วสูงภายในเซิร์ฟเวอร์

PCIe เป็นลิงก์หลักที่เชื่อมต่ออุปกรณ์เช่น:

• NIC\n- SSD และตัวควบคุมสตอเรจ\n- GPU และตัวเร่งอื่นๆ\n- DPU/Smart NIC

แบบจำลองช่วยให้เข้าใจได้ง่าย: PCIe เหมือนการเพิ่มเลนให้ทางด่วน เจเนอเรชันใหม่เพิ่มความเร็วต่อเลน และลิงก์กว้างขึ้น (x8, x16) เพิ่มความจุรวม สำหรับผู้ปฏิบัติการคลาวด์ นี่ส่งผลโดยตรงต่อความเร็วที่ข้อมูลเคลื่อนระหว่างคอมพิวต์และอุปกรณ์ที่ป้อนข้อมูล

ซิลิคอนโครงสร้างพื้นฐานของ Marvell มักอยู่ในปลายหนึ่งของการเชื่อมต่อ PCIe—ภายใน NIC, DPU, ตัวควบคุมสตอเรจ หรือส่วนที่ใกล้สวิตช์—ดังนั้นความสามารถ PCIe จึงเป็นตัวจำกัดหรือเปิดทางสำหรับการอัพเกรดประสิทธิภาพ

CXL: ใช้ทางเดียวกันเพื่อแชร์หน่วยความจำอย่างมีประสิทธิภาพขึ้น

CXL (Compute Express Link) สร้างบนชั้นกายภาพของ PCIe แต่เพิ่มวิธีแชร์ทรัพยากรเหมือนหน่วยความจำด้วยโอเวอร์เฮดต่ำ โดยสรุป CXL ช่วยให้เซิร์ฟเวอร์จัดการทรัพยากรภายนอก (เช่น การขยายหน่วยความจำหรือหน่วยความจำแบบพูล) ราวกับเป็นการขยายท้องถิ่นมากกว่าอุปกรณ์ที่ไกล

ผลลัพธ์เชิงปฏิบัติสำหรับการออกแบบคลาวด์

ผลประโยชน์ไม่ใช่แค่ “เร็วขึ้น” เท่านั้น PCIe และ CXL สนับสนุน:\n

• การออกแบบที่ยืดหยุ่นขึ้น: ผสมผสานคอมพิวต์ เครือข่าย และสตอเรจได้ตามต้องการ\n- การใช้ทรัพยากรดีขึ้น: ลดทรัพยากรที่ถูกทิ้ง (เช่น หน่วยความจำในเครื่องหนึ่งในขณะที่อีกเครื่องขาด)\n- การอัพเกรดราบรื่นขึ้น: การ์ดและคอนโทรลเลอร์ใหม่สามารถลงในตระกูลเซิร์ฟเวอร์เดิมได้ง่ายขึ้น

มาตรฐานการเชื่อมต่อไม่ค่อยได้ข่าว แต่มีผลอย่างมากต่อความเร็วที่คลาวด์จะนำเทคโนโลยีเครือข่าย สตอเรจ และการเร่งมาใช้

การเร่งความเร็วแบบกำหนดเอง: คอมพิวต์เฉพาะทางสำหรับเวิร์กโหลดคลาวด์

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

“กำหนดเอง” แปลว่าอะไรจริงๆ

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

ตัวอย่างการเร่งที่พบบ่อยที่คุณจะสัมผัสได้

หมวดหมู่ปฏิบัติที่พบซ้ำในดาต้าเซ็นเตอร์:

• ผู้ช่วยประมวลผลแพ็กเก็ต: แยก header, ชี้ทิศทางฟลู, ปรับทราฟฟิก, และบังคับใช้นโยบายที่อัตราไลน์\n- การเร่งความปลอดภัย: crypto (IPsec/TLS), การจัดการคีย์, และการตรวจสอบอินไลน์ที่ถ้าให้ CPU ทำจะกินรอบมาก\n- การเร่งสตอเรจ: erasure coding, บีบอัด, dedupe ช่วย, parity RAID และเช็กซัม—โดยเฉพาะที่ throughput และความหน่วงคงที่สำคัญ\n- วิดีโอ/มีเดีย: transcoding, packaging, และการเตรียมคอนเทนต์สำหรับสตรีม\n- ผู้ช่วย inference ของ AI: ไม่ใช่ตัวเร่งการเทรนขนาดใหญ่เสมอไป แต่เป็นเอนจินเล็กๆ สำหรับ embedding lookup, pre/post-processing หรือเสิร์ฟโมเดล

บริษัทปรับชิปให้เข้ากับเวิร์กโหลดอย่างไร

ทีมคลาวด์ขนาดใหญ่จะเริ่มจากการโปรไฟล์: คำขอชนตรงไหน และงานใดเกิดซ้ำเป็นล้านครั้งต่อวินาที จากนั้นเลือกว่าจะเร่งด้วยเอนจินที่โปรแกรมได้ (ปรับตัวได้มากกว่า) หรือบล็อกฟังก์ชันคงที่ (ประสิทธิภาพต่อวัตต์สูงสุด) ผู้ขายอย่าง Marvell มักให้บล็อกพื้นฐาน—เครือข่าย ความปลอดภัย อินเทอร์เฟซสตอเรจ—ทำให้ส่วนที่ “กำหนดเอง” โฟกัสที่เส้นทางร้อนของแพลตฟอร์มได้

ข้อแลกเปลี่ยน: งานต่อวัตต์ vs ความยืดหยุ่น

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

พลังงานและประสิทธิภาพ: ทำงานให้ได้มากขึ้นต่อวัตต์

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

ทำไม “offload” ถึงประหยัดพลังงาน

CPU ทั่วไปยืดหยุ่นแต่ไม่คุ้มค่าสำหรับงานซ้ำๆ อย่างการจัดการแพ็กเก็ต การเข้ารหัส โปรโตคอลสตอเรจ หรือเทเลเมทรี ซิลิคอนเฉพาะงานเช่น Smart NIC/DPU, สวิตช์, และตัวควบคุมสตอเรจ ทำงานเหล่านี้ด้วยรอบและการสูญเปล่าน้อยกว่า

ชัยชนะด้านพลังงานมักเป็นแบบอ้อม: หาก offload ลดการใช้ CPU คุณสามารถรันโหลดเดียวกันด้วยคอร์ CPU น้อยลง หรือลดนาฬิกา หรือลดจำนวนเซิร์ฟเวอร์ ซึ่งยังลดแรงกดดันหน่วยความจำและการจราจร PCIe ต่อไปด้วย

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

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

วิธีประเมินคำกล่าวอ้างด้านประสิทธิภาพ

ตัวเลขประสิทธิภาพง่ายจะตลาดแต่ยากเปรียบเทียบ เมื่อเห็น “งานต่อวัตต์ดีขึ้น” ให้ดู:\n

• บริบทการวัด: throughput, เป้าความหน่วง, ขนาดแพ็กเก็ต, และฟีเจอร์ที่เปิดใช้ (เช่น การเข้ารหัส)
• ขอบเขตระบบ: พลังงานเฉพาะชิป vs การ์ดเต็มรูปแบบ vs ผลกระทบทั้งเซิร์ฟเวอร์\n- พฤติกรรมช่วงโหลด: ประสิทธิภาพที่ 20–40% utilization อาจสำคัญกว่าจุดพีค\n- เบสไลน์ที่เทียบเท่า: งานเดียวกัน, เจเนอเรชัน CPU เดียวกัน, การตั้งค่า NIC/สวิตช์ที่ใกล้เคียง

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

ฟีเจอร์ความปลอดภัยและความทนทานที่ฝังในซิลิคอนโครงสร้างพื้นฐาน

ผู้ให้บริการคลาวด์แชร์เครื่องจริงกับลูกค้าหลายราย ดังนั้นความปลอดภัยไม่สามารถ "ใส่ทีหลัง" ได้ หลายอย่างถูกบังคับใช้ตั้งแต่ระดับชิป—ใน Smart NIC/DPU, ซิลิคอนเครือข่าย, สวิตช์อีเธอร์เน็ต และตัวควบคุมสตอเรจ—ที่การ offload ฮาร์ดแวร์สามารถประยุกต์การป้องกันด้วยอัตราไลน์ได้

root of trust ทางฮาร์ดแวร์และ secure boot

ซิลิคอนโครงสร้างพื้นฐานส่วนใหญ่รวมถึง root of trust ทางฮาร์ดแวร์: ลอจิกและคีย์ขนาดเล็กที่ไม่เปลี่ยนแปลงได้ซึ่งยืนยันเฟิร์มแวร์ก่อนการเริ่มทำงาน ด้วย secure boot ชิปตรวจสอบลายเซ็นคริปโตของเฟิร์มแวร์ (และบางครั้งส่วนบูตของโฮสต์) และปฏิเสธรันโค้ดที่ถูกแก้ไขหรือไม่รู้จัก

นโยบายนี้สำคัญเพราะ DPU หรือตัวควบคุมสตอเรจที่ถูกบุกรุกอาจอยู่ “ระหว่าง” เซิร์ฟเวอร์กับโครงข่าย/สตอเรจได้ secure boot ลดความเสี่ยงของการฝังตัวที่ชั้นนั้น

การเข้ารหัสอินไลน์สำหรับข้อมูลระหว่างทางและพัก

การเข้ารหัสมักถูกเร่งโดยตรงในซิลิคอนเพื่อไม่ให้กินรอบ CPU:\n

• ข้อมูลระหว่างทาง: DPU และ Smart NIC สามารถ offload การประมวลผล IPsec/TLS และการจัดการคีย์ในขณะรักษา throughput สูง\n- ข้อมูลพัก: ซิลิคอนสตอเรจสามารถทำการเข้ารหัสอินไลน์ในขณะเขียนและถอดรหัสเมื่ออ่าน รวมกับเส้นทาง NVMe โดยไม่ทำให้ I/O ทุกครั้งหนักบน CPU

เพราะเป็นอินไลน์ ความปลอดภัยจึงไม่จำเป็นต้องแลกมาด้วยสตอเรจช้าลง

การแยกโดเมนระหว่างผู้เช่าในโครงสร้างพื้นฐานที่แชร์

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

ฟีเจอร์สังเกตการณ์ที่เผยปัญหาได้เร็วขึ้น

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

ตัวอย่างตั้งแต่ต้นจนจบ: คำขอคลาวด์ช้าลงถูกเร่งอย่างไร

ลองจินตนาการการกระทำง่ายๆ: เปิดแอปช็อปปิ้งแล้วแตะ “ดูประวัติการสั่งซื้อ” คำขอเดียวนี้เดินทางผ่านหลายระบบ—และแต่ละขั้นตอนเป็นโอกาสให้เกิดความล่าช้า

ทีละขั้น: คำขอ → ฐานข้อมูล → การตอบกลับ

1. คำขอของคุณไปถึงขอบคลาวด์และโหลดบาลานเซอร์. แพ็กเก็ตถูกนำไปยังเซิร์ฟเวอร์แอปที่พร้อมใช้งาน.\n
2. ถึงโฮสต์แอป. ตามปกติ CPU โฮสต์ต้องจัดการงาน “ระบบท่อ” มากมาย: การเข้ารหัส, กฎไฟร์วอล, เครือข่ายเสมือน, และการจัดการคิว.\n
3. แอปถามฐานข้อมูล. คำถามนั้นต้องข้ามเครือข่ายดาต้าเซ็นเตอร์ไปยังคลัสเตอร์ฐานข้อมูล แล้วดึงข้อมูลจากสตอเรจ.\n
4. การตอบกลับกลับมาแบบเดียวกัน. ผลลัพธ์ถูกแพ็ก, เข้ารหัส, และส่งกลับไปยังโทรศัพท์ของคุณ.

จุดที่ความหน่วงแอบแฝง

• ฮ็อปเครือข่ายและการประมวลผลแพ็กเก็ต: แต่ละฮ็อปเพิ่มไมโครเดลย์ แต่ต้นทุนที่ใหญ่กว่าอาจเป็นงานต่อแพ็กเก็ต—การตัดสินเราท์, การห่อ/แกะห่อ, การตรวจสอบ ACL\n- I/O สตอเรจ: แม้กับ NVMe ความล่าช้าเกิดเมื่อคิวเต็ม เมทาดาต้าถูกจัดการไม่ดี หรือเส้นทางสตอเรจใช้ CPU มากเกินไป\n- การแย่งชิง CPU: หากคอร์เดียวกันรันทั้งแอปและงานโครงสร้างพื้นฐาน (เครือข่าย, ความปลอดภัย, สแต็กสตอเรจ) ทราฟฟิกกระแทกอาจทำให้เพื่อนร่วมงานดังส่งผล

การ offload และการเร่งความเร็วขจัดคอขวดอย่างไร

Smart NIC/DPU และซิลิคอนโครงสร้างพื้นฐานเฉพาะทาง (รวมถึงโซลูชันจากผู้ขายอย่าง Marvell) ย้ายงานซ้ำซ้อนออกจาก CPU ทั่วไป:\n

• การ offload เครือข่าย จัดการ tunneling, การสวิตชิ่ง/การชี้ทาง, และการบังคับใช้นโยบายใกล้สาย\n- การเร่ง crypto ลดต้นทุน TLS/IPsec ทำให้การเข้ารหัสไม่แย่งรอบแอป\n- การเร่งสตอเรจ ปรับปรุงการจัดการคิว NVMe, งาน parity/ปกป้องข้อมูล และลดภาระ I/O bookkeeping บนโฮสต์

สิ่งที่ดีขึ้นในโลกจริง

• ความหน่วงหางต่ำลง: คำขอที่ช้าเป็นครั้งคราวลดลงในช่วงสไปก์ทราฟฟิก\n- throughput สูงขึ้น: คำขอต่อเซิร์ฟเวอร์มากขึ้นเพราะ CPU มุ่งที่ตรรกะแอป\n- ความสม่ำเสมอดีขึ้น: ประสิทธิภาพคงที่เพราะงานโครงสร้างพื้นฐานแยกออกและคาดเดาได้

ทีมคลาวด์เลือกซิลิคอนอย่างไร

ผู้ปฏิบัติการคลาวด์ไม่เลือกชิปเพราะ “เร็วกว่า” ในเชิงนามธรรม—แต่เลือกเมื่อหน้างานใหญ่ ซ้ำบ่อย และคุ้มค่าต่อการทำเป็นฮาร์ดแวร์ ซิลิคอนเฉพาะมีค่าสูงสุดเมื่อมีคำขอเป็นล้านๆ รายการ รูปแบบการใช้งานคาดเดาได้ และการปรับปรุงเล็กๆ สะสมเป็นการประหยัดจริง

เริ่มจากงาน ไม่ใช่แผ่นสเปก

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

คำถามที่ควรถามผู้ขาย (ก่อน PoC)

ขอคำชี้แจงเกี่ยวกับ:\n

• เวิร์กโหลดที่ซิลิคอนจูนไว้ในวันนี้ (และไม่รองรับอะไร)\n- ความเสถียรของแผนงาน: ความเข้ากันได้พิน/บอร์ดเจนหน้า, หน้าต่างการสนับสนุนเฟิร์มแวร์, และจังหวะการปล่อยฟีเจอร์\n- ความเข้ากันได้: ไดรเวอร์, การสนับสนุนไฮเปอร์ไวเซอร์, การรวมกับ Kubernetes/CNI, และ hook สำหรับการสังเกตการณ์\n- การจัดหาและวงจรชีวิต: ระยะเวลาการส่งสินค้า, ยุทธศาสตร์แหล่งที่สอง, และความพร้อมใช้งานในระยะยาว

ทีมประเมินตัวเลือกอย่างไร

เบนช์มาร์กสำคัญ แต่มีประโยชน์ก็ต่อเมื่อสะท้อนการผลิตจริง: ผสมแพ็กเก็ตจริง, ความลึกคิวสตอเรจจริง, และการแยกผู้เช่าที่สมเหตุสมผล พลังงานต้องประเมินเป็น “งานต่อวัตต์” ไม่ใช่แค่ throughput จุดสูงสุด—โดยเฉพาะเมื่อแร็คถูกจำกัดพลังงาน

ความพยายามในการรวมมักเป็นตัวตัดสิน: ชิปที่ดีกว่า 10% บนกระดาษอาจแพ้ชิปที่ง่ายกว่าในการโปรวิชัน มอนิเตอร์ และแพตช์ในระดับสเกล

หลีกเลี่ยงการล็อกอิน

ทีมคลาวด์ลดความเสี่ยงโดยเลือกมาตรฐาน (Ethernet, NVMe, PCIe/CXL), API ที่มีเอกสารดี, และเครื่องมือการจัดการที่ทำงานร่วมกันได้ แม้จะใช้ฟีเจอร์ของผู้ขาย (รวมถึง Marvell และคู่แข่ง) พวกเขาพยายามให้ control plane ชั้นสูงพกพาได้เพื่อให้ฮาร์ดแวร์เปลี่ยนได้โดยไม่ต้องเขียนแพลตฟอร์มใหม่ทั้งหมด

หลักการเดียวกันใช้กับฝั่งซอฟต์แวร์: เมื่อคุณสร้างบริการที่จะรันบนโครงสร้างพื้นฐานนี้ในอนาคต ควรรักษาให้สถาปัตยกรรมพกพาได้ แพลตฟอร์มอย่าง Koder.ai ช่วยเร่งการทดลองต้นแบบและการทำซ้ำของ backend เว็บ (Go + PostgreSQL) และ frontend React ผ่านเวิร์กโฟลว์สนทนา ในขณะเดียวกันยังให้ทีมส่งออกซอร์สโค้ดและปรับใช้ให้เข้ากับคลาวด์และข้อกำหนดการปฏิบัติตามของตัวเองได้

ต่อไปสำหรับซิลิคอนโครงสร้างพื้นฐานข้อมูล

ซิลิคอนโครงสร้างพื้นฐานกำลังเปลี่ยนจาก “การเร่งที่เสริมได้” มาสู่ระบบพื้นฐาน เมื่อบริการมากขึ้นต้องการความหน่วงต่ำ (AI inference, วิเคราะห์เรียลไทม์, การตรวจสอบความปลอดภัย) ชิปที่จัดการเครือข่าย สตอเรจ และการเคลื่อนย้ายข้อมูลอย่างมีประสิทธิภาพจะสำคัญเทียบเท่า CPU

แบนด์วิดท์สูงขึ้นกลายเป็นค่าเริ่มต้น

เครือข่ายแบนด์วิดท์สูงไม่ใช่ระดับพิเศษอีกต่อไป—เป็นความคาดหวัง ซึ่งผลักให้การสวิตช์อีเธอร์เน็ต การประมวลผลแพ็กเก็ต และ DPU/Smart NIC มุ่งสู่พอร์ตที่เร็วขึ้น ความหน่วงต่ำกว่า และการควบคุมคอขวดที่ดีขึ้น ผู้ขายเช่น Marvell จะแข่งขันกันที่ว่ามีงานกี่อย่างที่สามารถ offload บนฮาร์ดแวร์ได้ (การเข้ารหัส เทเลเมทรี การสวิตชิ่งเสมือน) โดยไม่เพิ่มความซับซ้อนในการปฏิบัติการ

CXL และโครงสร้างพื้นฐานที่ประกอบได้ใช้งานจริง

PCIe และ CXL จะช่วยให้เกิดการแยกส่วนจริง: พูลหน่วยความจำและตัวเร่งเพื่อให้แร็คสามารถ “ประกอบ” ตามเวิร์กโหลด ซิลิคอนที่สำคัญไม่ใช่แค PHY ของ CXL แต่รวมถึงคอนโทรลเลอร์ สวิตช์ และเฟิร์มแวร์ที่ทำให้ทรัพยากรพูลคาดเดาได้ ปลอดภัย และสังเกตการณ์ได้สำหรับทีมคลาวด์

ซิลิคอนเฉพาะมากขึ้นในแพลตฟอร์มขนาดใหญ่

ผู้ให้บริการขนาดใหญ่ต้องการความแตกต่างและการผสานที่แน่นขึ้นข้ามชิปเครือข่าย สตอเรจ และการเร่งคัสตอม คาดว่าจะมีโปรแกรมกึ่งเฉพาะมากขึ้นที่ใช้บล็อกมาตรฐาน (SerDes, การสวิตช์อีเธอร์เน็ต, NVMe) ควบคู่กับฟีเจอร์เฉพาะแพลตฟอร์ม เครื่องมือปรับใช้ และหน้าต่างสนับสนุนยาว

สิ่งที่ควรดูเมื่อตรวจสอบชิ้นส่วนยุคหน้า

งานต่อวัตต์จะเป็นตัวชูโรง โดยเฉพาะเมื่อพลังงานจำกัดการขยาย ความปลอดภัยจะเลื่อนไปใกล้เส้นทางข้อมูล (การเข้ารหัสอินไลน์, secure boot, attestation) สุดท้ายเส้นทางอัพเกรดจะสำคัญ: คุณจะนำแบนด์วิดท์ใหม่, เวอร์ชัน CXL, หรือฟีเจอร์ offload มาใช้ได้โดยไม่ต้องออกแบบแพลตฟอร์มใหม่หรือทำลายความเข้ากันได้กับแร็คที่มีอยู่หรือไม่?