CXL内存池化的性能验收，不能等同于“设备能识别、带宽达标、延迟在纳秒级”这三项指标通过。企业需要建立一套从业务负载出发、覆盖多维度、包含边界条件的验收框架，否则极易把实验室数据误认为生产承诺。
验收的第一原则，是用真实工作负载替代基准测试。内存带宽基准（如STREAM）只能反映链路极限吞吐，无法揭示CXL内存在实际业务中的表现。企业至少应准备三组对照：纯本地内存、单机CXL扩展内存、多主机共享的池化内存。在每组配置下运行目标AI负载，观察端到端推理吞吐、首字节延迟、P95和P99尾延迟、CPU与内存控制器占用率，以及多租户并发时的资源争用表现。只有这些数据能映射到业务SLA，验收才有依据。
带宽和延迟的验收必须区分访问模式。CXL远端内存在顺序大块读取场景下表现较好，但随机小粒度访问、读写混合负载、多主机同时访问同一内存池时，有效带宽可能大幅下降，延迟抖动也会加剧。验收方案应覆盖：单主机独占访问、多主机并发访问、读写比例变化、数据访问粒度从64字节到4KB的变化。尤其要记录P99延迟的波动范围——如果尾延迟在并发场景下成倍增长，在线推理类业务将无法接受。
容量利用率是容易被忽视的验收维度。内存池化的经济价值建立在“资源错配真实存在”的前提下。验收前应先统计现有集群的平均内存使用率、峰值使用率、峰值是否同时发生、内存不足导致的任务排队或磁盘交换情况。如果所有服务器长期接近内存峰值，池化主要解决的是扩容方式而非利用率提升；如果峰值高度错开，池化才可能减少冗余配置。验收时应验证：池化后整体内存利用率是否提升，单台服务器的峰值配置是否可降低。
兼容性验收不能止步于“硬件识别成功”。需要逐层确认：CPU、主板、BIOS和固件是否支持目标CXL能力；操作系统、内核、驱动和监控工具能否正确识别资源；虚拟机和容器是否支持内存分配与隔离；Kubernetes或其他调度平台能否感知不同内存层级；应用是否依赖固定NUMA拓扑。硬件能枚举出CXL内存，不代表业务调度、故障隔离和在线运维已经成熟。验收应包含故障注入测试：模拟链路中断、设备热插拔、内存错误，观察系统能否正确隔离、恢复或切换。
成本验收应核算全生命周期投入，而非仅看设备单价。需要纳入：设备采购、机房改造、软件适配、运维监控、性能损耗带来的额外服务器需求、以及扩展收益。如果池化设备带来的软件改造和运维复杂度超过了节省的硬件成本，方案就不具备经济性。验收时应明确：兼容性验证由哪一方负责，性能指标采用什么测试方法，多厂商设备混用时的支持范围，固件和驱动升级是否影响业务。
最后，验收应设置明确的退出条件。如果延迟抖动、故障隔离或兼容性不达标，应保留回退到传统本地内存方案的能力。更稳妥的做法，是先做单机CXL扩展和小规模池化试点，把CXL定位为容量层或缓存层，而不是默认让所有数据无差别进入池化内存。在没有完成真实负载测试之前，不宜用单一参数承诺整个平台的收益。