PoC 不是所有项目都必须重复做的演示，也不是设备到货后的补救措施。它适合处理公开资料无法消除的不确定性，并应在批量采购和架构冻结前完成。是否需要 PoC，可以按兼容性、性能、规模和运维四类风险判断。
出现这些条件时应优先安排 PoC
- 服务器、网卡、交换机或介质存在跨品牌组合，支持边界不清楚。
- 端口需要特殊分拆、FEC、RoCE 或自定义拥塞参数。
- 目标性能、时延或多节点扩展效率是采购承诺的重要部分。
- 项目采用新的驱动、固件、操作系统或容器软件组合。
- 正式规模远大于现有经验，故障域和扩容路径尚未验证。
PoC 输入必须接近正式环境
测试应记录设备完整料号、拓扑、介质、软件版本、配置文件和业务数据特征。若只能使用缩小环境，应说明哪些结论可以外推，哪些必须在正式规模复验。用不同服务器或不同消息大小得到的结果，不能直接替代目标环境。
把通过条件写在测试之前
| 层面 | 建议验收内容 |
|---|---|
| 物理链路 | 目标速率、FEC、错误计数、温度与稳定性 |
| 主机路径 | PCIe、NUMA、网卡吞吐与双向流量 |
| RDMA/通信 | 时延、带宽、拥塞场景与跨节点扩展 |
| 业务 | 代表性模型、并发、持续时间和失败恢复 |
PoC 输出要能复现
交付物应包括拓扑与接线、设备清单、版本、关键配置、测试命令、原始日志、结果解释、已知限制和回退方案。只保留截图和单个峰值，无法支持后续采购争议、扩容或故障定位。
低风险标准组合可以依据厂商支持清单和既有验证基线直接实施；中高风险组合则应通过 PoC 降低不确定性。PoC 的价值在于把技术假设转成双方认可的事实和验收条件。
WeChat
Profile