conda创建虚拟环境并不会自带python
今天用conda创建虚拟环境偷懒，没有指定python版本；
原以为conda会模型安装较新的python版本，然而conda没有默认安装，导致了以下问题；
- 在vscode中配置python解释器，一直没有找到“偷懒创建的虚拟环境”；
- 后面通过路径找到了“偷懒创建的虚拟环境”；
然而这个虚拟环境没有/bin/python，我才意识到“偷懒创建的虚拟环境”并不会自动安装python，习惯性的以为安装了；
只是一个创建虚拟环境的小问题，耽误了一点点时间；
模型服务化后的路由层的设计思路；
现在有很多模型不单单只是一个模型推理，往往伴随很多附加的东西，比如：
paddle的PP-StructureV3文档解析产线，包含了表格模型推理，文本检测模型，文本识别模型等等
语音转文字funasr产线，包含vad_model对空白语音切断，减少输入语音大小，提高效率。
由此就需要切换产线的操作，通过从接口处传入query 参数，切换产线，就深入研究了一下路由的设计思路。
目前有两种路由设计方式，一种是单路由 + 传参，另一种是多路由。
| 方案 | 本质 |
|---|---|
| 单路由 + query传参 | 数据驱动（Data-driven） |
| 多路由 | 拓扑驱动（Topology-driven） |
单路由 + query传参优缺点：
- 优点：路由数量稳定、不会随着模型数爆炸、更容易自动化
- 缺点：限流 / 权限 / 超时不够细
多路由优缺点：
- 优点：独立限流、独立超时、独立权限
- 缺点：路由膨胀、文档膨胀、SDK 难维护、版本管理困难
显然目前我的项目更倾向于单路由 + query传参，目前没有复杂到需要多路由的地步，有点过度设计了。
模型服务落盘文件设计思路；
由于一个文件进入我的ai模型系统，可能需要调用许多模型服务；
以前没有区分外部上传文件和内部传path的接口区别，部分模型服务优化后，新增了内部path接口；
为了防止文件在服务器内存传来传去，浪费资源，就深入研究了一下落盘文件的设计思路。
目前的现状是：文件上传到模型调用平台的文件不用落盘，直接通过http访问本机端口的模型服务
问题在于是否跨边界
- 模型服务与平台是否在同一进程或同一服务内；
- 是不是通过 HTTP 再调一次模型服务；
都是判断的是否跨边界的关键。
根据以上条件判断，我现在在做的模型本地化已经跨了边界；
即使都在一台机器上，也会发生：
- 内存 → 序列化
- 用户态 → 内核态
- TCP / HTTP 协议栈
- 反序列化 → 内存