不能因为程序在 GPU 上跑了，就写“性能大幅提升”。我要知道用户到底少等了多久，以及 VPS 是否真的轻松了。
要解决什么
比较部署方式带来的收益，并把代价一起记录。所有数字都从实验来，这篇不预填提升比例。
有哪些测法
只看模型推理时间容易忽略下载和排队；只看一条任务总耗时又看不出瓶颈。我选同时记录阶段耗时、用户等待和服务资源三组数据。
实验怎样安排
准备短、中、长三组固定音频，保留摘要、语言、长度和人工校对文本。单机速度比较固定模型文件、量化方式、解码参数与软件版本；换模型的质量实验另列，不混在同一张加速比表里。
先做单任务，再做一批任务：
| 场景 | 要回答的问题 |
|---|---|
| VPS 本地 CPU 执行 | 基线成本和在线请求是否受影响 |
| VPS 接请求，一台边缘节点执行 | 网络开销是否值得 |
| 同一批任务交给两台边缘节点 | 总批次完成时间有没有缩短 |
| 快节点正在忙，慢节点空闲 | 分配策略是否减少等待 |
VPS 基线限制并发，在测试环境运行。若硬件根本装不下所选模型，记录“不满足条件”，不要改小模型以后直接宣称同条件加速。
每组记录排队、传输、准备、推理、上传和总耗时，分别做冷启动与模型常驻测试。单任务至少重复几次并保留原始值；比较 P95 时另收集足够多的样本，注明数量和统计方式。
用 RTF = 推理秒数 / 音频秒数 描述推理速度。RTF 小于 1 表示这一段推理快于音频时长，不代表整个任务实时完成。批量测试另外记录每小时处理多少音频分钟、最后一个任务何时完成。
同时测 VPS API 延迟、错误率、内存，以及节点内存和可取得的 GPU 指标。变模型或精度时补准确率评估：英文可用词错误率，中文可用字错误率，但必须公开文本正规化规则和参考答案。
怎样收尾
结果表至少保留：实验编号、硬件、模型摘要、配置、输入、各阶段耗时、资源峰值和失败情况。解释最慢的那一段，再选一项优化重跑对照。
KEDA 配置存在不代表会自动增加物理 GPU。扩 Pod 前先核对设备余量和实际可调度位置；一台机器没空闲资源时，更多副本只可能继续等待。KEDA RabbitMQ scaler
最后写三句事实：哪里改善了，付出了多少传输或资源代价，哪些情况下没有收益。这样的结果才经得起追问。