Gemma3:4b returns an empty JSON object with a long extraction prompt and structured output

快速结论：当通过 Ollama Python 库对 gemma3:4b 使用较长的信息抽取提示词并开启结构化输出（Pydantic 生成 schema）时，模型可能直接返回空 JSON 对象 {}，且 done=True、done_reason=’stop’，不报异常。优先排查提示词长度与结构化输出组合，并配合服务端日志确认模型加载与上下文配置。

适用环境：Issue 中已确认：OS 为 Windows；Ollama 版本 0.40.5；模型 gemma3:4b（对照模型 qwen2.5:3b）；显卡 NVIDIA GeForce GTX 1050（4 GB VRAM）；NVIDIA 驱动 582.78；Python 3.10.5；Ollama Python 库 0.6.3。CPU 为 Intel。服务端日志显示 CUDA 跳过 GTX 1050（compute capability 6.1 不在编译架构列表中），实际以 CUDA0 推理，并加载了 Vulkan。

最快修复方案：暂无确认的一步修复方案。Issue 中未记录明确验证过的修复步骤；可优先尝试拆分或缩短抽取提示词、减少 schema 复杂度，或在该任务上改用已验证可用的 qwen2.5:3b。

注意事项：上述仅为可优先尝试的方向，Issue 未验证其能否触发修复。返回 {} 时调用本身成功，因此需要在业务侧校验 JSON 内容，不能仅依赖 done=True 判断抽取成功。改用对照模型属于绕行方案，不解决 gemma3 本身行为。

问题场景

用户在“Automatic resume sorter”项目中，通过 Ollama Python 库调用 gemma3:4b，对 PDF 简历执行信息抽取。核心调用为 chat()，传入较长的抽取提示词，并用 format=Resume.model_json_schema() 开启结构化输出，temperature 设为 0。此前相同代码可以正常抽取，之后在代码无明显变化的情况下开始返回空 JSON 对象。相同代码、提示词和 schema 换成 qwen2.5:3b 时可正常返回抽取结果。

报错原文

Gemma3:4b returns an empty JSON object with a long extraction prompt and structured output

done=True done_reason='stop' total_duration=29885322700 load_duration=19419462700 prompt_eval_count=2449 prompt_eval_duration=10145038000 eval_count=2 eval_duration=259654000 message=Message(role='assistant', content='{}', thinking=None, images=None, tool_name=None, tool_calls=None) logprobs=None

原因分析

Issue 中通过多组对照测试进行了初步定位：不带结构化输出的简单提示词可正常生成；相同 Pydantic schema 配简单提示词可正常抽取；但原始较长简历抽取任务配 gemma3:4b 会返回 {}，而配 qwen2.5:3b 正常。因此可能原因集中在 gemma3 在长提示词 + 结构化输出（format 指定 JSON schema，可能涉及语法/grammar 约束）组合下的行为，而不是基础调用或 schema 格式本身。

日志显示 eval_count 仅 2，对应输出即 {}，说明模型在结构化约束下很早就停止生成。此外，服务端日志出现了“skipping CUDA device — compute capability not in compiled architectures”的设备跳过记录，以及 Vulkan、集成显卡相关信息；这些属于环境层面的观察，Issue 未确认它们与返回 {} 有直接因果关系，只能作为排查线索。服务端日志中的 403 Forbidden 出现在模型推荐/云缓存刷新相关请求上，与本次抽取失败的关系未得到确认。

环境排查

确认 Ollama 版本（Issue 为 0.40.5）与模型名称、标签（gemma3:4b）。
确认 Ollama Python 库版本（Issue 为 0.6.3）与 Python 版本（Issue 为 3.10.5）。
查看服务端日志，确认模型加载方式、上下文长度与设备分配情况；Issue 日志显示默认上下文为 4096，且存在 CUDA 设备因 compute capability 被跳过、回退使用 Vulkan 的情况。
确认显卡显存是否充足（GTX 1050 4 GB，Issue 中 gemma3 约 52% CPU / 48% GPU 分配）。
用同一提示词和 schema 分别测试 gemma3:4b 与 qwen2.5:3b，复现对照结果。
对比长提示词与短提示词、带 schema 与不带 schema 的组合，定位触发范围。

解决步骤

启用 Ollama 服务端日志（参考官方 troubleshooting 文档），复现问题并保存日志，确认模型加载与推理是否出现异常或设备回退记录。
按 Issue 的对照方法做最小化复现：短提示词 + 相同 schema、长提示词 + 无 schema、长提示词 + schema，分别记录 message.content 与 prompt_eval_count/eval_count。
可优先尝试削弱触发条件：将长抽取提示词拆分为多步或缩短，降低 Pydantic schema 的嵌套与字段复杂度，再验证是否仍返回 {}。
若业务允许，可优先尝试在该抽取任务上使用 qwen2.5:3b（Issue 中已验证相同代码、提示词和 schema 下可正常抽取）。
在调用侧增加结果校验：对返回内容做 JSON 解析，若为空对象或不符合 schema，则记录日志并重试或降级处理。

验证方法

用相同输入重新运行抽取流程，检查 message.content 是否返回符合 Resume schema 的非空 JSON，并确认其中包含从简历中抽取的字段。同时确认 done_reason 为 ‘stop’ 且 eval_count 不再仅为 2。若调整提示词后仍返回 {}，说明本次尝试未解决问题，需继续结合服务端日志排查。