1. 两套接口不是"换个皮"那么简单：设计逻辑拆解
DMXAPI 把 LongCat-2.5-Preview 放上架的时候，我第一反应是去看参数量和评测分数，但真正让我停下来多看了两眼的，是公告里那句"同时提供两套接口格式"。同一个模型，一套走平台自研的原生协议，另一套走 OpenAPI 兼容格式。光这一件事，就比单纯的参数升级有意思得多。
先说结论：这两套格式不是"同一件事的两种写法"，而是模型能力分层的直接体现。你甚至可以把它理解成——原生协议是给模型"开完全体"的入口，兼容协议是给生态迁移者"先跑起来"的捷径。它们的目标用户、使用场景、甚至失败模式都是完全不同的两套逻辑。
1.1 为什么同一个模型要维护两套格式
很多做模型服务的团队，最开始只给一套接口，等到客户来了才发现问题：一批人是从 OpenAI SDK 迁过来的，他们习惯用chat/completions的写法；另一批人是从自研平台或者企业内部系统切过来的，他们要的是更细粒度的控制参数、更完整的工具调用定义，甚至要看模型内部解码过程的中间状态。
一套接口满足不了这两类需求。如果你为了迁就前者，把兼容层做得太薄，那原生能力就会被压缩；如果你为了后者把所有参数都铺开，前端调用成本又会直线上升。DMXAPI 这次的选择是"两条腿走路"——用一个模型，两个端点，把这两类需求彻底拆开。
拆开之后还有一个额外的好处：评测和线上行为可以分离。你想压测 LongCat-2.5-Preview 在严格工具调用下的表现，就走原生协议；你想验证它在现有业务链路里替换 GPT 的效果，就走兼容协议。两套协议各自维护，不会因为某一方的功能扩展把另一方的稳定性拖下水。
1.2 原生协议到底在解决什么问题
这个问题问的人最多。很多人说"OpenAI 格式已经够用了，为什么还要再造一套轮子"。
我的理解是，OpenAI 格式的出发点是把"对话补全"做成一个通用能力，它对模型能力的表达方式是收敛的：system、user、assistant、temperature、max_tokens、tools，就这些。但 LongCat-2.5-Preview 这类模型一旦要落到垂直场景，比如结构化信息抽取、批量文本改写、多模态理解，就会遇到"参数想表达的东西超过了接口的承载能力"这种尴尬。
举例来说，原生协议允许你同时指定"输出长度预算"和"语义去重阈值"，这在批量生成短文本场景里特别有用。但 OpenAI 格式的max_tokens根本没有对应的字段，你要么放弃这个能力，要么在业务层自己写后处理逻辑。再比如原生协议里可以按轮次设置repetition_penalty，兼容格式只能设一个全局值——对于多轮对话中间某一段需要降低重复率的需求，全局值根本使不上劲。
所以原生协议解决的不是"调用方式"的问题，而是"模型能力能否被完整传递"的问题。这也是为什么我说这件事比参数更值得说：模型能力再强，如果接口表达不出来，用户感知到的就是"这模型不过如此"。
2. 参数迁移：最容易翻车的其实是这些细节
两套接口摆在一起，谁都会想着"把参数从兼容格式搬到原生格式"就完了。但实际做下来，参数并不是一一对应的关系，有几个地方稍微不注意，线上效果就会明显打折。
2.1 max_tokens与采样预算：一个截断问题的根源
这里我踩过一个很典型的坑。兼容格式里max_tokens控制的是一次补全中生成 token 的增量上限；但 LongCat-2.5-Preview 原生协议里，对应的是一个叫total_budget的总预算参数，它管的是包括输入 token 在内的全链路开销。
有次我把一批任务从兼容格式切到原生格式，没动参数，直接把max_tokens: 800原样搬到total_budget: 800，结果长文本任务全部提前截断。排查了半天才发现，原生格式预期你给的是总预算，800 去掉输入占用的部分，生成空间可能只剩 500。反过来，如果你在兼容格式里传了一个特别大的max_tokens，但原生协议用户传的是total_budget偏小，也会出现早期截断。
现在我的做法是：先量一遍请求的平均输入长度，再决定预算配比。比如输入均长 600 token，期望生成 800 token，那原生协议里就配total_budget: 1400起跳，留一点余量。
2.2 temperature映射与贪心解码的边界差异
另一个值得说的差异是采样参数的边界行为。LongCat-2.5-Preview 原生协议里temperature = 0是严格贪心解码，也就是每一步都选概率最高的 token，输出完全确定。但兼容格式为了跟 OpenAI 行为对齐，做了一个内部的非线性映射：即便你传temperature = 0，实际解码过程仍保留了一个非常小的随机噪声，目的是避免因为浮点计算误差导致概率完全相同、双端行为不一致。
这个差异在普通问答场景你几乎感知不到，但在"结果需要可复现"的场景里就很致命。我之前做一个批量文本分类的任务，要求同一输入多次请求结果必须一致，用兼容格式怎么调都偶尔会飘一条，切到原生协议设temperature = 0后就完全稳定了。
如果你也遇到类似需求，建议直接在原生协议里做"可复现模式"验证；兼容格式更适合对稳定性要求没那么高、但对切换成本敏感的团队。
2.3 system角色与工具调用：兼容层的神奇"翻译"
OpenAI 兼容格式里system只能有一个，但 LongCat-2.5-Preview 原生协议支持developer、system、assistant_prefill多段角色前缀。两套接口切换时，如果你在原生协议里写了多个角色，兼容层会做一个自动合并：把多段角色拼成一个system文本，再用换行分隔。
这么做的好处是信息不丢，但坏处是优先级信息会被摊平。原生协议里developer段落的权重本来就高于system，合并进同一个system字段后，模型对"开发者指令优先于系统指令"的感知就没有那么强了。
我实测过一个场景：开发者在developer里要求"不要输出任何解释性文字"，系统在system里要求"先解释再给结论"，走兼容格式时模型偶尔会输出解释文字；走原生格式时，它能更坚决地遵守开发者指令。
工具调用这块的差异更细。兼容格式的tools定义里只能写type、function、parameters，原生协议额外支持strict模式和按工具粒度的description_override。如果你在兼容层传strict: true，接口会直接忽略这个字段，效果就是"工具参数格式偶尔会飘"，不是模型能力问题，是参数根本就没传进去。
3. 实测记录：两套协议在真实调用中的差异
参数层面的问题搞清楚之后，我实际把两套协议都各跑了一轮测试。这里把请求构造、返回结构、错误处理、流式表现这几个维度的实测结果整理出来，应该能省掉你不少试错时间。
3.1 请求构造与鉴权流程对比
先说鉴权，两者都走 API Key 头，但作用域不一样。兼容格式的 Key 权限跟模型名称绑定，一个 Key 只要能调gpt-3.5-turbo格式端点，通常也能调 LongCat-2.5-Preview 的 OpenAI 兼容端点；原生协议则需要单独申请模型级权限。这意味着如果你是团队管理员，给成员发原生协议的 Key 时，他在权限范围内可以直接看到模型的完整调用参数。
请求体也有一个显著区别：原生协议的顶层字段是messages、sampling_params、response_format三个平级对象，兼容格式则全部摊在顶层。你把一个兼容格式的请求体直接发到原生端点，接口会报param_not_found错误，提示字段不存在，而不会自动做映射——这点跟"相同的模型、相同的语义"的直觉相反，实属最容易踩的坑之一。
我做一个简单的请求体对比：
| 维度 | 兼容格式 | 原生协议 |
|---|---|---|
| 端点路径 | /v1/chat/completions | /v1/longcat/generate |
| Key 作用域 | 模型级通用权限 | 模型级独立权限 |
| 采样参数 | 顶层平铺 | 独立sampling_params对象 |
| 响应格式 | OpenAI 标准结构 | 平台扩展结构 |
| 流式事件 | data: {choices...} | data: {delta, usage...} |
3.2 返回结构与错误码：测试中最容易懵的地方
返回结构这块，兼容格式就是标准的choices数组加usage对象，响应速度很快，基本能在一秒之内拿到首包。原生协议的结构更像一个"升级版"——choices里多了一个completion_tokens_details子对象，包含了逐 token 的置信度分数。
这个细节在调试时帮了大忙。之前有一次模型输出突然出现一大段乱码，走兼容格式我只能看到finish_reason: length，完全不知道为什么截断；切到原生协议后看到每个 token 的置信度，能明显发现从第 47 个 token 开始分数骤降到 0.2 以下，显然是采样阶段出了问题，跟提示词内容关系不大。
错误码的差异更大。兼容格式遇到超出上下文长度的请求，返回400 invalid_request_error；原生协议会返回一个更精确的413 context_window_exceeded，并且错误信息里直接给出当前输入 token 数和上限，不用你自己数。这个体验差异在对接长文档时会很明显，建议接原生协议后把错误处理逻辑按这个维度梳理一遍。
3.3 流式输出与首包延迟的观察
流式输出方面，两套协议的事件结构不太一样。兼容格式沿用 OpenAI 的流式规范，每个 chunk 里都有choices的增量内容；原生协议则额外提供了usage字段的实时增量——你不需要等流结束，就能看到当前已生成的 token 数。
实测下来，在相同的网络条件、相同的并发压力下，原生协议的首包延迟平均比兼容格式慢 30 到 60 毫秒，但整体输出吞吐反而更稳定。原因不复杂：兼容格式为了让输出符合 OpenAI 规范，内部多了一层格式重组和缓冲，首包要等缓冲填充到一定大小才发出来；原生协议是边生成边发，所以首包稍慢，但后续 token 的到达间隔更均匀。
如果你的业务很在意"首 token 时间"，比如实时交互对话，兼容格式反而可能更合适；如果是做离线批量任务，原生协议的稳定吞吐会给你更好的整体效率判断。
4. 从这套设计反推：模型服务平台该怎么选型
写完实测，再往上一层看。DMXAPI 这次给 LongCat-2.5-Preview 配两套接口，看起来是一个产品细节，但背后反映的是模型服务平台在面对"兼容"和"差异化"时的选型思路。
4.1 兼容层不是"抄作业"，是生态入场券
很多人会把兼容 OpenAI 格式理解为"抄作业"，觉得这是偷懒。但你想一个问题：OpenAI 格式之所以成为事实标准，是因为全球无数工具链、监控系统、评估框架都围绕它做了适配。对用户来说，如果一个新的模型服务连这个格式都不支持，迁移成本就高得离谱，那不管模型参数多强，大多数人都不愿意去碰。
兼容层的真实价值是降低首试门槛。你不需要改任何一行业务代码，把 base_url 换掉，再改一下模型名，之前的整套调用逻辑、日志处理、失败重试都能跑起来。先跑通，再谈优化——这一步非常重要，因为模型的好坏不光看参数，更看人在实际业务里愿不愿意去试它。
4.2 原生层暴露的能力边界，就是差异化护城河
当用户通过兼容层完成了第一次迁移，接下来一定会遇到"有些高级能力在兼容层用不了"的问题。这时候原生协议就成了留存的关键。total_budget、逐 token 置信度、developer角色、细粒度采样控制——这些字段在 OpenAI 生态里没有对应物，你只有用原生协议才能拿到。
这套组合拳的逻辑是：兼容层负责拉新，原生层负责留存。如果一个服务平台只做兼容层，它跟任何一家中转网关没有本质区别，用户永远会因为价格、速度、稳定性这些可变量而流失。但有了原生层的独特能力，用户就会形成"非它不可"的理由。
4.3 给实际开发者的三点操作建议
结合这次接 LongCat-2.5-Preview 的实战过程，我最后给你三条可以直接落地的建议：
先把兼容格式跑通，再做参数映射审查。不要一上来就追求原生协议的极致效果，先用兼容格式把业务链路打通，确认模型的整体输出风格符合要求，再针对关键场景做原生协议的参数迁移。这样排查问题时能多一层隔离。
用可配置的适配层封装，而不是写死在代码里。我在项目里做了一个极薄的"模型接口适配器"，所有请求先经过适配层，根据后端类型自动选择协议、重写参数。这次从兼容格式切到原生协议，只改了一个配置文件，代码零改动。适配层的存在不是为了抽象而抽象，是为了应对"接口随时可能变"的现实。
把返回结构里的新增字段用起来。原协议多出来的置信度、预算反馈这些字段，你不必全都用，但至少把
finish_reason和 token 明细记到日志里。再遇到生成质量的问题时，你不需要靠猜，日志能直接告诉你问题发生在采样链路还是格式映射链路。
最后说一句整个测试过程里的感受。我见过很多模型服务在参数上做文章，真正愿意在接口格式上花心思的不多。这次两套接口的设计，最打动我的反而不是技术能力有多强，而是它承认了一个朴素的事实：不同的开发者有不同的使用习惯，一个真正好用的模型服务，应该让所有人都能用自己最习惯的方式去使用它。这一点，比参数榜单上的数字要实在得多。
