后端云原生模型推理服务MLOps人工智能【免费下载链接】cortexProduction infrastructure for machine learning at scale项目地址https://gitcode.com/gh_mirrors/co/cortex点击查看免费下载导读Cortex 是一个面向大规模机器学习场景的生产级基础设施平台核心理念是让开发者能够以部署 API的方式完成机器学习模型的部署、管理与弹性伸缩。它提供 Realtime、Async、Batch 三类 Serverless 工作负载内置基于 CPU/GPU 实例与 Spot 实例的自动化集群管理并深度构建在 AWSEKS VPC IAM之上配合 Grafana 看板与 CloudWatch/日志流集成形成完整的 CI/CD 与可观测性闭环。阅读本文后你将掌握 Cortex 的核心架构、四类工作负载的运作原理、cluster.yaml集群配置的完整参数体系以及多环境管理与 IAM 认证授权的最佳实践。一、项目定位为规模化机器学习打造的生产级基础设施Cortex 在 README.md 中对自己的定位非常明确Production infrastructure for machine learning at scale——为规模化机器学习提供生产级基础设施。围绕这一目标平台解决了三个核心问题部署与管理在 AWS 账户中一键创建托管集群并以声明式配置文件或 Terraform Provider 完成资源供给Provisioning。规模化伸缩以工作负载为粒度自动扩缩容集群层与 API 层双重弹性。可观测性指标可发送到任意监控工具日志可流式转发到任意日志管理平台并内置 Grafana 看板与 CloudWatch 集成。结合 docs/overview.md 可以看到更完整的部署拓扑Cortex 集群运行在你 AWS 账户内、专有 VPC 中的 EKSKubernetes集群之上Kubernetes 集群以 EC2 自动扩缩组Auto Scaling Group承载 Worker 节点组并借助 Kubernetes Cluster Autoscaler 按工作负载的计算需求弹性伸缩节点组集群内所有日志经 FluentBit 推送至 CloudWatch 日志组Prometheus 负责采集用于可观测性与自动扩缩的指标Grafana 用于查看和修改工作负载与实例使用情况的看板。二、Serverless 工作负载四类核心部署形态Cortex 以Pod一组容器的集合作为原子部署单元扩缩容与副本管理都发生在 Pod 层。根据编排方式的不同工作负载被划分为Realtime、Async、Batch、Task四类其中前三种正是 README 所强调的 Serverless 工作负载。其中 Realtime 与 Async 的扩容逻辑在 pkg/autoscaler/autoscaler.go 中以统一的Scaler接口抽象出来type Scaler interface { Scale(apiName string, request int32) error GetInFlightRequests(apiName string, window time.Duration) (*float64, error) GetAutoscalingSpec(apiName string) (*userconfig.Autoscaling, error) CurrentRequestedReplicas(apiName string) (int32, error) }Autoscaler内部按userconfig.Kind工作负载类型注册对应的 Scaler 实现pkg/autoscaler/realtime_scaler.go、pkg/autoscaler/async_scaler.go并通过Awaken等入口驱动扩缩容决策。2.1 Realtime同步响应 基于在途请求量伸缩Realtime API 以同步方式响应请求并根据**在途请求量in-flight request volume**自动扩缩容见 docs/workloads/realtime/realtime.md。它适合将无状态容器作为可弹性伸缩的微服务运行例如把机器学习模型封装成 API。核心特性同步响应请求基于请求量自动扩缩容避免冷启动保持常驻副本支持缩容到 0scale to zero滚动更新自动从故障与 Spot 实例终止中恢复支持 A/B 测试与金丝雀canary发布。工作原理部署一个 Realtime API 时Cortex 会初始化一组 Worker Pod并为每个 Pod 挂载一个Proxy sidecar。Proxy 负责接收请求、必要时排队并在你的容器就绪后转发请求扩缩容依据的聚合在途请求量正是由这些 Proxy sidecar 上报的。这套请求代理逻辑的实现在 pkg/proxy/包括 handler.go、breaker.go 等文件激活/唤醒逻辑则在 pkg/activator/。2.2 Async异步处理 基于队列长度伸缩Async API 面向异步工作负载用户提交异步请求随后通过轮询或 Webhook获取结果见 docs/workloads/async/async.md。适合视频、音频、文档等耗时较长的处理任务。核心特性异步处理请求通过 HTTP 端点获取状态与响应基于队列长度自动扩缩容避免冷启动、支持缩容到 0、滚动更新、自动恢复。工作原理关键组件逐一对应源码部署 Async API 时Cortex 创建一条SQS 队列、一组Async GatewayWorker 和一组 Worker Pod每个 Worker Pod 内运行一个dequeuer sidecar与你的容器。请求到达时Async Gateway 将请求 payload 保存到S3把请求 ID 入队到SQS FIFO 队列然后向客户端返回请求 ID——对应 pkg/async-gateway/ 的实现。Worker Pod 中的 dequeuer sidecar 从 SQS 拉取请求、从 S3 下载 payload并向你的容器发起 POST 请求收到响应后删除 S3 中的请求 payload并将响应在 S3 中保留7 天——对应 pkg/dequeuer/ 的异步处理实现。你可以用请求 ID 对 Async API 端点发起 GET 请求获取状态与结果。Worker 池根据队列中的平均消息数自动扩缩可配置缩容到 0。2.3 Batch分布式、容错的批处理作业Batch API 按需运行分布式、容错的批处理作业见 docs/workloads/batch/batch.md。适合将大任务拆解后分发给一组专用 Worker 并行处理例如对一批图片做推理。核心特性将批处理作业分发到多个 Worker无作业时缩容到 0全部批次处理完毕后触发/on-job-complete钩子所有批次至少尝试一次at-least-once失败批次自动转入死信队列dead letter queue自动从故障与 Spot 实例终止中恢复。工作原理部署 Batch API 后Cortex 创建接收作业提交的端点提交作业后返回Job ID并异步触发 Batch Job。Batch Job 首先启动一个enqueuer进程把作业数据切分为批次并推入 SQS FIFO 队列见 pkg/enqueuer/入队完成后Cortex 初始化指定数量的 Worker Pod 并挂载 dequeuer sidecar由 dequeuer 从队列拉取批次并逐批向你的 Pod 发起 HTTP 请求对应 pkg/dequeuer/batch_handler.go。Worker 清空队列后作业标记为完成Cortex 终止 Worker Pod 并删除 SQS 队列。你可以对 Batch API 端点发起 GET 请求获取作业状态及已完成/失败批次数量等指标。2.4 TaskLambda 风格的按需容器执行Task API 提供Lambda 风格的容器按需执行见 docs/workloads/task/task.md。适合通过 HTTP 请求触发容器执行例如训练模型也可配置为 Airflow 等编排器的任务执行器。核心特性按需运行容器无任务时缩容到 0自动从故障与 Spot 实例终止中恢复。工作原理部署 Task API 后Cortex 创建接收任务提交的端点提交任务后返回Task ID并异步触发执行。Cortex 依据 API 规格初始化一个 Worker PodPod 运行完成后任务标记为完成并终止该 Pod通过 GET 请求 Task API 端点即可查询任务状态。Batch 与 Task 的提交/停止/查询端点实现可分别参考 pkg/operator/endpoints/submit_batch.go、submit_task.go、get_batch_job.go 与 get_task_job.go。三、自动化集群管理弹性扩缩、Spot 与多环境README 概括了集群管理的三大能力其落地方案在 docs/overview.md 与 docs/clusters/management/environments.md 中有更详细的展开Autoscaling集群弹性以 CPU 与 GPU 实例弹性伸缩集群。Kubernetes Cluster Autoscaler 依据工作负载的计算需求驱动对应节点组扩缩集群管理器侧的渲染与部署配置可见 manager/manifests/cluster-autoscaler.yaml.j2。Spot instances低成本实例可在 Spot 实例上运行工作负载并配备自动化的按需备份当 Spot 实例被回收时自动用按需实例顶替。Environments多环境创建多个配置不同的集群并通过 CLI 环境environment概念在它们之间切换部署目标。3.1 多环境管理实战当你用cortex cluster up创建集群时系统会自动创建一个与集群同名的 environment 指向该集群并将其设为默认环境对应默认 CLI 配置 manager/manifests/default_cortex_cli_config.yamlCLI 配置结构定义在 cli/types/cliconfig/cli_config.go。相关命令一览cortex env list列出所有环境cortex env default切换默认环境cortex env rename重命名环境cortex env delete删除环境cortex env configure创建/更新环境。管理多集群时可在cortex cluster up时用--configure-env指定环境名例如cortex cluster up --configure-env prod之后通过--env参数将部署目标切换到对应集群cortex cluster up cluster1.yaml --configure-env cluster1 # 配置 cluster1 环境 cortex cluster up cluster2.yaml --configure-env cluster2 # 配置 cluster2 环境 cortex deploy --env cluster1 cortex delete my-api --env cluster1 cortex deploy --env cluster2 cortex delete my-api --env cluster2如果创建集群时省略了--configure-env可以用cortex cluster info补齐cortex cluster info cluster1.yaml --configure-env cluster1 cortex cluster info cluster2.yaml --configure-env cluster2在新机器上配置 CLI 以连接已有集群时先在已配置好的机器上运行cortex env list记下环境名与 Operator 端点再在新机器上运行cortex env configure完成连接。四、CI/CD 与可观测性集成README 强调的第三块能力是工程化集成的完整闭环Provisioning声明式供给既可以用声明式配置cluster.yaml供给集群也支持 Terraform Provider 方式接入现有 IaC 工作流。Metrics指标指标可发送到任意监控工具集群内预置 Prometheus 采集与 Grafana 看板。看板按工作负载类型拆分仓库中提供了 async、batch、cluster、control-plane、nodes、realtime、task 等场景的 Grafana Dashboard 定义见 manager/manifests/grafana/例如 grafana-dashboard-realtime.yaml、grafana-dashboard-cluster.yaml。Logs日志日志可流式转发到任意日志管理工具内置 CloudWatch 集成集群内所有日志经 FluentBit 推送至 CloudWatch 日志组FluentBit 部署模板见 manager/manifests/fluent-bit.yaml.j2。从源码结构看集群侧还有event-exporter与metrics-server、prometheus-*系列组件共同支撑可观测性其镜像定义分布在 images/ 目录如 images/prometheus/Dockerfile、images/grafana/Dockerfile、images/fluent-bit/Dockerfile。五、深度构建于 AWSEKS、VPC 与 IAMCortex 专为 AWS 设计README 将其概括为三点docs/overview.md 给出了对应的架构事实EKSCortex 运行在 EKS 之上从而可靠且低成本地扩缩工作负载。默认安装时会在你的 AWS 账户中创建专有 VPC集群创建两个 AWS 负载均衡器分别承载 API 流量与 CLI/Python 客户端的 API 管理流量流量安全与访问限制可通过集群配置控制。负载均衡器与集群状态的获取逻辑见 manager/get_api_load_balancer_state.py 与 manager/get_operator_load_balancer_state.py。VPC集群部署在你账户的 VPC 内数据保持私有支持将集群安装进已有 VPC通过subnets配置指定现有子网。IAM与 IAM 集成实现认证与授权工作流详见下文第六节。集群安装过程中使用的 AMI 与 EKS 生成逻辑可参考 manager/manifests/ami.json 与 manager/generate_eks.py。六、快速开始安装 CLI、创建集群并部署根据 docs/start.md 与 docs/clusters/management/create.md最快上手路径如下。前置条件本机安装并运行 Docker若使用 GPU 集群需订阅带 GPU 支持的 AMI创建一个具有AdministratorAccess与编程访问权限的 IAM 用户视实例类型可能需要申请配额提升。安装 CLI 并创建集群# 安装 Cortex CLI仓库根目录提供安装脚本见 get-cli.sh bash -c $(curl -sS ...) # 或直接执行仓库内的 ./get-cli.sh 进行安装 # 创建集群 cortex cluster up cluster.yaml说明本文只描述查看与运行方式具体安装脚本内容可在仓库根目录 get-cli.sh 中查看其发布版本号对应文档所标注的 v0.42.1。构建可伸缩的 API# 部署 API cortex deploy apis.yaml配套的深度指南Realtime 示例构建实时响应请求的 APIAsync 示例构建异步响应请求的 APIBatch 示例构建运行分布式批处理作业的 APITask 示例构建按需运行作业的 API。仓库 test/ 目录为每种工作负载提供了可运行的端到端示例与配置模板例如 test/apis/realtime/hello-world/含cortex_cpu.yaml与 Dockerfile、test/apis/batch/image-classifier-alexnet/含 GPU 配置与提交脚本submit.py、test/apis/task/iris-classifier-trainer/。真实环境联测用例可参考 test/e2e/tests/aws/ 下的test_realtime.py、test_async.py、test_batch.py、test_task.py。6.1 cluster.yaml 完整配置解读集群配置以cluster.yaml声明docs/clusters/management/create.md 给出了完整模板核心参数如下# 集群名称 cluster_name: cortex # AWS 区域 region: us-east-1 # 可用区列表默认区域内 3 个随机可用区 availability_zones: # 例如 [us-east-1a, us-east-1b, us-east-1c] # 集群节点组列表 node_groups: - name: ng-cpu # 节点组名称 instance_type: m5.large # 实例类型 min_instances: 1 # 最小实例数 max_instances: 5 # 最大实例数 priority: 1 # 节点组优先级值越高优先级越高 [1-100] instance_volume_size: 50 # 每实例磁盘大小GB instance_volume_type: gp3 # 卷类型 [gp2 | gp3 | io1 | st1 | sc1] # instance_volume_iops: 3000 # 卷 IOPS仅 io1/gp3 适用 # instance_volume_throughput: 125 # 卷吞吐量仅 gp3 适用 spot: false # 是否使用 Spot 实例 - name: ng-gpu instance_type: g4dn.xlarge min_instances: 1 max_instances: 5 instance_volume_size: 50 instance_volume_type: gp3 spot: false # 子网可见性 [public实例有公网 IP| private实例无公网 IP] # 使用 private 子网时建议在 AWS 控制台为 S3 与 ECR 开启 VPC 端点以避免额外 NAT 网关费用 subnet_visibility: public # NAT 网关使用 private 子网时必需[none | single | highly_available每可用区一个 NAT 网关] nat_gateway: none # API 负载均衡器类型 [nlb | elb] api_load_balancer_type: nlb # API 负载均衡器方案 [internet-facing | internal] api_load_balancer_scheme: internet-facing # Operator 负载均衡器方案 [internet-facing | internal] # 注意若使用 internal必须配置 VPC Peering 以便 CLI 连接集群 Operator operator_load_balancer_scheme: internet-facing # 若要安装到已有 VPC可提供子网列表subnet_visibility 必须与子网实际可见性一致 # 该为高级功能要求 VPC 配置正确 # subnets: # - availability_zone: us-west-2a # subnet_id: subnet-060f3961c876872ae # - availability_zone: us-west-2b # subnet_id: subnet-0faed05adf6042ab7 # 按 CIDR/IP 范围限制 API 访问 api_load_balancer_cidr_white_list: [0.0.0.0/0] # 按 CIDR/IP 范围限制 Operator 访问 operator_load_balancer_cidr_white_list: [0.0.0.0/0] # 附加到 AWS 资源的标签所有资源会自动打上 cortex.dev/cluster-name: cluster_name tags: # string: string 键值对映射 # SSL 证书 ARN仅在使用自定义域名时需要 ssl_certificate_arn: # 附加到 Cortex API 的 IAM 策略列表 iam_policy_arns: [arn:aws:iam::aws:policy/AmazonS3FullAccess] # 集群 VPC 的主 CIDR 段 vpc_cidr: 192.168.0.0/16 # Prometheus 实例类型集群超过 300 节点或 300 Pod 时建议使用更大内存的实例 prometheus_instance_type: t3.medium可覆盖的集群镜像集群使用的 Docker 镜像可通过在配置文件中添加以下键覆盖默认值如 docs/clusters/management/create.md 所示涵盖image_manager、image_operator、image_autoscaler、image_proxy、image_async_gateway、image_enqueuer、image_dequeuer、image_cluster_autoscaler、image_fluent_bit、image_prometheus、image_grafana等全部组件对应的 Dockerfile 均可参考 images/ 目录。这一机制对私有化镜像仓库、离线环境部署尤其重要。七、认证与授权IAM 集成方案Cortex CLI 与 Python 客户端通过AWS 默认凭证链获取凭证按以下优先级读取见 docs/clusters/management/auth.md环境变量AWS_PROFILE环境变量指定的 profile~/.aws/credentials中的defaultprofile。集群管理cortex cluster *建议使用AdministratorAccess凭证创建集群的 IAM 用户/角色会被自动授予集群 RBAC 的system:masters权限因此请记录创建集群的 IAM 实体。默认情况下集群命令只能由创建者执行如需授权其他 IAM 用户可安装eksctl后使用eksctl create iamidentitymapping --region $CLUSTER_REGION --cluster $CLUSTER_NAME --arn $NEW_USER_ARN --group system:masters --username $NEW_USER_ARN添加身份映射撤销时运行eksctl delete iamidentitymapping ... --all。API 管理cortex deploy、cortex get等客户端通过 AWS IAM 向 Operator 认证凭证只需在同 AWS 账户内有效即可不需要特定权限但集群管理类命令需要相应权限。授权你的 API 访问 AWS 资源集群创建时可通过cluster.yaml的iam_policy_arns附加额外策略对已有集群可在 IAM 控制台搜索cortex-cluster_name-region找到自动创建的策略并追加权限注意该策略会在cortex cluster down时自动删除生产环境建议自行创建策略并写入iam_policy_arns自动创建的策略仅用于开发测试。仓库还提供了最小权限参考dev/minimum_aws_policy.json而 docs/clusters/management/auth.md 中给出了完整的最小 IAM 策略模板涵盖iam:CreateServiceLinkedRole、eks:*、cloudformation:*、ec2:*、sqs:*、s3:*等动作并将资源限定到eksctl-*、cortex-*、cx-*前缀适用于无法使用AdministratorAccess的场景。八、源码视角自动扩缩容的实现骨架Cortex 的自动扩缩容是平台最核心的机制之一。以 pkg/autoscaler/autoscaler.go 为例Autoscaler维护三张映射crons每个 API 的周期性调度任务、scalers按工作负载类型注册的扩缩容器与recs副本数推荐记录。Awaken方法按 API 的Kind找到对应 Scaler 并读取当前请求副本数据此唤醒或调整副本pkg/autoscaler/recommendations.go 负责计算推荐副本数而各工作负载的缩放函数实现集中在 pkg/autoscaler/scaler_func.go。集群侧 Pod 副本的最终落地由 pkg/operator/ 与 pkg/workloads/ 完成例如 pkg/workloads/k8s.go 中的 Kubernetes 资源操作。Realtime 与 Async 的缩放信号来源不同Realtime 依赖 Proxy sidecar 上报的聚合在途请求量Async 依赖 SQS 队列的平均消息数——这与前文工作负载原理一一对应也解释了为何两类工作负载在Scaler接口之上需要不同的实现。九、总结Cortex 的价值在于把模型部署上线从繁琐的 Kubernetes 编排中解放出来开发者只需维护一份 API 配置即可获得自动扩缩、故障恢复、滚动更新与 A/B 测试能力集群管理员则通过一份cluster.yaml完成 EKS/VPC/IAM 的声明式供给。它深度绑定 AWS 生态EKS、SQS、S3、CloudWatch、负载均衡器同时借助 Grafana 与 FluentBit 保持可观测性开放。需要注意的是Cortex 的部署与使用均依赖 AWS 账户且项目原维护者已不再积极维护见 README.md 顶部声明选用时建议结合生产环境的长期维护策略评估。赞分享后端云原生模型推理服务MLOps人工智能【免费下载链接】cortexProduction infrastructure for machine learning at scale项目地址https://gitcode.com/gh_mirrors/co/cortex点击查看免费下载相关推荐Cortex 集群创建实战指南用 cluster.yaml 在 AWS 上部署生产级机器学习基础设施Cortex 集群创建实战指南用 cluster.yaml 在 AWS 上部署生产级机器学习基础设施 本文是 Cortex 集群安装与创建的核心操作指南聚焦后端云原生模型推理服务MLOps人工智能Cortex大规模机器学习生产的基础设施Cortex大规模机器学习生产的基础设施 Cortex 是一个开源项目旨在为机器学习模型的生产部署、管理和扩展提供基础设施。该项目主要使用 Go 语言开发后端云原生模型推理服务MLOps人工智能Pixelle-Video技术架构深度解析全自动AI视频生成引擎的创作革命Pixelle Video技术架构深度解析全自动AI视频生成引擎的创作革命 在内容创作领域传统视频制作流程的复杂性和技术门槛长期制约着创作者的效率与想象力。人工智能AI 应用音视频媒体生成创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考