| 部分 | 评分标准 | 评语 | 得分 |
|---|
| Section 1：Web Service API Engineering（20 分） | HD： 实现非常出色，体现了对 Python 并发机制的深入理解。学生使用了高级 FastAPI 特性，确保 CPU 密集型的 YOLO 推理不会阻塞异步事件循环，从而实现更好的并发能力，并尽量减少延迟排队。 | 在 lifespan 中将 YOLO 模型加载到内存；为模型加载设置了合适的健康检查；通过 loop.run_in_executor 调用 await service.predict_from_b64；可以进一步改进：对 UUID 格式进行正确检查，而不只是使用 str 类型。 | 19 |
| Section 2：Containerization and Optimisation（10 分） | P： 提供了基础 Dockerfile，可以成功构建并运行应用程序。但是，由于安装了不必要的库，镜像大小过大。 | 使用了多阶段构建；将 YOLO 模型直接复制到了 Docker 镜像中。 | 5 |
| Section 3：Infrastructure as Code / IaC（10 分） | HD： 专业级自动化。配置变量被抽象到专门的变量文件中。配置依赖高级模块化结构，并通过数据源动态获取所需的 OCIDs，体现了对云自动化原则的深入理解。 | 使用了 Terraform 和 Ansible 脚本，并且变量设置得当。 | 10 |
| Section 4：Kubernetes Deployment（15 分） | HD： 除了满足所有 Distinction 标准之外，学生还主动在部署清单中实现了 readiness probe 和 liveness probe。这确保 Kubernetes 调度器只会将负载均衡流量路由到已经完全初始化、并且已将 YOLO 模型权重加载到内存中的 Pod，从而避免扩缩容过程中出现请求丢失。 | 使用了合适的 namespace；实现了 readiness 检查；使用了私有 Docker 镜像；可以进一步改进：加入 Kubernetes HPA。 | 12 |
| Section 5：Load Generation and Performance Baseline（20 分） | HD： 系统大幅超过性能基线，即每个 Pod 可持续达到超过 10 QPS，并且平均延迟低于 500ms。学生对 FastAPI 服务进行了工程化优化，使其能够在高并发负载下高效利用 CPU，并有效缓解 Python 在推理操作中的限制。 | 可以在 8 个 Pod、24 个用户的情况下运行且没有失败；benchmarking 可以进一步改进：使用多个图片或图片文件夹进行测试。 | 19 |
| Section 6：Empirical Benchmark Report（10 分） | HD： 一份非常出色、接近发表质量的基准测试报告。分析使用理论框架解释了系统达到饱和的精确位置，以及指数级延迟恶化发生的原因。讨论批判性地强调了在受限边缘/云环境中部署复杂机器学习模型时的内在取舍。 | 可以进一步改进：更合理、更全面地分析性能瓶颈和问题，例如讨论 GIL 竞争、线程过度订阅、上下文切换、OpenCV/PyTorch 内部线程膨胀、阻塞 FastAPI 事件循环、负载下队列积压等，并配合合适的引用/参考文献，例如 Little’s Law。 | 8 |
| Section 7：Interview Performance（15 分） | HD： 学生展现出对该主题的绝对掌握。他们能够轻松阐述复杂概念，例如详细说明服务器在同步模型推理过程中如何与 Python 后端交互，或者解释其状态管理的底层机制和依赖映射。 | 演示流畅，理解良好。 | 12 |
| 小计 | | | 85 |