后端云原生模型推理服务MLOps人工智能【免费下载链接】cortexProduction infrastructure for machine learning at scale项目地址https://gitcode.com/gh_mirrors/co/cortex点击查看免费下载导读本文是 Cortex 项目中 Realtime API实时推理 API配置文件的完整参考手册。Realtime API 以同步方式响应请求并基于在途请求数in-flight requests自动扩缩容适合将无状态容器尤其是机器学习模型以微服务形式对外提供。读完本文你将掌握cortex.yaml中 RealtimeAPI 的每一个配置字段含默认值与取值范围、健康检查与优雅停机的最佳实践以及自动扩缩容背后由 pkg/autoscaler/autoscaler.go 实现的完整决策算法。一、RealtimeAPI 配置总览一个 Realtime API 的配置以 YAML 列表的形式写在部署文件中通常命名为cortex.yaml每个列表项对应一个 API。kind必须为RealtimeAPI其余所有字段均有默认值。完整的配置骨架如下与官方 配置参考 一一对应- name: string # API 名称必填 kind: RealtimeAPI # 必须为 RealtimeAPI必填 pod: # Pod 配置必填 port: int # 请求发送到的端口默认: 8080以 $CORTEX_PORT 导出 max_concurrency: int # 并发送入容器的最大请求数默认: 1 max_queue_length: int # 每个副本允许排队等待的最大请求数默认: 100 containers: # 容器配置至少提供一个容器 - name: string # 容器名称必填 image: string # 容器使用的 Docker 镜像必填 command: list[string] # 入口点不在 shell 中执行默认: 镜像的 ENTRYPOINT args: list[string] # 入口点参数默认: 镜像的 CMD env: map[string:string] # 环境变量字典可选 compute: # 计算资源请求默认值见下文 cpu: string|int|float # CPU 请求默认: 200m gpu: int # GPU 请求默认: 0 inf: int # Inferentia 芯片请求默认: 0 mem: string # 内存请求默认: Null shm: string # 共享内存 /dev/shm 大小默认: Null readiness_probe: # 就绪探针可选 http_get: # HTTP 探针与 tcp_socket、exec 三选一 port: int|string # 访问的端口必填 path: string # HTTP 路径默认: / tcp_socket: # TCP 探针 port: int|string # 访问的端口必填 exec: # 命令探针 command: list[string] # 需以退出码 0 结束的命令必填 initial_delay_seconds: int # 容器启动后延迟探测的秒数默认: 0 timeout_seconds: int # 探测超时秒数默认: 1 period_seconds: int # 探测周期秒数默认: 10 success_threshold: int # 成功判定所需连续成功次数默认: 1 failure_threshold: int # 失败判定所需连续失败次数默认: 3 liveness_probe: # 存活探针可选失败将重启容器 # 结构与 readiness_probe 完全相同http_get / tcp_socket / exec 三选一 # 默认值: initial_delay_seconds0, timeout_seconds1, # period_seconds10, success_threshold1, failure_threshold3 pre_stop: # 容器终止前的 pre-stop 钩子可选 http_get: # HTTP 钩子与 exec 二选一 port: int|string # 访问的端口必填 path: string # HTTP 路径默认: / exec: # 命令钩子 command: list[string] # 需在容器内执行的命令必填 autoscaling: # 自动扩缩容配置默认值见下文 min_replicas: int # 最小副本数默认: 1 max_replicas: int # 最大副本数默认: 100 init_replicas: int # 初始副本数默认: min_replicas target_in_flight: float # 每个副本期望的在途请求数默认: max_concurrency window: duration # 在途请求平均窗口默认: 60s downscale_stabilization_period: duration # 缩容稳定期默认: 5m upscale_stabilization_period: duration # 扩容稳定期默认: 1m max_downscale_factor: float # 单次缩容事件最大比例默认: 0.75 max_upscale_factor: float # 单次扩容事件最大比例默认: 1.5 downscale_tolerance: float # 缩容容忍阈值默认: 0.05 upscale_tolerance: float # 扩容容忍阈值默认: 0.05 node_groups: list[string] # 可运行此 API 的节点组列表默认: 所有节点组 update_strategy: # 滚动更新策略默认值见下文 max_surge: string|int # 更新时可超出期望副本数的最大副本数默认: 25% max_unavailable: string|int # 更新时允许不可用的最大副本数默认: 25% networking: # 网络配置 endpoint: string # API 端点默认: api_name从源码结构看上述每个配置块都可以在 pkg/types/userconfig/api.go 中找到对应的 Go 结构体API、Pod、Container、Probe、PreStop、Compute、Autoscaling、UpdateStrategy、Networking字段名与 YAML 键一一对应且配置键常量集中在 pkg/types/userconfig/config_key.go 中统一管理。下面逐块展开。二、Pod 配置端口、并发与排队pod是 Realtime API 的核心配置块它描述了请求如何进入容器以及每个副本能承受的负载。port默认 8080请求将被发送到容器内监听此端口的 Web 服务器。该值会以环境变量$CORTEX_PORT的形式导出到容器中因此你可以在command、args里通过$(CORTEX_PORT)引用它例如pod: port: 8080 containers: - name: api image: image command: - uvicorn - --host - 0.0.0.0 - --port - $(CORTEX_PORT) - main:app提示在 test/apis/realtime/hello-world/cortex_cpu.yaml 等仓库自带示例中可以看到端口配置与容器镜像的实际搭配用法。max_concurrency默认 1Cortex 并发送入容器处理的最大请求数。如果容器的 Web 服务器如 Uvicorn、Gunicorn本身支持多并发调大该值可显著提升单个副本的吞吐从而在相同负载下减少所需副本总数。max_queue_length默认 100每个副本在超过max_concurrency之后还能排队等待的请求数上限超过部分将以 HTTP 503 直接拒绝。对于耗时长请求的 API调低该值并让客户端在收到 503 后重试可以防止请求长时间积压在个别副本的队列中从而改善跨副本的负载均衡公平性。max_concurrency与max_queue_length会通过pod.cortex.dev/max-concurrency与pod.cortex.dev/max-queue-length注解写入 Kubernetes 对象见 config_key.go由 pkg/proxy 中的代理 sidecar 读取执行——即排队与转发逻辑在代理层完成而非你的业务容器。三、容器配置镜像、启动命令与环境变量pod.containers是必填的列表至少提供一个容器。每个容器支持以下字段字段类型说明namestring容器名称必填同一 Pod 内需唯一imagestringDocker 镜像地址必填commandlist[string]入口点不经 shell 直接执行可用$(CORTEX_PORT)引用环境变量默认继承镜像 ENTRYPOINTargslist[string]入口点参数同样支持$(...)变量默认继承镜像 CMDenvmap[string:string]注入容器的环境变量字典一个 Realtime API 的 Pod 可以包含多个容器如 test/apis/realtime/multi-container/cortex_cpu.yaml 所示但只能有一个容器在目标端口上监听 HTTP 请求可以是任意一个容器。所有容器共享/mnt目录。每个容器的command和args在 Go 侧被定义为字符串数组api.go 中的Command []string/Args []string意味着它们会被直接 exec而不是通过/bin/sh -c运行——因此管道、重定向等 shell 语法不会生效。容器内使用 Cortex CLI/客户端所有容器内都会预置一份指向当前集群的 CLI 配置文件/cortex/client/cli.yaml环境变量CORTEX_CLI_CONFIG_DIR默认指向/cortex/client因此你可以在容器内直接使用 Python 客户端cortex.client()或 CLI 与集群交互无需额外配置。注意客户端版本需与集群版本一致可通过CORTEX_VERSION环境变量获取。四、computeCPU / GPU / Inferentia / 内存 / 共享内存compute定义容器的资源请求每个容器独立配置。Cortex 会累加所有容器的资源请求来调度 Pod并为 Realtime API 自动附加一个代理 sidecar 容器额外请求 100m CPU 与 100Mi 内存见 pkg/consts/consts.go 中的CortexProxyCPU/CortexProxyMem总资源计算逻辑在 api.go 的GetPodComputeRequest中实现。字段默认值说明cpu200mCPU 请求1 单位 CPU 对应 1 个 vCPU支持小数或m后缀如500m 0.5 vCPUgpu0GPU 请求1 单位对应 1 个虚拟 GPUinf0AWS Inferentia 芯片请求1 单位对应 1 个虚拟 Inferentia 芯片memNull内存请求1 单位为 1 字节支持K/M/G/T十进制后缀及Ki/Mi/Gi/Ti二进制后缀shmNull共享内存/dev/shm大小如64Mi、1Gi用于多进程间共享数据典型场景是 PyTorch DataLoader 的 num_workerscpu与mem在源码中被解析为 Kubernetes 的resource.Quantity类型api.go 中CPU *k8s.Quantity因此支持 Kubernetes 资源量表示的全部语法。CPU 默认200m与代理 sidecar 的100m之和为300m多容器时 Cortex 会取所有容器请求的总和作为 Pod 的调度依据。五、健康检查readiness_probe / liveness_probe / pre_stop探针的三种探测方式readiness_probe与liveness_probe结构相同都支持三种互斥的探测方式http_get、tcp_socket、exec只能三选一http_get请求容器内指定端口与路径响应状态码为 200 即视为成功。tcp_socket指定端口能够接受连接即视为成功。exec在容器内执行命令直接 exec不走 shell工作目录为容器根目录/退出码为 0 即视为成功。两者的通用时序参数及默认值参数默认值说明initial_delay_seconds0容器启动后延迟多少秒再开始探测timeout_seconds1单次探测的超时秒数period_seconds10探测周期秒success_threshold1判定成功所需的连续成功次数failure_threshold3判定失败所需的连续失败次数就绪探针readiness_probe作用只有 Pod 内所有容器的就绪探针都成功流量才会被送入该 Pod。默认情况下容器一旦绑定端口就会开始接收流量但某些 Web 服务器如tiangolo/uvicorn-gunicorn-fastapi可能在 worker 就绪前就监听端口。此时应实现就绪检查。最常用的做法是在 Web 服务里加一个返回 200 的/healthz路由并配置readiness_probe: http_get: port: 8080 path: /healthz存活探针liveness_probe作用探测失败时容器会被自动重启用于自愈死锁或泄漏的进程。pre_stop 钩子作用容器终止前执行的钩子用于优雅下线——例如在流量摘除后、进程退出前通知注册中心注销节点、冲刷缓冲区或等待在途请求完成。支持http_get向指定端口/路径发请求与exec执行命令两种方式二选一。Cortex 的滚动更新会配合该钩子完成优雅的流量迁移。在 api.go 中探针被建模为Probe结构体含HTTPGet、TCPSocket、Exec与五个时序字段与 Kubernetes 原生探针语义一一对应。六、autoscaling基于在途请求的自动扩缩容Realtime API 的自动扩缩容独立于每个 API 运行。Cortex 在 pkg/autoscaler/autoscaler.go 中为每个 API 启动一个每 10 秒触发一次的定时任务AutoscalingTickInterval 10 * time.Second定义于 pkg/types/spec/validations.go读取 pkg/autoscaler/realtime_scaler.go 中通过 PromQL 聚合得到的平均在途请求数再结合本节的配置参数计算目标副本数。核心指标 target_in_flighttarget_in_flight默认pod 配置中的max_concurrency是自动扩缩容的决策指标表示每个副本期望的在途请求数——即已发送给副本但尚未收到响应的请求数包含正在处理的和排队中的请求。扩缩容的核心公式desired replicas sum(in-flight requests across all replicas) / target_in_flight例如将target_in_flight设为max_concurrency默认行为会让集群调整副本数使得请求平均无需排队即可被立即处理。该公式在 autoscaler.go 中的实现为rawRecommendation : *avgInFlight / *autoscalingSpec.TargetInFlight recommendation : int32(math.Ceil(rawRecommendation))副本上下限与初始值字段默认值说明min_replicas1副本数下界支持缩容到 0实验性scale-to-zeromax_replicas100副本数上界init_replicasmin_replicas部署时的初始副本数平滑与稳定参数window默认60s在途请求的平均时间窗口。窗口越长自动扩缩容对流量变化的反应越慢。由于在途请求每 10 秒计算一次window必须是 10 秒的倍数该约束由 validations.go 强制校验。downscale_stabilization_period默认5m在此周期内不会缩容到历史最高建议值之下。自动扩缩容每 10 秒给出一次建议最终取当前建议与该周期内所有建议的最大值中较大的作为缩容目标。调大该值可让集群对流量下降反应更慢减少抖动thrashing。upscale_stabilization_period默认1m与上对应在此周期内不会扩容超过历史最低建议值之上。调大该值可让集群对流量上升反应更慢。max_downscale_factor默认0.75单次缩容事件的最大比例。例如设为0.5且当前 10 个副本时自动扩缩容不会建议少于 5 个副本。调大可让集群在流量骤降时更快收缩。max_upscale_factor默认1.5单次扩容事件的最大比例。例如设为10且当前 5 个副本时不会建议超过 50 个副本。downscale_tolerance默认0.05低于当前副本数一定比例之内的缩容建议不会被执行。例如容忍度为0.1、当前 20 个副本时建议 1819 个副本不会触发缩容。upscale_tolerance默认0.05高于当前副本数一定比例之内的扩容建议不会被执行。在 autoscaler.go 中一次完整决策的先后顺序是计算原始建议 → 应用上下容忍阈值 → 应用单次缩放因子上限且始终允许加减 1 个副本→ 夹取到min_replicas/max_replicas之间 → 记录历史建议 → 依据稳定期约束得出最终副本数 → 若与当前副本数不同则调用scaler.Scale执行变更。scale-to-zero 的实现细节当建议副本数为 0 时realtime_scaler.go 的Scale方法会把流量路由切换到 activator 组件通过 Istio VirtualService 权重调整并将 Deployment 副本数置 0当有请求唤醒时再切回服务路由并等待至少 1 个副本就绪waitForReadyReplicas。这就是 Realtime API 支持避免冷启动与缩容到零的原因。实例级扩缩容除副本外Cortex 还会根据所有 API 的资源请求总量自动上下调整节点实例数每个节点组的实例数保持在安装时配置的min_instances与max_instances之间可通过cortex cluster configure修改。过配置overprovisioning与响应速度过配置如果应用对流量尖峰敏感、或新副本创建耗时较长可以把target_in_flight设得比预期并发更低以维持额外冗余容量。例如副本可高效处理 2 个并发请求、平均收到 8 个并发请求时默认target_in_flight: 2会维持 4 个副本8/2若想冗余 25%设为1.6则会维持 5 个副本8/1.6。响应延迟在默认window60s与upscale_stabilization_period1m下从流量上升到新增副本被请求可能需要约 2 分钟随后还需等待新实例被 AWS 拉起、拉取镜像与初始化。若希望尽可能快的响应可将window与upscale_stabilization_period分别设为最小允许值10s与0s。更详细的行为说明可参考 自动扩缩容文档。七、node_groups 与 update_strategynode_groups默认所有节点组以列表形式指定该 API 可被调度到的节点组如 GPU 节点组、Inferentia 节点组。不配置时所有节点组均可用。资源类型GPU/INF通常与节点组的选择配套使用例如 test/apis/realtime/text-generator/cortex_gpu.yaml 中同时声明了 GPU 资源与对应的节点组。update_strategy滚动更新控制新副本替换旧副本的方式对应 Kubernetes Deployment 的滚动更新策略字段默认值说明max_surge25%更新期间可超出期望副本数的最大副本数可写绝对数如5或百分比如10%设为0可禁用滚动更新max_unavailable25%更新期间允许同时不可用的最大副本数同样支持绝对数或百分比合理的max_surge/max_unavailable组合决定了发布时的可用性与速度希望零中断发布时可保留默认值追求快速发布而允许短暂容量抖动时可调大max_surge。八、networking端点定制networking.endpoint用于自定义 API 的对外端点路径默认等于 API 名称。例如名为hello-world的 API 默认暴露在负载均衡器地址/hello-world若设置endpoint: v1/classify则请求路径随之改变。支持子路径转发请求load_balancer_url/hello-world/subpath会被路由到容器 Web 服务器的/subpath。注意endpoint在集群内必须是唯一的且不支持大写字母或下划线。九、一份完整的实战配置示例结合上述全部字段下面是一个完整的可运行示例镜像为仓库 示例文档 中的 hello-world FastAPI 应用# cortex.yaml - name: hello-world kind: RealtimeAPI pod: port: 8080 max_concurrency: 4 max_queue_length: 200 containers: - name: api image: AWS_ACCOUNT_ID.dkr.ecr.us-east-1.amazonaws.com/hello-world command: - uvicorn - --host - 0.0.0.0 - --port - $(CORTEX_PORT) - main:app env: LOG_LEVEL: info compute: cpu: 500m mem: 512Mi readiness_probe: http_get: port: 8080 path: /healthz initial_delay_seconds: 5 period_seconds: 10 liveness_probe: http_get: port: 8080 path: /healthz initial_delay_seconds: 10 period_seconds: 30 pre_stop: exec: command: [/bin/sh, -c, echo draining /tmp/drain] autoscaling: min_replicas: 2 max_replicas: 20 init_replicas: 2 target_in_flight: 4 window: 30s downscale_stabilization_period: 5m upscale_stabilization_period: 1m max_downscale_factor: 0.75 max_upscale_factor: 1.5 node_groups: - cpu-group update_strategy: max_surge: 25% max_unavailable: 0 networking: endpoint: hello-world将上述文件保存为cortex.yaml后在集群目录中执行cortex deploy即可部署cortex get --watch等待就绪cortex get hello-world获取端点地址随后即可用curl向http://负载均衡器地址/hello-world发送请求。十、相关参考配置字段的 Go 结构体与默认值处理pkg/types/userconfig/api.go配置键常量与 Kubernetes 注解名pkg/types/userconfig/config_key.go自动扩缩容决策算法实现pkg/autoscaler/autoscaler.goRealtime 扩缩容执行与 scale-to-zero 路由切换pkg/autoscaler/realtime_scaler.go自动扩缩容行为详解docs/workloads/realtime/autoscaling.md容器内请求处理、多容器与 CLI 使用docs/workloads/realtime/containers.mdRealtime API 概念总览docs/workloads/realtime/realtime.md端到端部署示例docs/workloads/realtime/example.md仓库自带测试用例如 test/apis/realtime/hello-world/cortex_cpu.yaml、test/apis/realtime/multi-container/cortex_cpu.yaml赞分享后端云原生模型推理服务MLOps人工智能【免费下载链接】cortexProduction infrastructure for machine learning at scale项目地址https://gitcode.com/gh_mirrors/co/cortex点击查看免费下载相关推荐League Akari英雄联盟玩家的智能助手5分钟开启高效游戏体验League Akari英雄联盟玩家的智能助手5分钟开启高效游戏体验 还在为英雄联盟游戏中繁琐的操作和决策压力而烦恼吗League Akari 是一款基于后端云原生模型推理服务MLOps人工智能UFO 配置系统扩展指南从 YAML 自定义字段到类型安全 Schema 的完整实战UFO 配置系统扩展指南从 YAML 自定义字段到类型安全 Schema 的完整实战 本篇指南围绕 UFO 仓库UFO³ / Galaxy的模块化配置系统人工智能AI Agent自主智能体GUI 自动化Agent 编排多智能体RAGSkyServe Service YAML 完整规范从 Readiness Probe 到弹性伸缩的字段级详解SkyServe Service YAML 完整规范从 Readiness Probe 到弹性伸缩的字段级详解 导读 本文聚焦 SkyPilot 中 SkyS后端任务调度MLOps集群管理上一篇Spark Excel 项目常见问题解决方案下一篇Gregwar/Captcha图像效果详解扭曲、线条、背景与透明度的艺术创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 Cortex RealtimeAPI 完整配置指南：从 Pod 到自动扩缩容的 YAML 全字段详解
后端云原生模型推理服务MLOps人工智能【免费下载链接】cortexProduction infrastructure for machine learning at scale项目地址https://gitcode.com/gh_mirrors/co/cortex点击查看免费下载导读本文是 Cortex 项目中 Realtime API实时推理 API配置文件的完整参考手册。Realtime API 以同步方式响应请求并基于在途请求数in-flight requests自动扩缩容适合将无状态容器尤其是机器学习模型以微服务形式对外提供。读完本文你将掌握cortex.yaml中 RealtimeAPI 的每一个配置字段含默认值与取值范围、健康检查与优雅停机的最佳实践以及自动扩缩容背后由 pkg/autoscaler/autoscaler.go 实现的完整决策算法。一、RealtimeAPI 配置总览一个 Realtime API 的配置以 YAML 列表的形式写在部署文件中通常命名为cortex.yaml每个列表项对应一个 API。kind必须为RealtimeAPI其余所有字段均有默认值。完整的配置骨架如下与官方 配置参考 一一对应- name: string # API 名称必填 kind: RealtimeAPI # 必须为 RealtimeAPI必填 pod: # Pod 配置必填 port: int # 请求发送到的端口默认: 8080以 $CORTEX_PORT 导出 max_concurrency: int # 并发送入容器的最大请求数默认: 1 max_queue_length: int # 每个副本允许排队等待的最大请求数默认: 100 containers: # 容器配置至少提供一个容器 - name: string # 容器名称必填 image: string # 容器使用的 Docker 镜像必填 command: list[string] # 入口点不在 shell 中执行默认: 镜像的 ENTRYPOINT args: list[string] # 入口点参数默认: 镜像的 CMD env: map[string:string] # 环境变量字典可选 compute: # 计算资源请求默认值见下文 cpu: string|int|float # CPU 请求默认: 200m gpu: int # GPU 请求默认: 0 inf: int # Inferentia 芯片请求默认: 0 mem: string # 内存请求默认: Null shm: string # 共享内存 /dev/shm 大小默认: Null readiness_probe: # 就绪探针可选 http_get: # HTTP 探针与 tcp_socket、exec 三选一 port: int|string # 访问的端口必填 path: string # HTTP 路径默认: / tcp_socket: # TCP 探针 port: int|string # 访问的端口必填 exec: # 命令探针 command: list[string] # 需以退出码 0 结束的命令必填 initial_delay_seconds: int # 容器启动后延迟探测的秒数默认: 0 timeout_seconds: int # 探测超时秒数默认: 1 period_seconds: int # 探测周期秒数默认: 10 success_threshold: int # 成功判定所需连续成功次数默认: 1 failure_threshold: int # 失败判定所需连续失败次数默认: 3 liveness_probe: # 存活探针可选失败将重启容器 # 结构与 readiness_probe 完全相同http_get / tcp_socket / exec 三选一 # 默认值: initial_delay_seconds0, timeout_seconds1, # period_seconds10, success_threshold1, failure_threshold3 pre_stop: # 容器终止前的 pre-stop 钩子可选 http_get: # HTTP 钩子与 exec 二选一 port: int|string # 访问的端口必填 path: string # HTTP 路径默认: / exec: # 命令钩子 command: list[string] # 需在容器内执行的命令必填 autoscaling: # 自动扩缩容配置默认值见下文 min_replicas: int # 最小副本数默认: 1 max_replicas: int # 最大副本数默认: 100 init_replicas: int # 初始副本数默认: min_replicas target_in_flight: float # 每个副本期望的在途请求数默认: max_concurrency window: duration # 在途请求平均窗口默认: 60s downscale_stabilization_period: duration # 缩容稳定期默认: 5m upscale_stabilization_period: duration # 扩容稳定期默认: 1m max_downscale_factor: float # 单次缩容事件最大比例默认: 0.75 max_upscale_factor: float # 单次扩容事件最大比例默认: 1.5 downscale_tolerance: float # 缩容容忍阈值默认: 0.05 upscale_tolerance: float # 扩容容忍阈值默认: 0.05 node_groups: list[string] # 可运行此 API 的节点组列表默认: 所有节点组 update_strategy: # 滚动更新策略默认值见下文 max_surge: string|int # 更新时可超出期望副本数的最大副本数默认: 25% max_unavailable: string|int # 更新时允许不可用的最大副本数默认: 25% networking: # 网络配置 endpoint: string # API 端点默认: api_name从源码结构看上述每个配置块都可以在 pkg/types/userconfig/api.go 中找到对应的 Go 结构体API、Pod、Container、Probe、PreStop、Compute、Autoscaling、UpdateStrategy、Networking字段名与 YAML 键一一对应且配置键常量集中在 pkg/types/userconfig/config_key.go 中统一管理。下面逐块展开。二、Pod 配置端口、并发与排队pod是 Realtime API 的核心配置块它描述了请求如何进入容器以及每个副本能承受的负载。port默认 8080请求将被发送到容器内监听此端口的 Web 服务器。该值会以环境变量$CORTEX_PORT的形式导出到容器中因此你可以在command、args里通过$(CORTEX_PORT)引用它例如pod: port: 8080 containers: - name: api image: image command: - uvicorn - --host - 0.0.0.0 - --port - $(CORTEX_PORT) - main:app提示在 test/apis/realtime/hello-world/cortex_cpu.yaml 等仓库自带示例中可以看到端口配置与容器镜像的实际搭配用法。max_concurrency默认 1Cortex 并发送入容器处理的最大请求数。如果容器的 Web 服务器如 Uvicorn、Gunicorn本身支持多并发调大该值可显著提升单个副本的吞吐从而在相同负载下减少所需副本总数。max_queue_length默认 100每个副本在超过max_concurrency之后还能排队等待的请求数上限超过部分将以 HTTP 503 直接拒绝。对于耗时长请求的 API调低该值并让客户端在收到 503 后重试可以防止请求长时间积压在个别副本的队列中从而改善跨副本的负载均衡公平性。max_concurrency与max_queue_length会通过pod.cortex.dev/max-concurrency与pod.cortex.dev/max-queue-length注解写入 Kubernetes 对象见 config_key.go由 pkg/proxy 中的代理 sidecar 读取执行——即排队与转发逻辑在代理层完成而非你的业务容器。三、容器配置镜像、启动命令与环境变量pod.containers是必填的列表至少提供一个容器。每个容器支持以下字段字段类型说明namestring容器名称必填同一 Pod 内需唯一imagestringDocker 镜像地址必填commandlist[string]入口点不经 shell 直接执行可用$(CORTEX_PORT)引用环境变量默认继承镜像 ENTRYPOINTargslist[string]入口点参数同样支持$(...)变量默认继承镜像 CMDenvmap[string:string]注入容器的环境变量字典一个 Realtime API 的 Pod 可以包含多个容器如 test/apis/realtime/multi-container/cortex_cpu.yaml 所示但只能有一个容器在目标端口上监听 HTTP 请求可以是任意一个容器。所有容器共享/mnt目录。每个容器的command和args在 Go 侧被定义为字符串数组api.go 中的Command []string/Args []string意味着它们会被直接 exec而不是通过/bin/sh -c运行——因此管道、重定向等 shell 语法不会生效。容器内使用 Cortex CLI/客户端所有容器内都会预置一份指向当前集群的 CLI 配置文件/cortex/client/cli.yaml环境变量CORTEX_CLI_CONFIG_DIR默认指向/cortex/client因此你可以在容器内直接使用 Python 客户端cortex.client()或 CLI 与集群交互无需额外配置。注意客户端版本需与集群版本一致可通过CORTEX_VERSION环境变量获取。四、computeCPU / GPU / Inferentia / 内存 / 共享内存compute定义容器的资源请求每个容器独立配置。Cortex 会累加所有容器的资源请求来调度 Pod并为 Realtime API 自动附加一个代理 sidecar 容器额外请求 100m CPU 与 100Mi 内存见 pkg/consts/consts.go 中的CortexProxyCPU/CortexProxyMem总资源计算逻辑在 api.go 的GetPodComputeRequest中实现。字段默认值说明cpu200mCPU 请求1 单位 CPU 对应 1 个 vCPU支持小数或m后缀如500m 0.5 vCPUgpu0GPU 请求1 单位对应 1 个虚拟 GPUinf0AWS Inferentia 芯片请求1 单位对应 1 个虚拟 Inferentia 芯片memNull内存请求1 单位为 1 字节支持K/M/G/T十进制后缀及Ki/Mi/Gi/Ti二进制后缀shmNull共享内存/dev/shm大小如64Mi、1Gi用于多进程间共享数据典型场景是 PyTorch DataLoader 的 num_workerscpu与mem在源码中被解析为 Kubernetes 的resource.Quantity类型api.go 中CPU *k8s.Quantity因此支持 Kubernetes 资源量表示的全部语法。CPU 默认200m与代理 sidecar 的100m之和为300m多容器时 Cortex 会取所有容器请求的总和作为 Pod 的调度依据。五、健康检查readiness_probe / liveness_probe / pre_stop探针的三种探测方式readiness_probe与liveness_probe结构相同都支持三种互斥的探测方式http_get、tcp_socket、exec只能三选一http_get请求容器内指定端口与路径响应状态码为 200 即视为成功。tcp_socket指定端口能够接受连接即视为成功。exec在容器内执行命令直接 exec不走 shell工作目录为容器根目录/退出码为 0 即视为成功。两者的通用时序参数及默认值参数默认值说明initial_delay_seconds0容器启动后延迟多少秒再开始探测timeout_seconds1单次探测的超时秒数period_seconds10探测周期秒success_threshold1判定成功所需的连续成功次数failure_threshold3判定失败所需的连续失败次数就绪探针readiness_probe作用只有 Pod 内所有容器的就绪探针都成功流量才会被送入该 Pod。默认情况下容器一旦绑定端口就会开始接收流量但某些 Web 服务器如tiangolo/uvicorn-gunicorn-fastapi可能在 worker 就绪前就监听端口。此时应实现就绪检查。最常用的做法是在 Web 服务里加一个返回 200 的/healthz路由并配置readiness_probe: http_get: port: 8080 path: /healthz存活探针liveness_probe作用探测失败时容器会被自动重启用于自愈死锁或泄漏的进程。pre_stop 钩子作用容器终止前执行的钩子用于优雅下线——例如在流量摘除后、进程退出前通知注册中心注销节点、冲刷缓冲区或等待在途请求完成。支持http_get向指定端口/路径发请求与exec执行命令两种方式二选一。Cortex 的滚动更新会配合该钩子完成优雅的流量迁移。在 api.go 中探针被建模为Probe结构体含HTTPGet、TCPSocket、Exec与五个时序字段与 Kubernetes 原生探针语义一一对应。六、autoscaling基于在途请求的自动扩缩容Realtime API 的自动扩缩容独立于每个 API 运行。Cortex 在 pkg/autoscaler/autoscaler.go 中为每个 API 启动一个每 10 秒触发一次的定时任务AutoscalingTickInterval 10 * time.Second定义于 pkg/types/spec/validations.go读取 pkg/autoscaler/realtime_scaler.go 中通过 PromQL 聚合得到的平均在途请求数再结合本节的配置参数计算目标副本数。核心指标 target_in_flighttarget_in_flight默认pod 配置中的max_concurrency是自动扩缩容的决策指标表示每个副本期望的在途请求数——即已发送给副本但尚未收到响应的请求数包含正在处理的和排队中的请求。扩缩容的核心公式desired replicas sum(in-flight requests across all replicas) / target_in_flight例如将target_in_flight设为max_concurrency默认行为会让集群调整副本数使得请求平均无需排队即可被立即处理。该公式在 autoscaler.go 中的实现为rawRecommendation : *avgInFlight / *autoscalingSpec.TargetInFlight recommendation : int32(math.Ceil(rawRecommendation))副本上下限与初始值字段默认值说明min_replicas1副本数下界支持缩容到 0实验性scale-to-zeromax_replicas100副本数上界init_replicasmin_replicas部署时的初始副本数平滑与稳定参数window默认60s在途请求的平均时间窗口。窗口越长自动扩缩容对流量变化的反应越慢。由于在途请求每 10 秒计算一次window必须是 10 秒的倍数该约束由 validations.go 强制校验。downscale_stabilization_period默认5m在此周期内不会缩容到历史最高建议值之下。自动扩缩容每 10 秒给出一次建议最终取当前建议与该周期内所有建议的最大值中较大的作为缩容目标。调大该值可让集群对流量下降反应更慢减少抖动thrashing。upscale_stabilization_period默认1m与上对应在此周期内不会扩容超过历史最低建议值之上。调大该值可让集群对流量上升反应更慢。max_downscale_factor默认0.75单次缩容事件的最大比例。例如设为0.5且当前 10 个副本时自动扩缩容不会建议少于 5 个副本。调大可让集群在流量骤降时更快收缩。max_upscale_factor默认1.5单次扩容事件的最大比例。例如设为10且当前 5 个副本时不会建议超过 50 个副本。downscale_tolerance默认0.05低于当前副本数一定比例之内的缩容建议不会被执行。例如容忍度为0.1、当前 20 个副本时建议 1819 个副本不会触发缩容。upscale_tolerance默认0.05高于当前副本数一定比例之内的扩容建议不会被执行。在 autoscaler.go 中一次完整决策的先后顺序是计算原始建议 → 应用上下容忍阈值 → 应用单次缩放因子上限且始终允许加减 1 个副本→ 夹取到min_replicas/max_replicas之间 → 记录历史建议 → 依据稳定期约束得出最终副本数 → 若与当前副本数不同则调用scaler.Scale执行变更。scale-to-zero 的实现细节当建议副本数为 0 时realtime_scaler.go 的Scale方法会把流量路由切换到 activator 组件通过 Istio VirtualService 权重调整并将 Deployment 副本数置 0当有请求唤醒时再切回服务路由并等待至少 1 个副本就绪waitForReadyReplicas。这就是 Realtime API 支持避免冷启动与缩容到零的原因。实例级扩缩容除副本外Cortex 还会根据所有 API 的资源请求总量自动上下调整节点实例数每个节点组的实例数保持在安装时配置的min_instances与max_instances之间可通过cortex cluster configure修改。过配置overprovisioning与响应速度过配置如果应用对流量尖峰敏感、或新副本创建耗时较长可以把target_in_flight设得比预期并发更低以维持额外冗余容量。例如副本可高效处理 2 个并发请求、平均收到 8 个并发请求时默认target_in_flight: 2会维持 4 个副本8/2若想冗余 25%设为1.6则会维持 5 个副本8/1.6。响应延迟在默认window60s与upscale_stabilization_period1m下从流量上升到新增副本被请求可能需要约 2 分钟随后还需等待新实例被 AWS 拉起、拉取镜像与初始化。若希望尽可能快的响应可将window与upscale_stabilization_period分别设为最小允许值10s与0s。更详细的行为说明可参考 自动扩缩容文档。七、node_groups 与 update_strategynode_groups默认所有节点组以列表形式指定该 API 可被调度到的节点组如 GPU 节点组、Inferentia 节点组。不配置时所有节点组均可用。资源类型GPU/INF通常与节点组的选择配套使用例如 test/apis/realtime/text-generator/cortex_gpu.yaml 中同时声明了 GPU 资源与对应的节点组。update_strategy滚动更新控制新副本替换旧副本的方式对应 Kubernetes Deployment 的滚动更新策略字段默认值说明max_surge25%更新期间可超出期望副本数的最大副本数可写绝对数如5或百分比如10%设为0可禁用滚动更新max_unavailable25%更新期间允许同时不可用的最大副本数同样支持绝对数或百分比合理的max_surge/max_unavailable组合决定了发布时的可用性与速度希望零中断发布时可保留默认值追求快速发布而允许短暂容量抖动时可调大max_surge。八、networking端点定制networking.endpoint用于自定义 API 的对外端点路径默认等于 API 名称。例如名为hello-world的 API 默认暴露在负载均衡器地址/hello-world若设置endpoint: v1/classify则请求路径随之改变。支持子路径转发请求load_balancer_url/hello-world/subpath会被路由到容器 Web 服务器的/subpath。注意endpoint在集群内必须是唯一的且不支持大写字母或下划线。九、一份完整的实战配置示例结合上述全部字段下面是一个完整的可运行示例镜像为仓库 示例文档 中的 hello-world FastAPI 应用# cortex.yaml - name: hello-world kind: RealtimeAPI pod: port: 8080 max_concurrency: 4 max_queue_length: 200 containers: - name: api image: AWS_ACCOUNT_ID.dkr.ecr.us-east-1.amazonaws.com/hello-world command: - uvicorn - --host - 0.0.0.0 - --port - $(CORTEX_PORT) - main:app env: LOG_LEVEL: info compute: cpu: 500m mem: 512Mi readiness_probe: http_get: port: 8080 path: /healthz initial_delay_seconds: 5 period_seconds: 10 liveness_probe: http_get: port: 8080 path: /healthz initial_delay_seconds: 10 period_seconds: 30 pre_stop: exec: command: [/bin/sh, -c, echo draining /tmp/drain] autoscaling: min_replicas: 2 max_replicas: 20 init_replicas: 2 target_in_flight: 4 window: 30s downscale_stabilization_period: 5m upscale_stabilization_period: 1m max_downscale_factor: 0.75 max_upscale_factor: 1.5 node_groups: - cpu-group update_strategy: max_surge: 25% max_unavailable: 0 networking: endpoint: hello-world将上述文件保存为cortex.yaml后在集群目录中执行cortex deploy即可部署cortex get --watch等待就绪cortex get hello-world获取端点地址随后即可用curl向http://负载均衡器地址/hello-world发送请求。十、相关参考配置字段的 Go 结构体与默认值处理pkg/types/userconfig/api.go配置键常量与 Kubernetes 注解名pkg/types/userconfig/config_key.go自动扩缩容决策算法实现pkg/autoscaler/autoscaler.goRealtime 扩缩容执行与 scale-to-zero 路由切换pkg/autoscaler/realtime_scaler.go自动扩缩容行为详解docs/workloads/realtime/autoscaling.md容器内请求处理、多容器与 CLI 使用docs/workloads/realtime/containers.mdRealtime API 概念总览docs/workloads/realtime/realtime.md端到端部署示例docs/workloads/realtime/example.md仓库自带测试用例如 test/apis/realtime/hello-world/cortex_cpu.yaml、test/apis/realtime/multi-container/cortex_cpu.yaml赞分享后端云原生模型推理服务MLOps人工智能【免费下载链接】cortexProduction infrastructure for machine learning at scale项目地址https://gitcode.com/gh_mirrors/co/cortex点击查看免费下载相关推荐League Akari英雄联盟玩家的智能助手5分钟开启高效游戏体验League Akari英雄联盟玩家的智能助手5分钟开启高效游戏体验 还在为英雄联盟游戏中繁琐的操作和决策压力而烦恼吗League Akari 是一款基于后端云原生模型推理服务MLOps人工智能UFO 配置系统扩展指南从 YAML 自定义字段到类型安全 Schema 的完整实战UFO 配置系统扩展指南从 YAML 自定义字段到类型安全 Schema 的完整实战 本篇指南围绕 UFO 仓库UFO³ / Galaxy的模块化配置系统人工智能AI Agent自主智能体GUI 自动化Agent 编排多智能体RAGSkyServe Service YAML 完整规范从 Readiness Probe 到弹性伸缩的字段级详解SkyServe Service YAML 完整规范从 Readiness Probe 到弹性伸缩的字段级详解 导读 本文聚焦 SkyPilot 中 SkyS后端任务调度MLOps集群管理上一篇Spark Excel 项目常见问题解决方案下一篇Gregwar/Captcha图像效果详解扭曲、线条、背景与透明度的艺术创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考