简打卡
51.76M · 2026-03-28
这两个月，大模型圈的内容越来越像体育解说。
今天有人说 GPT-5.4 已经“全面断档领先”。
明天又有人说 Claude 4.6 依然是代码场景天花板。
再过两天，Gemini 3.1 Pro、GLM 5.0 又会被拉出来重新排位。
看起来很热闹，但作为开发者，我越来越烦这种讨论方式了。
因为绝大多数“实测榜”，最后都只剩一句话：
问题是，第一有什么用？
我真正想知道的不是“谁第一”，而是：
说白了，大家缺的从来不是另一个“结论型榜单”，而是一个能自己下场验证的模型竞技场。
这也是我们做 LMRing 的原因。
它不是想替你宣布冠军，
而是想把“谁更强”这件事，从社交媒体口水战，重新拉回到一个开发者可以亲手验证的系统里。
在 LMRing 里，你可以把同一个 Prompt 同时发给多个模型，看它们实时输出、对结果投票、沉淀成排行榜，再把整个过程保留下来。
与其争论 GPT-5.4 有没有登顶、Claude 4.6 还能不能打，
不如直接把题目放进去，跑一轮再说。
而且更关键的是，LMRing 不只是一个“多开几个模型窗口”的小工具。
它背后其实是一套完整的架构设计：
这篇文章就不只想介绍“LMRing 是什么”，
也想讲清楚：一个真正能打的多模型竞技场，到底应该怎么设计。
LMRing 是一个开源的多模型对比竞技场，你可以把它理解成一个专门给开发者和团队准备的 AI Arena。
它解决的是一个很现实的问题：
所以 LMRing 做了几件事：
换句话说，LMRing 不只是一个“多模型聊天页”，它更像是一套 模型对比 + 结果沉淀 + 团队协作 的基础设施。
因为大模型评测的重点已经变了。
过去大家更关心“模型聪不聪明”，现在更关心：
也就是说，模型评测已经从“围观式评分”变成“工程化选型”。
这时候，一张静态排行榜就不够了。
你需要的是：
这才是 LMRing 想解决的问题。
最核心的是 Arena 模式。
你可以一次选择多个模型，把同一个问题同时发出去，然后看它们实时输出。
比如这些场景都很适合拿来比：
跑一轮之后，谁理解需求更准，谁结构更清楚，谁代码更稳，基本一眼就能看出来。
但如果只是把多个回答摆在一起，这还不够。
LMRing 更关键的地方在于，它背后不是“拼页面”，而是有一套明确的架构设计。
下面就从实现角度讲讲，它是怎么做到的。
我更愿意把它拆成 4 层来看：
可以先看一张简化版结构图：
用户输入 Prompt
↓
Arena 页面创建多个独立 workflow
↓
每个 workflow 通过统一流式接口请求对应模型
↓
后端根据 keyId / provider / modelId 动态创建 provider
↓
SSE 持续返回 chunk / reasoning / complete / error
↓
前端实时渲染多个回答卡片
↓
对话、回答、投票、统计结果落库
↓
排行榜页统一展示本地投票结果 + 外部评测数据
这套设计的好处是：
这个问题本质上是：
LMRing 的做法是把“模型元数据”和“Provider 构建”拆开。
项目里有一个 model-depot 包，负责维护 Provider 和模型能力描述，比如：
这层的价值不是“聊天”，而是“定义模型能力边界”。
这样前端和后端都不需要写死一堆 if/else，而是可以基于统一元数据决定：
真正的接入发生在服务端。
LMRing 的 provider-factory 做了几件很实用的事：
keyId 拉取并解密 API KeyproxyUrl，也能正常接入这意味着项目不是只支持少数硬编码模型，而是支持：
这对真实开发环境特别重要，因为很多团队不会只用一家模型服务。
这是 LMRing 最核心的一层。
LMRing 并不是把多个模型塞进一个大请求里统一处理。
它的设计更像：
这种设计的好处很明显：
LMRing 的流式接口不是简单返回一个大文本，而是基于 SSE 做事件流传输。
服务端在 /api/workflow/stream 里会持续推送这些事件：
ttft：首 token 时间chunk：普通文本增量reasoning：推理过程增量complete：完成事件，附带 metricserror：错误信息例如：
{ "type": "chunk", "workflowId": "...", "chunk": "Hello" }
{ "type": "reasoning", "workflowId": "...", "reasoning": "Let me think..." }
{ "type": "complete", "workflowId": "...", "metrics": { "totalTime": 1820, "totalTokens": 913 } }
所以 LMRing 不只是把 token 流出来，而是把一整套工作流指标也一起流出来了。
很多多模型产品在这里会掉坑。
因为 reasoning model 和普通聊天模型，不只是输出内容不同，连参数支持都不同。
LMRing 在服务端做了专门判断：
temperaturetemperature<think> 标签里，也会被解析成独立 reasoning 事件这意味着前端不是把思维链混进正文，而是能把“回答”和“推理过程”分开处理。
这对做多模型对比很重要。
因为开发者很多时候不只看最终答案，还会看模型“是怎么想出来的”。
如果后端只是能流式返回，那还不够。
前端体验如果做不好，多模型对比会非常卡。
LMRing 在前端 workflow 执行这层做了几个比较合理的设计。
每个 workflow 都会保存：
也就是说，在 Arena 页里，每一列并不是一个“纯 UI 卡片”，而是一套完整的状态单元。
流式输出如果每来一个 token 就直接 setState，前端会非常容易抖动。
LMRing 在 useWorkflowExecution 里不是直接把每个 chunk 都打进组件，而是先放进 buffer，再通过 requestAnimationFrame 批量刷新。
这个设计的价值很实际：
这类细节往往不容易在产品截图里看出来，但体验差异其实非常明显。
这个点我觉得很巧。
很多应用会在用户点击发送的那一刻立即建会话。
LMRing 则更谨慎：如果是新会话，它会等到首个 chunk 到来后，再触发 conversation 创建和消息持久化。
这样做的好处是：
这就是一个非常典型的“为了真实使用体验而做的架构细节”。
如果想让模型对比不只是即时体验，而是能长期沉淀，就必须把数据结构设计好。
LMRing 的数据库拆分得很清楚，核心几张表基本能看出产品设计思路：
保存会话主记录，对应一个完整对话线程。
保存每一轮用户或系统消息，包括用户上传的附件信息。
这张表很关键。
它不是把所有模型回答塞进一条消息里，而是为每个模型单独保存一条 response，包含：
modelNameproviderNameresponseContentattachmentstokensUsedresponseTimeMsdisplayPosition这意味着每个模型输出天然是“可独立管理、可独立统计”的。
投票不是简单记一个“我喜欢 A”。
LMRing 会先记一条 vote 主记录，再把每个参与模型的结果分开记录成：
winnerlosertieall_bad这让后续统计非常灵活。
因为系统不仅知道“谁赢了”，还知道“参与者是谁”“其他人输没输”“是不是平局”“是不是全不行”。
投票结果不会只停留在明细层。
系统还会把比较结果汇总成统计表，保存：
这说明 LMRing 不是把“投票”当一个装饰按钮，而是真把它设计成排行榜和长期统计的基础。
LMRing 的排行榜不是单一来源。
它本质上有两种数据视角：
这是前面说的本地比较结果。
它代表的是你和你的用户在真实 Prompt 下的偏好。
这部分适合回答：
Leaderboard 页面同时接了 ZeroEval 的外部评测数据，并且通过自己的 API route 做了一层代理：
/api/zeroeval/arena-scores/api/zeroeval/magia/leaderboard这层代理不是多余的，它解决了几个问题：
页面层则基于分类配置，把不同能力的评测结果组织起来，例如：
这样 Leaderboard 就不只是“一个表”，而是一个可以切维度、切图表视图、按指标排序的评测面板。
因为 LMRing 从一开始就不是按“聊天页面”做的，而是按“工作流系统”做的。
这一点从几个地方能看出来。
在校验层里，文本消息、图片附件、响应附件都有独立 schema。
工作流请求也支持 attachments，而不是把多模态内容硬塞进纯文本字段里。
项目里还有一个独立的 video-runtime 包，用来封装多 Provider 视频生成能力。
这不是在聊天逻辑里硬扩出来的，而是单独抽成了 runtime 层。
这意味着：
数据库里还有 webdev_sessions、webdev_responses、webdev_iterations 这类表。
这说明项目已经在往“多任务形态”扩展，而不是只围绕 chat 做增强。
也就是说，LMRing 的真正方向并不是“把聊天做花”，而是把各种 AI 生成任务都纳入一个统一竞技场。
很多人第一次看 LMRing，可能会觉得它只是一个“多模型对比 UI”。
但对开发者和团队来说，自部署能力往往比 UI 更重要。
因为一旦进入真实业务场景，你会很在意这些问题：
LMRing 在这些点上其实都给了比较明确的扩展空间：
这意味着它不是只能做“公开演示站”，也适合往团队内部评测工具演进。
你能得到的是一个真正可复用的模型实验台，而不是临时截图工具。
你可以：
你得到的更像一套 AI 选型基础设施。
你可以：
当模型越来越多、版本越来越快时，这种“基础设施化能力”会比单次热榜更有长期价值。
因为未来大家讨论模型，不会再只围绕一句“谁最强”。
真正重要的是：
这类问题不能靠别人替你回答。
你需要的是一个能自己验证、自己沉淀、自己扩展的平台。
LMRing 想做的，正是这件事。
它不是想宣布某个模型永远第一，而是想让你拥有自己建立判断的能力。
大模型圈最不缺的，就是“谁最强”的标题。
今天是 GPT-5.4，
明天可能是 Claude 4.6，
后天也许又轮到 Gemini 3.1 Pro 或 GLM 5.0。
热点会一直变，版本会一直更，榜单也会一直刷新。
但有一件事不会变：
因为别人测的是别人的任务，
别人的提示词，
别人的标准，
别人的业务场景。
真正对你有意义的，只能是你自己跑出来的结果。
这也是我觉得 LMRing 值得做、也值得被更多开发者看到的原因。
它不是在制造又一个“热闹排行榜”，
而是在尝试把一件原本很主观、很碎片化、很容易被营销裹挟的事情，重新做成一个可验证、可复盘、可沉淀、可协作的系统。
如果你只是想随手玩一下多模型对比，它可以是一个很好用的 Arena。
如果你是认真做 AI 产品的开发者，它也可以继续长成你的模型评测工作台。
如果你在团队里负责选型，它甚至可以成为一套内部的 AI 评估基础设施。
所以，与其继续刷“某某模型登顶”的帖子，
不如换一种方式：
把你真正关心的问题丢进去，
同时跑几个模型，
看输出、看推理、看投票、看排行，
然后用你自己的结果做决定。
这可能比看一百篇“年度最强模型榜”都更有用。
如果你也在做 AI 应用，或者正在纠结团队该接哪家模型，欢迎来试试。
下一次再看到“谁第一”的标题时，你至少可以先说一句：
别吵，先跑。
Cursor 和 Claude Code：AI 编程的两种哲学
Day10 学习日志：用 LangChain 搭一套可落地的**制度 RAG**（检索 + 生成）
