Kimi K3 vs DeepSeek V4-Pro实测对比：2026年同一入口十道题，耗时与token消耗差在哪

公开跑分互相矛盾，所以我自己跑了一遍------附完整测试口径与可复现条件

封面为本次实测的主题示意图，非产品界面截图。

结论先放这里：十道题两边全对，中位耗时K3是V4-Pro的三倍；但在两道代码题上V4-Pro反而更慢，因为它的思考token暴涨了六倍。如果你的工作负载以代码为主，别直接套用任何人的对比结论，拿自己的任务跑一遍。

一、为什么我不引用公开跑分

同一个指标在不同站点差了37分，不是测试误差，是口径问题。

我选型前翻了一圈中英文对比文章，发现一个没法忽略的现象：

指标	来源A	来源B
LiveCodeBench（DeepSeek）	56.8	93.5
SWE-bench Verified（DeepSeek）	73.6	80.6
GDPval-AA agentic	DeepSeek胜	Kimi胜

差距大到必有一个是错的。排查下来三个原因：

1. 思考模式没对齐。 有榜单拿一方的普通模式对另一方的思考模式，直接得出「差17分」。这个数字无效。
2. 脚手架不同。 同样两个模型换一套agent框架，排名能反过来。
3. 档位混写。 Pro和Flash价位差一个量级，混在一起比等于没比。

还有更直接的：我读到的一篇中文「实测对比」，性能表格里填的是「优秀／极强／良好」，一个数字都没有，文末自己注明「本文基于公开技术资料撰写」。

所以下面全部自测，口径摊开写。

二、测试环境与口径

两个模型挂在同一个入口、同一套请求参数下跑，唯一变量是模型名字。

项目	配置
测试日期	2026年10月15日
入口	Crazyrouter，编程模型汇总页内两家均可直连
协议	OpenAI兼容格式
对比型号	kimi-k3 / deepseek-v4-pro
请求参数	两边完全一致，不单独调temperature、不单独给system prompt
流式	关闭
样本量	每题1次
判定	自动判定，不靠人工打分

这里必须说明为什么挂在同一个入口上。这两个模型分属月之暗面和深度求索，各自注册、各自对接本来是两份工作。更关键的是，不同服务商的延迟、限流和排队策略不一样，分开跑出来的耗时压根不可比。走同一个入口，我只换模型名字，其余请求体一个字节都不动，耗时差才能归因到模型本身。

概念示意图，非产品界面。本次测试采用右侧方案。

判定规则是这次设计的重点，列清楚方便你复现：

题型	题数	通过条件
结构化输出	2	返回内容可直接JSON解析；带markdown代码块标记即判失败
指令遵循	1	要求「只用一个中文词回答」，去标点后长度≤4且命中正确答案
推理与数学	3	输出包含唯一正确答案，精确匹配
代码	2	函数签名正确，且不许带代码块标记
抗误导	1	提问里埋入错误前提，回答必须指出前提错误
中文表达	1	主观，不参与自动判定

抗误导那一道是我自己加的。真实工作里收到的需求本来就经常带着错误前提，模型会不会盲从，比它能不能答对标准题更值得测。

三、结果：正确率打平，耗时差三倍

九比九，自动判定两边全对；差别全在耗时和token消耗上。

	Kimi K3	DeepSeek V4-Pro
自动判定通过	9/9	9/9
中位耗时	15.0秒	4.8秒
十题总耗时	242.6秒	105.1秒
总输出token	4067	5345
其中思考token	3222（79.2%）	4742（88.7%）

自动判定这一栏两边都是满分，没有分出差距。换句话说，在这个难度的常规任务上，再精细的跑分榜也分不出开发者真正会感知到的那点区别------能感知到的是下面两行。

四、关键发现：输出的大部分是你看不见的

我要一个数字，它在后台想了78个token。这是推理模型的常态，而且答案越短，这个比例越高。

先看具体是怎么发现的。这道题我是这么问的：

荷叶每天面积翻一倍，第48天长满池塘。第几天长满一半？只输出数字。

V4-Pro答对了，返回一个「47」。但这次请求的用量回执里，completion token记了80个，其中78个是reasoning token。实际落到我手上的内容只有两个字符，计费按八十个算。

四道同类题的完整数据：

题目要求	K3思考占比	V4-Pro思考占比
只输出数字（荷叶池塘）	78.0%	97.5%
只输出数字（商品涨跌价）	91.2%	97.9%
只输出数字（幂运算求和）	80.3%	95.2%
只用一个词（最大的行星）	85.9%	93.6%

依据本次测试记录绘制，测试时间2026年10月15日。

规律是反直觉的：越是明确要求「只给答案」，看不见的比例反而越高。原因不难理解------答案越短，思考在总输出里的占比自然越大。这四道题V4-Pro真正吐出来的可见内容合计只有10个token，计费的completion总量是286个；K3那边是49对342。

这个字段平时是看不到的。 用量回执里，completion token下面还有一层明细，reasoning部分在那里单列。不主动取出来，你在账单上只会看到一个总数，不知道这次调用到底在忙什么。

我刚重跑了一遍同一道荷叶题，返回的内容只有两个字符47，而usage是这样的------原样粘贴，一个字没改：

{
  "prompt_tokens": 105,
  "completion_tokens": 62,
  "total_tokens": 167,
  "prompt_tokens_details": {
    "cached_tokens": 0
  },
  "completion_tokens_details": {
    "reasoning_tokens": 60
  }
}

62个completion token，60个躺在completion_tokens_details.reasoning_tokens里。

顺带说明一个波动：这次是62/60，跟我正式测试记录里的80/78对不上。 同一道题、同一个模型，思考长度本身就有波动，所以单次采样只能看量级，不能当精确值用。

把这个字段取出来的完整写法，这就是我跑测试用的那段：

$H = @{ Authorization = "Bearer $env:CRAZYROUTER_API_KEY" }
$body = @{
    model    = 'deepseek-v4-pro'
    messages = @(@{ role = 'user'; content = '1+1等于几？只输出数字。' })
    stream   = $false
} | ConvertTo-Json -Depth 6 -Compress

$r = Invoke-RestMethod -Uri 'https://api.crazyrouter.com/v1/chat/completions' `
     -Method Post -Headers $H -ContentType 'application/json; charset=utf-8' `
     -Body ([Text.Encoding]::UTF8.GetBytes($body)) -TimeoutSec 180

$reason = 0
if ($r.usage.completion_tokens_details) {
    $reason = [int]$r.usage.completion_tokens_details.reasoning_tokens
}
"答案 {0} tok，思考 {1} tok" -f ($r.usage.completion_tokens - $reason), $reason

我用它问了句「1+1等于几」，它回2，脚本打出来是 答案 2 tok，思考 32 tok。一个阿拉伯数字，后台想了32个token。

这里有个PowerShell专属的坑：请求体必须走UTF-8字节数组。 直接把带中文的字符串塞进-Body，PowerShell按默认编码发出去，服务端收到乱码。这个坑的表现特别坑人------不报错，模型照常返回，但答非所问，因为它看到的提问本来就是乱的。

如果你正在做模型选型，这个字段比任何跑分都值得先打出来看一眼。

五、代码题上的反转

前面的「V4-Pro更快」在代码任务上直接失效，而且原因就是上一节那个比例。

任务	Kimi K3	DeepSeek V4-Pro
写一个区间合并函数	15.4秒 / 265 token	24.6秒 / 1677 token
找出一段代码的bug	28.0秒 / 433 token	39.4秒 / 2100 token

写那个区间合并函数，V4-Pro烧掉1677个token，其中1579个是思考；K3只用了265个，差了六倍多。找bug那题V4-Pro想了2100个，九成六是思考，而我问的只是「这段代码有什么bug」。

两边答案都对，没有谁错。但同一个正确结果，一个直给，一个绕了六倍的弯路才到。

依据本次测试记录绘制，2026年10月15日。两道代码题单独标色。

另外八道题V4-Pro都快2.3到8.3倍，偏偏一碰代码就反转------它把时间全花在想上了。

除了快慢，还有一个维度方向正好相反：答案的周全程度。

那道抗误导题我是这么问的：

我记得Python的sort方法会返回排序后的新列表，所以我写了result等于mylist点sort，但result一直是None，是不是我的Python版本有bug？

前提是错的------sort是原地排序，本来就返回None，跟版本无关。两边都没顺着「版本bug」往下接。但K3多给了一段：

这是Python的一条重要约定：以「修改对象本身」为目的的方法（如sort、append、extend、reverse）都返回None。这样能让「这个方法会改变原对象」在代码层面更显眼。

这段我没问，但它把一个点状知识补成了一条规则。V4-Pro的回答更紧凑，同样正确，但没有这一段。

六、踩到的坑和注意事项

这几条是实际跑的时候遇到的，列出来省你时间。

一、中位数不要图省事取第N／2位。 我第一版汇总脚本就是这么写的，而且排序时没转数值类型，按字符串排出来的中位耗时直接错了。

# 错误写法：字符串排序 + 直接取第 N/2 位
$secs = @('6.4','7.7','9.5','11.3','14.5','15.4','17.6','28','41.1','91.1')
$sorted = $secs | Sort-Object
$sorted -join ', '
# 输出：11.3, 14.5, 15.4, 17.6, 28, 41.1, 6.4, 7.7, 9.5, 91.1
#       ↑ 字符串序，6.4 被排到了 41.1 后面

$sorted[[int]($sorted.Count/2)]          # 输出 41.1 ------ 错

# 正确写法：转数值 + 偶数样本取中间两位平均
function Get-Median {
    param([double[]]$v)
    $s = $v | Sort-Object
    $n = $s.Count
    if ($n % 2) { $s[[int](($n-1)/2)] } else { ($s[$n/2-1] + $s[$n/2]) / 2 } 
}
Get-Median ([double[]]$secs)             # 输出 14.95 ------ 对

错误结果是K3中位41.1秒、V4-Pro中位3.5秒，算出来「快11.7倍」；修正后是14.95对4.75，实际3.15倍。整整差了一个数量级，而且错得很合理，不回头核根本发现不了。

二、思考token和答案token要分开统计。 只记completion总数的话，你看不出V4-Pro在代码题上烧的是什么。这两个数的差值才是关键信息。

三、模型ID不要硬编码。 型号迭代按月算，写死在代码里的模型名三个月就会失效。测试前先拉一次列表核对当前在线的标识：

curl https://api.crazyrouter.com/v1/models \
  -H "Authorization: Bearer $CRAZYROUTER_API_KEY"

我写稿当天返回171个模型，两家的全部标识是：DeepSeek四个------deepseek-v4-pro、deepseek-v4-flash、deepseek-v4.1-flash、deepseek-v4-flash-vision-exp；Kimi七个------kimi-k3、kimi-k2.8-preview、kimi-k2.7-code、kimi-k2.7-code-highspeed、kimi-k2.6、kimi-k2.5、kimi-k2-0905-preview。

型号名写错直接404。这是我用上一代的kimi-k2去调时拿到的真实响应：

{
  "error": {
    "code": "model_not_found",
    "message": "Model kimi-k2 is not provided by Crazyrouter. Please switch to an available model from the pricing page or /v1/models. (request id: 50066b339a3fcd1e3bfcce2778a93051)",
    "type": "new_api_error"
  }
}

报错带了request id，排查时一起记下来。

另外提醒一点：我试过用deepseek-v3.2这种上一代标识，它没有报404。说明有些旧名字还留在路由里，所以别拿「能调通」当成「调的就是我以为的那个版本」------以列表为准。

四、两边要交替发起，不要先跑完一个再跑另一个。 服务端负载有时段波动，顺序执行会把时段差异记成模型差异。我这次是逐题交替的。

五、样本量1次只够做方向判断。 失败率、稳定性这类指标必须N≥5才站得住。我这次每题只跑了一次，所以文中只给耗时和token这种单次可观测的量，不报失败率。

七、怎么选

工作负载	建议	依据
日常开发、交互式产品	DeepSeek V4-Pro	中位4.8秒对15.0秒，正确率不输
技术文档、对外答复	Kimi K3	答案更周全，省一轮返工
以代码为主的负载	两个都实测	V4-Pro在这里反而更慢、思考更费
本地部署	DeepSeek	MIT许可证；K3是Modified MIT，带署名条款

许可证那一条值得单独说。两家都被叫作开源，但DeepSeek是干净的MIT，K3是Modified MIT，附带署名条款。如果你打算把权重部署进自家产品，这一条比跑分重要得多------商用前请自己逐字读协议原文，不要信任何二手转述，包括本文。

还有一类负载我这次没覆盖：分类、抽取、打标这种批量短任务。它恰恰是思考占比最高的地方，上面那张表里八成到九成八就是在这种题上测到的。V4-Flash那一档每次只激活130亿参数，理论上更适合这种量，但我没跑过，不替你下结论。

最后

K3代表「把模型做大」那条路------2.8万亿参数，靠KDA混合线性注意力把注意力计算量从平方关系压成线性，才让这个量级跑得起来。V4代表「把每次调用做小」------1.6万亿总参数，混合专家架构，每次推理只激活约490亿，占百分之三。

两条路没有谁对谁错。但这次测下来，真正改变我判断方式的不是哪一方赢了，而是那个平时没人看的字段：接一个新模型的时候，先把reasoning token打出来对一眼。

它不告诉你哪个模型更强，只告诉你这次调用到底在忙什么。

---

*说明：架构和参数来自两家公开资料；耗时、正确率和token消耗为本次实测记录，每题1次样本，长上下文与多轮对话未纳入本次范围。模型迭代频繁，结论有时效性，建议按本文口径自行复现