AI21 Jamba

AI21 Jamba 是由成立于 2017 年的以色列 AI 研究公司 AI21 Labs 开发的大型语言模型系列。与其他所有主流的开放权重 LLM 不同，Jamba 没有采用纯 Transformer 架构。相反，它将 Mamba 状态空间模型 (SSM) 层与传统的 Transformer 注意力层以大约 1:7 的比例交替排列，并在每两个块应用混合专家 (MoE) 路由。这种设计的实际效果是：在 256K Token 时，其 KV 缓存比 Mixtral 8x7B 小 8 倍，比同类的基于 Llama 的模型小 32 倍，从而在长上下文推理速度上提升了 2.5 倍，同时又没有牺牲纯 SSM 模型在规模化时会丢失的检索准确性。

于 2024 年 8 月 22 日发布的 Jamba 1.5 代包含两个开放权重变体：Jamba 1.5 Mini（12B 激活参数，总计 52B 参数）和 Jamba 1.5 Large（94B 激活参数，总计 398B 参数）。两者均支持 256K Token 上下文窗口、函数调用、结构化 JSON 输出，以及通过内置的 documents 参数为 RAG 管道提供有根据的生成（grounded generation）。该 API 可通过 AI21 Studio 以及包括 AWS Bedrock、Azure AI、Google Cloud Vertex AI 和 NVIDIA NIM 在内的主要云平台获取。开放权重模型托管在 Hugging Face 上，遵循允许研究和商业用途的 Jamba Open Model License。最新的 API 模型（Jamba Mini 1.7、Jamba Large 1.7）延续了相同的架构，并在指令遵循和基础准确性方面进行了改进。

Jamba 概览（2024 年 8 月）

2024 年 8 月 22 日发布的 Jamba 1.5 是非 Transformer 架构首次在此规模上达到生产级质量。AI21 同时发布了两款模型：Jamba 1.5 Mini 和 Jamba 1.5 Large。Large 模型在 Arena Hard 上的得分为 65.4，在发布时超越了该基准测试中的 Llama 3.1 70B 和 Llama 3.1 405B。在 256K 的 RULER 长上下文基准测试中，Large 模型的准确率达到了 93.9%，这证明了其上下文窗口绝非营销噱头。AI21 还推出了 ExpertsInt8，这是一种专有的量化技术，使 Jamba 1.5 Large（总计 398B 参数）能够适配并在单个 8 x 80GB H100 GPU 节点上运行。

截至 2026 年 4 月，当前的模型阵容包括 Jamba Mini 1.7 和 Jamba Large 1.7（分别于 2025 年 7 月和 8 月发布），以及用于端侧任务的 Jamba Reasoning 3B，和面向企业订阅的 Jamba 2 系列。Hugging Face 上的 Jamba 1.5 模型的知识截止日期为 2024 年 3 月 5 日。API 模型拥有更新的训练数据。所有模型均支持英语、西班牙语、法语、葡萄牙语、意大利语、荷兰语、德语、阿拉伯语和希伯来语。

Jamba 的真正优势所在

Jamba 的真正优势在于处理文档密集型企业工作流时的长上下文吞吐量。当任务需要一次性处理 200 页的合同、400 页的技术手册或多会话的客户支持记录时，Jamba 的架构能够以比同类 Transformer 模型更低的 Token 成本和更低的推理延迟提供这种能力。其有根据的生成（grounded generation）功能允许您直接在聊天模板中传递 documents 列表，专为无需分块（chunking）的 RAG 设计。正是在这种用例下，Jamba 在每 Token 成本上击败了 Llama 和 Mistral。

对于批处理 API 工作负载，Jamba Mini 1.7 每百万输入 Token $0.20 的价格大幅低于 GPT-4o（$2.50/1M）和 Claude Sonnet（$3.00/1M）。对于运行高容量文档处理且输入始终很长的组织来说，Jamba 在成本上的优势显而易见。

“在长上下文处理方面，Jamba Large 每百万输入 Token $2 的价格与 Claude Sonnet 4.6（$3/M）和 GPT-4o（$2.50/M）相比极具竞争力。”——AI Tools Atlas 评论，2026 年

于 2025 年发布的 Jamba Reasoning 3B 针对的是对延迟要求极高且无法满足完整 Jamba 1.5 Large 权重需求的端侧部署。AI21 报告称，在其内部基准测试中，该模型比同类紧凑型模型的效率提高了 2-5 倍。

Jamba 的局限性：用户经常遇到的失败模式

Jamba 不是一个推理模型。Jamba 1.5 Large 的 GPQA 得分为 36.9，在研究生级别的推理任务上明显低于 GPT-4o 和 Claude。那些期望将 Jamba 作为通用思考模型来部署的用户，在多步代理任务、代码生成以及任何需要持续逻辑链的任务上都报告了令人失望的结果。该架构的权衡是显而易见的：Mamba 层在处理上下文时非常高效，但在短距离信息检索方面不如注意力机制精确。

“SSM 记住细节的能力不如 [Transformer]……对于许多应用来说，节省内存足以证明这种权衡是合理的。”——az226，Hacker News，2024 年 4 月

自托管 Jamba 1.5 Large 的要求非常苛刻。该模型最低配置需要 8 x 80GB H100 GPU 并配合 ExpertsInt8 量化。尝试在双 RTX 4090 设置上运行它的社区用户报告称，检查点加载在 71% 左右失败，且没有明确的错误解决方案。最广泛使用的本地推理工具 Ollama 原生不支持 Jamba 1.5（GitHub issue #6491，2024 年 8 月开启）。Apple Silicon MLX 生态系统同样缺乏对 Jamba 的支持。这实际上将自托管的 Jamba 限制在了企业级硬件上的 vLLM 中。

AI21 自己的模型卡对输出一致性的描述异常坦诚：“Jamba 的响应有时是不一致的、矛盾的，或者包含看似随机的句子和段落”，并且“新颖的输入往往会在其输出中产生更高的方差”。这不仅仅是套话。在非典型或特定领域的提示词上运行 Jamba 的用户报告称，与同等规模的 Llama 或 Mistral 相比，其输出稳定性明显较差。

社区和生态系统的存在感有限。没有大型的 Jamba 专属 Reddit 社区，没有著名的微调集合，GGUF 或量化模型变体也比 Llama 或 Mistral 的同类产品少。在开源社区参与度方面，AI21 比 Mistral 或 Meta 更为低调。该公司的重点是企业合同，而不是开发者的关注度。

Jamba vs. Falcon Mamba vs. Mistral 7B

Falcon Mamba 7B（阿联酋 Technology Innovation Institute）在 SSM 方向上比 Jamba 走得更远：它使用了零注意力层。该架构是一个纯 Mamba SSM，拥有 7.27B 参数，全部激活（无 MoE），在 5.8 万亿 Token 上进行训练。Falcon Mamba 理论上支持任意序列长度，但在实践中目标是 8K 上下文。没有任何注意力层使得 Falcon Mamba 在固定的短上下文推理中比 Jamba 更快，并完全消除了二次内存扩展问题。代价是：纯 SSM 架构在极长上下文的“大海捞针”式检索中表现挣扎，因为它们缺乏注意力机制直接索引特定 Token 的能力。Jamba 的 1:7 混合架构每八层保留一个注意力层正是出于这个原因。Falcon Mamba 更适合固定上下文、高吞吐量的工作负载；而当 256K 真正的召回准确率至关重要时，Jamba 则是更好的选择。

Mistral 7B（以及 Mistral NeMo 12B）使用纯 Transformer 架构，带有分组查询注意力 (GQA) 和滑动窗口注意力。基础的 7B 模型中没有 Mamba，也没有 MoE。上下文窗口：Mistral 7B 为 8.2K Token，Mistral NeMo 为 128K。在短上下文中，Mistral 7B 在原始质量方面的基准测试与 Jamba Mini 相当。问题出现在规模化时：在 256K 上下文下，纯 Transformer 需要的 KV 缓存内存比同等长度的 Jamba 高出一个数量级。Mistral 的优势在于社区采用率：庞大的微调生态系统、广泛的 Ollama 支持以及适用于消费级硬件的 GGUF 可用性。Jamba 的优势在于能够高效处理真正长文档的架构空间。对于 16K Token 以下的典型开发者用例，Mistral 7B 部署起来更实用，支持也更好。对于 100K+ Token 的企业文档处理，Jamba 的架构让这种比较变得毫无意义。Mistral 在物理上无法以经济实惠的方式做到这一点。

付费 API 层级值得吗？

Jamba API 在一种特定场景下具有财务意义：输入始终为 50K Token 或更多的高容量长上下文批处理。在这些长度下，相对于 GPT-4o 和 Claude 的成本优势会显著复合。Jamba Mini 1.7 每百万输入 $0.20 的价格比 GPT-4o 的 $2.50/1M 便宜 12.5 倍。在每月 10 亿 Token 的长文档输入工作负载上，每年的差额高达 230 万美元。对于这种狭窄的用例，该 API 显然是值得的。

对于其他所有情况，其价值主张就会减弱。如果您的典型上下文低于 16K Token，通过商品化提供商使用 Mistral 或 Llama 通常能提供更好的性价比。如果您需要强大的编码或推理能力，在基于基准测试的代理任务上，无论是 Jamba Mini 还是 Jamba Large 都无法与 GPT-4o、Claude Sonnet 或 Llama 3.1 405B 竞争。AI21 Studio 提供的 $10 试用额度足以评估长上下文性能是否值得投入生产。

对于开源自托管者来说，在许可证允许的情况下，mini 变体实际上可以在任何满足显存底线的 CUDA 硬件上免费运行（单个 80GB GPU 可处理 140K 上下文的 Jamba 1.5 Mini）。成本在于基础设施，而不是许可证。

最佳用例（以及何时应避开）

在以下情况使用 Jamba：您正在批量处理 100K Token 或更长的文档。法律审查、财务报告提取、合规文档分析或长篇客户交互日志是天然的契合点。需要 256K 上下文且无外部 API 调用的本地、物理隔离部署的企业团队会发现，在 vLLM 上运行的 Jamba 1.5 Large 是最实用的开放权重选项。正是出于这个原因，医疗保健和国防承包商在 AI21 公布的客户群中占据了显著位置。

当您正在构建一个希望完全避免分块（chunking）的 RAG 管道时，Jamba 也是有意义的。将一份 150 页的文档作为单一上下文传递并针对它提出问题，使用 Jamba 比使用任何同等成本的纯 Transformer 模型都要轻松得多。

在以下情况避开 Jamba：您需要编码辅助、多步推理或代理任务执行。在这些任务上，该模型无法与 GPT-4o、Claude 或 Llama 3.1 405B 竞争。如果您的上下文始终低于 16K Token，请避开它，因为架构优势会消失，更小、支持更好的模型能更好地为您服务。如果您想要消费级工具，请避开它：没有 Ollama 支持，没有 LM Studio 支持，没有现成的 GGUF 变体，这意味着自托管体验专属于拥有 GPU 集群和工程时间的团队。如果您想要一个包含微调配方、LoRA 或提示词工程指南的丰富社区生态系统，请避开它。与 Llama 或 Mistral 相比，Jamba 的开发者社区很小。

开始使用 Jamba

最快的途径是访问 studio.ai21.com 的 AI21 Studio，它提供 $10 的试用额度。API 调用使用标准的聊天补全格式，其中 model 参数指向 jamba-mini-1.7 或 jamba-large-1.7。对于有根据的生成（grounded generation），请在请求体中传递 documents 数组。这使得在适合 256K Token 的上下文中无需向量存储即可实现 RAG。

对于自托管部署，AI21 推荐使用 vLLM 0.6.5 到 0.8.5 版本。Jamba 1.5 Mini 模型需要一个 80GB GPU 在 8 位量化下实现 140K 上下文窗口。Jamba 1.5 Large 需要 8 x 80GB GPU 并配合 ExpertsInt8 量化。在使用 Transformers 加载之前，请安装 mamba-ssm 和 causal-conv1d。注意：Transformers 4.44.0 和 4.44.1 版本有记录显示与 Jamba 存在错误；请使用相邻版本。在开放权重模型中，函数调用和 JSON 模式可通过聊天模板的 knobs 参数使用。