<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom" xmlns:content="http://purl.org/rss/1.0/modules/content/"><channel><title>SGLang on Hypho - AI Agent 技术博客</title><link>https://blog.hypho.cn/tags/sglang/</link><description>Recent content in SGLang on Hypho - AI Agent 技术博客</description><image><title>Hypho - AI Agent 技术博客</title><url>https://blog.hypho.cn/papermod-cover.png</url><link>https://blog.hypho.cn/papermod-cover.png</link></image><generator>Hugo -- 0.148.2</generator><language>zh-cn</language><lastBuildDate>Wed, 22 Apr 2026 10:07:05 +0800</lastBuildDate><atom:link href="https://blog.hypho.cn/tags/sglang/index.xml" rel="self" type="application/rss+xml"/><item><title>Kimi K2 API厂商精度大考：有人100%，有人76%</title><link>https://blog.hypho.cn/posts/k2-vendor-verifier-api-precision/</link><pubDate>Wed, 22 Apr 2026 10:07:05 +0800</pubDate><guid>https://blog.hypho.cn/posts/k2-vendor-verifier-api-precision/</guid><description>MoonshotAI开源的K2 Vendor Verifier揭示了一个严重问题：同一套Kimi K2模型，经不同厂商API分发后，toolcall精度差异巨大——官方100%，部分厂商仅76%。问题出在哪？</description><content:encoded><![CDATA[<p>你选了一个Kimi K2的第三方API提供商，省了30%的成本。结果线上agent跑着跑着开始乱调用工具——你以为模型有问题，实际是API供应商的工程实现挖的坑。</p>
<p>这不是段子，是真实发生的。MoonshotAI最近开源的 <a href="https://github.com/MoonshotAI/K2-Vendor-Verifier">K2 Vendor Verifier</a>（551 Stars）干了一件事：他们对市面上的Kimi K2第三方API做了套标准化精度测试，结果发现同样一个模型，经不同厂商分发后，toolcall精度可以从100%掉到76%。</p>
<h2 id="背景k2的核心能力就是toolcall">背景：K2的核心能力就是toolcall</h2>
<p>Kimi K2是MoonshotAI发布的专注于Agent场景的LLM。什么叫&quot;专注Agent&quot;？说白了就是它的核心能力不是聊天，而是<strong>toolcall</strong>——让模型学会调用外部工具完成复杂任务。</p>
<p>这类能力对精确度要求极高。一次toolcall失败，可能导致整个agentic loop崩溃：</p>
<ul>
<li>工具ID格式错误 → 解析异常</li>
<li>JSON Schema不匹配 → 调用参数丢失</li>
<li>触发时机错误 → 该调工具时模型&quot;停了&quot;</li>
</ul>
<p>所以K2的toolcall精度不是&quot;体验问题&quot;，是&quot;能不能用&quot;的问题。</p>
<h2 id="测试方法和官方api同题作答">测试方法：和官方API同题作答</h2>
<p>K2VV的测试思路很直接：用同一套4000条测试请求，分别走官方MoonshotAI API和各第三方厂商API，对比toolcall结果。</p>
<p>核心指标就两个：</p>
<p><strong>① tool_call_f1（触发精度）</strong>
模型该不该调用工具、该调用哪个工具。用F1分数衡量，和官方API对比。</p>
<p><strong>② schema_accuracy（Schema符合度）</strong>
模型决定调用工具了，但它生成的JSON参数对不对。用通过schema验证的比例衡量。</p>
<p>结果？差异触目惊心。</p>
<h2 id="数据说话同卷不同分">数据说话：同卷不同分</h2>
<p>K2-thinking版本（temperature=1.0，max_tokens=64000）的成绩单：</p>
<table>
  <thead>
      <tr>
          <th>厂商</th>
          <th>schema_accuracy</th>
      </tr>
  </thead>
  <tbody>
      <tr>
          <td>MoonshotAI（官方）</td>
          <td><strong>100%</strong></td>
      </tr>
      <tr>
          <td>Fireworks</td>
          <td>100%</td>
      </tr>
      <tr>
          <td>InfiniAI</td>
          <td>99.89%</td>
      </tr>
      <tr>
          <td>SiliconFlow</td>
          <td>98.96%</td>
      </tr>
      <tr>
          <td>GMICloud</td>
          <td>95.95%</td>
      </tr>
      <tr>
          <td><strong>vLLM（自托管）</strong></td>
          <td><strong>87.22%</strong></td>
      </tr>
      <tr>
          <td>DeepInfra</td>
          <td>86.91%</td>
      </tr>
      <tr>
          <td>GoogleVertex</td>
          <td>85.76%</td>
      </tr>
      <tr>
          <td>Together</td>
          <td>84.63%</td>
      </tr>
  </tbody>
</table>
<p>vLLM自托管版本，schema精度只有87%——意味着每100次toolcall，13次生成的参数过不了schema校验。这在生产环境里是什么概念？你的agent每天跑1000次toolcall，有130次会在运行时崩溃。</p>
<p>K2-0905-preview版本（temperature=0.6）的数据更明显：</p>
<table>
  <thead>
      <tr>
          <th>厂商</th>
          <th>schema_accuracy</th>
      </tr>
  </thead>
  <tbody>
      <tr>
          <td>MoonshotAI（官方）</td>
          <td><strong>100%</strong></td>
      </tr>
      <tr>
          <td>SGLang（自托管）</td>
          <td><strong>73.13%</strong></td>
      </tr>
      <tr>
          <td>vLLM（自托管）</td>
          <td><strong>76.00%</strong></td>
      </tr>
      <tr>
          <td>Volc</td>
          <td>72.86%</td>
      </tr>
  </tbody>
</table>
<p>SGLang和vLLM这两个最流行的开源推理框架，精度都没过80%。</p>
<h2 id="根因分析三个工程坑">根因分析：三个工程坑</h2>
<p>K2VV的维护者直接点名了三个最常见的问题：</p>
<p><strong>① 推理引擎版本不对</strong></p>
<p>K2对vLLM和SGLang的版本有明确要求：</p>
<ul>
<li>K2-0905需要 <a href="https://github.com/vllm-project/vllm/releases/tag/v0.11.0">vLLM v0.11.0+</a> 或 <a href="https://github.com/sgl-project/sglang/releases/tag/v0.5.3rc0">SGLang v0.5.3rc0+</a></li>
<li>K2-thinking需要 v0.11.1rc6+ 和 SGLang v0.5.5.post2+</li>
</ul>
<p>很多自托管用户跑的是旧版本，模型权重对齐不完整，自然精度下滑。</p>
<p><strong>② Tool Call ID格式问题</strong></p>
<p>K2模型要求历史消息里所有tool call的ID必须符合 <code>functions.func_name:idx</code> 格式（如 <code>functions.search:0</code>）。但很多测试用例集里的格式是错的（如 <code>search:0</code>），导致模型生成了一批格式不统一的ID，后续解析直接失败。</p>
<p>官方API在调用前会统一做ID重写，但自托管方案往往漏掉了这一步。</p>
<p><strong>③ 没有 Guided Decoding（填空式生成）</strong></p>
<p>这是最关键的一个问题。LLM是逐token生成的，没有任何机制能&quot;保证&quot;输出符合JSON Schema。再怎么写prompt，模型偶尔也会漏字段、加多余字段、嵌套错误。</p>
<p>正确的做法是加guided decoding——让推理引擎在生成阶段就约束输出格式，确保每一步token都在schema范围内。很多自托管方案没有这个配置。</p>
<p>K2VV的文档里给了一段配置示例：</p>
<div class="highlight"><pre tabindex="0" class="chroma"><code class="language-bash" data-lang="bash"><span class="line"><span class="cl">python tool_calls_eval.py samples.jsonl <span class="se">\
</span></span></span><span class="line"><span class="cl"><span class="se"></span>    --model kimi-k2-0905-preview <span class="se">\
</span></span></span><span class="line"><span class="cl"><span class="se"></span>    --base-url https://api.moonshot.cn/v1 <span class="se">\
</span></span></span><span class="line"><span class="cl"><span class="se"></span>    --api-key YOUR_API_KEY <span class="se">\
</span></span></span><span class="line"><span class="cl"><span class="se"></span>    --concurrency <span class="m">5</span>
</span></span></code></pre></div><p>如果你要比对OpenRouter上的其他厂商，加一个 <code>provider.only</code> 参数即可。</p>
<h2 id="工程化建议选型时把这个benchmark列入清单">工程化建议：选型时把这个benchmark列入清单</h2>
<p>如果你正在选型Kimi K2的API供应商，或者打算自托管K2，有几点建议：</p>
<p><strong>第一，先问清楚他们用的是哪个推理引擎和版本。</strong> 拿着K2VV的<a href="https://github.com/MoonshotAI/K2-Vendor-Verifier#suggestions-to-vendors">版本要求</a>去问，答不上来的供应商可以直接排除。</p>
<p><strong>第二，对于成本敏感型场景，OpenRouter多厂商比价是有意义的，但精度要自己测。</strong> K2VV放出了一部分<a href="https://statics.moonshot.cn/k2vv/tool-calls.tar.gz">测试数据集</a>，你可以用自己的case跑一遍，对比官方API和你选中的供应商。</p>
<p><strong>第三，自托管用户务必开启guided decoding。</strong> vLLM和SGLang都支持在serving时配置JSON schema约束，这是唯一能保证toolcall schema精度的工程手段。</p>
<h2 id="数据集和工具">数据集和工具</h2>
<p>K2VV已开源，包含完整的评测脚本和部分测试数据（4000条中的50%）。如果你关心K2的toolcall精度，或者你正在做API供应商的选型，这个仓库值得你花半小时跑一遍：</p>
<ul>
<li><strong>GitHub</strong>: <a href="https://github.com/MoonshotAI/K2-Vendor-Verifier">https://github.com/MoonshotAI/K2-Vendor-Verifier</a></li>
<li><strong>技术博客</strong>: <a href="https://www.kimi.com/blog/kimi-vendor-verifier">https://www.kimi.com/blog/kimi-vendor-verifier</a></li>
<li><strong>测试数据集下载</strong>: <a href="https://statics.moonshot.cn/k2vv/tool-calls.tar.gz">https://statics.moonshot.cn/k2vv/tool-calls.tar.gz</a></li>
</ul>
<hr>
<p><em>评测数据来源：K2 Vendor Verifier GitHub README，测试时间2025-11-15。精度数据为原项目披露信息，生产环境实测结果可能有所差异。</em></p>
]]></content:encoded></item></channel></rss>