AWS发布llama.cpp决策模型部署方案，SemIf扩展可返回选项概率
AWS Machine Learning博客介绍在Amazon SageMaker AI上部署llama.cpp的两种路径：直接用DLC提供OpenAI兼容聊天补全，或构建SemIf子镜像，对预先声明的选项返回概率而非生成文本。帖子给出CPU与GPU的JevBench基准数据，并说明授权与业务规则应留在模型之外。
AI解读：AWS作者Jyothirmai Kottu在AWS Machine Learning博客中说明，llama.cpp的AWS Deep Learning Container（DLC）可在SageMaker AI上托管量化决策模型，支持CPU或GPU。
标准路径直接引用已发布的DLC镜像，把模型打包为model.tar.gz放入S3，容器找到 /opt/ml/model下第一个 .gguf文件，将POST /invocations映射到llama-server的 /v1/chat/completions，并通过SM_LLAMA_CPP_* 环境变量传递参数。
帖子将SemIf（原OpenJev）作为扩展路径：由于llama-server HTTP API不暴露SemIf所需的末位logits和状态操作，需要用AWS CodeBuild构建保留DLC编译库、替换入口为SageMaker兼容适配器的子镜像，并存入Amazon ECR。
SemIf请求包含调用方定义的ID、非结构化state、question和有序options列表，响应按同序返回option_ids、probabilities、option_logits，以及prompt、计时和被固定的模型元数据。
作者称，该模式适用于在请求时定义允许选项、需要模型解读非结构化上下文的场景，例如把工单路由到队列、从已知集合中抽取一个值、分配事件优先级、核对政策结果或选择智能体动作。帖子明确要求把授权和确定性业务规则留在模型之外，并在把模型概率当作运营置信度之前进行验证。
帖子给出的基准仅针对SemIf扩展，不适用于文本生成端点。用同一批 231 个公开JevBench任务串行发往一个CPU端点和一个GPU端点：Qwen3.5-4B Q4_K_M在ml.c6i.8xlarge、32 线程、llama-cpp:server-sagemaker-cpu-v1下，有效响应 231/231，准确率 179/231（77.5%），客户端p50 1.715秒、p95 19.291秒；在ml.g6e.xlarge、完整GPU卸载、llama-cpp:server-sagemaker-cuda-v1下，有效响应 231/231，准确率 180/231（77.9%），p50 0.352秒、p95 0.599秒。
作者据此称GPU端点p50快 4.9 倍、p95快 32.2 倍，并说明CPU与GPU镜像使用不同llama.cpp构建，在六个困难任务上产生不同预测，这一个答案的准确率差异应视为运行时差异，而非GPU卸载提升模型质量的证据。
作者称较小模型降低了中位延迟，但 2B和 0.8B候选准确率分别为 66.7% 和 58.4%，因此代码示例保留 4B Q4_K_M作为质量优先的默认值。这些测量包含网络延迟，且不构成服务保证。作者建议对延迟不敏感的后台、离线或低吞吐工作负载使用CPU，对交互式决策、长提示或严格尾部延迟目标使用GPU；并建议保持state和选项描述简洁、把共享同一state的决策合并为一个请求、按并发扩展端点实例。
帖子列出前置条件：AWS账户、部署区域内的S3桶、Python 3.10或更高版本、Git、AWS CLI、用于可选SemIf扩展的专用CodeBuild服务角色、SageMaker AI可代入的IAM角色，以及SageMaker AI、Amazon ECR、Amazon S3、CodeBuild、IAM pass-role和Amazon CloudWatch Logs的权限，外加兼容的x86 CPU或NVIDIA GPU实时端点配额。
作者还说明共享state评分会复用公共提示前缀，适配器在避免无界排队时返回可重试的HTTP 503。
AWS Machine Learning博客发布一篇技术文章，介绍如何在Amazon SageMaker AI上使用llama.cpp部署决策模型。作者Jyothirmai Kottu称，该方案提供在CPU或GPU基础设施上托管量化模型的托管路径，属于AWS生成式AI推理专用深度学习容器（DLC）系列文章的后续，此前文章涉及WhisperX和vLLM-Omni第一、二部分。
标准路径：用llama.cpp DLC提供OpenAI兼容聊天补全
文章给出的标准路径直接引用已发布的DLC镜像：把模型打包为model.tar.gz放入Amazon S3，容器会找到 /opt/ml/model下第一个 .gguf文件，将POST /invocations映射到llama-server的 /v1/chat/completions，并接收SM_LLAMA_CPP_* 环境变量传给llama.cpp参数。作者称该路径不需要Dockerfile或ECR仓库。
请求使用OpenAI Chat Completions schema，包含messages数组（role和content）以及max_tokens、stream等生成控制；响应使用OpenAI兼容的choices数组，生成的文本从choices[0].message.content读取。文本生成示例使用CPU DLC和固定CPU实例。
- 打包模型为S3中的model.tar.gz，引用已发布DLC镜像即可。
- 容器查找 /opt/ml/model下第一个 .gguf文件。
- POST /invocations映射到llama-server的 /v1/chat/completions。
- 也可配置SM_LLAMA_CPP_HF_REPO和SM_LLAMA_CPP_HF_FILE，在端点有网络出口时从Hugging Face下载GGUF文件。
- 应选择server-sagemaker-cpu-v1或server-sagemaker-cuda-v1镜像，而非对应的EC2镜像。
SemIf扩展：返回声明选项的概率而非生成文本
文章将SemIf（原名OpenJev）描述为结构化决策路径。由于llama-server的HTTP API不暴露SemIf使用的末位logits和状态操作，该路径需要用AWS CodeBuild构建子镜像并存入Amazon ECR。子镜像保留DLC的CPU或CUDA编译库，但把入口替换为SageMaker兼容适配器。
SemIf请求不用聊天消息，而是包含调用方定义的ID、非结构化state、question和有序的允许选项列表，每个选项带有id和description。响应按相同顺序返回option_ids、probabilities和原始option_logits，并附带prompt、计时和被固定的模型元数据。文章称，使用稳定选项ID，应用可施加阈值、回退和政策检查，而无需解析生成的散文。
- SemIf示例请求：decision.id为support-route，state为客户收不到密码重置邮件，question为应由哪个队列处理，options为account_access和billing。
- 示例响应保留选项顺序，返回条件概率、原始logits、token和prompt元数据以及固定模型身份；示例中probabilities为 0.99996、0.00003、0.00001。
- SemIf归入一类更广的决策模型，从非结构化状态为应用定义的结果打分；文章提到的其他实现包括Jev、TypeSafe的决策模型和 /v1/systemone API、面向TypeSafe API兼容的模型服务器Kev，以及面向智能体工作流、带校准输出的Strands Decider 2B。
适用场景与作者给的使用限制
作者称，当应用在请求时定义允许选择并需要模型解读非结构化上下文时，可使用该模式，例如把案例路由到队列、从已知集合中抽取一个值、分配事件优先级、检查政策结果或选择智能体动作。
文章要求把授权和确定性业务规则保留在模型之外，并在把模型概率视为运营置信度之前进行验证。作者还指出，移除答案token生成并不移除模型推理：模型仍在SemIf读取最终logits之前处理完整state、question和选项描述。建议保持提示聚焦，并在生产使用前用应用自身的标注决策评估所选模型。
- 仅在需要直接logits和状态访问等接口不具备的行为时构建子镜像。
- 共享同一state的决策可合并为一个请求，以复用公共提示前缀。
- 适配器在其有状态的llama.cpp上下文之外返回可重试的HTTP 503，而不是允许无界队列。
基准数据：231 个JevBench任务上的CPU与GPU对比
文章给出的基准仅适用于SemIf扩展，不适用于文本生成端点。基准把同一批 231 个公开JevBench任务串行发往一个CPU端点和一个GPU端点。作者称模型规模、量化、提示长度、运行时和CPU线程数都会影响每次决策。
CPU配置为Qwen3.5-4B Q4_K_M、ml.c6i.8xlarge、32 线程、llama-cpp:server-sagemaker-cpu-v1：有效响应 231/231，准确率 179/231（77.5%），客户端p50 1.715秒、p95 19.291秒。GPU配置为Qwen3.5-4B Q4_K_M、ml.g6e.xlarge、完整GPU卸载、llama-cpp:server-sagemaker-cuda-v1：有效响应 231/231，准确率 180/231（77.9%），p50 0.352秒、p95 0.599秒。
作者据此称GPU端点相比CPU配置在p50上快 4.9 倍、p95上快 32.2 倍。文章说明CPU与GPU镜像使用不同llama.cpp构建，在六个困难任务上产生不同预测，因此这一个答案的准确率差异应视为运行时差异，而不是GPU卸载提高模型质量的证据。文章还称较小模型降低了中位延迟，但 2B和 0.8B候选准确率分别为 66.7% 和 58.4%，因此示例保留 4B Q4_K_M作为质量优先的默认值。这些测量包含网络延迟，且不构成服务保证。
- 示例使用SageMaker AI实例池按优先级列出兼容GPU类型：g6e、g6、g5、g4dn。
- SageMaker选择了ml.g6e.xlarge，启动日志确认llama.cpp将全部 34 个模型层卸载到NVIDIA L40S。
- 实例池是有序放置回退，不是推理负载均衡。
- 作者建议CPU用于后台、离线或低吞吐且对延迟不敏感、可容忍数秒响应时间的工作负载；GPU用于交互式决策、长提示或严格尾部延迟目标。
前置条件与部署步骤要点
文章列出的前置条件包括：AWS账户和部署区域内的S3桶；Python 3.10或更高版本、Git和AWS CLI；用于可选SemIf扩展的专用CodeBuild服务角色；SageMaker AI可代入的IAM角色；SageMaker AI、Amazon ECR、Amazon S3、CodeBuild、IAM pass-role和Amazon CloudWatch Logs的权限；以及兼容的x86 CPU或NVIDIA GPU SageMaker实时端点配额。文章建议在创建端点前查看SageMaker AI定价。
- 克隆代码示例仓库并安装依赖，设置AWS_REGION、ARTIFACT_BUCKET、CODEBUILD_ROLE_ARN、SAGEMAKER_ROLE_ARN等部署变量。
- 用CodeBuild打包固定版本的GGUF模型和tokenizer；build在model-manifest.json中记录来源修订和校验和，若GGUF校验和与已验证值不同则停止。
- 部署标准端点时解析摘要固定的server-sagemaker-cpu-v1镜像，示例使用ml.c6i.2xlarge。
- 构建SemIf子镜像时CPU使用默认Dockerfile，GPU使用Dockerfile.gpu；部署脚本拒绝可变镜像标签。
- SemIf CPU配置使用ml.c6i.8xlarge、32 线程；GPU图像提供有序实例池并请求完整模型卸载。
清理与结论
文章提供清理脚本删除明确命名的SageMaker AI端点、端点配置和模型，并提示在不再需要时删除CodeBuild项目、ECR仓库、S3中的模型和源对象、日志以及专用IAM角色。
- 作者总结称，AWS DLC for llama.cpp为在SageMaker AI上跨CPU和GPU实例提供托管基础，可加载GGUF模型并提供OpenAI兼容聊天补全，需要直接logits和模型状态操作时可用SemIf适配器扩展。
- 文章建议按工作负载选择CPU或GPU，并参考代码示例、DLC文档和SageMaker AI自定义推理容器契约调整部署。