Marico's space
最近折腾了几轮 AI（人工智能）系统的基准测试，踩了不少坑：GPU 跑分很漂亮，端到端延迟却根本压不下来；单次实验结果很漂亮，换个数据集、换台机器就完全对不上。这篇把系统实验、基准测试、性能指标、可复现性、压力测试和系统比较放到一条线上说清楚，重点放在真正部署时能不能复现、能不能扛住、能不能算得过账。
本文对应 STATERA Library（技术架构资料库）第 38 卷第 8 章，主题是 AI 系统架构中的实验与基准测试。原始章节资料来自 GitHub 上的 STATERA Library 项目。
系统基准测试（System Benchmarking）是一个核心过程：它在受控环境和真实运营条件下，评估人工智能架构（Artificial Intelligence Architecture）的性能（Performance）、效率（Efficiency）、可扩展性（Scalability）和可靠性（Reliability）。以预测准确率（Predictive Accuracy）为主要目标的模型级评估（Model-Level Evaluation）关注的是模型本身，而系统基准测试关注的是完整计算环境，包括处理器（Processor）、加速器（Accelerator）、内存（Memory）、存储设备（Storage）、网络（Network）、软件框架（Software Framework）和数据流水线（Data Pipeline）。
综合基准测试（Comprehensive Benchmark）需要分析各个组件如何通过相互协作，决定整个系统的运行特征。即使 AI 模型（AI Model）在 GPU 上拥有很强的计算性能，也可能在数据预处理（Data Preprocessing）、内存传输（Memory Transfer）和网络通信（Network Communication）环节产生明显延迟。因此，系统基准测试不能只看硬件规格或理论算力，而要测量整个处理链路的端到端执行（End-to-End Execution）时间。
基准测试设计（Benchmark Design）的第一步，是定义目标工作负载（Workload）和运营要求（Operational Requirements）。训练系统（Training System）、推理服务器（Inference Server）、边缘设备（Edge Device）和实时机器人平台（Real-Time Robotic Platform）具有不同的性能特征。分布式训练（Distributed Training）更关注计算资源利用率（Computational Utilization）和通信效率（Communication Efficiency），推理服务（Inference Service）则更重视响应时间（Response Time）、请求吞吐量（Request Throughput），以及工作负载变化时资源消耗（Resource Consumption）是否可预测。
具有代表性的工作负载（Representative Workload）是获得有意义基准测试结果的必要条件。合成工作负载（Synthetic Workload）可以在受控条件下隔离计算瓶颈（Computational Bottleneck），方便分析；面向具体应用的工作负载（Application-Specific Workload）则能反映真实生产环境的复杂度。可信的评估策略通常会结合两种方法，同时找出理论性能边界（Performance Boundary）和真实运营环境中的约束。
硬件基准测试（Hardware Benchmarking）主要评估 CPU、GPU、专用加速器（Specialized Accelerator）和内存子系统（Memory Subsystem）的计算能力。常见指标包括处理吞吐量（Processing Throughput）、加速器利用率（Accelerator Utilization）、内存带宽（Memory Bandwidth）、缓存行为（Cache Behavior）和功耗（Power Consumption）。理论浮点性能（Floating-Point Performance）是一个有用的基准，但实际 AI 执行性能很大程度上取决于内核效率（Kernel Efficiency）、内存访问模式（Memory Access Pattern）以及支持的数值精度（Numerical Precision）。
GPU 基准测试（GPU Benchmarking）尤其需要注意计算精度（Computational Precision）和工作负载结构（Workload Structure）。FP32、FP16、BF16、INT8 以及更低精度的数据格式，可能表现出完全不同的运行特征。张量核心加速（Tensor Core Acceleration）、算子融合（Operator Fusion）、内核调度（Kernel Scheduling）和内存对齐（Memory Alignment）都会影响实际吞吐量。因此，基准测试报告中必须明确写出数值格式和优化设置，否则结果很难被正确解释。
内存系统基准测试（Memory System Benchmark）主要分析内存分配开销（Allocation Overhead）、传输延迟（Transfer Latency）、带宽利用率（Bandwidth Utilization）和容量约束（Capacity Constraint）。大规模语言模型（Large Language Model）和多模态系统（Multimodal System）经常在真正发挥全部计算能力之前，就先撞上内存上限。因此，需要把设备内存（Device Memory）、主机内存（Host Memory）、中间激活存储（Intermediate Activation Storage）以及处理设备之间的数据移动（Data Movement）分开测量，尤其是在多 GPU 配置（Multi-GPU Configuration）中。
存储基准测试（Storage Benchmarking）在数据密集型 AI 工作负载（Data-Intensive AI Workload）中更加重要。训练流水线（Training Pipeline）需要持续从本地磁盘（Local Disk）和分布式存储系统（Distributed Storage System）读取大规模图像、视频和多模态数据集（Multimodal Dataset）。只看顺序带宽（Sequential Bandwidth）无法完整描述存储性能，真实的数据加载效率往往取决于随机访问（Random Access）、元数据操作（Metadata Operation）、缓存（Caching）、解压（Decompression）和并发请求（Concurrent Request）。
网络基准测试（Network Benchmarking）用于评估分布式计算环境（Distributed Computing Environment）中的通信带宽（Communication Bandwidth）、消息延迟（Message Latency）、数据包行为（Packet Behavior）和同步开销（Synchronization Overhead）。以太网（Ethernet）、InfiniBand 和远程直接内存访问（RDMA，Remote Direct Memory Access）等技术，会影响集合通信（Collective Communication）和计算节点（Compute Node）之间的数据交换效率。有效的评估不能只看标称链路速率，还要同时考虑网络拓扑（Network Topology）、拥塞（Congestion）、消息大小（Message Size）和通信模式（Communication Pattern）。
分布式训练基准测试（Distributed Training Benchmark）用于衡量计算任务在多个加速器和节点上的扩展效果。数据并行（Data Parallelism）会引入梯度同步（Gradient Synchronization）开销，模型并行（Model Parallelism）和流水线并行（Pipeline Parallelism）则需要额外的激活数据传输（Activation Transfer）与协调工作。基准实验需要定量分析计算与通信比例（Computation-to-Communication Ratio）、同步延迟（Synchronization Delay）、空闲时间（Idle Period）以及整体训练吞吐量（Aggregate Training Throughput）。
扩展效率（Scaling Efficiency）通常通过实际性能提升与理想扩展基准（Ideal Scaling Reference）的对比来评估。强扩展（Strong Scaling）关注在固定工作负载上投入更多计算资源后，运行时间能缩短多少；弱扩展（Weak Scaling）则分析资源增加多少、工作负载按比例扩大后，性能是否还能维持。两种方法都会暴露通信开销（Communication Overhead）、资源争用（Resource Contention）和负载不均衡（Load Imbalance）等架构限制。
推理基准测试（Inference Benchmarking）评估的是从输入数据采集（Input Acquisition）到最终结果交付（Output Delivery）的完整执行路径，包括预处理（Preprocessing）、模型执行（Model Execution）、后处理（Postprocessing）、序列化（Serialization）和通信（Communication）。如果只测加速器执行时间，就会低估用户实际感受到的延迟（User-Visible Latency）。在包含远程服务（Remote Service）、多模态传感器处理（Multimodal Sensor Processing）和复杂应用编排（Application Orchestration）的系统中，这种差距会被进一步放大。
批大小（Batch Size）对推理性能影响很大。较大的批次可以提高加速器利用率（Accelerator Utilization），但也会增加单个请求的等待时间（Waiting Time）。所以基准测试需要分析批大小、吞吐量（Throughput）、内存消耗（Memory Consumption）和延迟分布（Latency Distribution）之间的关系。动态批处理（Dynamic Batching）会引入额外的调度行为（Scheduling Behavior），因此不能只用恒定请求流量（Constant Traffic）进行评估，而应该尽量还原真实的请求到达模式（Request Arrival Pattern）。
延迟（Latency）不应该只用一个平均值来衡量，而要通过统计分布（Statistical Distribution）进行观察。中位数延迟（Median Latency）通常可以代表一般运行特征，高百分位延迟（High-Percentile Latency）则能暴露那些会影响时间敏感型应用的慢请求。尤其是 P95 和 P99，非常适合用来分析由调度争用（Scheduling Contention）、内存压力（Memory Pressure）、网络波动（Network Variability）和偶发计算停顿（Computational Stall）引起的尾延迟（Tail Latency）。
实时 AI 基准测试（Real-Time AI Benchmarking）的目标不只是优化吞吐量（Throughput），还必须满足实时性要求。自动驾驶机器人（Autonomous Robot）、工业控制器（Industrial Controller）和安全关键感知系统（Safety-Critical Perception System）都必须在规定的时间约束内完成计算。因此，要评估截止时间满足率（Deadline Satisfaction）、调度抖动（Scheduling Jitter）、观测到的最坏执行时间（Worst-Case Observed Execution Time）和处理延迟影响。仅仅报告平均推理速度，无法证明系统的实时可靠性。
边缘 AI 基准测试（Edge AI Benchmark）需要考虑受限的计算资源（Computational Resource）、热环境（Thermal Condition）、电池容量（Battery Capacity）和通信可用性（Communication Availability）。嵌入式加速器（Embedded Accelerator）刚开始运行时可能有很高的处理速度，但持续工作后可能因为热降频（Thermal Throttling）或功耗限制（Power Limitation）而性能下降。因此，不能只依赖一次短时间基准测试，而要测量持续性能（Sustained Performance Measurement）。
混合边缘—云架构（Hybrid Edge-Cloud Architecture）需要在多个处理位置进行基准测试。本地推理（Local Inference）可以降低通信延迟，但云端执行（Cloud Execution）能够提供更大的计算能力。评估时要测量网络传输开销（Network Transfer Overhead）、边缘预处理成本（Edge Preprocessing Cost）、云端处理时间（Cloud Processing Time）和结果交付延迟（Result Delivery Latency）。这样才能评估连接状态和资源可用性变化时的自适应工作负载放置（Adaptive Workload Placement）。
多模态 AI 基准测试（Multimodal AI Benchmarking）用于评估图像（Image）、音频（Audio）、文本（Text）、激光雷达（LiDAR）、雷达（Radar）及其他传感器流（Sensor Stream）的并发处理。单独进行模型基准测试，未必能够准确预测集成系统的性能，因为多个流水线会共享加速器内存、CPU 调度、存储带宽和通信资源。因此，端到端测试（End-to-End Test）必须复现真实的传感器频率（Sensor Frequency）、同步要求（Synchronization Requirement）和并发计算（Computational Concurrency）。
资源利用率测量（Resource Utilization Measurement）有助于解释不同架构产生不同基准结果的原因。应该把 CPU 占用率（CPU Occupancy）、GPU 利用率（GPU Utilization）、内存带宽（Memory Bandwidth）、磁盘活动（Disk Activity）、网络流量（Network Traffic）与应用程序性能一起采集。高利用率并不一定意味着高效率：过度同步、内存停顿（Memory Stall）和重复数据传输，都可能在没有增加有效计算结果的情况下消耗资源。
能效基准测试（Energy Efficiency Benchmarking）把计算性能和功耗（Electrical Power Consumption）联系起来。常见指标包括每次推理能耗（Energy per Inference）、每个处理样本能耗（Energy per Processed Sample）和完成一次训练任务所需的总能耗（Total Training Energy）。应该区分加速器功耗（Accelerator Power）与系统总功耗（System Power），后者还包括 CPU、内存、存储设备、网络和冷却设备。基础设施开销（Infrastructure Overhead）可能对实际运营效率产生很大影响。
可靠性基准测试（Reliability Benchmarking）评估系统在长时间运行和异常运营条件下，能否维持可接受的性能。长时间工作负载（Extended Workload）可能暴露内存泄漏（Memory Leak）、资源碎片化（Resource Fragmentation）、同步失败（Synchronization Failure）、热不稳定性（Thermal Instability）和渐进式性能下降（Progressive Performance Degradation）。还可以通过故障注入实验（Fault-Injection Experiment）模拟加速器故障、网络中断、存储错误和服务异常退出，评估系统恢复行为（Recovery Behavior）。
基准测试环境（Benchmark Environment）需要严格控制，以降低测量波动（Measurement Variability）。应记录硬件配置（Hardware Configuration）、固件（Firmware）、操作系统（Operating System）、设备驱动（Device Driver）、运行时库（Runtime Library）、模型版本（Model Version）和优化参数（Optimization Parameter）。后台进程（Background Process）、电源管理策略（Power Management Policy）、热环境以及缓存状态（Cache State）也会影响结果。预热流程（Warm-Up Procedure）和重复试验（Repeated Trial）有助于区分系统的持续特性与短时性能波动。
统计分析（Statistical Analysis）可以提高基准测试结论的可信度。通过重复测量（Repeated Measurement），可以估计波动（Variability）、置信区间（Confidence Interval）和观测性能差异的稳定性（Stability）。比较结果时，不应把小数值差异直接认定为确定性改进，而要结合测量噪声（Measurement Noise）和实验条件（Experimental Condition）判断。没有充分依据时，不要随意删除异常值（Outlier），而应系统地调查其原因。
基准测试自动化（Benchmark Automation）可以在软件发布（Software Release）和不同硬件配置之间维持一致的测试执行。自动化流水线（Automated Pipeline）能够完成工作负载初始化（Workload Initialization）、远程遥测数据采集（Telemetry Collection）、重复试验执行，以及结构化性能报告（Structured Performance Report）生成。接入持续集成（Continuous Integration）系统后，还可以检测性能回归（Performance Regression），识别模型更新、运行时调整和基础设施变更带来的意外性能变化。
面向应用的基准测试（Application-Oriented Benchmark）负责把技术指标与运营目标（Operational Objective）连接起来。在自动驾驶机器人中，传感器输入到决策的延迟（Sensor-to-Decision Latency）、感知更新频率（Perception Update Frequency）和截止时间合规（Deadline Compliance）最为重要。智慧城市平台（Smart-City Platform）可能更关注并发视频流（Concurrent Video Stream）、事件处理吞吐量（Event-Processing Throughput）和通信效率（Communication Efficiency）。企业 AI 系统（Enterprise AI System）通常更重视请求承载能力（Request Capacity）、服务响应性（Service Responsiveness）以及可预测的基础设施资源消耗。
归根结底，系统基准测试（System Benchmarking）为架构设计（Architectural Design）和优化（Optimization）提供实证基础（Empirical Foundation）。把有代表性的工作负载、受控的测量、统计分析以及真实部署环境（Deployment Environment）结合起来，工程师才能找出瓶颈（Bottleneck），评估架构中的取舍关系（Architectural Tradeoff）。最终目标不是把单个基准测试分数拉到最高，而是确认集成 AI 系统（Integrated AI System）能否持续满足功能要求（Functional Requirements）、性能要求（Performance Requirements）和运营要求（Operational Requirements）。
性能指标（Performance Metrics）是定量评估 AI 系统（Artificial Intelligence System）运营效果（Operational Effectiveness）的基础。最重要的评估维度包括延迟（Latency）、吞吐量（Throughput）和成本（Cost），它们分别决定系统的响应能力（Responsiveness）、处理容量（Processing Capacity）以及经济可持续性（Economic Sustainability）。尤其是在分布式和异构计算架构（Distributed and Heterogeneous Computing Architecture）中，改善一个指标，往往会在另一个指标上产生权衡（Tradeoff），所以必须综合分析这三项指标。
延迟（Latency）是指系统完成特定任务所需的经过时间（Elapsed Time），通常从输入到达开始，到对应输出生成结束。AI 系统中的延迟可能包括数据采集（Data Acquisition）、预处理（Preprocessing）、队列处理（Queueing）、模型执行（Model Execution）、后处理（Postprocessing）和通信（Communication）。端到端延迟（End-to-End Latency）尤其重要，因为只测加速器的单独执行时间，很难准确反映用户或下游应用（Downstream Application）实际感受到的响应时间。
延迟可以拆解为计算延迟（Computational Latency）、内存延迟（Memory Latency）、通信延迟（Communication Latency）和调度延迟（Scheduling Latency）。计算延迟是数学运算（Mathematical Operation）的执行时间，内存延迟来自数据访问（Data Access）或数据传输。通信延迟包括网络传输（Network Transmission）和协议开销（Protocol Overhead），调度延迟则是资源尚未可用时产生的等待时间。进行这种拆解，有助于找到优化机会（Optimization Opportunity）。
平均延迟（Average Latency）是有用的汇总指标，但不能完整说明性能波动（Performance Variability）。通常表示为 P50 的中位数延迟（Median Latency）反映典型响应特征，P95 和 P99 则展示最慢请求区间中的延迟情况。尾延迟（Tail Latency）在分布式系统（Distributed System）中尤其重要，因为单个依赖组件（Dependent Component）的延迟可能传播到整个请求链路，显著拉长端到端响应时间（End-to-End Response Time）。
延迟测量（Latency Measurement）需要清晰的计时边界（Timing Boundary）和一致的实验条件（Experimental Condition）。如果不考虑预热执行（Warm-Up Execution）、异步加速器操作（Asynchronous Accelerator Operation）、批处理策略（Batching Policy）和网络同步（Network Synchronization），结果就可能被扭曲。GPU 计算通常以异步方式执行，因此记录完成时间之前，必须进行适当的同步（Synchronization）。重复测量（Repeated Measurement）和统计分布（Statistical Distribution）比单次测量更可靠。
实时 AI 系统（Real-Time AI System）还有额外约束：计算结果必须在运营截止时间（Operational Deadline）之前到达。自动驾驶机器人（Autonomous Robot）、工业控制器（Industrial Controller）和传感器驱动应用（Sensor-Driven Application）都可能要求确定性或受限的响应行为（Deterministic or Bounded Response Behavior）。截止时间错失（Deadline Miss）可能降低控制稳定性（Control Stability），甚至威胁运营安全（Operational Safety）。因此，最坏执行时间分析（Worst-Case Execution Analysis）、调度抖动（Scheduling Jitter）和截止时间满足率（Deadline Satisfaction），有时比平均延迟更重要。
吞吐量（Throughput）是指在定义的时间间隔（Time Interval）内完成的有效工作（Useful Work）数量。根据应用不同，可以用每秒请求数（Requests per Second）、每秒图像数（Images per Second）、每秒 token 数（Tokens per Second）、每秒训练样本数（Training Samples per Second）或每秒处理传感器帧数（Processed Sensor Frames per Second）表示。延迟描述单个任务的执行时间，吞吐量则反映系统在持续工作负载（Sustained Workload）下的整体处理能力（Aggregate Processing Capacity）。
吞吐量受计算并行性（Computational Parallelism）、批大小（Batch Size）、资源利用率（Resource Utilization）和流水线效率（Pipeline Efficiency）影响。现代加速器（Modern Accelerator）可以同时处理多个操作，从而获得高吞吐量，但前提是有足够的工作负载。过小的批次无法充分利用 GPU 资源；过大的批次又会增加内存消耗（Memory Consumption）和队列延迟（Queueing Delay），导致整体吞吐量虽然上升，响应性（Responsiveness）却下降。
延迟与吞吐量的关系受到工作负载强度（Workload Intensity）和系统容量（System Capacity）影响。随着请求到达率（Request Arrival Rate）增加，系统在接近饱和状态（Saturation）之前，资源利用率通常会上升。但一旦越过饱和点，吞吐量不再按比例增长，队列长度（Queue Length）和响应时间（Response Time）却可能迅速恶化。因此，性能评估不能只依赖最大观测吞吐量（Maximum Observed Throughput），还要找出可持续运营区间（Sustainable Operating Region）。
排队论（Queueing Theory）是理解并发工作负载（Concurrent Workload）下系统行为的数学框架（Mathematical Framework）。利特尔法则（Little's Law）描述了稳定系统（Stable System）中平均请求数（Average Number of Requests）、吞吐量和平均响应时间（Average Response Time）之间的关系。它说明，提高并发（Concurrency）虽然可以增强处理能力，却也可能增加等待时间。解释这个关系时，需要明确稳定的运营条件和一致的测量边界（Measurement Boundary）。
分布式 AI 系统（Distributed AI System）还会受到通信（Communication）、同步（Synchronization）和负载均衡（Load Balancing）相关因素影响。增加 GPU 或计算节点（Compute Node）可以提升整体处理容量，但网络争用（Network Contention）和同步开销（Synchronization Overhead）可能限制扩展效率（Scaling Efficiency）。比较数据并行（Data Parallelism）、模型并行（Model Parallelism）和流水线并行（Pipeline Parallelism）时，必须区分内部计算活动（Internal Computational Activity）与真正完成的有效工作，才能正确计算吞吐量。
训练吞吐量（Training Throughput）通常以每秒处理的样本数或 token 数衡量，推理吞吐量（Inference Throughput）则关注已完成请求或生成的输出。解读这些数据时，必须同时考虑模型准确度（Model Accuracy）、序列长度（Sequence Length）、批次配置（Batch Configuration）和数值精度（Numerical Precision）。如果工作负载特征、输出质量（Output Quality）和计算需求（Computational Requirement）差异很大，那么高吞吐量不一定代表系统更优秀。
流式 AI 应用（Streaming AI Application）需要能够反映持续数据到达（Continuous Data Arrival）的吞吐量测量。视频分析（Video Analytics）、工业监控（Industrial Monitoring）和机器人感知系统（Robotic Perception System）必须持续处理传感器流（Sensor Stream），不能让未处理数据无限堆积。帧处理率（Frame Processing Rate）需要结合帧丢失（Frame Drop）、缓冲区占用率（Buffer Occupancy）和端到端延迟（End-to-End Delay）一起评估。即便平均吞吐量很高，应用所需的时间一致性（Temporal Consistency）仍可能无法保证。
成本（Cost）是指开发（Development）、部署（Deployment）、运营（Operation）和维护（Maintenance）AI 系统所需的经济资源（Economic Resource）。性能评估应考虑资本性支出（Capital Expenditure）、运营支出（Operational Expenditure）、计算基础设施（Computational Infrastructure）、能源消耗（Energy Consumption）、网络（Networking）、存储（Storage）和维护成本。只看硬件采购成本，很难准确评估整体成本；运营要求和资源利用率，会显著影响系统生命周期（System Lifecycle）内的总支出。
资本性支出（Capital Expenditure）包括服务器（Server）、GPU、网络设备（Networking Equipment）、存储基础设施（Storage Infrastructure）和配套设施（Supporting Facility）的投入。运营支出（Operational Expenditure）则包括电力（Electricity）、冷却（Cooling）、云服务（Cloud Service）、软件许可（Software Licensing）、维护（Maintenance）和工程运营（Engineering Operations）。总拥有成本（TCO，Total Cost of Ownership）把这些项目按照确定的评估周期（Evaluation Period）合并起来，用于比较本地部署基础设施（On-Premises Infrastructure）、云计算（Cloud Computing）和混合部署架构（Hybrid Deployment Architecture）。
云计算（Cloud Computing）通常采用按资源和运行时长计费的用量计费模式（Usage-Based Pricing Model）。GPU 实例费用（GPU Instance Charge）、存储容量（Storage Capacity）、数据传输（Data Transfer）和托管服务（Managed Service）都会影响总成本。云基础设施具有灵活性和快速资源交付能力，但如果资源分配效率低，或者长期保持高使用率，就会产生可观的持续费用。因此，成本分析必须结合工作负载模式（Workload Pattern）和服务要求（Service Requirement）。
本地 AI 基础设施（On-Premises AI Infrastructure）通常前期投入较高，但能为持续工作负载提供可预测的处理容量（Predictable Capacity）。经济性评估（Economic Evaluation）必须考虑硬件折旧（Hardware Depreciation）、利用率（Utilization Rate）、电力、冷却、维护和基础设施管理（Infrastructure Administration）。与云端方案比较时，必须采用相同的工作负载、性能要求、可用性假设（Availability Assumption）和评估周期，否则很容易得出错误结论。
成本效率（Cost Efficiency）可以用每次推理成本（Cost per Inference）、每百万 token 成本（Cost per Million Tokens）、每个训练样本成本（Cost per Training Sample）和每次完整训练运行成本（Cost per Completed Training Run）等归一化指标（Normalized Indicator）表示。这些指标把财务支出（Financial Expenditure）与有效计算输出（Useful Computational Output）连接起来。但要做有意义的比较，必须保证工作负载定义（Workload Definition）、模型质量要求（Model Quality Requirement）和成本核算边界（Accounting Boundary）一致，在比较硬件性能不同的架构时尤其如此。
能源消耗（Energy Consumption）直接影响运营成本（Operational Cost）和基础设施可持续性（Infrastructure Sustainability）。高能效加速器（Power-Efficient Accelerator）可以降低用电和冷却需求，但系统整体效率还取决于工作负载利用率（Workload Utilization）和执行时间（Execution Time）。每次推理能耗（Energy per Inference）和每个处理 token 能耗（Energy per Processed Token）可以补充成本指标，在评估嵌入式设备（Embedded Device）、大规模推理集群（Large-Scale Inference Cluster）和持续运行的 AI 服务（Continuously Operating AI Service）时尤其有用。
延迟、吞吐量和成本并不是彼此独立的目标，而是相互连接形成优化空间（Optimization Space）。增大批大小，可以提高吞吐量并降低单位处理成本（Unit Processing Cost），但可能增加单次响应延迟（Individual Response Latency）。增加加速器可以减少队列延迟（Queueing Delay），却会提高基础设施支出（Infrastructure Expenditure）。因此，选择合适的系统配置（Configuration），必须根据具体应用的服务要求（Application-Specific Service Requirement），平衡这些冲突。
性能—成本优化（Performance-Cost Optimization）通常需要找出帕累托前沿（Pareto Frontier）：改善一个目标，往往要牺牲另一个目标。工程师可以依据延迟约束（Latency Constraint）、吞吐量目标（Throughput Target）和财务预算（Financial Budget），比较多个系统配置，筛选可落地的架构方案（Feasible Architectural Alternative）。这种分析通常比根据单个基准测试分数给系统排名更有用，因为实际部署决策会同时受到多个目标和运营限制（Operational Limitation）影响。
服务等级目标（SLO，Service-Level Objective）可以把性能指标转换成可测量的运营承诺（Operational Commitment）。生产推理服务（Production Inference Service）可以规定指定请求率（Request Rate）下的最大 P99 延迟；工业感知系统（Industrial Perception System）可以规定最低持续帧率（Minimum Sustained Frame Rate）。成本约束（Cost Constraint）则可以通过资源预算（Resource Budget）和允许的最大处理支出（Maximum Allowable Processing Expenditure）体现。这些目标必须在有代表性的工作负载条件（Representative Workload Condition）下进行评估。
基准实验（Benchmark Experiment）需要系统地改变工作负载强度（Workload Intensity）、并发数（Concurrency）、批大小、模型配置（Model Configuration）和分配资源（Allocated Resource）。每次实验都要记录延迟分布（Latency Distribution）、可持续吞吐量（Sustainable Throughput）、资源利用率（Resource Utilization）以及对应成本（Corresponding Cost）。重复试验（Repeated Trial）有助于区分真实的架构改进（Architectural Improvement）和测量波动（Measurement Variability），而一致的软硬件配置则能支持候选系统之间可复现的比较（Reproducible Comparison）。
最终，性能指标为设计响应性高、可扩展且经济实用的 AI 系统提供了依据。延迟表示交付结果所需的时间，吞吐量衡量可持续处理容量，成本则量化实现这些性能所消耗的资源。综合评估这三项指标，工程师才能在满足运营要求（Operational Requirement）的同时，减少不必要的计算开销（Computational Overhead）和财务负担（Financial Overhead），选出合适的架构。
可复现性（Reproducibility）是 AI 系统工程（Artificial Intelligence System Engineering）的基本要求。即使重复执行（Repeated Execution）、计算环境（Computing Environment）和开发团队（Development Team）发生变化，实验结果（Experimental Results）也应该能够被验证。可复现实验（Reproducible Experiment）应让研究者和工程师重建模型训练（Training）、评估（Evaluation）和部署（Deployment）时所处的条件，从而提升科学有效性（Scientific Validity）、运营可靠性（Operational Reliability）以及架构决策（Architectural Decision）的可信度。
可复现性不只是让重复训练得到相近的模型准确度（Model Accuracy）。它还涉及一致的数据集（Dataset）、软件依赖（Software Dependency）、硬件配置（Hardware Configuration）、数值精度（Numerical Precision）、随机初始化（Random Initialization）和执行流程（Execution Procedure）。在复杂 AI 架构（AI Architecture）中，这些因素即使只出现很小差异，也可能导致延迟（Latency）、吞吐量（Throughput）、资源利用率（Resource Utilization）和模型行为（Model Behavior）出现可测量变化，因此必须进行系统控制。
可复现实验要从明确定义的实验规范（Experimental Specification）开始。实验规范应包含研究目标（Research Objective）、工作负载特征（Workload Characteristics）、模型架构（Model Architecture）、训练参数（Training Parameters）、评估方法（Evaluation Methodology）和预期输出（Expected Outputs）。明确的文档（Explicit Documentation）可以避免不同工程师重复实验或在其他基础设施上执行时产生歧义，也能让不同架构配置之间的比较真正有意义。
数据集版本管理（Dataset Versioning）必不可少，因为训练数据（Training Data）或评估数据（Evaluation Data）的变化可能影响实验结果。每个数据集都应具备持久标识符（Persistent Identifier）、有文档记录的预处理流程（Preprocessing Procedure）和可验证的完整性信息（Integrity Information）。数据集清单（Dataset Manifest）和加密校验和（Cryptographic Checksum）可以帮助确认整个实验是否使用了相同的输入文件。为了避免评估条件出现非预期差异，还应保存数据划分策略（Data Splitting Strategy）。
要实现软件环境可复现（Software Environment Reproducibility），必须准确管理操作系统（Operating System）、编程语言（Programming Language）、框架（Framework）、库（Library）和加速器驱动（Accelerator Driver）。依赖锁文件（Dependency Lockfile）或同等机制应该记录依赖包版本（Package Version）。Docker 等容器技术（Container Technology）可以把应用依赖打包进可移植的执行环境（Portable Execution Environment），但不同内核行为（Kernel Behavior）、设备驱动和底层硬件特性（Underlying Hardware Characteristics）仍然可能带来差异。
硬件配置（Hardware Configuration）是实验波动（Experimental Variability）的另一个重要来源。GPU 架构（GPU Architecture）、内存容量（Memory Capacity）、处理器拓扑（Processor Topology）、存储性能（Storage Performance）和网络互连（Network Interconnect）都会影响计算行为（Computational Behavior）。基准测试报告（Benchmark Report）应记录加速器型号（Accelerator Model）、设备数量（Device Count）、内存配置（Memory Configuration）和相关固件版本（Firmware Version）。缺少这些信息，就很容易把基础设施变化（Infrastructure Change）造成的性能差异误判为算法改进（Algorithmic Improvement）的结果。
随机性（Randomness）可能来自神经网络初始化（Neural Network Initialization）、数据打乱（Data Shuffling）、数据增强（Data Augmentation）和随机优化（Stochastic Optimization），因此应尽可能控制。必须记录 Python、NumPy、机器学习框架（Machine Learning Framework）和数据加载进程（Data-Loading Process）使用的随机种子（Random Seed）。不过，固定随机种子（Fixed Seed）并不能保证结果完全一致，尤其是在并行执行（Parallel Execution）或包含非确定性加速器操作（Nondeterministic Accelerator Operation）时。
确定性执行（Deterministic Execution）的目标是让相同输入和配置产生相同的计算输出。PyTorch 等框架提供了请求确定性算法（Deterministic Algorithm）以及控制后端行为（Backend Behavior）的功能。但部分操作仍然可能是非确定性的，或者无法提供确定性版本。此外，强制开启确定性可能降低性能，因此必须明确记录可复现性与效率之间的权衡（Reproducibility-Efficiency Tradeoff）。
数值精度（Numerical Precision）会给现代 AI 系统带来额外的可复现性问题。浮点运算（Floating-Point Operation）对执行顺序（Execution Order）、舍入行为（Rounding Behavior）和硬件实现（Hardware Implementation）非常敏感。使用 FP16 或 BF16 的混合精度训练（Mixed-Precision Training），可能因加速器代际不同而产生不同的数值训练轨迹（Numerical Trajectory）。即使数学上等价的运算，只要并行归约顺序（Parallel Reduction Order）或优化计算内核（Optimized Computational Kernel）发生变化，结果也可能略有差异。
分布式训练（Distributed Training）会进一步增加可复现性的复杂度，因为多个进程（Process）需要协调梯度计算（Gradient Computation）、通信和参数更新（Parameter Update）。进程调度（Process Scheduling）、集合通信（Collective Communication）、梯度累积（Gradient Accumulation）和同步时机（Synchronization Timing）的差异，都可能影响执行行为。可复现的分布式实验必须记录总进程数（World Size）、并行策略（Parallelism Strategy）、通信后端（Communication Backend）、检查点配置（Checkpoint Configuration）和相关同步策略（Synchronization Policy）。
检查点管理（Checkpoint Management）让工程师不必从头开始就能恢复、检查和比较实验。完整训练检查点（Training Checkpoint）应保存模型参数（Model Parameters）、优化器状态（Optimizer State）、学习率调度器信息（Learning-Rate Scheduler Information）以及相关随机数生成器状态（Random Number Generator State）。即使模型权重（Model Weight）看起来完全相同，不完整的恢复（Incomplete Restoration）仍可能改变后续优化行为（Optimization Behavior），所以必须验证检查点的完整性（Checkpoint Integrity）和兼容性（Compatibility）。
实验跟踪系统（Experiment Tracking System）会结构化记录实验配置（Configuration）、执行历史（Execution History）、性能指标（Metrics）和生成的产物（Generated Artifact）。MLflow、Weights & Biases 等平台，可以把模型版本（Model Version）与数据集、超参数（Hyperparameter）、软件环境（Software Environment）和性能结果（Performance Result）关联起来。集中式跟踪（Centralized Tracking）能够减少对手工记录管理的依赖，并支持对训练运行（Training Run）、推理优化（Inference Optimization）和基础设施实验（Infrastructure Experiment）进行系统比较。
版本控制（Version Control）负责把实验结果与具体实现（Implementation）关联起来。Git 提交标识符（Git Commit Identifier）可以精确标识基准测试所使用的源代码修订版（Source-Code Revision），带标签的发布版本（Tagged Release）则代表一个稳定配置。条件允许时，配置文件（Configuration File）也应纳入版本管理。预处理逻辑（Preprocessing Logic）、模型定义（Model Definition）、推理运行时（Inference Runtime）和评估脚本（Evaluation Script）的改动都应可追踪，这样才能避免错误地比较实验结果。
要确保基准测试可复现（Benchmark Reproducibility），还需要一致的工作负载生成（Workload Generation）和测量流程（Measurement Procedure）。输入维度（Input Dimension）、批大小、请求到达模式（Request Arrival Pattern）、并发水平（Concurrency Level）和预热时间（Warm-Up Duration）都需要标准化。测量异步 GPU 执行（Asynchronous GPU Execution）时，实验之间的测量开始和结束边界（Timing Boundary）尤其要一致。否则，报告中的性能提升（Performance Improvement）可能只是测量方法（Measurement Methodology）不同，而不是系统优化（System Optimization）真正带来的结果。
性能测量（Performance Measurement）总会受到一些无法完全消除的环境条件（Environmental Condition）影响。后台进程、热降频、功耗限制（Power Limit）、操作系统调度（Operating System Scheduling）和共享网络拥塞（Shared Network Congestion）都可能制造波动。基准测试流程（Benchmark Procedure）应监控这些条件，并执行重复试验（Repeated Trial）。报告完整分布（Distribution）和置信区间（Confidence Interval），比只挑出一个有利的测量值更能说明真实性能特征。
边缘 AI 系统（Edge AI System）的可复现性，还要考虑部署环境特有的限制（Deployment-Specific Constraint）。嵌入式加速器（Embedded Accelerator）可能在不同功耗模式（Power Mode）、热环境（Thermal Condition）和内存限制（Memory Limitation）下运行。应记录固件版本（Firmware Version）、推理引擎（Inference Engine）、量化设置（Quantization Setting）和传感器配置（Sensor Configuration）。在机器人应用（Robotic Application）中，还要记录传感器校准（Sensor Calibration）、时间戳同步（Timestamp Synchronization）和运营条件（Operating Condition），否则很难进行有意义的重复评估。
云端实验（Cloud-Based Experiment）会引入虚拟化基础设施（Virtualized Infrastructure）、共享资源（Shared Resource）、实例放置（Instance Placement）和托管服务更新（Managed Service Update）带来的波动。即使选择了相同的实例类型（Instance Type），底层硬件修订版（Hardware Revision）或网络条件（Network Condition）也可能不同。因此，为保证可复现性，必须把实例规格（Instance Specification）、部署区域（Deployment Region）、容器镜像（Container Image）、存储配置（Storage Configuration）和相关服务版本（Service Version）与实验结果一起保存。
自动化实验流水线（Automated Experiment Pipeline）通过减少人工介入（Manual Intervention）和流程不一致（Procedural Inconsistency），可以提高可复现性