AWS 发布 llama.cpp 专用深度学习容器，可在 SageMaker AI 上部署决策模型并返回选项概率
来源AWS Machine Learning查看原文
速览
- AWS 为 llama.cpp 提供官方 DLC，GGUF 模型可直接在 SageMaker AI 上托管，无需自建容器
- 标准路径走 OpenAI 兼容接口，适合需要生成文本的场景
- SemIf 路径返回选项概率而非生成文本，适合路由、分级、策略判定等决策任务
- SemIf 需要末位 logits 和状态访问，因此必须构建子镜像，不能直接用标准 DLC
- 231 个 JevBench 任务上，4B 模型 CPU 准确率 77.5%、GPU 77.9%，两者基本持平
- GPU 的主要收益在延迟：p50 快 4.9 倍，p95 快 32.2 倍
- 2B 与 0.8B 模型准确率降至 66.7% 和 58.4%，AWS 仍以 4B 为默认
- AWS 明确提醒：去掉答案 token 生成不等于去掉模型推理，仍需处理完整 state、question 和选项描述
- 授权与确定性业务规则应留在模型之外，模型概率需经应用层阈值和回退校验
- CPU 适合后台、离线、低吞吐场景，GPU 适合交互式决策和严格尾延迟目标
AWS 在官方博客中介绍了基于 llama.cpp 的 AWS Deep Learning Container（DLC），用于在 Amazon SageMaker AI 上部署「决策模型」——即对一组预先声明的选项打分，而不是生成自由文本。标准路径下，用户把 GGUF 模型打包成 model.tar.gz 放到 S3，直接引用已发布的 DLC 镜像，容器会自动找到 /opt/ml/model 下的第一个 .gguf 文件，把 POST /invocations 映射到 llama-server 的 /v1/chat/completions，并通过 SM_LLAMA_CPP_* 环境变量向 llama.cpp 传参，从而以 OpenAI 兼容格式提供 chat completions。由于 llama-server 的 HTTP API 不暴露 SemIf 所需的末位 logits 和状态操作，结构化决策路径改用 AWS CodeBuild 构建子镜像并推送到 Amazon ECR，保留 DLC 编译好的 CPU 或 CUDA 库，只替换入口为 SageMaker 兼容适配器。SemIf（原 OpenJev）接收调用方定义的 id、非结构化 state、question 和有序 options 列表，返回 option_ids、probabilities 和原始 option_logits，不生成答案 token。AWS 用 231 个公开 JevBench 任务做了基准测试：Qwen3.5-4B Q4_K_M 在 ml.c6i.8xlarge（32 线程）上 231/231 有效响应、准确率 179/231（77.5%）、客户端 p50 1.715 秒、p95 19.291 秒；在 ml.g6e.xlarge 全 GPU 卸载下 231/231 有效、准确率 180/231（77.9%）、p50 0.352 秒、p95 0.599 秒，p50 快 4.9 倍、p95 快 32.2 倍。更小的 2B 和 0.8B 模型准确率分别只有 66.7% 和 58.4%，因此示例仍以 4B Q4_K_M 为质量优先默认值。
关键事实
- AWS 发布 llama.cpp 专用 DLC，可在 SageMaker AI 上以 CPU 或 GPU 托管量化模型，标准路径通过 InvokeEndpoint 提供 OpenAI 兼容 chat completions
- 标准路径无需 Dockerfile 或 ECR：把模型打包为 model.tar.gz 放 S3，容器自动查找 /opt/ml/model 下第一个 .gguf 文件，并把 POST /invocations 映射到 llama-server 的 /v1/chat/completions
- 结构化决策路径用 AWS CodeBuild 构建子镜像并存入 Amazon ECR，保留 DLC 的 CPU 或 CUDA 库，仅把入口替换为 SageMaker 兼容适配器
- SemIf（原 OpenJev）接收 id、state、question 和有序 options，返回 option_ids、probabilities 与原始 option_logits，不生成答案 token
- 基准测试使用 231 个公开 JevBench 任务串行发送到单个 CPU 端点和单个 GPU 端点
- Qwen3.5-4B Q4_K_M 在 ml.c6i.8xlarge、32 线程下：231/231 有效响应，准确率 179/231（77.5%），客户端 p50 1.715 秒，p95 19.291 秒
本站视角
这件事的直接受益者是在 AWS 上做 agent 编排、工单路由、风控策略判定的团队，尤其是那些已经在用 GGUF 量化模型、但苦于要自己维护推理容器的中小团队。过去要在 SageMaker 上跑 llama.cpp，通常得自己写 Dockerfile、处理 /ping 与 /invocations 契约、再想办法把 logits 暴露出来；现在标准路径可以直接引用官方 DLC，只有需要末位 logits 的场景才需要构建子镜像，工程成本明显下降。 我们的判断是：这次发布的价值主要在「托管化」而不是「能力突破」。SemIf 这类决策模型本身不是新东西，Jev、Kev、Strands Decider 2B 已经在做类似的事，AWS 做的是把其中一条实现路径产品化，并给出可复现的基准。真正值得关注的是它把「不生成 token、只读末位 logits」当作一等公民来支持——这代表云厂商开始承认，相当一部分生产负载根本不需要自由文本生成，需要的是封闭选项上的概率。对国内做 Agent 的团队来说，这个思路可以直接借鉴：与其让模型输出 JSON 再解析、再处理格式错误，不如把选项固定下来只取概率，配合应用层阈值和回退，工程上更稳。 需要观察和警惕的地方有三点。第一，基准只有 231 个任务、单一模型家族（Qwen3.5-4B 及 2B/0.8B），且全部来自公开 JevBench，样本量和任务分布都有限，77.5% 与 77.9% 的差距在统计上几乎没有意义，AWS 自己也承认这是运行时差异，读者不应把 GPU 卸载理解为质量提升。第二，AWS 明确写了测量包含网络延迟、不构成服务保证，p95 19.291 秒 这个 CPU 数字在实际生产里相当难看，说明 CPU 路径只适合非延迟敏感场景，选型时不能只看 p50。第三，SemIf 适配器围绕单个有状态 llama.cpp 上下文串行化打分，并发要靠增加端点实例来横向扩展，这意味着高并发下的成本曲线可能比预期陡，AWS 建议先测量再扩容，但没有给出并发与成本的量化数据。此外，SemIf 是第三方开源项目（原 OpenJev），并非 AWS 自研，其长期维护与生产成熟度需要自行评估。
背景与影响
决策模型是一类与聊天模型不同的用法：应用在请求时声明一组允许的选项，模型只负责根据非结构化上下文给这些选项打分，输出概率分布。这类模式常见于工单路由、事件优先级判定、策略结果检查、agent 动作选择等场景，好处是输出空间封闭、可用稳定 ID 做阈值和回退，不必解析模型生成的散文。SemIf 原名为 OpenJev，与 TypeSafe 的 Jev、面向 TypeSafe API 兼容的 Kev、以及面向 agent 工作流的 Strands Decider 2B 属于同一类实现。AWS 这次把 llama.cpp 的托管路径补齐，并给出 CPU 与 GPU 两种部署形态和一组公开基准，实际上是在把「小模型 + 量化 + 结构化输出」这条路线纳入 SageMaker AI 的标准交付方式。对使用 SageMaker 的团队来说，这意味着不必再为 GGUF 模型自建推理容器；对做 agent 与工作流编排的团队来说，SemIf 这类接口提供了一种比「让模型输出 JSON 再解析」更可控的决策原语。需要注意的是，AWS 在文中明确说明基准数据包含网络延迟、不构成服务保证，且 CPU 与 GPU 镜像使用不同 llama.cpp 构建、在 6 个困难任务上预测不同，因此那一题的准确率差异被 AWS 自己定性为运行时差异而非质量提升。
本文由 AI 辅助整理自公开信源，事实部分以原文为准；「本站视角」一节为编辑部判断，欢迎指正。版权归原作者所有，如有异议请联系我们。