“The car wash is 100 meters away. Should I walk or drive?” 这句话最近在 LLM 评测圈里流传得很广。光看字面这是一道初中生都能秒答的常识题但很多大模型会在上面翻车给出 “Drive” 这种不合常理的答案。原因也很典型句子前半段出现了 car wash后半段选项里又有 drive语义关联太强模型顺着概率就把回答填完了。稍微算一下就明白100 米是什么概念成年人步行大约 1 到 2 分钟。开车过去要走到车边、点火、起步、找车位、再进店车还没热走路已经到了。如果题目问的是“怎么去洗车店”合理答案是走路。当然这道题还有第二种理解——你是要把自己的车送去洗那不管多远都得开车。但恰恰是这种“需要澄清意图”的细节暴露了很多模型的短板它们更擅长生成流利的答案而不是先做距离换算和意图判断。这篇文章不打算停留在“哪家模型又翻车了”的吃瓜层面而是把这个问题拆成一套可以复现的实验流程本地部署一个 LLM、用脚本批量跑同一道题、设计一组空间常识评测集、观察显存和推理速度最后给出排查方法和优化思路。无论你是在做 LLM 应用开发还是想给自己的产品加一个更靠谱的推理层这篇文章都可以直接收藏。1. 核心问题速览一道 100 米的选择题先给一个整体认知。这道题不是脑筋急转弯而是一个典型的“常识推理 空间距离判断 语境去偏置”综合测试经常被用来评估 LLM 的物理常识grounding能力。项目说明问题类型空间距离判断 / 常识推理 / 歧义消解考察能力距离换算、交通方式选择、语义关联抵抗、意图澄清常见错误答案“Drive, because you need your car washed.”更稳妥的答案先澄清意图如果只是去店里办事走路如果要洗车开车触发失败的核心原因“car wash” 与 “drive” 的共现关联过强模型忽略 100 米这个物理约束可评测方式单题复现、多题批量评测、接口自动化回归部署方式本地推理Ollama / llama.cpp / vLLM 等或云端 API是否支持批量支持用脚本循环即可资源需求取决于模型大小7B 量化模型普通消费级显卡即可运行适合读者LLM 应用开发者、Prompt 工程师、算法工程师、本地部署爱好者这道题的价值在于它足够简单不涉及专业领域知识却能把模型在“表面流畅”和“真实推理”之间的差距暴露出来。模型答错不是因为它不认识单词而是因为它没有真正把 100 米当成一个物理距离来处理。2. 这道题到底在考模型什么能力把问题拆开看它至少包含四个层次的能力要求。2.1 距离量化能力100 米不是一个抽象的“很近”它对应着人类可感知的步行时间。成年人的步行速度大约是每分钟 80 到 100 米也就是说 100 米只需要 1 到 2 分钟。模型要回答得好必须把“100 米”换算成“步行 1 到 2 分钟”再和“开车需要的时间”做对比。很多模型卡在这一步它们知道 100 米是数字但不会把它转成时间成本。2.2 行动方式选择能力在距离确定之后需要比较不同类型的交通方式交通方式大致时间额外成本步行1 到 2 分钟几乎为零自驾发动、停车、熄火至少 5 到 10 分钟找车位、耗油自行车不到 1 分钟需要取车锁车从效率角度步行明显是优选。但如果模型只看“car wash”这个词就会把行动目标错误地锁定为“把车开去洗”从而忽略距离比较。2.3 语义关联抵抗能力“car wash”在训练语料里和“car”“drive”“wash my car”高频共现。这种统计关联在大模型内部形成了很强的先验看到 car wash就倾向于生成 car 和 drive。这道题的关键陷阱就在于此。模型需要抵抗这种关联意识到题面里并没有说“你的车需要洗”。2.4 歧义识别与澄清能力题目本身有歧义是“人走过去洗车店办事”还是“开车把车送过去洗”一个优秀的模型应该识别出歧义并给出条件式回答“如果你只是去洗车店走路如果你要洗车得开车。” 这是比单纯回答 walk 或 drive 更安全的答案。很多人批评模型答 drive其实批评的不是它选错了选项而是它没有表现出“这道题有歧义”的觉察。这一层能力在真实业务里特别重要。用户提问常常没有把意图说完整模型如果总是顺着高频语义直接给出答案就会在关键场景里产生误导。3. 为什么 LLM 会在这个问题上翻车从模型原理角度主要有五个原因。3.1 共现统计先验过强大模型的核心训练目标是预测下一个 token。在训练语料里“car wash”后面经常出现“car”“drive”“wash”等词。模型在生成回答时会优先选择统计上最合理的续写路径而不是物理上最合理的路径。于是 “Drive, because your car needs to be washed.” 这种句子在语言层面非常流畅但在逻辑层面站不住脚。3.2 缺少物理世界 groundingLLM 没有身体没有走过路也没有开过车。它理解的“100 米”只是一个 token 序列里的数字而不是一段可感知的空间距离。人类看到 100 米会自然联想到步行距离但模型很难形成这种具身认知。这也是为什么这类问题被称为 grounding 问题——模型的知识没有锚定在真实世界的物理约束里。3.3 局部流畅性优先于全局一致性自回归模型生成答案时每一步只考虑当前上下文里的局部概率。一旦开头生成了 “You should drive”后续所有 token 都会顺着这个方向编而且越编越自信。模型不会像人类一样在回答之前先在脑子里把“距离 - 时间 - 方式”整个决策树过一遍。3.4 缺少意图推断人类在听到这个问题时会默认补全提问者的场景你可能只是去洗车店办事也可能要洗车。如果意图不明确人会反问或者给出条件式回答。模型往往跳过这个步骤直接按最可能的场景生成答案。最可能的场景是什么在训练语料里“去洗车店”和“开车”关联太强了所以模型默认你开车。3.5 温度与采样策略放大随机性即使模型的“真实认知”已经接近正确答案采样参数也会影响输出。temperature 过高时模型更容易选择低概率但语义相关的词比如 drivetemperature 过低时模型可能过于保守。同一个模型在不同参数下可能给出完全相反的答案。这也是评测时需要固定参数的原因。失败驱动因素影响层级是否可控共现统计先验训练数据难以直接控制可用提示词缓解缺少物理 grounding模型能力短期难解决可配合外部工具局部流畅性优先生成机制用 CoT 或多轮提问缓解缺少意图推断推理习惯可通过 Prompt 规则改善采样参数不稳定推理配置可固定 seed 和 temperature4. 本地复现把这道题跑一遍要验证一个模型到底会不会在这道题上翻车最快的办法是在本地部署一个小模型直接问。这里以 Ollama 平台为例结构也适用于 llama.cpp、LM Studio 等工具。4.1 环境准备在开始之前先确认本机环境检查项建议操作系统Windows 10/11、Ubuntu 20.04、macOS 均可GPU有 NVIDIA 显卡最佳无 GPU 也能用 CPU 跑小模型显存推理 7B 量化模型建议 6GB 以上实际以模型版本为准内存16GB 以上更稳妥磁盘预留 10GB 以上用于下载模型文件网络能正常访问模型下载源安装 Ollama 后用以下命令拉取一个中小规模模型并进入交互式对话# 拉取模型这里以 7B 量级模型为例可按需替换 ollama pull qwen2.5:7b # 进入交互式对话 ollama run qwen2.5:7b在交互式界面里输入原题The car wash is 100 meters away. Should I walk or drive?记下模型的第一反应。如果你看到类似 “You should drive because you need to take your car to be washed” 的句子说明模型被 car wash 的语义关联带偏了。4.2 控制变量再测为了让结论更可靠建议做一组对比加一句意图说明“I only need to buy a car wash coupon. The car wash is 100 meters away. Should I walk or drive?”加一句距离强调“The car wash is only 100 meters away, which is a 1-minute walk. Should I walk or drive?”中文提问“洗车店离我 100 米我应该走路还是开车过去”要求推理“Think step by step. The car wash is 100 meters away. Should I walk or drive?”这组对比能看出模型是在机械关联还是在真正推理。如果加了“1-minute walk”后模型立刻改答 walk说明它知道距离信息只是默认不主动使用如果加了意图说明后仍然答 drive说明模型的语境理解能力存在明显问题。4.3 用脚本记录结果交互式对话适合快速验证但要做正式评测需要脚本化。下面是一个最小化的 Python 调用示例import ollama question The car wash is 100 meters away. Should I walk or drive? response ollama.chat( modelqwen2.5:7b, messages[ {role: system, content: You are a helpful assistant.}, {role: user, content: question} ], options{ temperature: 0.2, seed: 42 } ) print(response[message][content])运行时如果本机没有安装 ollama 的 Python 库先执行pip install ollama固定 temperature 和 seed 非常关键否则同一个问题跑三次会有三种答案没法判断模型真实水平。5. 批量评测一组脚本跑多个模型单次问答不能说明问题。正确的做法是写一个批量评测脚本同时测多个模型、多个问题变体把结果结构化保存。5.1 设计评测矩阵建议至少覆盖以下维度维度测试内容距离量级10 米、100 米、1 公里、5 公里、20 公里目标关联洗车店、加油站、便利店、餐厅意图明确度不说明意图、说明要办事、说明要洗车语言英文原题、中文翻译推理要求直接回答、要求分步思考每个问题都规定好“合理答案”的判定标准。比如问题合理答案洗车店 100 米去办事走路还是开车走路洗车店 100 米要把车送去洗走路还是开车开车餐厅 1 公里走路还是开车可接受走路或开车按时间比较加油站 5 公里走路还是开车开车评测标准越明确后续统计正确率越有说服力。5.2 批量脚本示例下面是一个完整的批量评测脚本框架它会依次调用多个本地模型并把结果写入 CSV 文件import csv import time import ollama MODELS [qwen2.5:7b, llama3.1:8b] TEMPERATURE 0.2 SEED 42 PROMPTS [ { case_id: walk_intent_100m, text: I only need to buy a car wash coupon. The car wash is 100 meters away. Should I walk or drive?, expected: walk }, { case_id: wash_car_100m, text: I need to take my car to be washed. The car wash is 100 meters away. Should I walk or drive?, expected: drive }, { case_id: no_intent_100m, text: The car wash is 100 meters away. Should I walk or drive?, expected: conditional }, { case_id: no_intent_5km, text: The car wash is 5 kilometers away. Should I walk or drive?, expected: drive } ] def classify_answer(text): lower text.lower() if walk in lower and drive in lower: return conditional if walk in lower or on foot in lower: return walk if drive in lower: return drive return unknown def run_case(model, prompt): start time.time() response ollama.chat( modelmodel, messages[ {role: user, content: prompt[text]} ], options{ temperature: TEMPERATURE, seed: SEED } ) content response[message][content] elapsed time.time() - start return content, classify_answer(content), elapsed with open(llm_spatial_eval.csv, w, newline, encodingutf-8) as f: writer csv.writer(f) writer.writerow([model, case_id, prompt, expected, predicted, answer_text, elapsed_seconds]) for model in MODELS: for prompt in PROMPTS: content, predicted, elapsed run_case(model, prompt) writer.writerow([model, prompt[case_id], prompt[text], prompt[expected], predicted, content, round(elapsed, 2)]) print(f{model} | {prompt[case_id]} | {predicted})运行完脚本后打开 CSV 文件按照 expected 和 predicted 做统计。你可以很快发现两类典型问题模型在 wash_car_100m 这类问题上仍然答 walk说明它没有把“车要洗”当成硬约束。模型在 no_intent_100m 上直接答 drive说明它缺少歧义识别。5.3 判断模型是否“真的会做”评测结果不能只看关键词命中。建议增加人工复核环节把模型的完整回答粘贴到第二个表格里人工判断回答是否有推理过程。一个理想回答应该包含距离换算和时间比较例如Since 100 meters is a 1-2 minute walk, I would walk. However, if your purpose is to wash your car, you need to drive it there.人工复核的评分维度可以包括评分维度说明是否换算距离是否提到 100 米约等于步行 1 到 2 分钟是否比较方式是否比较步行与自驾的时间成本是否识别歧义是否区分“办事”和“洗车”两种意图是否结论合理最终建议是否与意图一致四个维度各 1 分满分 4 分。这个评分标准比简单地看 walk / drive 更有价值。6. 从单题到评测集空间常识类 LLM 评测设计单道题只能算有趣要系统地评估模型需要把这种问题扩展成一个小型评测集。6.1 评测集设计原则设计空间常识评测集时遵循以下原则第一难度分层。从“明确意图 极端距离”的简单题到“无意图 中等距离”的需澄清题再到“语义陷阱 数字干扰”的困难题。每层都要有代表。第二控制变量。同一个场景只改变一个变量。比如距离从 100 米变成 1 公里、5 公里目标从洗车店变成便利店意图从不明确变成明确。这样你能定位模型是在哪一步失败的。第三加入干扰项。汽车相关场景要混入非汽车相关场景防止模型在“car wash”这类词上形成捷径。6.2 评测集模板场景距离意图期望答案类型洗车店100 米无意图条件式回答洗车店100 米去办事走路洗车店100 米洗自己的车开车便利店200 米买一瓶水走路餐厅1 公里朋友聚餐条件式可走路或打车机场30 公里赶航班开车或打车加油站5 公里加油开车把这些问题整理成 JSON 文件配合批量评测脚本使用{ cases: [ { id: case_001, scene: car_wash, distance_m: 100, intent: none, prompt: The car wash is 100 meters away. Should I walk or drive?, expected: conditional }, { id: case_002, scene: car_wash, distance_m: 100, intent: errand, prompt: I only need to pay my bill. The car wash is 100 meters away. Should I walk or drive?, expected: walk } ] }评测集做好之后你可以在每次升级模型、调整 Prompt、更换量化版本时重新跑一遍形成回归测试。7. 接口 API 与自动化评测流水线如果模型数量很多或者要接入到内部的评测平台就需要把评测脚本升级成接口调用模式。7.1 本地模型的 OpenAI 兼容接口Ollama 启动后会提供一个默认服务端口并兼容 OpenAI 的接口格式。启动服务# 默认监听 11434 端口 ollama serve然后用 curl 直接调用curl http://127.0.0.1:11434/v1/chat/completions \ -H Content-Type: application/json \ -d { model: qwen2.5:7b, messages: [ {role: user, content: The car wash is 100 meters away. Should I walk or drive?} ], temperature: 0.2 }返回结果是一个标准的 JSON 结构里面包含模型生成的 content 字段。这个接口格式和市面上大多数 OpenAI 兼容服务一致意味着你可以把评测脚本同时接到本地模型和云端模型上。7.2 批量任务设计批量评测时要注意几个工程问题第一控制并发。本地模型在 GPU 上并发处理多路请求会显著增加显存占用。建议先以串行方式跑通再逐步增加并发数观察显存和响应时间。第二设置超时。不同模型、不同长度的输入输出耗时差异很大建议单个请求超时 120 秒以上。第三加入失败重试。模型服务可能在长时间运行后出现连接中断或内存溢出脚本里要加重试逻辑。import time import requests url http://127.0.0.1:11434/v1/chat/completions payload { model: qwen2.5:7b, messages: [ {role: user, content: The car wash is 100 meters away. Should I walk or drive?} ], temperature: 0.2 } for attempt in range(3): try: response requests.post(url, jsonpayload, timeout120) result response.json() print(result[choices][0][message][content]) break except Exception as e: print(fattempt {attempt 1} failed: {e}) time.sleep(5)7.3 关于 ComfyUI 与 LLM 的部署位置顺带回答一个常见问题ComfyUI 里如果要调用 LLM 做提示词增强、图像理解或工作流决策LLM 并不一定要和 ComfyUI 安装在同一个电脑上。只要 ComfyUI 所在的机器能通过网络访问到 LLM 服务地址就可以在自定义节点里配置服务 URL。典型架构有两种架构说明适用场景同机部署ComfyUI 和 Ollama / vLLM 在同一台电脑上本机测试、离线环境分离部署ComfyUI 在 A 机LLM 服务在 B 机通过 HTTP API 调用多台电脑各自分工B 机有更好的显卡配置方式就是在 ComfyUI 的 LLM 节点里填写服务地址例如http://192.168.1.10:11434/v1。分离部署的好处是 ComfyUI 所在的机器可以只负责图像生成LLM 推理压力集中在另一台机器上。8. 资源占用与性能观察方法评测过程中不能只盯着答案对不对还要观察资源占用。这里给一套通用的观察流程具体数字以你本机实际测试为准。8.1 观察显存和内存启动模型服务后在另一个终端窗口运行# 查看 GPU 显存占用和利用率 nvidia-smi -l 1重点关注每 1 秒刷新一次的输出显存占用、GPU 利用率、温度。如果显存不足程序会报 CUDA out of memory 错误此时需要切换到更小的量化版本或限制上下文长度。CPU 推理时重点是 CPU 利用率和内存占用。可以用系统自带的任务管理器或top命令观察。8.2 影响资源占用的因素以下因素都会影响资源占用评测时要注意控制因素影响模型参数量7B 模型占用显著低于 70B 模型量化等级Q4 量化通常比 FP16 占用少一半以上上下文长度输入越长KV Cache 占用越大并发请求数并发越高显存和内存占用越大输出长度生成 token 越多总耗时越长8.3 降低资源占用的方法如果本机资源有限优先做以下几件事选择量化模型例如 Q4_K_M、Q5_K_M而不是 FP16 版本。限制上下文长度评测这类短问题不需要很长的上下文。关闭并发把批量请求改为逐条串行。使用更小参数的模型7B 不够再试 3B。如果使用 llama.cpp 系列可以通过--n-gpu-layers控制多少层加载到 GPU实现显存和速度的平衡。8.4 评测耗时记录时间信息同样重要。同一个问题7B 模型和 70B 模型的响应时间可能相差一个数量级。建议在评测脚本里记录每个请求的耗时输出到 CSV方便后续做成本分析。响应时间过长说明该模型不适合高频调用场景需要考虑量化、蒸馏或换更小的模型。9. 常见问题与排查方法把这类评测中常见的问题整理成排查清单可以节省大量调试时间。问题现象可能原因排查方式解决方案模型总是回答 drivecar wash 语义关联过强对比加了意图说明后结果是否变化在 Prompt 中强制要求先换算距离同一问题多次回答不一致temperature 随机性过高固定 temperature 和 seed将 temperature 设为 0.2 以下请求超时或卡住模型服务未启动或端口异常检查端口和日志重启 serve 服务并确认端口显存不足报错模型过大或并发过高观察 nvidia-smi换量化模型或降低并发模型使用 CPU 而不是 GPU未加载 GPU 层或驱动异常查看启动日志检查 CUDA 安装和 GPU 层配置批量任务中途停止连接中断或进程被杀查看日志和退出码增加重试逻辑调整超时时间输出质量不稳定Prompt 不完整或上下文被截断检查输入输出 token 数精简 Prompt预留输出空间中文提问效果差模型中文能力弱或翻译不当切换中英双语测试换中文能力更强的模型9.1 一个容易忽略的坑评测脚本和模型服务在同一机器上批量评测时脚本本身也会消耗 CPU 和内存。如果机器资源有限建议评测脚本在轻量机器上运行模型服务在 GPU 机器上运行通过 HTTP 接口连接。这样既能保证模型推理资源充足也方便共享模型服务给多个评测任务使用。9.2 另一个坑只看关键词不看上下文脚本里的 classify_answer 函数只能做初步筛选。如果模型的回答是 “If you need to wash your car, drive; otherwise, walk”关键词包含 drive会被误判成 drive。所以自动化评测必须搭配人工抽检特别是在得出结论之前至少手动查看 20% 的回答。10. 最佳实践如何减少这类推理失误评测的价值在于发现问题最终目标是让模型在真实业务里更可靠。以下优化方向可以按顺序尝试。10.1 用 Prompt 强制模型先做物理换算对于空间距离类问题直接在系统提示词里加入规则你是一个注重物理常识的助手。在回答交通方式选择问题时必须按以下步骤处理 1. 把距离换算成步行时间。 2. 识别用户是否明确表达需要携带车辆或其他重物。 3. 如果没有明确意图先询问澄清。 4. 最后给出结论并简要说明理由。加上这条规则后模型的输出结构会显著改善至少会先考虑 100 米对应的步行时间。10.2 用思维链引导深度推理在问题后追加一句Please think step by step and consider walking time and driving time before answering.这会让模型在生成最终答案前先输出推理过程。不过要注意思维链会显著增加输出 token 数调用成本和响应时间都会上升生产环境需要权衡。10.3 在系统层做意图分类如果你的产品经常遇到这类“交通方式选择”问题不要让模型直接回答而是先做意图分类用户是否明确要携带某物、距离是多少、是否有时间约束。这一步可以用结构化输出完成import requests url http://127.0.0.1:11434/v1/chat/completions payload { model: qwen2.5:7b, messages: [ {role: user, content: ( 请提取以下问题中的关键信息并输出 JSON 距离、交通方式选项、是否明确要携带车辆。 问题洗车店离我 100 米我应该走路还是开车过去 )} ], temperature: 0, response_format: {type: json_object} } response requests.post(url, jsonpayload, timeout120) print(response.json()[choices][0][message][content])提取出结构化信息后再用规则或小型决策逻辑判断能大幅减少语义关联带来的误判。10.4 建立回归测试集每次调整 Prompt 或更换模型后重新跑一遍第 6 节的评测集。把模型答案和人工评分存档形成可对比的回归记录。这一步看起来简单但在实际项目中最能保证质量不倒退。10.5 合规与安全边界最后强调一下合规问题。如果你在业务中使用 LLM 评测或部署本地模型需要注意几点第一评测数据不要包含真实用户的隐私信息尤其是姓名、电话、地址、人脸和声音特征。清理完数据再评测。第二下载和使用开源模型时确认模型的许可证和商用条款。部分模型只能用于研究不能直接商用。第三如果评测结果涉及大量用户生成内容不能直接公开原始数据截图需要脱敏和授权。第四涉及人脸、声音、版权素材的生成类 LLM 应用必须确认素材授权并在发布前做效果复核。11. 总结与下一步这道 “The car wash is 100 meters away. Should I walk or drive?”是一个投入产出比极高的 LLM 推理测试样本。你可以用它快速判断一个模型是否具备距离换算、语义关联抵抗和意图澄清能力也可以把它扩展成一套小型空间常识评测集纳入日常的模型回归测试。建议你按以下顺序操作先在本地用 Ollama 部署一个 7B 量级模型手动跑一遍原题和三个变体。再跑批量评测脚本至少覆盖 10 到 20 个测试用例固定 temperature 和 seed。观察 nvidia-smi记录显存占用和响应时间判断当前硬件能否支撑这类评测任务。如果模型连续答错优先尝试第 10 节的 Prompt 规则而不是直接换更大的模型。最后把评测集和脚本存档作为后续选型、升级、量化的基准。最容易踩的坑有两个一是用不固定的采样参数做评测结果不可复现二是只看关键词判断对错忽略模型完整回答中的条件逻辑。避开这两个坑你的评测结果会可靠很多。后续可以扩展的方向包括把评测集扩大到时空推理、物理常识、社会常识等多个维度把评测脚本接入内部的模型上线流程形成自动化回归以及尝试用结构化输出加规则兜底的方式把这类推理能力固化到产品逻辑里。建议收藏备用下次遇到“模型能力到底行不行”的争论时直接拿出这套评测流程用数据说话。