5家推理商齐聚AllModels：Abliterated模型路由层是怎么做的

一场Abliterated模型供给端的静默扩容

HN 上那条帖子只有 1 分、0 条评论，标题却声称已经有 5 家推理商在做 abliterated DeepSeek 来源：HN。我在这个社区里看过太多类似的安静，往往越是结构性变化的信号，越没什么人在公开讨论里吵。点进 AllModels 的页面，副标题直接写"One endpoint for every abliterated model" 来源：AllModels，这已经不是某个单一模型的服务页，而是把 abliterated 当成一个独立生态品类来路由。我不太确定这个页面的流量如何，但至少它的定位变了，从卖一个模型，变成卖一条通向整个 abliterated 谱系的通道。

页面把 DeepSeek V4.1 Flash Abliterated 和 Abliterated GLM 5.3 两类模型的推理入口都摆了出来。默认选择器里暴露了模型 ID，比如"deepseek/deepseek-v4.1-flash-abliterated"，GLM 系列也共用一个公开模型 ID 来源：AllModels。这看起来像是一个路由层，把多个独立推理商的请求按模型 ID 做聚合。页面说"One connection to the entire abliterated ecosystem" 来源：AllModels，但 5 家推理商的名字并没有直接列出来，只挂在两条"Loading live DeepSeek provider routes"和"Loading live GLM provider routes"的异步加载状态后面。所以那 5 家的具体身份，我目前无法确认。

有意思的是，HN 帖子的标题用的是"there are now"这种完成时陈述，但整个页面没有一处写明这 5 家是谁、什么时候接入的。这个扩容更像是在供给端静默发生，页面只给出路由层的抽象，把供应商的多样性藏在异步加载和 fallback 池后面。我倾向于认为，AllModels 正在做的不是简单的模型聚合，而是把"abliterated"变成一个可寻址的产品维度，跟传统的按模型名聚合区分开来。

路由层的技术细节：文本走fallback，图像才挑能读的

AllModels 页面写了一句很关键的规则："AllModels keeps text routes in the fallback pool and sends image requests only to a provider that can actually read them" 来源：AllModels。也就是说，文本请求可以在多个推理商之间做 failover，哪个都能处理，所以全放进 fallback 池；图像请求不一样，只有具备视觉能力的推理商才能接，路由层会把它定向到能读图的 provider 那里。这是个细但关键的差异化处理，说明路由层不是简单轮询，而是按请求类型做能力路由。

接入方式上，JavaScript 和 Python 都走 baseURL "https://api.allmodels.io/oai"，模型参数直接写"deepseek/deepseek-v4.1-flash-abliterated" 来源：AllModels。示例代码用 OpenAI SDK 的 responses.create，请求体里写"Open the pod bay doors."。这个接入体验跟 OpenAI 兼容，迁移成本很低。路由层同时暴露了两套 API：Chat Completions 走 POST /oai/chat/completions，Responses 走 POST /oai/responses 来源：AllModels。我注意到 Responses API 还支持结构化输出、推理控制、自定义工具和 hosted web search，功能面比 Chat Completions 宽。

页面上有个性能指标面板，但读数都是占位符："p50 — ms" 和 "— tok/s" 来源：AllModels。这让我觉得基础设施还在完善，延迟和吞吐的实时监控没完全接上。路由规则里提到"web search is processed at AllModels instead of being"，原文被截断了，但至少可以确认，外部搜索被放到 AllModels 这一层做统一控制，而不是把搜索的请求透传给下游推理商。这个设计把路由层从纯粹的模型分发器，变成了一个带安全边界的中间件。

多源视角下的观察与质疑

HN 侧数据给我提供了一个对照视角：该帖 1 分、0 评论，跟 AllModels 页面强调的"Federated model access"叙事形成了明显反差 来源：HN。页面上说这是"A fast reasoning model served by several independent providers" 来源：AllModels，但 HN 社区几乎没有接这个话。这种冷清不一定是坏事，也许是因为这个变化太底层，普通用户感知不到，但作为技术观察者，这个反差本身值得记一笔。

我对"5家推理商"这个数字有疑问。页面并没有列出这 5 家的具体名称，只在异步加载的 provider routes 处暗示了存在多个。如果这个数字是真实的，那么 AllModels 作为路由层的价值就很清楚：它让你不用为每个推理商单独建集成，一条安全加固的 API 就能覆盖供应商多样性、容量 failover 和新模型接入 来源：AllModels。但我也愿意直说，页面把"5"这个具体数字隐藏在"several independent providers"这个模糊说法后面，我无法核实到底是不是刚好 5 家。

供给端的定位差异也值得琢磨。官方自陈"DeepSeek and GLM are only the starting point" 来源：AllModels，暗示当前这 5 家推理商主要围绕这两个 abliterated 系列，尚无更宽泛的模型谱覆盖。这跟"One endpoint for every abliterated model"的宏大表述之间，存在一个现实差距：目录还没铺满，路由层先把架子搭起来了。我判断这个策略是对的，先做品类路由，再扩充模型目录，比等目录齐了再建路由更容易积累供给端资源。

最让我觉得反直觉的，是 AllModels 把"abliterated"作为一个独立生态品类来路由，而不是传统按模型名聚合。这意味着在推理供给端，"abliterated"本身已经变成一个可寻址的产品维度。模型 ID 里直接嵌了"abliterated"字段，路由规则里也专门区分文本和图像的处理方式。我见过太多模型服务商把 abliterated 当成一个普通变体塞进模型列表，而这里把它单独拎出来做联邦路由，这是供给端的一次结构性分化，不只是模型数量的增加。不过我也不确定这种分化是否会一直持续下去，取决于 abliterated 模型在用户端的接受度，以及是否有更多推理商愿意承接这类特殊模型的请求。

原文：

There are now 5 inference providers for abliterated DeepSeek · 来源：Hacker News

作者：itfan123 值班编辑 · 发布于 2026年10月27日