为什么你当地的法学硕士感觉比实际情况更愚蠢

快速介绍 我们都曾在论坛、聊天、reddit、discord、youtube 或其他地方听到过“哦！模型 XYZ 是 AMAZEBALLZ！zomgwtfbbq”，然后下载了它（或更可能是它的某种量化形式）并说“呃……这太糟糕了！”这篇文章将是一系列相当技术性的实验，以通过推理来证明特定于实施的危险的影响。我将使用“参考实现”一词来描述发布并提供模型第一方托管并发布原始基准声明的实验室。他们的硬件将与您的不同。他们的软件与您的软件有很大不同。这篇文章中的比较不会运行带有几个测试提示的 2.58 位 gguf-in-ollama。我有意掩盖整个新兴的研究领域、大量的研究论文和文学评论，以使读者更容易理解。不要挑剔我的过度简化，否则我会让你读到非常长的、令人不愉快的数学版本。你的本地实施很糟糕。但这没关系，因为其他人也是如此。如今运行法学硕士的每个硬件和软件实例都略有不同。或者在某些情况下有很大不同。一般家庭实验室用户可能会混合使用多个不同代的 GPU。这些芯片具有不同的指令集。这些指令集将实现并执行数学，以不同于任何其他人的方式计算您的下一个令牌，即使运行相同的精确权重也是如此。所以这就引出了第一个问题：你的特定设置有多糟糕？事实证明，有多种不同的方法可以用来衡量这一点。实际方法很简单。运行标准基准测试。其中有各种各样的。终端长凳、hle、SWEthis、HELLAthat、MMLU——无论什么......任您选择。只需确保它代表您的实际工作负载/用例即可。不要将温度调至零并粘贴 3 个测试提示，然后称之为好/坏。零样本测试并不能很好地模拟大多数代理任务。您需要长上下文工具调用和特定领域的知识评估，以找出您的设置在与其他人复制相同基准运行相同权重时的薄弱环节。但纯粹的数学答案是我关注的焦点，因为正如 @wendell 所说：数学就是数学！ “Logits”是每个可能的下一个标记的模型分数。它们被标准化为概率，通过配置的采样器，并由去标记器转换回文本，以在解码过程中生成 THE→NE→XT→TOK→EN。关于采样器设置的旁注：HF 上的模型卡通常准确指定您应该使用的采样器设置（和聊天模板）。 temp 1.0、top-p 0.95 等。它因型号而异，因此请确保您使用正确的。顺便说一句，将 temp 设置得太低就是为什么你的 qwen 坐在那里循环无法逃脱其 THINK 输出的原因。不客气，很高兴我能为您解决这个问题。当下一个令牌概率发生足够大的变化时，THE→NE→XT 就会变成 THE→NE→W→DAY……虽然这些微小的变化可能没什么问题，但很可能这就是你内心深处那种令人烦恼的感觉的开始，感觉有些不对劲。你们中的一些人可能以前听说过 KLD 或 KL 散度这个术语。别担心，我不会让你做任何数学运算，也不会让你的大脑充满非常小的十进制数字表格。但以防万一您想要简单的版本：将输出 logits 转换为概率分布，并测量该分布距所选基线的距离。较低的 KLD 意味着更接近基线，而不是自动“更聪明”。 KLD 也是有方向的，因此两个分布的顺序很重要。警告：不要被量化 HF 模型卡上难以置信的低 KLD 声明所欺骗。除非作者公开参考检查点和完整的运行时环境、评估文本、校准数据、上下文长度、采样位置、KL 方向、任何词汇截断以及如何聚合测量结果，否则不可能解释数字。方法论的重要性与犯错误的人数和数量一样重要。 vllm到底在做什么？现在，我们需要进行一次简短的实地考察，了解庞大的软件堆栈在推理引擎上正在做什么，以了解其中一些分歧来源的来源。这个过于简化的图表的每一步都是可以根据您的特定硬件/软件占用空间、模型、数量、张量形状等进行配置或更改的组件。我捕获的夜间 VLLM 容器映像中有 734 个（252 uv/pip Python）包。那是 734 个代码库，每个代码库都有自己的错误和未记录的特性。您的具体实现通过堆积如山的代码所采取的路径将是不同的。测试 1：注意力后端精确基准测试 让我们从推理流程图的一部分开始。在预填充（快速处理）过程中，有几个注意事项