LongCat 2.5：Meituan 的预览模型是什么，以及它不是什么

请求LongCat 2.5，在美团自有平台上，你得到的模型叫作 LongCat-2.5-Preview——而且这个后缀并非装饰。它就是模型 ID、每个代码示例中的字符串、价目表上的名称，也是厂商的模型列表端点返回的唯一一条 LongCat 2.5 条目。美团的 LongCat API Platform 于 2026 年 9 月 25 日在一则带日期的更新日志条目中将其上线，与平台上唯一的另一个模型——LongCat-2.0。将近三周后，它仍未更名，其价格仍被标为促销价，而且没有任何人——包括美团在内——为它公布过哪怕一个基准测试数字。

这种组合正是本页存在的全部理由。接口已有完整文档：一个与 OpenAI 兼容的端点、一个与 Anthropic 兼容的端点、一份已公布的费率表、一个已公布的上下文限制。能力概况则完全没有文档，而且同一套文档中的两页对一项主打功能给出了两种不同说法。如果你正在决定是否基于它进行构建，有用的是精确列出哪些是已知的、哪些是宣称的，以及哪些根本不存在。

LongCat 2.5 是什么，以及由谁发布

LongCat 是美团的模型系列，LongCat API 平台是美团为其提供的自有服务入口——而非第三方网关。平台 FAQ 将其服务描述为“专为 LongCat 系列模型提供的 AI 模型代理服务”，并保持与 OpenAI 和 Anthropic API 格式的兼容性，使现有 SDK 无需更改即可使用。厂商自有页面上的支持地址是longcat-team@meituan.com，文档站点、控制台和 API 主机均位于美团控制的域名和美团静态资源 CDN 下。

目录很短。平台的支持模型表中恰好只列出两个条目：LongCat-2.5-Preview 和 LongCat-2.0，两者的描述完全相同，均为“高性能 Agentic 模型”。GET /openai/v1/models 端点返回的也正是这两个，别无其他，且每个的 owned_by 都设为 "LongCat"。因此，“LongCat 2.5”并不是一个需要你在多个变体中做选择的模型家族——2.5 只有一个模型，它是平台上这两者中较新的一个，也是平台自家的按量计费定价页首要推荐的模型。

厂商在发布说明中称其用途有三项：图像理解、编码，以及与主流开发环境的兼容性——被点名的包括 Claude Code、Hermes、OpenClaw、OpenCode 和 Kilo Code。那份发布说明是厂商自己发布的带日期条目，也是所有这些说法唯一出现的地方。

"Preview" 是模型 ID，不是营销用语

这个区别比通常更为重要，因为在这个平台上，“preview”在三个具体方面都起着承重作用。

首先，这是你必须发送的字符串。文档中的每一个示例请求——cURL、Python、OpenAI SDK 示例、Anthropic SDK 示例——都使用了 LongCat-2.5-Preview，而 Retrieve Model 参考文档也将其用作路径参数。没有 GA 别名可以替代发送。

其次，价格明确是暂定性的。定价页面在每个数字上方的列标题里都标着“限时”二字，并以一句值得读两遍的话收尾：“价格可能发生变化。LongCat API Platform 上显示的价格以及你的账单记录才是权威依据。”一份价目表若告诉你它并非自身数字的权威来源，那就是在告诉你：别拿它来搭建单位经济模型。

第三，任何地方都不存在稳定性承诺。没有公布的弃用窗口，没有版本化承诺，也没有说明模型转正时是会保留同一个 ID，还是 -Preview 会直接退役、让位于一个新名称。这是预览版的正常风险，而诚实的应对方式是：你今天可以调用它，但不能假定你今天写下的调用就是你日后会一直保留的调用。

预览不意味着这里的访问受限。平台是自助式的：注册、创建密钥、为预付余额充值。中国大陆的用户必须完成身份验证后才能充值；中国大陆以外的用户可以用手机号码或电子邮箱地址注册。文档中没有任何内容将模型置于审批流程之后。

参数与架构：大家都在引用的那个数字属于 LongCat 2.0

Meituan 并未公布 LongCat-2.5-Preview 的参数数量。它不在更新日志里，不在定价页面上，不在 API 参考文档中，也不在常见问题里。如果你看到“大致 1.6 万亿总参数，其中约 480 亿活跃参数”被挂在 LongCat 2.5 名下，那你看到的是一个贴着 2.5 标签的 LongCat 2.0 数字——而破绽就在于，这句话几乎总是用“大约”来限定，因为它是从旧模型卡里照搬过来的，而不是从这一张模型卡上读出来的。

那个数字的来源是美团自己在 Hugging Face 上为 longcat-2.0 发布的模型卡，卡片开头写道："我们介绍 LongCat-2.0，一个大规模 MoE 语言模型，总参数量达 1.6 万亿，每个 token 约激活 480 亿参数。"该模型卡接着描述了 LongCat Sparse Attention、在"数千亿 token 的 100 万上下文数据"上进行的预训练，以及模型中包含的 1350 亿个 N-gram 嵌入参数。这是一套有充分文档记录的架构，而它属于 LongCat 2.0。至于 2.5 是否继承了这一形态，这既是一种合理的预期，也是一个没有文档记录的事实。本页面不会把它当作 LongCat 2.5 的规格来刊载，你这个月读到的其他任何内容也不该如此。

开放权重：否

美团在 Hugging Face 上发布的内容非常多——meituan-longcat这个组织旗下有大约三十个仓库，涵盖文本、图像、视频和音频模型，LongCat-2.0 系列也一应俱全：基础模型加上 FP8 和 INT8 的同门版本，全部采用 MIT 许可。并不存在 LongCat-2.5 仓库。该组织最新的文本生成发布是 2026 年 7 月初的 LongCat-2.0，而在 Hub 上搜索 LongCat-2.5，无论来自美团还是其他任何人，都找不到任何仓库。

这一模式在相反方向上也同样说明问题。LongCat 2.0 的权重开放，在围绕开放权重形成的生态中清晰可见——社区 3 比特和 2 比特量化、MLX 转换、混合精度 AutoRound 构建。2.5 则完全没有这些，因为没有任何权重可供量化。在美团发布代码仓库之前，无论 LongCat 系列的未来如何，都应将 LongCat-2.5-Preview 视为闭源、仅提供 API 的模型。

供应商实际发布的信封

这些内容摘自 Meituan 自己的文档和定价页面，日期为 2026 年 10 月 13 日。其中每一项都是供应商自己给出的数字；没有一项经过独立核实，而最后一项根本不是数字。

• 上下文窗口 — 1,048,576 个 token。Retrieve Model 参考文档中 LongCat-2.5-Preview 的示例响应返回 context_length: 1048576，而快速开始文档中也以文字形式说明了相同的限制："1M token 上下文窗口"。

• 最大输出 — 131,072 个 token。快速入门中将其写为“最大输出长度为 128K 个 token”；Chat Completions 参考文档则将上限写为 131072，默认值为 128k。同一个数字，三种写法，而其中最大的那个才是真正的上限。

• 输入模态——以文本形式记录。同一个 Retrieve Model 响应会返回 input_modalities: ["text"]，其 modality 字符串为 text->text。更新日志声称支持图像输入。这两项内容位于同一个文档站点上，却相互矛盾；下一节将对此进行说明。

• 输出模态——文本，模型的思考过程会单独返回于reasoning_content字段中，而非混入回答内容。推理 token 在用量统计块中单独计数，这使得长链路的成本归因变得可处理。

每百万 token 价格——未缓存输入 $0.30，缓存输入 $0.006，输出 $1.20。页面将这三项都标注为“限时”。同一张表还列出了面向在中国计费账户的人民币费率卡：¥2 / ¥0.04 / ¥8。

• 参数——此模型未公布。1.6T/48B 的规模是 LongCat 2.0 的。

• 独立评分——不存在。不是低分：而是没有评分。

供应商在图像方面自相矛盾之处

更新日志的头条宣称毫不含糊："多模态理解：全新的图像理解能力，能够解析图像内容，支持跨模态问答、内容总结和复杂的视觉推理。"对于一个唯一有据可查的其他差异化优势仅仅是便宜的模型来说，这才是你真正会去着力打造的功能。

API 参考文档说的恰恰相反。针对这个确切的模型 ID 调用 Retrieve Model，返回的是 input_modalities: ["text"]和 output_modalities: ["text"]。Chat Completions 参考文档将消息的 content 字段描述为“消息内容为纯文本字符串”——是一个字符串，而不是内容部分数组，文档化的请求体中既没有图像 URL 参数，也没有任何附件字段。文档化的接口里没有任何可以放入图片的位置。

那两个页面中有一个已经过时，而从外部无法判断是哪一个。更新日志是发布公告，而公告是在某项能力落地时写的；API 参考文档则是根据端点实际接受的内容生成的，而参考页是所有人最后才会更新的东西。这个推理指向一个方向，但它是推理而非证据，因此本页不会断言图像输入是一项可用功能。如果你感兴趣的原因是视觉能力，就花十分钟发一张图片并读一读响应。不要围绕更新日志的措辞来规划流水线，也不要仅凭参考页就排除这个模型。

没有基准。情况就是如此。

Meituan 尚未发布 LongCat-2.5-Preview 的任何基准测试。文档中没有评估表，更新日志中没有对比图，定价页面上没有分数，也没有发布博客文章来承载它——Meituan 自家上一代模型页面附有一份技术说明，而 2.5 在 Meituan 的任何公开渠道上，我们都找不到与之相当的内容。这不是本文的疏漏；这是买家需要知道的第一个事实。

也没有独立的评分。Artificial Analysis 确实测量了 LongCat 系列——它收录了 LongCat 2.0，发布日期为 2026 年 6 月 29 日，以及 LongCat Flash Lite——但我们在 2026 年 10 月 13 日查看时，其模型索引中并没有 LongCat 2.5 的条目。如果你这个月看到某个 LongCat 2.5 的基准测试数字，首先要问的是它究竟挂靠在什么之上，因为最可能的答案是：那是某个假定这两个模型共享同一画像的人，把 LongCat 2.0 的结果重新贴上了 LongCat 2.5 的标签。上文描述的参数数量混淆，是同一个错误换了身装束。

厂商真正声称的——而这些全都未被复现——是更新日志里的那份三项清单：多模态理解、横跨“代码生成、代码理解与自动化编程任务”的“卓越编码能力”，以及与 Claude Code、Hermes、OpenClaw、OpenCode 和 Kilo Code 配合时的高效运行。不妨把这些当作厂商对自身意图的描述。三项之中有两项，是这一档次的每份模型卡都会做出的宣称；而第三项——环境兼容性——则是那种你自己花一个下午就能验证的事：把你的 agent 指向该端点，看看返回的工具调用是否是你的运行框架能理解的形态。

如何从中获得回应

该平台通过一个密钥提供两个兼容接口，该密钥从控制台的 API Keys 页面签发，并作为Authorization: Bearer传递。

• OpenAI-compatible — POST https://api.longcat.chat/openai/v1/chat/completions. Point the Open​AI SDK's base_url at https://api.longcat.chat/openai and it works unchanged; the vendor's own example sends model: "LongCat-2.5-Preview" with max_tokens: 1000 and temperature: 0.7.

• Anthropic-compatible — POST https://api.longcat.chat/anthropic/v1/messages with the anthropic-version: 2023-06-01 header, and https://api.longcat.chat/anthropic as the Anthrop​ic SDK's base URL. Both request and response formats follow the Messages API.

• 接受的参数 — max_tokens 最高 131072（默认 128k），temperature 范围 0 到 1，top_p，stream 用于 SSE，tools 和 tool_choice，以及一个 thinking 对象，可接受 {"type":"enabled"} 或 {"type":"disabled"}。推理是请求上的一个开关，而不是单独的模型 ID。

• 速率限制——超限请求会返回 HTTP 429，并附带 retry_after: 60，文档还建议客户端采用指数退避。任何地方都没有公布每分钟请求数或每分钟 token 数的上限，因此你无法根据文档来估算并发预算；你只能通过触碰到限制才知道它的存在。对于每个任务就要发起数十次调用的 agent 循环来说，这一点值得在遇到第一个 429 之前就了解，而不是在遭遇之后才明白。

• 计费 — 预付费余额，按请求计费，且仅对成功的响应计费。失败的请求 — 文档中列出了 401、403、429 和 500 — 明确不计费。余额不会过期，且赠金会先于付费余额被消耗。

两个会让你付出一次调试代价的细节

第一个是 reasoning 字段。供应商自己的响应示例返回的 assistant 消息同时携带content和reasoning_content，其中reasoning_tokens在usage.completion_tokens_details中单独列出。这不是 Open​AI 的形态，也不是 Anthrop​ic 的形态：它是一个交错字段，每次响应都会出现。如果客户端反序列化为固定 schema 并丢弃未知键，就会悄悄丢弃模型的思考——而且这种失败是看不见的，因为答案仍然会返回。你会认为模型比实际更弱，而你的判断会错，原因与模型毫无关系。在评判输出质量之前，请检查你的客户端是否保留该字段。

第二个是上面提到的模态问题。它之所以在这份清单上，是因为这两份文档的分工方式：变更日志是你用来了解模型能做什么的页面，而 API 参考是你用来了解该如何提问的页面。在这里，它们对同一个模型各执一词，而分歧恰恰在于发布说明开篇就重点介绍的那个功能。

什么会改变这个推荐

本页只是一张快照，而它呈现的是一个仍带有四个未决问题的模型，而非一个已有定论的模型。有五件事会推动它向前：

• 一次更名，或更新日志中出现 GA 条目——就在-Preview不再是模型 ID、价格不再被标注为限时、稳定性承诺变得有实际意义的那一刻。

• 一项基准测试——无论是来自美团，还是来自某家测评机构——都能取代当前的局面：模型的能力并非仅仅是低下，而根本是未知的。

• 图像输入是在参考文档中演示的，而非在发布说明中加以断言——这里的修复只需对某个生成的页面做一行改动，即可消除整套文档中唯一的内部矛盾。

• 一项参数披露或一个 Hugging Face 仓库——二者任一都能让 2.5 架构的讨论以证据为依据，而不是靠从 LongCat 2.0 继承。

• 已公布的速率限制——五者中最小的，也是对代理工作负载是否可规划影响最大的那一个。

与此同时，务实的做法其实很直接，而且它与你面对一个已评分、已定价、稳定的模型时该采取的姿态并不相同。一个未评分、以促销价提供的预览模型，是用来评估的，而不是把生产路径指向它的——正因如此，回退方案才是值得仔细搭建的部分。在 OrcaRouter 上，我们提供的模型都通过同一个密钥、以供应商标价访问，零加价，因此供应商的价格变动当天就会反映到你的账单上，而不是等到续约时；自动故障转移会把出现降级的请求转到健康的供应商，而你的代码无需知情。LongCat-2.5-Preview 不在我们的路由之中，我们也不提供它，所以想试用它就意味着直接去美团的平台；这里的论点仅仅是：无论你在它后面保留什么，都应该只需一行配置就能接入，因为这个模型提出的问题——它对我的工作来说够不够好——只有实际跑起来才能回答，而答案很可能是不。

这就是整件事的全貌。LongCat 2.5 是真实平台上的一个真实模型，拥有有文档记录的接口、已公布的价格和 100 万 token 的上下文窗口；同时它也是一个预览版，其参数、基准测试和视觉支持都尚未确定。这两部分都是真的，都值得写下来，而第二部分是没人会转载的那一半。