Mercury 2.5
247 points • 5 days agoArticle Link

Inception 正式发布了 Mercury 2.5,标志着其生产级模型线取得重大进展。基于 Mercury 2,新版本在智能能力上实现了显著跃升,公司通过大量客户反馈和真实生产故障案例的分析验证了这一点。数据驱动的做法让团队得以调整评估标准,打造出在保持前代高速度和低成本优势的同时,整体性能提升约 40% 的模型。

作为迄今开发出的最大规模的扩散语言模型,Mercury 2.5 旨在与 GPT-5.6 Luna 、 Gemini 3.5 Flash-Lite 和 Claude Haiku 4.5 等前沿模型竞争。它拥有 260K tokens 的上下文窗口,在标准 NVIDIA GPUs 上可实现每秒 1,107 tokens 的吞吐量。模型还引入了可调推理、并行工具调用和 schema-aligned JSON 等专业功能,并以极具竞争力的价格提供;发布期间可享受标准费率 80% 的折扣。

Mercury 2.5 的应用场景广泛,从复杂搜索流水线到交互式语音代理均可受益。在搜索场景中,低延迟使得在一次用户交互内完成多次连续调用(如查询重写与事实核验)成为可能。在语音 AI 领域,OpenCall 等公司报告称中位响应延迟已降至 170 毫秒以下,这对于营造自然、流畅的对话体验至关重要,因为延迟会破坏交互节奏。

编程助手在上下文压缩和模型路由等高频任务中也能借助 Mercury 2.5 提高效率。将这些辅助调用交由 Mercury 处理,开发平台通常能显著降低运营成本和延迟。为进一步支持此类工作流,Inception 推出了面向严格延迟场景优化的 Mercury Voice 和面向智能路由的 Mercury Router 预览版,后者可根据质量、速度与成本动态将提示路由到最合适的模型。

展望未来,Inception 已在研发下一代更大规模的模型,目标是在不牺牲当前扩散架构效率的前提下再次实现能力飞跃。对当前技术感兴趣的开发者与企业可通过 Inception API 、 Baseten 和 OpenRouter 访问 Mercury 2.5 。公司将持续在训练与基础设施方面创新,以不断扩展模型能力,显示出强劲的发展势头。

54 comments • Comments Link

• 该模型以极快的推理速度著称,一些用户认为这在对延迟敏感的任务(例如向量库重排)或作为多模型系统中低延迟的判定器时非常有用。

• 基于 Diffusion 的文本生成架构与标准的逐词预测技术不同:它一次性生成完整输出,然后对其进行去噪处理。

• 虽然"推理"和"思考"功能在逻辑推导上表现强劲,但在创意写作中常带来负面影响,例如增加幻觉(hallucinations)和对良性提示过度谨慎的安全限制。

• 在创意场景中,幻觉通常表现为一致性丧失,包括局部不一致(行为突然改变)或整体不一致(时代背景错误)。

• 尽管速度很快,该模型在通用工具使用和具有主体性的编码(agentic coding)方面仍显吃力,在复杂的指令遵循和人格模拟方面落后于前沿模型。

• 缺乏开源权重是争议点之一,因为用户普遍更倾向于可自托管或可审查的模型,而非依赖专有且不透明的 API 。

• 虽然速度技术指标令人印象深刻,但一些观察者对其营销持怀疑态度,指出若以较旧、能力较弱的模型为基准进行对比,可能会掩盖其真实效用。

• 这些高速度模型的利基市场被视为"子代理(sub-agent)"任务:由快速、低成本的模型承担高频、低复杂度的工作,从而减轻更强、更"智能"模型的负担。

• 关于基于 Diffusion 的模型的竞争优势存在争议,一些人认为缺乏明确的经济护城河,会使它们容易被快速模仿或收购。

• 产品命名引起的混淆也很常见,不少用户最初误以为讨论的是编程语言、化学元素或其他不相关的机械系统。

总体而言,讨论反映了对基于 Diffusion 的语言模型在架构创新上既感到兴奋又对其长期实际效用持怀疑的分歧。极高的速度为语音代理和搜索重排等特定 B2B 应用带来直接价值,但该模型目前在实现更高层次的主体性和创意连贯性所需的细微能力上仍存在困难。参与者普遍认为,快速执行能催生新的工作流,但尚不能取代对高推理能力前沿模型的需求;未来更可能由分层的模型编排(tiered model orchestration)来定义,而非单一模型的统治。