محصولات آکو
HPE
DELL
Broadcom
خدمات آکو
بلاگ
دانلود
HPE
DELL
Broadcom
Vmware
درباره ما
ارتباط با ما
فناوری CXL (Compute Express Link) یک رابط باز و Cache-Coherent برای اتصال پردازنده، شتاب‌دهنده و حافظه است که از زیرساخت فیزیکی PCI Express استفاده می‌کند، اما با افزودن Memory Semantics و Coherency، مدل سنتی «منابع کاملاً محلی و ثابت در هر سرور» را به سمت حافظه قابل توسعه، Pooling، Sharing و معماری‌های Composable هدایت می‌کند. اهمیت CXL فقط در سرعت لینک نیست؛ ارزش اصلی آن این است که CPU و دستگاه‌های سازگار بتوانند با سربار نرم‌افزاری کمتر و مدل دسترسی منسجم‌تری با حافظه و داده کار کنند. در نسل فعلی استاندارد، CXL 4.0 نرخ انتقال را به 128 GT/s رسانده و قابلیت‌هایی مانند Bundled Ports و بهبودهای RAS حافظه را اضافه کرده است.
- CXL سه خانواده پروتکل اصلی دارد: CXL.io برای I/O و مدیریت، CXL.cache برای Coherency کش و CXL.mem برای دسترسی حافظه‌ای.
- مزیت CXL نسبت به PCIe در همان نسل، «پهنای‌باند خام بیشتر» نیست؛ بلکه Coherency، Memory Semantics و قابلیت‌های Pooling و Fabric است.
- CXL 2.0 Switching و Memory Pooling را گسترش داد؛ CXL 3.x Fabric، Memory Sharing و ارتباطات پیشرفته‌تر را توسعه داد؛ CXL 4.0 نیز نرخ انتقال را به 128 GT/s رساند.
- کاربردهای مهم CXL شامل Memory Expansion، زیرساخت‌های Composable، AI/HPC، دیتابیس‌های حافظه‌محور و محیط‌های Cloud/Hyperscale است.
- پشتیبانی واقعی به CPU، Root Port، مادربرد، Firmware/BIOS، نوع دستگاه CXL، سیستم‌عامل و در برخی سناریوها Hypervisor یا Fabric Manager وابسته است.
- کاهش TCO یا مصرف انرژی نتیجه خودکار CXL نیست؛ این مزایا زمانی حاصل می‌شوند که Pooling، Tiering و Sizing منابع با Workload هماهنگ باشند.
CXL چیست و چگونه کار می‌کند؟
CXL یک Interconnect استاندارد و باز برای سیستم‌های محاسباتی مدرن است که ارتباط Cache-Coherent و Memory-Semantic میان Host Processor و دستگاه‌هایی مانند شتاب‌دهنده‌ها، Memory Expanderها و برخی Smart I/O Deviceها را فراهم می‌کند. CXL از بستر الکتریکی و فیزیکی PCI Express استفاده می‌کند؛ بنابراین قرار نیست یک گذرگاه کاملاً مستقل از PCIe باشد. تفاوت اصلی در لایه‌های پروتکل و مدل دسترسی به داده و حافظه شکل می‌گیرد.
CXL را می‌توان «رابطی مبتنی بر PCIe برای ایجاد Coherency و دسترسی حافظه‌ای میان CPU و دستگاه‌های سازگار» تعریف کرد؛ رابطی که هدف آن کاهش کپی‌های غیرضروری داده، افزایش انعطاف حافظه و ایجاد زیرساخت‌های قابل ترکیب‌تر است.
سه پروتکل اصلی: CXL.io، CXL.cache و CXL.mem
CXL.io از مدل تراکنش‌های PCIe برای Discovery، Configuration، Management و I/O استفاده می‌کند. CXL.cache به دستگاه اجازه می‌دهد داده‌های موجود در حافظه Host را به‌صورت Coherent Cache کند. CXL.mem نیز مسیر Load/Store حافظه‌ای را فراهم می‌کند تا Host بتواند به حافظه متصل به دستگاه CXL دسترسی داشته باشد. ترکیب این پروتکل‌ها باعث می‌شود CXL برای سناریوهایی فراتر از I/O سنتی مناسب باشد.
این نکته مهم است که هر دستگاه الزاماً هر سه پروتکل را هم‌زمان استفاده نمی‌کند. نوع دستگاه تعیین می‌کند کدام قابلیت‌ها مورد نیاز است؛ به همین دلیل بررسی «Device Type» در زمان طراحی سرور یا Fabric اهمیت عملی دارد.
تفاوت Device Type 1، Type 2 و Type 3
| نوع دستگاه | پروتکل‌های اصلی | کارکرد عمومی | نمونه سناریو |
|---|---|---|---|
| Type 1 | CXL.io + CXL.cache | شتاب‌دهنده بدون حافظه Host-Managed قابل توجه روی خود دستگاه | Acceleratorهایی که بیشتر به حافظه Host متکی‌اند |
| Type 2 | CXL.io + CXL.cache + CXL.mem | شتاب‌دهنده دارای حافظه محلی که Host نیز می‌تواند به بخشی از حافظه آن دسترسی منسجم داشته باشد | شتاب‌دهنده‌های محاسباتی با Device-Attached Memory |
| Type 3 | CXL.io + CXL.mem | افزایش یا ارائه ظرفیت حافظه برای Host | Memory Expander و Memory Pool |
برای بسیاری از I/O Deviceهای سنتی که به Coherency یا Memory Semantics نیاز ندارند، PCIe همچنان انتخاب کافی و ساده‌تری است. CXL زمانی ارزش بیشتری ایجاد می‌کند که محدودیت حافظه، جابه‌جایی داده، شتاب‌دهنده‌ها یا Disaggregation واقعاً مسئله طراحی باشند.
سیر تکامل CXL از نسخه 1.0 تا 4.0
مسیر CXL از یک لینک مستقیم برای Host و Device به سمت Switching، Memory Pooling، Fabricهای چندسطحی، Memory Sharing و در نهایت پهنای‌باند بالاتر و قابلیت‌های RAS پیشرفته حرکت کرده است. به همین دلیل، ارزیابی CXL فقط با دیدن عبارت «CXL Supported» کافی نیست؛ نسخه استاندارد و Feature Set قابل پشتیبانی باید دقیقاً مشخص شود.
| نسخه | زمان انتشار | نرخ انتقال مرجع | تغییر مهم |
|---|---|---|---|
| CXL 1.0 | مارس 2019 | 32 GT/s | پایه‌گذاری اتصال Coherent و Direct-Attached Device روی بستر PCIe 5.0 |
| CXL 1.1 | سپتامبر 2019 | 32 GT/s | تمرکز بیشتر بر Compliance و Interoperability |
| CXL 2.0 | نوامبر 2020 | 32 GT/s | Switching، Memory Pooling و پشتیبانی از Persistent Memory |
| CXL 3.0 | اوت 2022 | 64 GT/s | Fabric، Multi-Level Switching، Peer-to-Peer و Memory Sharing |
| CXL 3.1 | نوامبر 2023 | 64 GT/s | بهبود Fabric، Port-Based Routing، امنیت TSP و قابلیت‌های بیشتر Memory Expander |
| CXL 3.2 | دسامبر 2024 | 64 GT/s | بهبود مدیریت و مانیتورینگ حافظه، Security/Compliance و قابلیت‌های Memory Device |
| CXL 4.0 | نوامبر 2025 | 128 GT/s | Bundled Ports، بهبود Memory RAS، افزایش Reach و تداوم سازگاری با نسل‌های قبل |
از اتصال مستقیم تا Switching و Memory Pooling
CXL 1.x پایه ارتباط Coherent را ایجاد کرد، اما CXL 2.0 برای دیتاسنتر اهمیت ویژه‌ای داشت چون Switching و Memory Pooling را وارد معماری استاندارد کرد. در این مدل می‌توان ظرفیت حافظه را از حالت «کاملاً ثابت و متصل به یک Host» به منبعی قابل تخصیص‌تر تبدیل کرد. با این حال، Pooling به این معنا نیست که همه Hostها الزاماً همان ناحیه حافظه را هم‌زمان و Coherent به اشتراک می‌گذارند؛ این مفهوم در نسل‌های بعدی توسعه پیدا کرد.
از CXL 3.x تا CXL 4.0؛ حرکت به سمت Fabric
CXL 3.0 نرخ انتقال را به 64 GT/s رساند و قابلیت‌هایی مانند Fabric، Multi-Level Switching، Peer-to-Peer و Memory Sharing را گسترش داد. CXL 3.1 و 3.2 بیشتر روی Fabric Manageability، امنیت، RAS، مانیتورینگ و قابلیت‌های Memory Device کار کردند. CXL 4.0 نیز بر پایه نسل سریع‌تر PCIe، نرخ انتقال 128 GT/s را ارائه می‌کند و با Bundled Ports و بهبودهای حافظه، مسیر Scale-Out و اتصال‌های پرظرفیت‌تر را تقویت می‌کند.
بنابراین اگر مقاله یا طراحی قدیمی هنوز CXL 3.0 را «آخرین نسل» معرفی می‌کند، این دیدگاه دیگر به‌روز نیست. در ارزیابی تجهیزات باید علاوه بر نسخه استاندارد، به نسخه‌ای که واقعاً در CPU، Board، BIOS و Device پیاده‌سازی شده توجه کرد.
چرا CXL معماری سرورها را تغییر می‌دهد؟
تحول اصلی CXL در این است که بخشی از منابعی که قبلاً به‌صورت محلی، ثابت و سخت‌متصل به یک سرور در نظر گرفته می‌شدند، می‌توانند در معماری‌های جدید انعطاف‌پذیرتر شوند. این تغییر به‌خصوص در حافظه اهمیت دارد؛ زیرا افزایش تعداد Coreها و رشد Workloadهای AI و Data-Intensive فشار زیادی به ظرفیت، پهنای‌باند و بهره‌برداری از DRAM وارد کرده است.
Memory Expansion، Pooling و Disaggregation
با CXL Type 3 می‌توان ظرفیت حافظه قابل دسترس Host را فراتر از DIMMهای محلی توسعه داد. در معماری‌های پیشرفته‌تر، Pooling و Fabric کمک می‌کنند حافظه به‌صورت یک منبع زیرساختی مدیریت شود و ظرفیت بلااستفاده کاهش یابد. این موضوع با ایده Composable Infrastructure در دیتاسنتر هم‌راستا است؛ یعنی Compute، Memory و Accelerator بر اساس نیاز Workload به شکل منعطف‌تری ترکیب شوند.
با این حال، CXL-attached Memory را نباید بدون اندازه‌گیری هم‌ارز Local DRAM فرض کرد. Latency، Bandwidth، Topology و NUMA Placement می‌توانند متفاوت باشند و سیستم‌عامل یا نرم‌افزار باید Memory Tiering و Placement را متناسب با Workload مدیریت کند. برای درک بهتر جایگاه لایه‌های حافظه، مطالعه مفهوم Storage-Class Memory در دیتاسنتر نیز دید معماری مفیدی ایجاد می‌کند.
Heterogeneous Compute و کاهش جابه‌جایی غیرضروری داده
در سرورهای شتاب‌یافته، CPU، GPU، FPGA و سایر Acceleratorها ممکن است مدل‌های حافظه متفاوتی داشته باشند و کپی داده میان فضای Host و Device هزینه ایجاد کند. CXL با Coherency و Memory Semantics می‌تواند در طراحی‌های سازگار، بخشی از این پیچیدگی را کاهش دهد و دسترسی به داده را منسجم‌تر کند. این مزیت به‌ویژه زمانی مهم است که سرور از چند نوع پردازنده کمکی استفاده می‌کند و Data Movement به یکی از گلوگاه‌های اصلی تبدیل می‌شود.
این تحول در کنار فناوری‌هایی مانند DPU و نقش آن در آینده سرورها نشان می‌دهد معماری Server در حال حرکت از یک CPU-centric Design ساده به سمت مجموعه‌ای از Compute Engineهای تخصصی است که باید حافظه، شبکه و شتاب‌دهی را هماهنگ‌تر مدیریت کنند.
کاربردهای عملی CXL در AI، HPC، دیتابیس و Cloud
CXL زمانی بیشترین ارزش را دارد که محدودیت حافظه یا هزینه جابه‌جایی داده واقعاً روی کارایی، ظرفیت یا بهره‌وری زیرساخت اثر گذاشته باشد. استفاده از CXL صرفاً به دلیل جدید بودن فناوری منطقی نیست؛ باید مشخص باشد کدام Bottleneck را رفع می‌کند و چه بخش‌هایی از Stack قابلیت بهره‌برداری از آن را دارند.
AI و HPC؛ ظرفیت حافظه و ارتباط با Accelerator
Workloadهای AI و HPC معمولاً به ترکیبی از CPU، GPU یا سایر Acceleratorها و حجم بالایی از حافظه نیاز دارند. CXL می‌تواند در برخی معماری‌ها برای Memory Expansion، Memory Pooling و دسترسی منسجم‌تر میان Host و Accelerator مفید باشد. نتیجه عملی می‌تواند کاهش فشار روی حافظه محلی یا انعطاف بیشتر در Sizing باشد، اما افزایش Performance تضمین‌شده نیست و به الگوی دسترسی داده، Topology و پشتیبانی نرم‌افزاری وابسته است.
در مرحله انتخاب سخت‌افزار، ابتدا باید مشخص شود Bottleneck اصلی Compute است یا Memory. برای همین، راهنمای انتخاب GPU Server برای پروژه‌های هوش مصنوعی و مقایسه HPC Cluster با GPU Cluster برای AI می‌توانند قبل از تصمیم درباره CXL، معماری محاسباتی مناسب‌تر را روشن کنند.
دیتابیس، Analytics، Virtualization و Cloud
دیتابیس‌های In-Memory، موتورهای Analytics، Cacheهای بزرگ و برخی سرویس‌های Cloud می‌توانند از افزایش ظرفیت حافظه یا Tiering سود ببرند. در این سناریوها، CXL اجازه می‌دهد طراحی حافظه فقط به تعداد DIMM Slotهای محلی محدود نباشد. برای Hyperscale و Private Cloud نیز Pooling و Disaggregation می‌تواند ظرفیت را بر اساس تقاضا تخصیص‌پذیرتر کند.
در Virtualization، وجود CXL به‌تنهایی به این معنا نیست که VMها مستقیماً هر Memory Pool یا Accelerator را به‌صورت اشتراکی مصرف می‌کنند. Hypervisor، سیستم‌عامل، Firmware و ابزارهای مدیریت باید مدل Resource Assignment را پشتیبانی کنند. بنابراین CXL بیشتر یک قابلیت زیرساختی است که لایه نرم‌افزار باید آن را به سرویس قابل استفاده برای Workload تبدیل کند.
اگر سرور با کمبود ظرفیت حافظه، Stranded Memory، هزینه بالای کپی داده میان Host و Accelerator، نیاز به Memory Pooling یا برنامه حرکت به سمت Composable Infrastructure مواجه است، CXL یک گزینه جدی است. اگر Workload کوچک است، حافظه محلی کافی است و هیچ نیاز Coherency یا Disaggregation وجود ندارد، مزیت عملی CXL ممکن است محدود باشد.
مزایا، محدودیت‌ها و چالش‌های CXL
مزایای CXL باید در سطح سیستم سنجیده شوند، نه فقط بر اساس Spec Sheet لینک. همان قابلیتی که برای یک دیتاسنتر باعث افزایش Utilization می‌شود، در محیط دیگر ممکن است به دلیل Latency، هزینه Switch، محدودیت Firmware یا نبود پشتیبانی نرم‌افزاری ارزش اقتصادی کافی نداشته باشد.
مزایای قابل انتظار در طراحی درست
محدودیت‌ها و ریسک‌هایی که نباید نادیده گرفته شوند
| چالش | چرا مهم است؟ | اقدام پیشنهادی |
|---|---|---|
| سازگاری End-to-End | وجود CXL روی CPU به‌تنهایی کافی نیست؛ Board، Slot، BIOS، Device و Software Stack نیز باید Feature مورد نظر را پشتیبانی کنند. | Compatibility Matrix و Firmware Release Notes را برای همان Platform بررسی کنید. |
| Latency و Memory Tiering | حافظه متصل از طریق CXL ممکن است رفتار متفاوتی از Local DRAM داشته باشد. | NUMA، Hot/Cold Data Placement و Benchmark واقعی Workload را در طراحی لحاظ کنید. |
| هزینه و توان مصرفی Fabric | Switch، Retimer، Memory Device و مدیریت Fabric هزینه و توان اضافه دارند. | TCO را در سطح Rack/Cluster محاسبه کنید، نه فقط قیمت هر سرور. |
| بلوغ نرم‌افزار و عملیات | Provisioning، Telemetry، RAS و Automation باید با معماری جدید هماهنگ شوند. | PoC با OS/Hypervisor و ابزار مانیتورینگ واقعی سازمان انجام شود. |
| امنیت و Multi-Tenancy | Memory Sharing و Fabric سطح جدیدی از Trust Boundary و Isolation ایجاد می‌کند. | قابلیت‌های IDE، TSP، Firmware Security و مدل Tenant Isolation بررسی شوند. |
نباید صرفاً با دیدن نرخ 128 GT/s در CXL 4.0 نتیجه گرفت که هر Workload دو برابر سریع‌تر از CXL 3.x یا PCIe خواهد شد. Throughput لینک فقط یکی از اجزای Performance است؛ Memory Controller، Device، Topology، Software، Access Pattern و Latency انتها به انتها تعیین‌کننده‌اند.
مقایسه CXL با PCIe، Gen-Z و CCIX
CXL در خلأ شکل نگرفت. PCIe بستر اصلی I/O در سرورهاست و استانداردهایی مانند Gen-Z و CCIX نیز برای حل بخشی از مسائل Coherency، Memory و Accelerator Connectivity توسعه یافته بودند. تفاوت مهم امروز این است که صنعت تا حد زیادی تلاش‌های استانداردسازی را حول CXL همگرا کرده است.
CXL در برابر PCIe؛ مکمل، نه جایگزین کامل
PCIe یک Interconnect عمومی و بسیار گسترده برای I/O است. CXL از همان PHY و زیرساخت پایه استفاده می‌کند و CXL.io نیز با مدل PCIe هم‌راستا است، اما CXL.cache و CXL.mem قابلیت‌هایی را اضافه می‌کنند که PCIe سنتی به‌تنهایی برای Coherent Memory Access ارائه نمی‌دهد. بنابراین سؤال «کدام سریع‌تر است؟» معمولاً سؤال دقیقی نیست؛ در یک نسل مشخص، نرخ لینک می‌تواند مشابه باشد و تفاوت اصلی در Semantics و Use Case است.
CXL در برابر Gen-Z و CCIX؛ همگرایی اکوسیستم
Gen-Z و CCIX با اهدافی نزدیک به Disaggregation، Memory Fabric و Coherent Accelerator Attach توسعه یافته بودند. با گذشت زمان، دارایی‌ها و مشخصات این اکوسیستم‌ها به CXL Consortium منتقل شد و تمرکز صنعت روی یک استاندارد مشترک بیشتر شد. این اتفاق به معنای بی‌ارزش بودن آن فناوری‌ها نیست؛ بلکه نشان می‌دهد Interoperability و تمرکز سرمایه‌گذاری سازندگان برای موفقیت یک Fabric استاندارد اهمیت زیادی دارد.
| فناوری | تمرکز اصلی | Coherency / Memory Semantics | وضعیت نقش در معماری امروز |
|---|---|---|---|
| PCIe | I/O عمومی و اتصال Device | به شکل CXL.cache/CXL.mem ارائه نمی‌شود | بستر اصلی و پایه فیزیکی نسل‌های CXL |
| CXL | Coherent Compute، Memory Expansion، Pooling و Fabric | بله، با پروتکل‌های CXL.cache و CXL.mem | استاندارد متمرکز صنعت برای حافظه و محاسبات ناهمگن Coherent |
| Gen-Z | Memory-Semantic Fabric و Disaggregation | تمرکز قوی بر Memory Fabric | مشخصات و دارایی‌ها به CXL Consortium منتقل شده‌اند |
| CCIX | Coherent Accelerator Interconnect | بله، برای شتاب‌دهنده‌های Coherent | دارایی‌ها و مشخصات به CXL Consortium منتقل شده‌اند |
چک‌لیست انتخاب و پیاده‌سازی CXL
برای تصمیم‌گیری B2B، عبارت «CXL Ready» باید به یک Compatibility Matrix واقعی تبدیل شود. قبل از خرید یا طراحی، این موارد را به‌ترتیب بررسی کنید:
- Workload را مشخص کنید: مشکل اصلی Capacity، Bandwidth، Accelerator Data Movement، Memory Pooling یا Composability است؟
- نسخه و Feature مورد نیاز را تعیین کنید: برای مثال Memory Expansion ساده با Type 3 با یک Fabric چند Host و Memory Sharing نیازهای یکسانی ندارد.
- CPU و Root Port را بررسی کنید: تعداد Lane، نسل CXL، Device Typeهای پشتیبانی‌شده و محدودیت‌های هر Socket یا Slot را از مستندات همان Platform استخراج کنید.
- Board و Firmware را تطبیق دهید: مادربرد، BIOS/UEFI، BMC و Firmware Device باید Feature مورد نظر را فعال و پشتیبانی کنند.
- Software Stack را اعتبارسنجی کنید: OS، Kernel، Hypervisor، Driver، Fabric Manager و ابزارهای Monitoring باید قابلیت‌های لازم را داشته باشند.
- Performance را با Workload واقعی بسنجید: Local DRAM و CXL Memory را از نظر Latency، Bandwidth، NUMA، QoS و رفتار در Failure مقایسه کنید.
- RAS و Security را وارد Sizing کنید: Error Handling، Telemetry، IDE/TSP، Firmware Update و Isolation در طراحی عملیاتی لحاظ شوند.
- TCO را در سطح سیستم محاسبه کنید: هزینه Memory Device، Switch/Retimer، توان، مدیریت، پشتیبانی و ظرفیت آزادشده را یکجا ببینید.
جمع‌بندی؛ آیا CXL واقعاً یک انقلاب در سرورهاست؟
CXL را می‌توان یک تغییر معماری مهم در سرورها دانست، اما نه به این دلیل که صرفاً یک لینک سریع‌تر معرفی کرده است. اثر اصلی آن در نزدیک کردن Compute و Memory، استاندارد کردن Coherency، فراهم کردن Memory Expansion و Pooling و باز کردن مسیر برای Fabricهای Composable و Disaggregated است. این قابلیت‌ها برای AI، HPC، Cloud و دیتابیس‌های Data-Intensive می‌توانند بسیار ارزشمند باشند، به‌خصوص زمانی که حافظه به عامل محدودکننده تبدیل شده باشد.
در عین حال، CXL نسخه‌ای جادویی برای افزایش Performance یا کاهش هزینه نیست. مزیت واقعی به سازگاری End-to-End، طراحی Memory Tiering، Topology، Software Support و Sizing بستگی دارد. برای سازمانی که قصد خرید سرور نسل جدید دارد، بهترین رویکرد این است که CXL را به‌عنوان بخشی از Roadmap زیرساخت ارزیابی کند و Featureهای مورد نیاز را با Workloadهای واقعی تطبیق دهد.
مطالب و محصولات مرتبط
پس از آشنایی با CXL، موضوعات Memory Architecture، GPU Server Design، DPU و Composable Infrastructure برای درک معماری نسل جدید دیتاسنترها مکمل طبیعی این مقاله هستند.
در صفحات محصول، صرف وجود PCIe Gen5/Gen6 یا عبارت CXL کافی نیست. نسخه CXL، نوع Device، Slot Mapping و محدودیت Firmware باید برای همان مدل و کانفیگ بررسی شود.
سوالات متداول درباره CXL
CXL چه تفاوت اصلی با PCIe دارد؟
CXL از بستر PCIe استفاده می‌کند، اما علاوه بر I/O، پروتکل‌های CXL.cache و CXL.mem را برای Coherency و Memory Semantics ارائه می‌دهد. در همان نسل، مزیت اصلی CXL لزوماً نرخ لینک بالاتر نیست؛ بلکه مدل دسترسی حافظه و اشتراک منابع است.
آخرین نسخه CXL کدام است؟
CXL 4.0 در نوامبر 2025 منتشر شد و نرخ انتقال را از 64 GT/s در نسل 3.x به 128 GT/s رساند. این نسخه همچنین Bundled Ports و بهبودهای Memory RAS را اضافه می‌کند و با نسخه‌های قبلی سازگاری رو به عقب دارد.
آیا CXL می‌تواند جایگزین PCIe شود؟
خیر. CXL بر پایه زیرساخت PCIe ساخته شده و برای Use Caseهایی که به Coherency، Memory Expansion، Pooling یا Fabric نیاز دارند قابلیت‌های اضافه فراهم می‌کند. بسیاری از Deviceهای عادی همچنان فقط به PCIe نیاز دارند.
آیا هر سرور جدید از CXL پشتیبانی می‌کند؟
خیر. پشتیبانی به CPU، Chipset یا Root Complex، مادربرد و Slot، BIOS/Firmware و نوع Device بستگی دارد. حتی در یک خانواده سرور ممکن است همه Slotها یا همه کانفیگ‌ها Featureهای یکسان CXL را ارائه نکنند.
آیا CXL باعث کاهش قطعی هزینه و مصرف انرژی می‌شود؟
نه به‌صورت خودکار. CXL می‌تواند با افزایش Utilization حافظه و کاهش Stranded Capacity به TCO کمک کند، اما Switch، Memory Device، Retimer و مدیریت Fabric نیز هزینه و توان مصرف می‌کنند. نتیجه باید در سطح Rack یا Cluster محاسبه شود.
CXL برای AI و HPC چه مزیتی دارد؟
مهم‌ترین مزایا می‌توانند Memory Expansion، Pooling و مدل Coherentتر برای ارتباط Host و Accelerator باشند. با این حال، افزایش Performance به Workload، Data Placement، Topology و Software Support وابسته است و باید Benchmark شود.