尧图网站建设 
Immich Machine Learning 模块解析uv 环境配置、ONNX Runtime 硬件加速与 Locust 推理压测实践【免费下载链接】immichHigh performance self-hosted photo and video management solution.项目地址: https://gitcode.com/GitHub_Trending/im/immichImmich 的机器学习模块machine-learning/目录是整个自托管照片/视频管理系统背后的推理引擎它提供 CLIP 视觉与文本向量编码、人脸检测/识别等能力供服务端任务队列消费。本篇以 machine-learning/README.md 为主体完整覆盖其 uv 环境搭建、依赖管理、Locust 压测方法与 InsightFace 模型许可边界并结合 pyproject.toml、immich_ml/main.py、immich_ml/sessions/ort.py 等源码把 README 中的每一步操作落到可验证的实现细节上帮助读者独立完成本地开发环境搭建、推理端点压测与硬件加速选型。模块职责与技术栈概览README 开篇即声明了该模块的两大核心能力CLIP embeddings将图像与文本编码到同一向量空间支撑 Immich 的语义搜索Facial recognition人脸检测与特征向量提取支撑人脸聚类功能。从源码结构看这是一套以FastAPI Gunicorn/Uvicorn为服务框架、以ONNX Runtime为推理运行时、以aiocache 内存缓存管理模型生命周期的独立 HTTP 服务入口为 immich_ml/main.py它通过subprocess拉起gunicorn immich_ml.main:app工作进程类为自定义的CustomUvicornWorker并读取gunicorn_conf.py日志配置应用主体 immich_ml/main.py 暴露GET /、GET /ping与核心的POST /predict端点核心依赖在 pyproject.toml 中声明fastapi、onnx、onnxruntime-*按设备条件引入、opencv-python-headless、huggingface-hub、tokenizers、rapidocr等要求 Python3.11,4.0。服务默认监听地址为[::]:3003见 config.py 中NonPrefixedSettings的immich_host/immich_port默认值这与部署时 docker/docker-compose.yml 中immich-machine-learning服务的定位一致。环境搭建基于 uv 的隔离虚拟环境README 的 Setup 一节指明项目使用 uv 管理依赖需先安装 uv再执行uv sync --extra cpu这会在隔离的虚拟环境中安装 CPU 推理所需的全部依赖。若要使用硬件加速 API将--extra cpu替换为对应设备 extrasuv sync --extra cuda # NVIDIA GPU uv sync --extra rocm # AMD GPUMIGraphX uv sync --extra openvino # Intel 设备README 特别提醒CUDA 路径要求 GPU 的 compute capability ≥ 5.2。对照 pyproject.toml 中[project.optional-dependencies]的定义每个 extra 实际拉入的 onnxruntime 发行版如下这是一套代码、多后端运行时的实现基础extra引入的包说明cpuonnxruntime1.23.2,2纯 CPU 推理cudaonnxruntime-gpu1.23.2,2NVIDIA GPUrocmonnxruntime-migraphx1.23.2,2AMD GPUMIGraphX EPopenvinoonnxruntime-openvino1.24.1,2Intel 设备armnnonnxruntimeARM Mali配合仓库内置的 ann/ C 扩展rknnonnxruntimerknn-toolkit-lite22.3.0,3Rockchip NPU依赖的日常维护命令 README 也给出了uv add $PACKAGE_NAME # 添加依赖 uv remove $PACKAGE_NAME # 移除依赖 uv lock # 重新生成锁定文件并要求将uv.lock与pyproject.toml一并提交——仓库根目录下确实存在 uv.lock说明该约定在项目中是强制执行的以保证 CI 与 Docker 构建Dockerfile 中以uv sync --frozen --extra ${DEVICE}消费锁文件获得可复现的环境。服务启动与关键运行参数python -m immich_ml启动后即 Dockerfile 的CMDGunicorn 按main.py 传参运行-w对应settings.workers-t对应settings.worker_timeout--keep-alive对应http_keepalive_timeout_s--graceful-timeout 10。所有这些参数均可通过环境变量覆盖。config.py 中的Settings使用pydantic-settingsenv_prefixMACHINE_LEARNING_、嵌套分隔符__常用项与默认值如下均可作为部署调优的入口环境变量默认值作用MACHINE_LEARNING_WORKERS1Gunicorn worker 数MACHINE_LEARNING_WORKER_TIMEOUT300ROCm 设备下900见default_worker_timeoutworker 超时秒MACHINE_LEARNING_MODEL_TTL300模型空闲卸载时间秒0表示禁用卸载MACHINE_LEARNING_MODEL_TTL_POLL_S10空闲检测轮询间隔MACHINE_LEARNING_REQUEST_THREADSCPU 核数推理线程池大小绕过 asyncio 阻塞瓶颈MACHINE_LEARNING_MODEL_INTRA_OP_THREADS/INTER_OP0自动ONNX Runtime 线程数覆盖MACHINE_LEARNING_MODEL_ARENAtrue是否启用 CPU 内存 arenaCPU 镜像在 Dockerfile 中显式关闭MACHINE_LEARNING_DEVICE_ID0GPU/设备编号MACHINE_LEARNING_CACHE_FOLDER~/.cache/immich_ml模型下载缓存目录容器内设为/cacheMACHINE_LEARNING_PRELOAD__*未设置启动时预热模型如MACHINE_LEARNING_PRELOAD__CLIP__VISUAL等MACHINE_LEARNING_MAX_BATCH_SIZE__*未设置限制人脸/OCR 批量推理的 batch 上限两个值得注意的源码级机制请求线程池main.py 在 lifespan 中创建ThreadPoolExecutor(settings.request_threads)所有阻塞推理通过run_in_executor调度注释明确指出 asyncio is a huge bottleneck for performance空闲自杀idle_shutdown_task 轮询检查——当无活跃请求、无模型加载锁、且距上次请求超过model_ttl时进程向自己发送SIGINT优雅退出。这对按需拉起的部署形态例如无定时任务时 ML 容器可以自行释放内存非常关键。preload配置则可以在启动时提前加载指定模型避免首次请求的冷启动延迟加载逻辑见 preload_models。推理接口POST /predict 的请求模型压测文件与实现共同揭示了统一推理端点的协议形态。/predict接受multipart/form-dataentries一段 JSON描述任务 → 类型 → 模型与选项的推理计划image待推理图片视觉任务必需text待编码文本CLIP 文本任务使用。run_inference 将 entries 拆为without_deps与with_deps两组并行执行依赖项例如人脸识别依赖人脸检测的输出排在依赖组之后通过模型输出字典串联——这解释了人脸请求为何必须同时下发 detection 与 recognition 两个条目。模型实例由 ModelCache 以乐观锁方式从内存缓存获取/创建缓存键为model_name type task并按model_ttl过期与上文空闲自杀共同构成模型的完整生命周期管理。人脸识别的实现类 FaceRecognizer 声明了depends [(ModelType.DETECTION, ModelTask.FACIAL_RECOGNITION)]并对超过batch_size的人脸裁剪自动分批推理当模型输入不含动态 batch 维时它会用onnx.tools.update_model_dims就地改写 ONNX 模型添加 batch 轴。压测Locust 推理吞吐与延迟测量README 的 Load Testing 一节完整给出了方法使用 Locust因为 Locust 直接查询模型端点并聚合统计被测服务必须先部署好。启动命令locust --web-host 127.0.0.1然后浏览器打开localhost:8089访问控制台 UI可在界面上调整并发用户数、启动速率等。locustfile.py 通过命令行参数暴露了可调的实验变量默认值如下参数默认值含义--clip-modelViT-B-32::openai用于编码的 CLIP 模型名--face-modelbuffalo_l人脸检测/识别模型名--face-min-score0.034人脸检测最低置信度README 注释指出该默认值大约每请求返回 1 张人脸设为0会把返回的人脸数放大到成千上万--image-size1000测试图片边长像素测试图是程序生成的纯色 JPEG压测流量模型由三个用户类构成全部 POST 到http://127.0.0.1:3003/predicthost 定义CLIPTextFormDataLoadTest发送clip.textual条目 text表单字段模拟语义搜索的文本编码CLIPVisionFormDataLoadTest发送clip.visual条目 image文件模拟图片向量编码RecognitionFormDataLoadTest一次请求同时携带facial-recognition.detection与facial-recognition.recognition两个条目且 detection 带上minScore选项完整模拟生产环境的人脸推理管线。README 特别解释了 Locust 的并发术语换算这也是实际压测中最容易搞错的一点Locust 的users是全局并发用户数每个用户一次只执行一个任务。要得到每个端点固定 N 个并发请求应令users N × 端点数。按 locustfile 中的三个用户类计算若希望每个端点同时有 8 个请求在途用户数应设为8 × 3 24。硬件加速执行提供商与镜像形态README 声明支持 CUDA、ROCm 与 OpenVINO 三类加速 API。在源码中提供商优先级集中定义在 constants.py 的SUPPORTED_PROVIDERSSUPPORTED_PROVIDERS [ CUDAExecutionProvider, MIGraphXExecutionProvider, OpenVINOExecutionProvider, CoreMLExecutionProvider, CPUExecutionProvider, ]OrtSession 构造时按该顺序过滤当前 onnxruntime 中实际可用的提供商因此同一份模型代码在 CPU/CUDA/ROCm/OpenVINO 环境下无差别运行。各提供商的会话选项由 provider_options 分支生成几个关键细节CUDA透传device_id来自MACHINE_LEARNING_DEVICE_ID内存 arena 策略设为kSameAsRequestedMIGraphXROCm自动创建模型目录下的migraphx缓存目录否则运行时会崩溃并按MACHINE_LEARNING_ROCM_PRECISION决定 FP16 开关ROCm 场景下OrtSession.run还会用模型级锁串行化首次推理MIGraphX 首次运行需在线编译见 run 方法OpenVINO优先选择GPU.{device_id}无 GPU 时回退CPU精度由MACHINE_LEARNING_OPENVINO_PRECISION控制缓存目录为模型旁的openvino目录CPU 线程策略_sess_options_default 仅在纯 CPU 提供商下默认inter_op1、intra_op2注释说明 ORT 默认线程数在 GPU 场景会造成瓶颈显式配置 0 表示不干预。部署侧的对应关系见 docker/docker-compose.yml镜像基础标签ghcr.io/immich-app/immich-machine-learning:${IMMICH_VERSION:-release}需要加速时向 image tag 追加-cuda/-rocm/-openvino/-armnn/-rknn之一并可通过hwaccel.ml.yml扩展服务定义compose 注释中给出的做法更完整的硬件加速配置说明可参阅仓库内文档 ml-hardware-acceleration。Dockerfile 以构建参数ARG DEVICEcpu驱动整套多阶段构建builder 阶段用对应 extra 执行uv sync --frozenprod-${DEVICE}阶段分别安装 CUDA 12.2 runtime cuDNN 9.10注释注明 9.11 起弃用 Pascal 支持、ROCm 的 migraphx/MIOpen、Intel OpenCL/IGC 组件等所有 prod 镜像统一将模型与 Hugging Face 缓存指向/cacheMACHINE_LEARNING_CACHE_FOLDER/cache、HF_HOME/cache/hf-cache与 compose 中的model-cache卷一一对应并以内置healthcheck.py做健康检查。人脸识别模型与许可边界README 的 Facial Recognition 一节说明模型来自 InsightFace 项目的 model zoo明确列出了四个可用模型组antelopev2、buffalo_l、buffalo_m、buffalo_s。这与源码 constants.py 中白名单_INSIGHTFACE_MODELS完全一致——服务端只接受这四个名字经clean_name归一化后作为 InsightFace 来源的模型再由 get_model_source 分派到对应下载源locustfile 中压测使用的默认buffalo_l也在该集合内。许可条款方面README 给出了明确的法律事实项目方于2023 年 3 月 18 日通过邮件获得 Jia Guoguojiainsightface.ai对 InsightFace 人脸模型在本项目内使用的授权但该授权不延伸至第三方对这些模型的分发或商业使用使用者应自行遵守 InsightFace 仓库给出的许可条款。任何将 Immich ML 集成到商业产品、或自行二次分发这些模型文件的场景都应以该条款为约束边界。从能力链路看detection 输出框、关键点、置信度会被 recognition 阶段消费FaceRecognizer._predict 对每张检测到的人脸执行对齐裁剪align_face、归一化后批量提取 embedding最终postprocess输出boundingBoxembeddingscore结构供上层数据库存储与聚类。小结与关键路径本篇围绕 machine-learning/README.md 的三个核心章节展开并落到仓库内的可验证实现环境uv sync --extra {cpu|cuda|rocm|openvino}extras 与 onnxruntime 发行版的映射定义在 pyproject.toml锁文件提交是硬约定服务与调优MACHINE_LEARNING_*环境变量族覆盖 worker、TTL、线程池、预加载与批大小实现在 config.py空闲自杀与线程池调度在 main.py压测locust --web-host 127.0.0.1 locustfile.py记住users 每端点并发 × 端点数的换算加速执行提供商优先级在 constants.py会话选项与线程策略在 ort.py容器形态由 Dockerfile 的DEVICE构建参数与 docker-compose.yml 的镜像 tag 后缀共同决定合规InsightFace 四个模型组的授权范围仅限本项目内部使用禁止第三方分发与商用。【免费下载链接】immichHigh performance self-hosted photo and video management solution.项目地址: https://gitcode.com/GitHub_Trending/im/immich创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 Immich Machine Learning 模块解析：uv 环境配置、ONNX Runtime 硬件加速与 Locust 推理压测实践
Immich Machine Learning 模块解析uv 环境配置、ONNX Runtime 硬件加速与 Locust 推理压测实践【免费下载链接】immichHigh performance self-hosted photo and video management solution.项目地址: https://gitcode.com/GitHub_Trending/im/immichImmich 的机器学习模块machine-learning/目录是整个自托管照片/视频管理系统背后的推理引擎它提供 CLIP 视觉与文本向量编码、人脸检测/识别等能力供服务端任务队列消费。本篇以 machine-learning/README.md 为主体完整覆盖其 uv 环境搭建、依赖管理、Locust 压测方法与 InsightFace 模型许可边界并结合 pyproject.toml、immich_ml/main.py、immich_ml/sessions/ort.py 等源码把 README 中的每一步操作落到可验证的实现细节上帮助读者独立完成本地开发环境搭建、推理端点压测与硬件加速选型。模块职责与技术栈概览README 开篇即声明了该模块的两大核心能力CLIP embeddings将图像与文本编码到同一向量空间支撑 Immich 的语义搜索Facial recognition人脸检测与特征向量提取支撑人脸聚类功能。从源码结构看这是一套以FastAPI Gunicorn/Uvicorn为服务框架、以ONNX Runtime为推理运行时、以aiocache 内存缓存管理模型生命周期的独立 HTTP 服务入口为 immich_ml/main.py它通过subprocess拉起gunicorn immich_ml.main:app工作进程类为自定义的CustomUvicornWorker并读取gunicorn_conf.py日志配置应用主体 immich_ml/main.py 暴露GET /、GET /ping与核心的POST /predict端点核心依赖在 pyproject.toml 中声明fastapi、onnx、onnxruntime-*按设备条件引入、opencv-python-headless、huggingface-hub、tokenizers、rapidocr等要求 Python3.11,4.0。服务默认监听地址为[::]:3003见 config.py 中NonPrefixedSettings的immich_host/immich_port默认值这与部署时 docker/docker-compose.yml 中immich-machine-learning服务的定位一致。环境搭建基于 uv 的隔离虚拟环境README 的 Setup 一节指明项目使用 uv 管理依赖需先安装 uv再执行uv sync --extra cpu这会在隔离的虚拟环境中安装 CPU 推理所需的全部依赖。若要使用硬件加速 API将--extra cpu替换为对应设备 extrasuv sync --extra cuda # NVIDIA GPU uv sync --extra rocm # AMD GPUMIGraphX uv sync --extra openvino # Intel 设备README 特别提醒CUDA 路径要求 GPU 的 compute capability ≥ 5.2。对照 pyproject.toml 中[project.optional-dependencies]的定义每个 extra 实际拉入的 onnxruntime 发行版如下这是一套代码、多后端运行时的实现基础extra引入的包说明cpuonnxruntime1.23.2,2纯 CPU 推理cudaonnxruntime-gpu1.23.2,2NVIDIA GPUrocmonnxruntime-migraphx1.23.2,2AMD GPUMIGraphX EPopenvinoonnxruntime-openvino1.24.1,2Intel 设备armnnonnxruntimeARM Mali配合仓库内置的 ann/ C 扩展rknnonnxruntimerknn-toolkit-lite22.3.0,3Rockchip NPU依赖的日常维护命令 README 也给出了uv add $PACKAGE_NAME # 添加依赖 uv remove $PACKAGE_NAME # 移除依赖 uv lock # 重新生成锁定文件并要求将uv.lock与pyproject.toml一并提交——仓库根目录下确实存在 uv.lock说明该约定在项目中是强制执行的以保证 CI 与 Docker 构建Dockerfile 中以uv sync --frozen --extra ${DEVICE}消费锁文件获得可复现的环境。服务启动与关键运行参数python -m immich_ml启动后即 Dockerfile 的CMDGunicorn 按main.py 传参运行-w对应settings.workers-t对应settings.worker_timeout--keep-alive对应http_keepalive_timeout_s--graceful-timeout 10。所有这些参数均可通过环境变量覆盖。config.py 中的Settings使用pydantic-settingsenv_prefixMACHINE_LEARNING_、嵌套分隔符__常用项与默认值如下均可作为部署调优的入口环境变量默认值作用MACHINE_LEARNING_WORKERS1Gunicorn worker 数MACHINE_LEARNING_WORKER_TIMEOUT300ROCm 设备下900见default_worker_timeoutworker 超时秒MACHINE_LEARNING_MODEL_TTL300模型空闲卸载时间秒0表示禁用卸载MACHINE_LEARNING_MODEL_TTL_POLL_S10空闲检测轮询间隔MACHINE_LEARNING_REQUEST_THREADSCPU 核数推理线程池大小绕过 asyncio 阻塞瓶颈MACHINE_LEARNING_MODEL_INTRA_OP_THREADS/INTER_OP0自动ONNX Runtime 线程数覆盖MACHINE_LEARNING_MODEL_ARENAtrue是否启用 CPU 内存 arenaCPU 镜像在 Dockerfile 中显式关闭MACHINE_LEARNING_DEVICE_ID0GPU/设备编号MACHINE_LEARNING_CACHE_FOLDER~/.cache/immich_ml模型下载缓存目录容器内设为/cacheMACHINE_LEARNING_PRELOAD__*未设置启动时预热模型如MACHINE_LEARNING_PRELOAD__CLIP__VISUAL等MACHINE_LEARNING_MAX_BATCH_SIZE__*未设置限制人脸/OCR 批量推理的 batch 上限两个值得注意的源码级机制请求线程池main.py 在 lifespan 中创建ThreadPoolExecutor(settings.request_threads)所有阻塞推理通过run_in_executor调度注释明确指出 asyncio is a huge bottleneck for performance空闲自杀idle_shutdown_task 轮询检查——当无活跃请求、无模型加载锁、且距上次请求超过model_ttl时进程向自己发送SIGINT优雅退出。这对按需拉起的部署形态例如无定时任务时 ML 容器可以自行释放内存非常关键。preload配置则可以在启动时提前加载指定模型避免首次请求的冷启动延迟加载逻辑见 preload_models。推理接口POST /predict 的请求模型压测文件与实现共同揭示了统一推理端点的协议形态。/predict接受multipart/form-dataentries一段 JSON描述任务 → 类型 → 模型与选项的推理计划image待推理图片视觉任务必需text待编码文本CLIP 文本任务使用。run_inference 将 entries 拆为without_deps与with_deps两组并行执行依赖项例如人脸识别依赖人脸检测的输出排在依赖组之后通过模型输出字典串联——这解释了人脸请求为何必须同时下发 detection 与 recognition 两个条目。模型实例由 ModelCache 以乐观锁方式从内存缓存获取/创建缓存键为model_name type task并按model_ttl过期与上文空闲自杀共同构成模型的完整生命周期管理。人脸识别的实现类 FaceRecognizer 声明了depends [(ModelType.DETECTION, ModelTask.FACIAL_RECOGNITION)]并对超过batch_size的人脸裁剪自动分批推理当模型输入不含动态 batch 维时它会用onnx.tools.update_model_dims就地改写 ONNX 模型添加 batch 轴。压测Locust 推理吞吐与延迟测量README 的 Load Testing 一节完整给出了方法使用 Locust因为 Locust 直接查询模型端点并聚合统计被测服务必须先部署好。启动命令locust --web-host 127.0.0.1然后浏览器打开localhost:8089访问控制台 UI可在界面上调整并发用户数、启动速率等。locustfile.py 通过命令行参数暴露了可调的实验变量默认值如下参数默认值含义--clip-modelViT-B-32::openai用于编码的 CLIP 模型名--face-modelbuffalo_l人脸检测/识别模型名--face-min-score0.034人脸检测最低置信度README 注释指出该默认值大约每请求返回 1 张人脸设为0会把返回的人脸数放大到成千上万--image-size1000测试图片边长像素测试图是程序生成的纯色 JPEG压测流量模型由三个用户类构成全部 POST 到http://127.0.0.1:3003/predicthost 定义CLIPTextFormDataLoadTest发送clip.textual条目 text表单字段模拟语义搜索的文本编码CLIPVisionFormDataLoadTest发送clip.visual条目 image文件模拟图片向量编码RecognitionFormDataLoadTest一次请求同时携带facial-recognition.detection与facial-recognition.recognition两个条目且 detection 带上minScore选项完整模拟生产环境的人脸推理管线。README 特别解释了 Locust 的并发术语换算这也是实际压测中最容易搞错的一点Locust 的users是全局并发用户数每个用户一次只执行一个任务。要得到每个端点固定 N 个并发请求应令users N × 端点数。按 locustfile 中的三个用户类计算若希望每个端点同时有 8 个请求在途用户数应设为8 × 3 24。硬件加速执行提供商与镜像形态README 声明支持 CUDA、ROCm 与 OpenVINO 三类加速 API。在源码中提供商优先级集中定义在 constants.py 的SUPPORTED_PROVIDERSSUPPORTED_PROVIDERS [ CUDAExecutionProvider, MIGraphXExecutionProvider, OpenVINOExecutionProvider, CoreMLExecutionProvider, CPUExecutionProvider, ]OrtSession 构造时按该顺序过滤当前 onnxruntime 中实际可用的提供商因此同一份模型代码在 CPU/CUDA/ROCm/OpenVINO 环境下无差别运行。各提供商的会话选项由 provider_options 分支生成几个关键细节CUDA透传device_id来自MACHINE_LEARNING_DEVICE_ID内存 arena 策略设为kSameAsRequestedMIGraphXROCm自动创建模型目录下的migraphx缓存目录否则运行时会崩溃并按MACHINE_LEARNING_ROCM_PRECISION决定 FP16 开关ROCm 场景下OrtSession.run还会用模型级锁串行化首次推理MIGraphX 首次运行需在线编译见 run 方法OpenVINO优先选择GPU.{device_id}无 GPU 时回退CPU精度由MACHINE_LEARNING_OPENVINO_PRECISION控制缓存目录为模型旁的openvino目录CPU 线程策略_sess_options_default 仅在纯 CPU 提供商下默认inter_op1、intra_op2注释说明 ORT 默认线程数在 GPU 场景会造成瓶颈显式配置 0 表示不干预。部署侧的对应关系见 docker/docker-compose.yml镜像基础标签ghcr.io/immich-app/immich-machine-learning:${IMMICH_VERSION:-release}需要加速时向 image tag 追加-cuda/-rocm/-openvino/-armnn/-rknn之一并可通过hwaccel.ml.yml扩展服务定义compose 注释中给出的做法更完整的硬件加速配置说明可参阅仓库内文档 ml-hardware-acceleration。Dockerfile 以构建参数ARG DEVICEcpu驱动整套多阶段构建builder 阶段用对应 extra 执行uv sync --frozenprod-${DEVICE}阶段分别安装 CUDA 12.2 runtime cuDNN 9.10注释注明 9.11 起弃用 Pascal 支持、ROCm 的 migraphx/MIOpen、Intel OpenCL/IGC 组件等所有 prod 镜像统一将模型与 Hugging Face 缓存指向/cacheMACHINE_LEARNING_CACHE_FOLDER/cache、HF_HOME/cache/hf-cache与 compose 中的model-cache卷一一对应并以内置healthcheck.py做健康检查。人脸识别模型与许可边界README 的 Facial Recognition 一节说明模型来自 InsightFace 项目的 model zoo明确列出了四个可用模型组antelopev2、buffalo_l、buffalo_m、buffalo_s。这与源码 constants.py 中白名单_INSIGHTFACE_MODELS完全一致——服务端只接受这四个名字经clean_name归一化后作为 InsightFace 来源的模型再由 get_model_source 分派到对应下载源locustfile 中压测使用的默认buffalo_l也在该集合内。许可条款方面README 给出了明确的法律事实项目方于2023 年 3 月 18 日通过邮件获得 Jia Guoguojiainsightface.ai对 InsightFace 人脸模型在本项目内使用的授权但该授权不延伸至第三方对这些模型的分发或商业使用使用者应自行遵守 InsightFace 仓库给出的许可条款。任何将 Immich ML 集成到商业产品、或自行二次分发这些模型文件的场景都应以该条款为约束边界。从能力链路看detection 输出框、关键点、置信度会被 recognition 阶段消费FaceRecognizer._predict 对每张检测到的人脸执行对齐裁剪align_face、归一化后批量提取 embedding最终postprocess输出boundingBoxembeddingscore结构供上层数据库存储与聚类。小结与关键路径本篇围绕 machine-learning/README.md 的三个核心章节展开并落到仓库内的可验证实现环境uv sync --extra {cpu|cuda|rocm|openvino}extras 与 onnxruntime 发行版的映射定义在 pyproject.toml锁文件提交是硬约定服务与调优MACHINE_LEARNING_*环境变量族覆盖 worker、TTL、线程池、预加载与批大小实现在 config.py空闲自杀与线程池调度在 main.py压测locust --web-host 127.0.0.1 locustfile.py记住users 每端点并发 × 端点数的换算加速执行提供商优先级在 constants.py会话选项与线程策略在 ort.py容器形态由 Dockerfile 的DEVICE构建参数与 docker-compose.yml 的镜像 tag 后缀共同决定合规InsightFace 四个模型组的授权范围仅限本项目内部使用禁止第三方分发与商用。【免费下载链接】immichHigh performance self-hosted photo and video management solution.项目地址: https://gitcode.com/GitHub_Trending/im/immich创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考