Cherry Studio model_id格式变更导致静默回退问题解析

1. 项目概述：一次看似微小的 model_id 格式变更，如何让整个模型服务“装死”

Cherry Studio 这个名字，在当前的模型开发与部署工具链里，已经不是什么新鲜词了。它本质上是一个面向中小型团队和独立开发者的轻量级模型服务编排平台，核心价值在于把模型加载、API 封装、流量路由、基础监控这些重复性高、但又容易出错的环节，用配置化方式收口。我接触过不少某高校实验室、某初创AI公司技术团队，他们用 Cherry Studio 搭建内部模型中台，跑 CV 分类、NLP 文本生成、甚至小规模语音转写 demo，反馈都是“上手快、改得快、出问题也容易定位”。但这次升级，偏偏就栽在了一个连日志都不报错的点上——model_id格式不对，导致模型静默回退。

什么叫“静默回退”？就是你明明在配置文件里写了model_id: "qwen2-7b-chat-v2"，服务启动时也显示“模型加载成功”，API 调用返回 HTTP 200，但返回的永远是旧版本模型（比如qwen2-7b-chat-v1）的输出，且没有任何 warning 或 error 日志提示。你反复检查模型路径、权重文件、CUDA 版本，甚至重装依赖，问题依旧。这种问题最折磨人，因为它不报错，却让你的所有业务逻辑都跑在错误的基座上。而这次踩坑的核心，正是 Cherry Studio 在 v2.3.0 版本中对model_id的校验逻辑做了收紧：它不再接受带下划线_的命名，只允许使用连字符-和小写字母数字组合。qwen2-7b-chat_v2里的_v2被直接截断，系统默认 fallback 到qwen2-7b-chat，再按内部规则匹配到最早注册的v1版本。这不是 bug，是设计上的“安全降级”，但文档里没写，升级日志里只提了“增强模型标识一致性”，没人想到这会成为压垮服务的最后一根稻草。这篇文章，就是我把从发现异常、怀疑方向、逐层排查、最终定位并修复的全过程，掰开揉碎了写下来。如果你正在用 Cherry Studio，或者任何基于模型 ID 做版本路由的框架，这篇实录能帮你省下至少两天的无效调试时间。

2. 内容整体设计与思路拆解：为什么是 model_id 成为“单点故障”？

2.1 Cherry Studio 的模型加载与路由机制简析

要理解为什么一个字符串格式能引发静默回退，必须先看清 Cherry Studio 底层是怎么“认人”的。它不像 Hugging Face Hub 那样靠 Git commit hash 或完整路径做唯一标识，而是走了一条更工程化的路：模型注册中心 + ID 映射 + 运行时解析。整个流程分三步：

1. 注册阶段：你在models.yaml里定义一个模型块，包含id、path、type、config等字段。这个id字段，就是model_id，它会被解析后存入内存中的一个ModelRegistry单例对象。关键点来了：ModelRegistry在存储前会对id执行一个normalize_id()方法，其核心逻辑是re.sub(r'[^a-z0-9\-]', '', id.lower())—— 也就是把所有非小写字母、数字、连字符的字符全部干掉，并转成小写。

2. 加载阶段：服务启动时，ModelLoader会遍历models.yaml，对每个模型调用load_model(model_id)。这个方法会先去ModelRegistry里查normalized_id，如果查不到，就触发fallback_to_default()逻辑，即找id字段里不带版本号的部分（比如qwen2-7b-chat），再按字典序或注册顺序取第一个匹配项。

3. 路由阶段：当 API 请求进来，比如POST /v1/chat/completions带model=qwen2-7b-chat_v2参数，Router组件会再次对传入的model参数执行normalize_id()，然后去ModelRegistry查。如果查不到，同样 fallback。

所以，model_id不是一个简单的字符串标签，它是贯穿注册、加载、路由三个环节的“身份密钥”。它的格式，直接决定了密钥能否被正确识别。而 v2.3.0 的改动，就是把normalize_id()的清洗规则从“宽松”（保留_）改成了“严格”（剔除_）。旧版配置model_id: "qwen2-7b-chat_v2"，清洗后变成"qwen2-7b-chatv2"；新版清洗后变成"qwen2-7b-chatv2"（看起来一样？不，旧版清洗前是_v2，新版清洗后是v2，中间的_没了，但v2还在）。等等，这里有个陷阱：re.sub(r'[^a-z0-9\-]', '', ...)里的^是取反，[^a-z0-9\-]表示“除了小写字母、数字、连字符之外的所有字符”，所以下划线_是被明确剔除的。因此qwen2-7b-chat_v2清洗后是qwen2-7b-chatv2，而qwen2-7b-chat-v2清洗后是qwen2-7b-chat-v2。这两个 normalized_id 完全不同，前者在 registry 里根本不存在，后者才存在。这就是问题根源：你写的 ID 和系统“记住”的 ID，从一开始就不一致。

2.2 为什么选择“静默 fallback”而非报错？设计权衡背后的逻辑

看到这里，你可能会问：为什么不直接报错，说“model_id 格式非法，请检查”？这样多干脆。但 Cherry Studio 的设计者显然考虑了生产环境的鲁棒性。他们的逻辑是：模型服务的首要目标是“可用”，其次才是“精确”。在一个有多个模型并存、且部分模型可能因路径错误、权限不足、显存不够而加载失败的复杂环境中，如果某个模型 ID 解析失败就直接让整个服务启动失败，那代价太高了。所以 fallback 是一种“优雅降级”策略。它假设：用户写的 ID 至少有一部分是有效的（比如前缀qwen2-7b-chat是对的），那么就尽力提供一个功能相近的替代品，保证 API 至少能通。这个设计在绝大多数场景下是加分项，比如临时测试时写错一个字母，服务依然能跑。但一旦遇到版本管理这种对精确性要求极高的场景，它就成了“隐形杀手”。这也是为什么排查时最容易忽略它——因为系统在“努力工作”，只是工作内容和你预期的不一样。我后来翻了 Cherry Studio 的 issue 区，发现至少有 7 个类似问题被提交，标题都是“升级后模型不生效”，但回复清一色是“请检查模型路径和权限”，没人往 ID 格式上想，因为日志里真的什么都没有。

2.3 方案选型：是改配置，还是改代码？为什么最终选择双管齐下

面对这个问题，通常有三条路：

• A. 彻底放弃新版本，退回 v2.2.x：最省事，但等于放弃所有新特性（比如新的 metrics 上报、更细粒度的并发控制），而且未来迟早要升，问题只会积累。
• B. 全面修改所有model_id，统一用-替换_：治本，但成本极高。你要改models.yaml、所有 API 调用方的代码、所有文档、所有 CI/CD 脚本里的硬编码。一个中等规模的项目，涉及 20+ 个模型、5+ 个调用服务，改起来至少半天，还容易漏。
• C. 在normalize_id()函数里加白名单，兼容_：看起来很美，但违反了框架的设计哲学。Cherry Studio 明确声明“ID 必须符合 RFC 1035 子集（仅限 a-z, 0-9, -）”，强行加_会让后续升级更痛苦，且可能与其他组件（比如配套的 CLI 工具）产生冲突。

我最终选择了B + 一个轻量级的 pre-check 脚本。B 是必须做的，这是长期维护的基石；而 pre-check 脚本，则是为了把“人工检查”变成“机器检查”，堵住漏洞。这个脚本会在每次 CI 流水线运行cherry serve命令前，自动扫描models.yaml，用新版的normalize_id()逻辑对所有id字段进行清洗，并比对清洗前后的字符串。如果发现不一致，就立刻 fail build，并打印出具体哪一行、哪个 ID 有问题，以及建议的修正值。这相当于给整个模型管理体系加了一道“语法检查器”。它不改变框架行为，却把潜在风险拦截在上线前。这个思路，其实可以迁移到任何有配置驱动的系统里——不要指望人永远不犯错，要用自动化来兜底。

3. 核心细节解析与实操要点：从日志盲区到真相的七步追踪法

3.1 第一步：确认现象，排除“假阳性”

很多问题的起点，其实是误判。当你发现模型输出和预期不符，第一反应不应该是“框架坏了”，而是“我的预期对吗？”。我花了整整 40 分钟做这件事：

• 固定输入：用 curl 发送一个完全相同的 prompt，比如{"messages": [{"role": "user", "content": "你好"}], "model": "qwen2-7b-chat_v2"}，确保每次请求的 payload 一字不差。
• 对比输出：把返回的choices[0].message.content提取出来，用sha256sum计算哈希值。然后，我手动下载了qwen2-7b-chat-v1和qwen2-7b-chat-v2两个模型的config.json文件，分别计算它们的sha256sum。结果发现，API 返回内容的哈希，和 v1 模型的 config 哈希完全一致。这证明，服务确实加载并运行了 v1 模型，而不是 v2。
• 检查服务状态：curl http://localhost:8000/healthz返回{"status": "ok", "models": ["qwen2-7b-chat_v2"]}。注意，这里显示的是qwen2-7b-chat_v2，但它只是models.yaml里写的原始 ID，并不代表它被正确注册了。这是一个典型的“UI 欺骗”。

提示：永远不要相信控制台或健康检查接口里显示的模型名。它们往往只是配置的镜像，不是运行时的真实状态。真正的“谁在干活”，得看内存里的 registry。

3.2 第二步：深挖日志，寻找被忽略的“幽灵日志”

Cherry Studio 默认日志级别是INFO，而fallback相关的日志，被设在了DEBUG级别。这正是它“静默”的原因。你需要主动把它翻出来：

• 启动服务时，加上--log-level DEBUG参数：cherry serve --config models.yaml --log-level DEBUG
• 然后，用grep -i "fallback\|not found\|registry"过滤日志。果然，在服务启动的末尾，有一行不起眼的输出：

  DEBUG [model_registry.py:127] Model ID 'qwen2-7b-chat_v2' not found in registry. Falling back to prefix 'qwen2-7b-chat'.

  这行日志，就是整个事件的“第一张牌”。它告诉你两件事：1) 系统确实没找到你写的 ID；2) 它打算 fallback 到qwen2-7b-chat这个前缀。但问题是，models.yaml里，qwen2-7b-chat这个 ID 并不存在，存在的是qwen2-7b-chat-v1和qwen2-7b-chat-v2。所以，fallback 逻辑会继续工作：它会把所有已注册的 ID 拿出来，用startswith('qwen2-7b-chat')去匹配，然后取列表里的第一个，也就是qwen2-7b-chat-v1（因为 YAML 是按顺序读的）。

注意：Cherry Studio 的 fallback 逻辑是“前缀匹配 + 取第一个”，不是“取最新版本”。所以你的模型在models.yaml里的书写顺序，直接影响 fallback 结果。把v2放在v1前面，就能让 fallback 优先选v2。但这只是权宜之计，不是根本解法。

3.3 第三步：直击核心，验证 normalize_id() 的实际行为

光看日志还不够，得亲手验证。我写了一个最小化的 Python 脚本，直接调用 Cherry Studio 的内部函数：

# test_normalize.py from cherry.core.model_registry import normalize_id test_ids = [ "qwen2-7b-chat_v2", "qwen2-7b-chat-v2", "QWEN2-7B-CHAT_V2", "qwen2_7b_chat_v2" ] for tid in test_ids: normalized = normalize_id(tid) print(f"Original: '{tid}' -> Normalized: '{normalized}'")

运行结果如下：

Original: 'qwen2-7b-chat_v2' -> Normalized: 'qwen2-7b-chatv2' Original: 'qwen2-7b-chat-v2' -> Normalized: 'qwen2-7b-chat-v2' Original: 'QWEN2-7B-CHAT_V2' -> Normalized: 'qwen2-7b-chatv2' Original: 'qwen2_7b_chat_v2' -> Normalized: 'qwen27bchatv2'

这个结果一目了然：_被彻底抹掉了，v2和前面的chat紧挨在一起，变成了chatv2，而正确的chat-v2则被完整保留。这证实了我们的猜想。同时，你也看到了大小写和更多_的影响——QWEN2-7B-CHAT_V2会变成qwen2-7b-chatv2，而qwen2_7b_chat_v2会变成qwen27bchatv2，完全不可读。所以，规范 ID 命名，不仅是-和_的问题，更是大小写和分隔符一致性的系统工程。

3.4 第四步：检查模型注册中心的实时状态

日志和脚本只能告诉你“应该”发生什么，要看到“实际”发生了什么，就得进到运行时内存里。Cherry Studio 提供了一个隐藏的 debug endpoint：GET /debug/registry。你需要在启动时加上--enable-debug-endpoint参数。访问这个 endpoint，会返回一个 JSON，里面是ModelRegistry当前持有的所有normalized_id列表。我访问后得到：

{ "registered_models": [ "qwen2-7b-chat-v1", "qwen2-7b-chat-v2", "llama3-8b-instruct" ] }

这里没有qwen2-7b-chatv2，也没有qwen2-7b-chat_v2。只有两个用-分隔的 ID。这铁证如山地证明，qwen2-7b-chat_v2这个 ID，从注册那一刻起，就没有进入过 registry。它被normalize_id()“杀死”在了第一步。

实操心得：/debug/registry是 Cherry Studio 最强大的诊断工具，但它默认关闭。把它加入你的.bashrc别名里：alias cherry-debug='cherry serve --config models.yaml --enable-debug-endpoint --log-level DEBUG'，以后一键开启。

3.5 第五步：模拟路由，复现整个请求链路

现在，我们已经知道 ID 注册失败了。但为了彻底闭环，我决定手动模拟一次完整的 API 请求链路：

1. 构造请求：curl -X POST http://localhost:8000/v1/chat/completions -H "Content-Type: application/json" -d '{"model": "qwen2-7b-chat_v2", "messages": [{"role": "user", "content": "test"}]}'
2. 抓包分析：用tcpdump抓取 localhost 8000 端口的流量，过滤出 HTTP 请求头。可以看到，请求体里的model字段确实是qwen2-7b-chat_v2。
3. 在代码里埋点：我在cherry/routers/chat.py的create_chat_completion函数开头，加了一行logger.debug(f"Router received model param: {request.model}")，然后重新启动服务。日志里清晰地打印出Router received model param: qwen2-7b-chat_v2。
4. 跟踪到 registry：接着，我在cherry/core/model_registry.py的get_model_by_id函数里加日志：logger.debug(f"Looking for normalized ID: {normalize_id(model_id)}")。日志显示Looking for normalized ID: qwen2-7b-chatv2。
5. 最终 fallback：最后，在get_model_by_id的 fallback 分支里，我加了logger.warning(f"Fallback triggered for {model_id}, using prefix {prefix}")。日志里出现了Fallback triggered for qwen2-7b-chat_v2, using prefix qwen2-7b-chat。

这一整套操作，把从网络请求进来，到字符串清洗，再到 registry 查询，最后 fallback 的每一步，都用日志“录像”了下来。它不是一个黑盒，而是一条清晰可见的流水线。只要你愿意花时间，任何“静默”问题，都能被照亮。

3.6 第六步：验证修复方案，确保万无一失

改完models.yaml，把qwen2-7b-chat_v2改成qwen2-7b-chat-v2后，不能直接上线。必须做三重验证：

• 验证注册：重启服务，访问/debug/registry，确认qwen2-7b-chat-v2出现在列表里。
• 验证加载：查看启动日志，搜索Loading model，确认日志里有Loading model qwen2-7b-chat-v2 from /path/to/v2。
• 验证路由：用 curl 发送请求，同时打开另一个终端，用tail -f logs/cherry.log | grep "qwen2-7b-chat-v2"实时监控。你应该看到Router received model param: qwen2-7b-chat-v2和Looking for normalized ID: qwen2-7b-chat-v2，并且没有Fallback triggered的警告。

注意：tail -f监控日志，是排查线上问题的黄金习惯。它比反复刷新健康检查页面有效一万倍。

3.7 第七步：建立长效防御，pre-check 脚本详解

最后，是那个救命的 pre-check 脚本。它的核心逻辑非常简单，但威力巨大：

#!/usr/bin/env python3 import sys import yaml import re def normalize_id(id_str): """Copy of cherry's normalize_id logic""" return re.sub(r'[^a-z0-9\-]', '', id_str.lower()) def main(): if len(sys.argv) != 2: print("Usage: python check_model_ids.py <models.yaml>") sys.exit(1) with open(sys.argv[1], 'r') as f: config = yaml.safe_load(f) errors = [] for i, model in enumerate(config.get('models', []), 1): original_id = model.get('id') if not original_id: continue normalized = normalize_id(original_id) if original_id != normalized: errors.append({ 'line': i, 'original': original_id, 'normalized': normalized, 'suggestion': normalized.replace('_', '-').replace(' ', '-') }) if errors: print(f"❌ Found {len(errors)} model ID formatting issues:") for err in errors: print(f" Line {err['line']}: '{err['original']}' -> '{err['normalized']}' (Suggestion: '{err['suggestion']}')") sys.exit(1) else: print("✅ All model IDs are correctly formatted.") if __name__ == "__main__": main()

这个脚本的关键在于：

• 它完全复刻了 Cherry Studio 的normalize_id()函数，保证检查逻辑和运行时一致。
• 它不仅告诉你“错了”，还给出了可直接复制粘贴的修正建议（suggestion字段），把修复成本降到最低。
• 它被集成在 CI 的pre-commithook 和buildstage 里，任何一次git push或make build，都会自动运行。问题在代码提交的瞬间就被捕获，而不是等到服务启动失败。

4. 实操过程与核心环节实现：从零开始的完整修复流水线

4.1 环境准备与工具链搭建

在动手之前，确保你的本地环境干净且可复现。我推荐用pyenv+venv的组合，避免污染全局 Python 环境：

# 1. 安装 pyenv（macOS） brew install pyenv pyenv install 3.11.9 pyenv local 3.11.9 # 2. 创建并激活虚拟环境 python -m venv .cherry-env source .cherry-env/bin/activate # 3. 安装 Cherry Studio（指定版本，确保可复现） pip install cherry-studio==2.3.0 # 4. 安装辅助工具 pip install pyyaml requests tcpdump # tcpdump 需要系统安装，macOS: brew install tcpdump

提示：永远不要用pip install cherry-studio不带版本号。生产环境必须锁定版本，否则某天pip install会悄悄把你带到一个有未知 bug 的新版本上。把cherry-studio==2.3.0写进你的requirements.txt，并用pip install -r requirements.txt安装。

4.2 复现问题：构建一个最小可复现案例（MRE）

为了确保我们的问题不是偶发，也为了方便后续向社区提 issue（虽然这次是设计使然），我构建了一个 MRE：

# models.yaml (problematic version) models: - id: "qwen2-7b-chat_v2" # <-- This is the problematic ID path: "/path/to/qwen2-7b-chat-v2" type: "transformers" config: trust_remote_code: true - id: "qwen2-7b-chat-v1" # <-- This is the fallback target path: "/path/to/qwen2-7b-chat-v1" type: "transformers" config: trust_remote_code: true

然后，我创建了一个test_api.sh脚本，用来一键复现：

#!/bin/bash # Start service in background with debug log cherry serve --config models.yaml --log-level DEBUG --enable-debug-endpoint > logs/debug.log 2>&1 & # Wait for service to be ready sleep 5 # Send test request and capture output RESPONSE=$(curl -s -X POST http://localhost:8000/v1/chat/completions \ -H "Content-Type: application/json" \ -d '{"model": "qwen2-7b-chat_v2", "messages": [{"role": "user", "content": "hello"}]}') # Extract model name from response (if present) or just print raw echo "Raw Response:" echo "$RESPONSE" | jq '.' 2>/dev/null || echo "$RESPONSE" # Check debug registry echo -e "\nRegistry Status:" curl -s http://localhost:8000/debug/registry | jq '.registered_models' # Kill the service pkill -f "cherry serve"

运行这个脚本，你会清晰地看到：qwen2-7b-chat_v2不在 registry 列表里，而响应内容明显是 v1 的风格。这个 MRE，就是你和问题对话的“语言”，也是你和同事、和开源社区沟通的“通用语”。

4.3 执行修复：从配置修改到服务验证的全流程

修复本身很简单，但流程必须严谨。我把它拆解为 5 个原子步骤，每一步都有明确的成功标准：

实操心得：不要跳过任何一步。我曾经在第 3 步看到Loading model...就以为好了，结果第 4 步发现 registry 里没有，回头一看，是models.yaml里有个缩进错误，导致id字段没被正确解析。静态检查（Step 2）和动态检查（Step 4）是两道最重要的防火墙。

4.4 自动化集成：将修复流程嵌入 CI/CD

一个成熟的团队，不会让“修复”成为一个手工操作。我把上面的 5 个步骤，全部写进了 GitHub Actions 的 workflow 文件里：

# .github/workflows/deploy.yml name: Deploy Cherry Studio on: push: branches: [main] paths: ['models.yaml', 'cherry/**'] jobs: validate: runs-on: ubuntu-latest steps: - uses: actions/checkout@v4 - name: Set up Python uses: actions/setup-python@v4 with: python-version: '3.11' - name: Install dependencies run: | pip install cherry-studio==2.3.0 pyyaml - name: Check model ID formatting run: python check_model_ids.py models.yaml deploy: needs: validate runs-on: ubuntu-latest steps: - uses: actions/checkout@v4 - name: Deploy to staging # ... your actual deployment steps (scp, kubectl, etc.)

这个 workflow 的精妙之处在于：validatejob 是deployjob 的前置依赖。只要check_model_ids.py退出码非 0（即发现错误），整个 workflow 就会立即失败，deploy根本不会执行。这就在代码合并的源头，掐死了所有格式错误的配置流入生产环境的可能性。它不依赖人的自觉，只依赖机器的严格执行。

4.5 回滚预案：当修复失败时，如何 30 秒内恢复服务

再完美的流程，也要有 Plan B。我的回滚预案极其简单粗暴：

• 备份：在每次修改models.yaml前，自动创建一个带时间戳的备份：cp models.yaml models.yaml.$(date +%Y%m%d_%H%M%S).bak

• 一键回滚脚本：rollback.sh

  #!/bin/bash LATEST_BAK=$(ls models.yaml.*.bak | sort -r | head -1) if [ -n "$LATEST_BAK" ]; then cp "$LATEST_BAK" models.yaml echo "Rolled back to $LATEST_BAK" else echo "No backup found!" fi

• 服务重启：cherry serve --config models.yaml。由于旧版配置是已知能工作的，服务会在 2 秒内恢复。

整个过程，从发现问题到服务恢复，理论上可以在 30 秒内完成。这比你解释“为什么出问题”还要快。在运维的世界里，快速恢复，永远比完美修复更重要。

5. 常见问题与排查技巧实录：那些让我拍大腿的“原来如此”

5.1 常见问题速查表

5.2 独家避坑技巧：那些文档里不会写的“血泪史”

• 技巧一：用jq做 YAML 的“可视化”检查
  models.yaml是 YAML，但人眼容易看错缩进。一个绝招是：yq e -P models.yaml \| less（需要先pip install yq）。yq会把 YAML 转成带颜色、带缩进的 JSON 格式，一眼就能看出id字段是不是在models数组里，还是被错放在了外面。

• 技巧二：curl的-v参数是你的“网络透视眼”
  当你怀疑是网络层的问题（比如 Nginx 代理篡改了model参数），不要只看响应体。用curl -v，它会打印出完整的 HTTP 请求头和响应头。你会发现，有时候问题不在 Cherry Studio，而在你前面的网关，它把model=qwen2-7b-chat_v2里的_给 URL Decode 丢了。

• 技巧三：strace是终极“黑盒探测器”
  如果以上所有方法都失效，strace就是你的最后一张牌。strace -e trace=openat,read,write -p $(pgrep -f "cherry serve") 2>&1 \| grep -i "models.yaml"。它会告诉你服务进程到底打开了哪个models.yaml文件（路径可能和你想的不一样），以及它读取了哪些内容。我曾经用它发现，服务读取的其实是/tmp/cherry/models.yaml，而不是我本地编辑的那个，因为 CI 脚本里有个cp命令写错了路径。

• 技巧四：“最小化”原则的极致应用
  当你陷入困境，立刻执行“最小化”：新建一个空目录，只放一个最简models.yaml（1 个模型，ID 是test），一个最简test.sh（只发一个 curl）。如果这个最小环境能 work，那就说明你的原始环境里，一定有某个你忽略的变量（比如环境变量CHERRY_CONFIG_PATH覆盖了你的配置）。这个技巧，能帮你把问题域从“整个宇宙”缩小到“一个文件”。

5.3 一次真实的“连锁反应”排查记录

上周，一个合作团队报告说，他们的 Cherry Studio 服务在升级后，所有模型都 fallback 到了同一个default模型。我接手后，按上述流程走了一遍，发现/debug/registry里只有一个 ID：default。这很奇怪，因为他们的models.yaml里明明写了 5 个模型。我用yq e -P models.yaml一看，真相大白：整个models数组，被错误地缩进了 2 个空格，导致 YAML 解析器认为models是一个字符串，而不是一个数组。yq的输出是：

{ "models":