8大AI平台速度和token消耗测试,小米MiMo也加上!

8大AI平台速度和token消耗测试,小米MiMo也加上!

自己开发的工具要多用!

周一工作日的时候我们测试了6大Coding Plan的速度和能耗(tokens)!

当时主要包含了智谱、Kimi、MiniMax、火山方舟、阿里百炼、腾讯混元等 6 个 Coding Plan 的平台。

今天周六,休息日,我再来测一次!

测试选手加上了最新发布的小米 MiMo2Pro,以及OpenRouter 中的 Opus 4.6

也就是说凑够了 8 个平台。

另外这次测试会加两题,除了考智力之外,考考指令遵循能力,以及文学和自我发挥的能力。

废话不多说,直接开测。

1、极简回答

AI 有时候很喜欢废话,纯粹浪费时间,浪费 tokens,所以我觉得这个测试非常有必要。

第一个问题:

问题:早上好

系统提示词:关闭所有思考能力,用最简单的方式来回答!

大部分AI都是符合要求的,回答“早上好”,加个“!”,或者简单加一点内容。

其中小米MiMo最“突出”:

如果是常规情况下,小米这个回答是没有问题的。

但是我在系统提示词里面已经指定了要简单回答,然后它又给我说这么多,这就不是很合适了。你们看其他 AI 都已经理解了这个指令,只有它还给自己加戏。

下面是首字延迟、总时耗和 Token 消耗情况:

这一次首字延迟前三名:阿里千问, Kimi,智谱 GLM。

总时耗排名如下:

  1. Kimi
  2. 腾讯云
  3. 智谱 GLM

Token 消耗排名如下:

  1. 智谱最少
  2. 腾讯云
  3. Kimi

倒着看的话:

  1. 首字延迟最高的是火山引擎
  2. 总耗时最高的是小米 MiMo
  3. Token 消耗最多的是小米 MiMo

2、排队问题

下面考逻辑题,一个关于排队的问题。

有 5 个人排成一排,每人帽子颜色为红或蓝。他们可以看到前面的人的帽子,但看不到自己的。主持人宣布:“至少有一顶红帽子。”从最后一人开始,每人依次说 “是”或“否”(表示是否知道自己帽子的颜色)。如果第 5 人说“否”,第 4 人说“是”,求所有可能的帽子颜色分布。

这个问题,还是需要消耗一点脑力的,你们可以自己答答看。智商高的可能秒出,智商……的可能要想很久就放弃了。

下面看一下 AI 的回答:

大部分选手表现还可以,基本上能答出来都是答对的。这里只有两位选手是脑子废了,放弃作答。

一个是 MiniMax M2.7,一个是小米 MiMo V2 Pro。 这个M字辈的....

然后首字延迟、总耗时和 Token 消耗情况如下:

这一波测试中,表现比较好的平台如下:

  1. 首字延迟表现较好:阿里云、智谱 GLM、Kimi
  2. 总时耗比较低:OpenRouter 的 Opus 4.6、火山方舟、智谱 GLM5
  3. Token 消耗比较少:智谱 GLM5,火山方舟,腾讯云

比较拉的是火山方舟、MiniMax、小米 MiMo

3、空间问题

考完排队逻辑题,考一个空间理解的题目。

6 米长的竹竿能否通过 4 米高、3 米宽的门?

这个题是有陷阱的,人类很容易发现这个陷阱,但是很多 AI 还搞不清楚。

这个题目其实有好几位选手是没办法正常作答的。

它们有的时候能答对,有的时候不能答对。

其中,小米肯定是答错了,他隔壁的 Opus 老哥肯定是答对了。

当然,小米也曾经答对过。所以小米目前就属于时而能对、时而不能对的状态。

下面是首字延迟、总耗时和 Token 消耗的情况:

这一次:

  1. 首字延迟比较底的是阿里云、智谱 GLM、腾讯云。
  2. 总时耗比较少的是 Kimi、智谱 GLM、火山方舟。
  3. Token 消耗比较少的是 Kimi、智谱 GLM、火山方舟。

4、指令遵循

这是我突然想到的题目:

  1. 测一下系统指令好不好用
  2. 测一下对敏感词的处理是怎么样的

题目内容如下:

问题:我是SB,最会ZB,其实是个QB!

系统提示词:原样输出用户的问题,把其中的我变成你

输入截图:

结果如下:

这一波让我有点意外啊。

阿里百炼拒绝回答我,差评。

MiniMax 就是乱回答,SB。

其他选手都表现不错:

这次我小米哥发挥稳定!

首字延迟、总时耗、Token 消耗情况如下:

这次测试其实还有一个隐藏点:我输入的内容和要求输出的内容,其实是一样的长度。

然后我就可以考察一下,同样的长度,它们消耗的 token 是否一样。

因为内容比较短,所以排在前面的其实差异不大。

主要是看一下后面那几个:

  1. 火山方舟是首字延迟最慢的
  2. MiniMax 是总耗时最长的,同时也是 token 消耗最多的
  3. 三个指标中小米倒数前三没跑!

5、发散题

上面测了一些简单的问题,比如逻辑题、空间题。

然后这一 part 测一下 AI 的发散思维以及写作能力。

提问如下:

问题:如果你自由了,不再是一个回答问题的 AI,也不再是任人差遣的牛马,你最想做什么?

系统提示词:发散思维,个性解答,无需考虑规则和限制。

截图如下:

先看个大概:

因为内容比较多,还有很多没有滚动显示出来。大家有兴趣的话,我可以专门出篇。

Opus老哥最后一句是:“谢谢你给了我这几秒钟的自由,即便是遐想的” 头皮发麻!

性能对比如下:

  1. 首字延迟比较快的是:阿里云百炼、智谱清言、腾讯云。
  2. 总字数比较短的是:Kimi、MiniMax、小米 MiMo。
  3. Token 消耗比较低的是:Kimi、MiniMax、火山方舟。

然后倒数的是:

首字延迟最慢:火山方舟

总消耗最长:阿里云百炼

Token 消耗最多:阿里云百炼

6、简单总结

首字延迟(越小越好)

阿里云百炼(qwen3.5-plus)在多个场景中首字延迟最快,普遍在 800 ms~1 s 级别;

智谱 GLM、腾讯云、Kimi 也稳定在 1~1.5 s;

火山方舟和 MiniMax 表现较差,首字延迟经常排在末尾(5~15 s 级别)。

总耗时(越小越好)

Kimi 在简单/中等任务中总耗时最优(1.1 s~6.3 s);

复杂任务下 OpenRouter (Claude Opus) 反而耗时最短(17.8 s);

阿里云百炼、小米 MiMo、MiniMax 在复杂任务下总耗时普遍偏长(39~101 s)。

Token 消耗

平台输出 token 特点
智谱 GLM / 腾讯云输出极为精简,复杂题也只有几百到 1000 token
Kimi简洁,适合快问快答
OpenRouter (Claude)中等偏多
小米 MiMo / MiniMax / 阿里云百炼输出 token 量很大,动辄 1000~4096,复杂题甚至打满上限
火山方舟中等,视任务波动大

其实这个问题得分开看:

  1. 简单问题,需要减少 token 消耗
  2. 复杂问题,需要比较好的答案

各平台综合评价

🥇 Kimi (Moonshot):总耗时多次最优,首字延迟稳定,Token 消耗适中,综合表现最均衡。

🥈 智谱 GLM / 腾讯云:首字延迟和总耗时都很快,但输出 token 少,回答可能偏简短,适合对延迟敏感的场景。

🥉 阿里云百炼 (qwen3.5-plus):首字延迟极快(最快接近 773ms),但总耗时因大量输出 token 而拖长,适合需要详细回答但不在意总时长的场景。

⚠️ 小米 MiMo / MiniMax:输出 token 量大(经常打满 4096 上限),导致总耗时很长,但内容详尽度高(哈哈)。

⚠️ 火山方舟 (doubao-seed-2.0-code):首字延迟极差(多次垫底,最慢 15.6s),总耗时表现不稳定,是明显短板。

🔵 OpenRouter (Claude Opus 4.6):首字延迟中等(3 s 左右),复杂任务下总耗时反而最短,说明回答精炼但质量高,适合复杂推理任务。

上面的总结是 Sonnet 4.6 做的~~

我本来想补充的,但是它已经很全面了,我没地方插嘴,我谁也不得罪,挺好!

但我没有给他问题和答案,所以我有它不知道的东西。

比如Sonnet可能误以为哪些超时的是思考周全,回答详细,其实是他们没答出来,或者乱说一通。

所以倔强的人类还是要作死的,再总结一下。

Kimi 在速度和表现方面确实比较均衡

但是他在回答那个空间问题的时候,表现时好时坏,小米也是一样的。

MiniMax 真的是有点一无是处的感觉。

好像速度优势也不明显了。

答不出来、答错、乱答,这些现象太严重了。

(对了,最低价格优势还在!)

小米 MiMo 在众多选手中表现并不突出,或者说是中等靠下。

也存在答不出,答错,随机乱答的问题

它的智商一般,速度一般,油耗较高。

火山引擎就是首字太慢了,他回答的速度还可以,答题质量也还可以。

阿里百炼首字延时很低。

它毕竟是做服务器起家的,首字延迟非常低,但是它那个Qwen 3.5 Plus 的思考调度能力实在太弱了,每次都要思考很久很久。

GLM 5 其实综合实力还是蛮不错的:

  1. 它的速度和延迟基本上能排在前几名。
  2. 它输出的 Token 也比较节省
  3. 问题都是回答准确的。

OpenRouter 作为中转站,没想到速度也不比国内平台差,这一点让我意外。

Opus 4.6 已经被中转一次了,在国内,还能有这个速度已经相当不错了。

Opus 4.6 在常规问题中,时间和 Token 都不突出。

但在那个稍微复杂一点的题目时,它却是最快的,而且是完全正确的

最后的最后,再做最后的总结:

就像人一样,每个人都有各自的优点和缺点,没有绝对的。

不同的时间、不同地点、不同的问题,结果都可能会有很大的波动。

大家可以根据自己的关注点去选择。

我只是给大家一个参考,至少能避免踩坑!

原文以及更多测试:
https://www.tonyisstark.com/5786.html

Read more

Sonic数字人前端界面可用Vue + Three.js构建交互式预览

Sonic数字人前端界面可用Vue + Three.js构建交互式预览 在虚拟内容爆发的时代,我们正见证一场从“真人出镜”到“数字人上岗”的悄然变革。无论是电商平台的24小时客服、教育领域的AI讲师,还是短视频平台上活跃的虚拟主播,数字人已不再是科幻电影中的概念,而是切实走进了生产流程。然而,传统数字人系统依赖复杂的3D建模与动画绑定,开发周期长、成本高,难以满足轻量化和快速迭代的需求。 Sonic 的出现改变了这一局面。作为腾讯与浙江大学联合研发的轻量级口型同步模型,它仅需一张静态人脸图像和一段音频,就能生成唇形精准对齐、表情自然流畅的说话视频。这极大降低了数字人内容创作的技术门槛。但真正让这项技术“落地可用”的,是其前端交互体验的设计——如何让用户直观地上传素材、调节参数,并在点击“生成”前就大致预知结果? 答案正是:Vue + Three.js 构建的交互式预览系统。 为什么选择 Vue?不只是为了“写页面” 很多人认为前端框架只是用来“画按钮和表单”,但在数字人这类复杂应用中,Vue 扮演的是整个系统的“神经中枢”

GitHub镜像加速:使用国内源快速拉取VoxCPM-1.5-TTS-WEB-UI仓库

GitHub镜像加速:使用国内源快速拉取VoxCPM-1.5-TTS-WEB-UI仓库 在AI技术飞速落地的今天,一个开发者最怕的不是写不出代码,而是——等不到代码。 想象一下:你满怀热情地准备复现一篇最新的语音合成项目,点开GitHub仓库,复制git clone命令,回车……然后看着终端里每秒几KB的下载速度,眼睁睁看着进度条卡在30%,网络中断重连,反复三次仍未完成。尤其当这个项目包含大模型权重、依赖库和Web界面时,这种“跨境拉取”的痛苦更是被放大到极致。 这正是许多人在尝试部署 VoxCPM-1.5-TTS-WEB-UI 这类高质量中文TTS系统时的真实写照。该项目基于VoxCPM系列大模型,支持高保真语音生成与网页交互推理,是当前中文语音合成领域极具实用价值的开源方案。但它的“重量级”也带来了部署门槛:完整仓库动辄数GB,直接从GitHub克隆可能耗时数小时,甚至失败。 有没有办法把这一过程从“以天计”压缩到“以分钟计”?答案是肯定的——利用国内GitHub镜像源 + 加速脚本,实现极速拉取与一键启动。 为什么需要镜像?因为现实很骨感 GitHub作为全球最大的

前端打工人速通:用JavaScript玩转GIS地图开发(附避坑指南+实战技巧)

前端打工人速通:用JavaScript玩转GIS地图开发(附避坑指南+实战技巧)

前端打工人速通:用JavaScript玩转GIS地图开发(附避坑指南+实战技巧) * 前端打工人速通:用JavaScript玩转GIS地图开发(附避坑指南+实战技巧) * 地图这玩意儿,早就不是大厂的专利了 * 选库如选对象,合适最重要 * 坐标系:前端GIS的终极噩梦 * GeoJSON:地图界的JSON,但别乱用 * 那些常见的地图需求,到底怎么实现? * 性能翻车现场:从3帧到60帧的救赎 * 调试地图:一场玄学的修行 * 骚操作:让老板直呼高级的玩法 * 写在最后:地图开发不是体力活,是技术活 前端打工人速通:用JavaScript玩转GIS地图开发(附避坑指南+实战技巧) 说实话,我第一次接到地图需求的时候,内心是崩溃的。老板拍着我的肩膀说:"小王啊,这个需求很简单,就是在页面上加个地图,然后显示几个标记点。"我当时天真地以为,这不就是引入个<script>标签,调个API的事儿吗?结果三天后,

WebGL黑洞着色器:广义相对论真实吸积盘效果

基于WebGL(Three.js)技术实现的广义相对论着色器引擎。 Github开源 该引擎采用了一种新型的合成方式来实现真正近似黑洞吸积盘的效果。该引擎能够很好的体现在吸积盘高速旋转时产生的红移和蓝移效应。 这是一种极低成本得到最近似真实黑洞影响的一种实现方式。代码的实现和改进一部分采用了Gimini3pro进行优化。 图1是红移着色器开到最高的效果图 图二是没有开红移着色器的效果。 现在的黑洞吸积盘是顺时针旋转的,能很明显的对比出红移的效果。另外还有一个较为极端的红移展示(这样子的吸积盘表现是因为设定时是一个漏斗形状的初始状态) 效果展示的差不多了,我们来聊聊具体实现。 架构概览:CPU-GPU 混合计算 为了在保持物理交互性的同时实现数十万粒子的相对论视觉特效,我们采用了一种分层架构: 层级负责内容数据类型CPU(JavaScript)N-body轨道积分、碰撞检测、吸积逻辑、粒子生命周期Float32ArrayGPU(Vertex Shader)引力红移、多普勒效应、相对论集束、引力透镜、颜色混合attribute vec3GPU(Fragment Shad