VLLM

AI 芯片为什么越来越像内存生意？从 HBM 成本看 LLM 推理的真正瓶颈 Gemma 4 的多 token 预测：LLM 推理加速不该只盯着量化 KV-cache 量化为什么一直"不敢开" 做过 vLLM 生产部署的人大概都纠结过一个问题：context 越来越长，KV-cache 吃掉的 GPU 显存越来越多，但官方文档里那个 --kv-cache-dtype 参数，你真的敢在生产环境打开吗？ vLLM 团队今年 5 月发了一篇 TurboQuant 的系统性基准测试1，结论相当诚实：除了 FP8 之外，所有 KV-cache 量化方案都在"拿吞吐量换容量"。具体来说： TurboQuant 4bit-nc：最高 3.4 倍 KV-cache 容量，但吞吐量损失 40-52%，延迟增加最高 60% TurboQuant 3bit-nc：精度大幅下降，推理和长上下文任务表现尤其差 FP8：2 倍容量，吞吐量基本无损，但容量增幅有限 说白了就是：你要么选 FP8（安全但只翻倍），要么选更激进的量化（容量大但吞吐暴跌）。在推理密集型场景——比如长上下文 Agent、代码生成、数学推理——吞吐量下降意味着请求排队变长、用户等待变久，这在生产环境是不可接受的。 所以 vLLM 官方的建议一直是：默认用 BF16，显存不够就用 FP8，其他量化方案慎用。 这就是 KVarN 想解决的问题。 KVarN 是什么：华为的 KV-cache 量化新方案 KVarN（读作 /kvɑːɳ/，瑞典语"研磨机"的意思）来自华为通讯系统实验室（Huawei CSL），论文在 arXiv 上2，代码以 Apache 2.0 开源在 GitHub3，目前 196 星，最新提交就在今天。 ...

你选了一个Kimi K2的第三方API提供商，省了30%的成本。结果线上agent跑着跑着开始乱调用工具——你以为模型有问题，实际是API供应商的工程实现挖的坑。 这不是段子，是真实发生的。MoonshotAI最近开源的 K2 Vendor Verifier（551 Stars）干了一件事：他们对市面上的Kimi K2第三方API做了套标准化精度测试，结果发现同样一个模型，经不同厂商分发后，toolcall精度可以从100%掉到76%。 背景：K2的核心能力就是toolcall Kimi K2是MoonshotAI发布的专注于Agent场景的LLM。什么叫"专注Agent"？说白了就是它的核心能力不是聊天，而是toolcall——让模型学会调用外部工具完成复杂任务。 这类能力对精确度要求极高。一次toolcall失败，可能导致整个agentic loop崩溃： 工具ID格式错误 → 解析异常 JSON Schema不匹配 → 调用参数丢失 触发时机错误 → 该调工具时模型"停了" 所以K2的toolcall精度不是"体验问题"，是"能不能用"的问题。 测试方法：和官方API同题作答 K2VV的测试思路很直接：用同一套4000条测试请求，分别走官方MoonshotAI API和各第三方厂商API，对比toolcall结果。 核心指标就两个： ① tool_call_f1（触发精度） 模型该不该调用工具、该调用哪个工具。用F1分数衡量，和官方API对比。 ② schema_accuracy（Schema符合度） 模型决定调用工具了，但它生成的JSON参数对不对。用通过schema验证的比例衡量。 结果？差异触目惊心。 数据说话：同卷不同分 K2-thinking版本（temperature=1.0，max_tokens=64000）的成绩单： 厂商 schema_accuracy MoonshotAI（官方） 100% Fireworks 100% InfiniAI 99.89% SiliconFlow 98.96% GMICloud 95.95% vLLM（自托管） 87.22% DeepInfra 86.91% GoogleVertex 85.76% Together 84.63% vLLM自托管版本，schema精度只有87%——意味着每100次toolcall，13次生成的参数过不了schema校验。这在生产环境里是什么概念？你的agent每天跑1000次toolcall，有130次会在运行时崩溃。 K2-0905-preview版本（temperature=0.6）的数据更明显： 厂商 schema_accuracy MoonshotAI（官方） 100% SGLang（自托管） 73.13% vLLM（自托管） 76.00% Volc 72.86% SGLang和vLLM这两个最流行的开源推理框架，精度都没过80%。 根因分析：三个工程坑 K2VV的维护者直接点名了三个最常见的问题： ...