怎么选模型

• 谁读你的健康数据：只有你自己的电脑，还是按某家模型厂商的条款交给它；
• 回答要多好，以及要为此付出多少速度和费用。

​

简短的回答

​

三种方式，各有什么离开这台机器

​

本机：两种大小，由 llama.cpp 提供服务

​

读文档的模型：GLM-OCR-0.9B

​

照片

​

云端：一个开放权重的基线，四个闭源参照

​

结果

• 评分是 Claude Code 按一份写好的评分表打的分：对不对、有没有出处、是否按报告印的范围判断、 是否用提问的语言、有没有用，要图时还有图，每项 0 到 2 分。通过是五项自动检查全过：答完了、 调对了工具、每个期望的事实都在、用提问的语言、图能解析。
• 印刷行数的是和文档印出的某一行对得上的读数。此外每个模型都存了对不上任何一行的读数：云端模型 47 到 49 条， 小号 9 条。这些还没有逐条看过；在更早的一次 DeepSeek 运行里，其中 40 条来自那本 7 页的体检册。 表格规则放在前面之后（见下），云端模型的降到 26–41 条。
• 大号这一行是 config.llm.yaml 和 local-models.md 里沿用的早先测量：8 道题各问两遍， 加 4 份 demo 文档。其余各行所用的 16 GB 机器装不下它。
• 记录和提交。 小号全部在 958fae5 上跑，读的记录（qa4）经最终版流水线载入，和今天用户的记录一样。 云端模型读的是在 490a0e1 上载入的记录（qa3，其中两份文档在 321aa2c 上重读过），之后没有重新载入。 DeepSeek、Sonnet 和 Luna 的文档和日记在 4e3c06f 上读，20 道题在 490a0e1 上答，读那两份重读文档的 4 道题在 321aa2c 上答；Opus 和 Gemini 的每一部分都在 321aa2c 的应用代码上跑。

• 三个模型并列第一：Claude Sonnet 5.5、Claude Opus 5.5 和 Gemini 3.8 Flash 都是 248 分得 247，丢的是同一分， 都丢在月视图的平均值上（这是流水线的问题，不是模型的）。一套 24 道题排不出它们的先后；价格和速度能分开它们： Gemini 每次回答 $0.012，Sonnet 约$0.029，Opus $0.045；三个里 Sonnet 回答最快（中位数 9.0 秒，另两个 14.9 秒）。
• DeepSeek V4.1 Flash 是开放权重的基线，回答最快（中位数 4.2 秒），比第一少 2 分，140 个印刷行漏了 2 个。
• GPT-6 Luna 每次回答最便宜（$0.0009），存对了每个印刷行、写出了每条日记条目。它丢的 11 分里， 有只在一年之内搜一个症状、把血脂的问题推回给用户而不去查读数、说一个印出来的范围不存在。
• MiniCPM5-2B 在一台 16 GB 的笔记本上、什么都不发出去，也存对了每个印刷行，单位和范围都和印的一样， 问答比并列第一的三个少 32 分。

​

表格规则在前面时

• 这不是「规则关」对「规则开」。 参照的配置里一直留着本地 OCR 的路由，所以之前那几次规则也在跑， 只是当时认得的表头少。这个比较测的是更广的表头词汇。Gemini 之前那次已经用上了它，所以它的两次几乎没有差别。
• 规则读每一份上传最要紧的地方，这里没有测：用厂商 key、又没有本地 OCR 模型的部署，在 c396b4f 之前那里没有任何表格是按规则读的。
• 生成标题和摘要的那次调用仍然把每份文档的前 3,000 个字符发给厂商，不管有没有规则（12 份一共 12,200 个字符）。

​

花多少钱

​

OpenRouter 上的健康数据

• 精度。 OpenRouter 上 deepseek/deepseek-v4.1-flash 的端点列表（/api/v1/models/deepseek/deepseek-v4.1-flash/endpoints） 列了 32 家托管方。很多家提供的是量化版，标着 fp4（OpenInference、Sail Research、Decart）或 fp8 （Morph、DeepInfra、AtlasCloud、Novita 等）；好几家没列 structured_outputs，DeepSeek 自己的那家列了 response_format，没列 structured_outputs。
• 一家把按 schema 的回答清空的托管方。 对一份家庭体重记录的 OCR 文字（12 行，每行带日期）发提取请求，带 response_format: json_schema，被转到了 InferenceNet（响应里的 provider 字段），返回 333 个字符， "indicators": [] 排在 content_type 前面。同一个请求不带 response_format、同一家托管方，返回了全部 12 行和各自的日期。 在一次对照检查里，4 种 schema 写法各试 5 次，DeepSeek 在每种写法下（包括原样不改的 schema）都是 5 次里有 3 次 读出 demo 血脂 CSV 的全部 5 行，而每一次空结果都来自 InferenceNet：问题出在转发，不在 schema。
• 它让一次评测付出的代价。 第一次跑 DeepSeek V4.1 Flash 时没有固定托管方，用的是自带的按 schema 的条目， 140 个印刷行只存对 86 个，有六份文档一个读数都没有。最可能的原因是托管方；生成器的水印在那家托管方上让情况更糟 （去掉那一行，一张化验单从 0 行变成 6 行全对）。固定到 Together、在之后的提交上重跑，同一个模型在带水印的情况下 存对了 140 个里的 138 个。

1. 账号开零数据保留。 在 OpenRouter 账号设置里只允许不保留数据的托管方。这样 OpenRouter 遇到不提供零数据保留的 托管方会拒绝，而不是转发过去：2026-10-06 它就以这个设置拒绝了 DeepSeek 自己的 API（「ZDR violation (account settings), Paid model training violation」）， 所以 DeepSeek V4.1 Flash 跑在 Together 上。DEEPSEEK_API_KEY 用的就是这同一个 API。
2. 每个模型固定一家托管方，不回退。 provider.order 指定托管方，allow_fallbacks: false 让 OpenRouter 不去试别家。没有用 require_parameters: true：OpenRouter 没给 GPT-6 Luna 列出 temperature 参数， 带上它会返回 404。每次运行前，固定的托管方都先答过一个和条目本身同样形状的请求，temperature 和 JSON 格式都在 （每个参照的 meta.json 里的 host_probe）。Claude Opus 5.5 和 Gemini 3.8 Flash 只有 Google 的托管方通过： anthropic、azure 和 amazon-bedrock 对带 temperature 的 JSON schema 请求都没给 Opus 可用的端点，Gemini 的 google-ai-studio 被零数据保留排除。

MODELS:                           # 加在已有条目旁边
  deepseek-zdr:                   # 在对话里回答问题
    llm_type: openai
    api_key: OPENROUTER_API_KEY
    base_url: https://openrouter.ai/api/v1
    model: deepseek/deepseek-v4.1-flash
    supports_image: false         # 照片以 OCR 文字送达；没有图片出去
    extra_body:
      provider: {order: [together], allow_fallbacks: false}
  deepseek-zdr-utils:             # 读文档文字、日记、标题
    llm_type: openai
    api_key: OPENROUTER_API_KEY
    base_url: https://openrouter.ai/api/v1
    model: deepseek/deepseek-v4.1-flash
    supports_image: false
    chat: false
    response_format: json_object  # DeepSeek 接受 JSON 模式，不接受 schema
    extra_body:
      reasoning: {enabled: false}
      provider: {order: [together], allow_fallbacks: false}

services:
  mirobody:
    volumes:
      - ./config.llm.yaml:/app/config.llm.yaml:ro
  mirobody_worker:
    volumes:
      - ./config.llm.yaml:/app/config.llm.yaml:ro

​

按情况选

​

隐私优先，一台普通电脑

​

隐私优先，一台大内存的机器

​

要最好的回答

​

要最低的成本

​

混合：文档在本机读，回答交给云端

OPENROUTER_API_KEY=sk-or-...
LOCAL_OCR_BASE_URL=http://host.docker.internal:8080/v1   # UTILS_OCR_MODEL 在这里读每一张照片和每一页
UTILS_VISION_MODEL=local-utils                           # 没有文字的图片不发出去生成描述

​

怎么切换

• 设置页。 ./deploy.sh 会打印它的链接；之后在「设置 › 模型」。粘贴一把 key（旁边显示它会用的模型， 可以改成别的名字，用一次真实请求验证），或选100% 在本机运行再选大小。选择加密存储，不用重启就生效。
• .env。 写 key，再按每个 config.llm.yaml 条目的 model_env 变量写模型：OpenRouter 的 key 对应 OPENROUTER_CHAT_MODEL（对话）和 OPENROUTER_UTILS_MODEL（文档、日记、标题）；本地服务对应 LOCAL_MODEL（minicpm5-2b 或 qwen3.8-27b）和 LOCAL_OCR_MODEL（glm-ocr）。DEFAULT_MODEL、 UTILS_TEXT_MODEL、UTILS_VISION_MODEL、UTILS_OCR_MODEL 指定每个环节用哪个条目。然后 docker compose up -d：restart 不会重新读 .env。
• 不改任何文件就用 GPT-6 Luna。 有 OpenRouter 的 key 时，对话的模型菜单里也有 GPT-6 Luna（gpt 条目）； DEFAULT_MODEL=gpt 把它设为默认。和所有自带条目一样，它不固定托管方。
• 检查：
  docker compose exec mirobody mirobody doctor --probe
  
  它列出每个环节用的条目，经产品自己的代码给每个条目发一次真实请求（一次工具调用、一次按 schema 的回答、 一张图、OCR 的各遍），并检查每个本地服务跑的是不是条目里写的那个模型。

​

怎么测的，怎么复现

• 记录。 mirobody-gen，Mirobody 的合成记录生成器，正在开源， 版本 248df0f，--seed 7 --people 6：结果确定，同一个提交和种子生成逐字节相同的文件。每个期望答案都由它的 真值算出，不手写。里面没有任何真人的数据。
• 题目。 24 道题（中英文各 12 道），关于四个人，每道题在一个新会话里通过产品的 HTTP API 问一次；12 份文档 （带文字层的 PDF、CSV、XLSX、扫描件、手机照片、复印件、截图、一本 7 页体检册、一份门诊病历、一份家庭记录）， 逐行对照文档印出的内容打分；15 句日记，对照每句话说出的条目打分。
• 评分。 自动检查（score.py），加上 Claude Code 对照期望答案、按上面的评分表读每一份对话记录；两者都保留， 每个分数都附理由（grades.json），可以互相核对。
• OCR。 同一次生成里的 28 个印刷页（303 行，另有两份家庭记录的 57 行），以及 mirobody-gen 手写版生成的 28 个手写页（301 行；b4a8c50，--seed 42 --people 18），每页都走产品自己的提取路径。

B=benchmarks/local_models; G=~/mirobody-gen-seed7
mirobody-gen build --seed 7 --people 6 --out $G --render     # 在 mirobody-gen 的检出目录里
python $B/cases.py --corpus $G
python $B/load.py --corpus $G --qa
python $B/run.py --size small --corpus $G
python $B/run.py --ref deepseek-v4.1-flash-v2 --corpus $G     # 一个云端参照；准备步骤见它的 README
python $B/report.py summary

python benchmarks/local_ocr/run.py --model glm-ocr-q8 --corpus <corpus> --models-dir <models>
python benchmarks/local_ocr/extract.py --model glm-ocr-q8 --corpus <corpus>

• 合成数据，一个种子，跑一次。 一份记录、24 道题、12 份文档，每个模型跑一次。差一两道题不算结论， llama.cpp 的批处理也不能逐位复现。
• 水印。 生成的每一页都印着「SYNTHETIC SAMPLE — GENERATED DATA, NOT A REAL PATIENT RECORD」，小模型会照字面理解； 真实报告上没有它，所以 OCR 那张表两种都给。
• 手写来自字体。 手写页是用手写字体渲染、再扫描或拍照的，不是人写的。
• 只有一个评分者，Claude Code，题目也是它写的。评分表和每个分数的理由都公开，读者可以重新评。
• 速度只在两台机器上。 本地耗时是一台 M1 Pro 和一台 M4 Pro 用 GPU 跑的；上面只用 CPU 的数字是在 4 个 vCPU 上另测的。云端的取决于托管方当晚的负载。
• GPT-6.1 Sol 没有纳入比较：即使固定到 Azure，OpenRouter 也一直对它上游限流（24 道题里有 9 道要重试最多四轮， 其中一道始终没有答上；140 个文档行有 50 个始终没有存下），而价格约是 GPT-6 Luna 的 20 倍 （每百万 token $2/$10，对 $0.10/$0.50）。
• 云端模型是在看不见图的条件下测的，读的是本地 OCR 的文字。让它们自己看页面图片，可能读得更多， 但更贵，图片也会发出去。

​

1.6.0 预告：Mirobody 自己的模型

• 回答模型，从 MiniCPM5-2B（Apache-2.0）后训练：用在真实 harness 里跑出、且每项检查都通过的运行来训练， 再以「回答里每个数是否在记录里」为奖励继续训练；
• 读文档的模型，从 GLM-OCR-0.9B（MIT）后训练：用加了手机拍摄畸变的渲染报告，学会写出每一行的名称、值、 单位、范围、标记和日期。