很显然，作为一群对yolov8尚不了解的大学生。。能够直接使用python进行detect任务对调用是一个极为便利的途径。
或者说我们其实并不清楚怎样用其他的方式使用yolo，从官方的文档中看，我们或许可以将模型转译为tensorflow.js所需的格式，从而更加从容的使用nodejs作为后端？？也许之后会尝试
至于说为什么用fastapi而不是flask，我问了chatgpt，他这么说：
基于 YOLO 模型设计出供 Web 程序调用的 API，你可能会面临处理图像数据、模型推理、API 构建等多个方面的任务。根据这些需求，我会推荐使用 FastAPI。以下是一些原因：
- 异步支持： YOLO 模型的推理通常是相对耗时的任务，而 FastAPI 的异步能力可以在处理多个请求时提供更好的性能和响应时间。
- 类型提示和数据验证： YOLO 模型的输入和输出数据通常有特定的格式，使用 FastAPI 的类型提示和数据验证功能可以确保请求和响应的数据格式正确，并在开发过程中就能发现问题。
- 自动文档生成： 你可以使用 FastAPI 自动生成交互式的 API 文档，其中包括请求和响应的数据模型、参数以及示例请求和响应。这对于与其他开发者合作或测试 API 非常有用。
- 依赖注入和模块化： FastAPI 的依赖注入系统可以帮助你将不同的功能模块化，比如图像处理、模型推理等，使代码更易于管理和测试。
- 活跃的社区和发展： FastAPI 的社区不断壮大，你可以获得来自其他开发者的支持和贡献，以及许多现成的库和工具，以满足你的需求。
总之，基于 YOLO 模型构建 Web API 需要考虑多个方面，FastAPI 是一个强大且适合现代异步 Web 开发的框架，可以帮助你满足这些需求。
说到底，fastapi的fast真的很吸引我。（起个好名字的重要性）
首先来看看我希望这个api去做些什么
在上个期末完成了对模型的训练后，已经通过Gradio完成了一个简单的ui实现
那么这个方案有什么问题吗？
有，太慢了！
这种慢并不是模型运行的耗时而是在一个垃圾云服务器上因为带宽限制导致的。没错，gradio给我们的输入和输出方式定义为了图片，也就是我们要把这张图来回上传下载两次，这无疑使愚蠢的。
一种我理解中（我以为）的工作方式
众所周知 webui可是跑在浏览器上的，如果我们把绘制边框的操作交给浏览器（本地）进行，服务器只是回传一段表示位置的数据，那是不是我们就节省了回传一张图片的时间~~（获得50%的性能提升）~~
另一种我理解中（我以为）的工作方式