Azure ML部署Web服务端点失败卡在PodInitializing状态排障咨询

参考相关教程尝试将ML模型部署为Azure ML平台上的Web服务。
目前模型已成功上传（如图1所示），但创建Web服务端点时部署失败（如图2所示）。


当前“Deployment logs（部署日志）”标签页仅展示如下简短信息：

container "predict" in pod "wk-caas-f62cbd87d3e3400a8fffc23a20f0744e-8c212518c5f6b7404584eb194515f3a1-pod" is waiting to start: PodInitializing

本次部署使用的相关资源包括：模型文件、入口脚本（Entry script）、Conda环境配置YAML文件、完整部署日志。

Pod长期停在PodInitializing状态，说明故障出在predict容器启动前的初始化阶段，和容器内推理服务本身的运行逻辑无关，按以下优先级排查：

• 第一步先拉取全量初始化日志，不要只看页面默认展示的短日志
  进入Azure ML工作室端点详情页，选中对应部署项，选择下载完整日志包，重点排查两个日志文件：azureml-logs/init-inference-server.log记录初始化阶段的服务启动流程，azureml-logs/conda-install.log记录Conda环境的安装过程，绝大多数初始化卡住问题都会在这两个文件中输出明确报错。初始化阶段日志会持续写入，不需要等Pod状态变更，卡住超过10分钟即可直接拉取日志分析。
• 优先排查Conda环境配置错误
  这是该类故障最高发的原因。部署初始化阶段会单独根据conda_env.yml创建运行环境，若文件中存在不存在的包版本、依赖冲突、默认源无法拉取的第三方包，会直接卡在环境安装步骤，无法进入后续容器启动流程。
  修复方式：在本地使用和Azure ML部署环境同大版本的Python，执行conda env create -f conda_env.yml验证环境是否能正常创建，删除存在冲突的版本约束，尽量使用Azure ML默认源内置的包，不要随意添加第三方Conda源；大体积Python包统一放到配置的pip段，避免用latest标签，尽量固定明确的小版本号。
• 排查入口脚本与模型加载逻辑错误
  入口脚本scoring.py的init()函数如果存在路径错误、死循环、耗时超长的操作，也会导致初始化流程卡住。
  本地验证方法：将模型文件与scoring.py放到同一目录，手动执行脚本调用init()函数，验证模型是否能正常加载、是否存在依赖缺失。注意Azure ML部署时模型会被挂载到AZUREML_MODEL_DIR环境变量对应的路径下，禁止写本地绝对路径，必须通过os.getenv('AZUREML_MODEL_DIR')拼接模型文件的相对路径，这是新手部署时最常见的路径配置错误。
• 排查资源配额与基础镜像问题
  若选择的部署SKU配置过低（比如低于2核4G），镜像解压、依赖安装过程中出现内存不足会触发系统杀进程，表现就是长期卡在初始化状态，可以先选用2核4G以上的SKU测试部署，成功后再按需缩容。
  若使用了自定义基础镜像，需要确认镜像地址公网可访问、镜像标签配置正确，Azure ML无法拉取自定义镜像时也会卡在初始化阶段。如果使用Azure ML官方默认推理镜像，选择和训练模型时所用SDK版本一致的镜像即可，不要随意修改镜像版本号。
• 最小化部署定位问题
  如果以上步骤都没找到问题，先将部署配置简化到最小可用版本：把scoring.py改为最简逻辑，init()函数不加载任何模型，run()函数直接返回固定测试字符串；conda_env.yml仅保留python、azureml-defaults、numpy、pandas几个核心依赖，先验证最小端点可以正常部署，再逐步添加模型、其他业务依赖，逐段定位导致初始化卡住的具体配置项。

内容的提问来源于stack exchange，提问作者ammfat