深入 OpenMed PII 模型卡：pii::small::mlx-fp last-green 指针与 44M 全精度 MLX 端侧脱敏模型

深入 OpenMed PII 模型卡：pii::small::mlx-fp last-green 指针与 44M 全精度 MLX 端侧脱敏模型

【免费下载链接】openmedLocal-first healthcare AI: clinical NER & HIPAA PII de-identification that runs 100% on-device. 2,200+ medical models, 21 languages, Apple MLX + Python, no cloud, no patient data leaving your network. Apache-2.0项目地址: https://gitcode.com/GitHub_Trending/ope/openmed

导读：本文以 OpenMed 仓库中 pii-small-mlx-fp-last-green.md 这张模型卡为骨架，逐段解读OpenMed/OpenMed-PII-SuperClinical-Small-44M-v1-mlx这一 PII 小尺寸全精度 MLX 检查点的清单元数据、注册表槽位与 last-green 指针语义、tokenizer 脚本覆盖审计、50 个规范实体标签以及本地接入方法。读完本文，你将掌握"如何读懂一张 manifest 驱动的 OpenMed 模型卡"，并能在设备端（Apple Silicon）正确选用与验证这款 44M 的 HIPAA PII 脱敏模型。

模型卡的由来：manifest 驱动的注册表发布面

这张卡片本身是一份生成产物，而非手写文档。卡片开头的注释写得很明确：

• Generated from models.jsonl. Do not edit this file directly.
• Registry pointer: pii::small::mlx-fp/last_green -> OpenMed/OpenMed-PII-SuperClinical-Small-44M-v1-mlx

也就是说，仓库根目录下的 models.jsonl 是 OpenMed 模型目录（model manifest）的唯一事实来源，每一行是一个按repo_id键控的 JSON 对象，注册表无需网络即可加载它。模型卡由发布步骤从 manifest 行渲染生成，模型清单 中明确说明了各字段含义与更新方式。

完整的发布流程分为四步：

# 1. 从 Hugging Face 组织刷新基础 manifest（保留已有 enrichment 字段） python scripts/manifest/generate_manifest.py --output models.jsonl # 2. 对 PII 家族执行 11 脚本 tokenizer 覆盖审计（新加入的 PII 行必须完成审计才能通过校验） uv pip install -e ".[dev,hf]" .venv/bin/python scripts/audit_pii_tokenizer_coverage.py --update-manifest --resume # 3. 合并基准与设备测量结果（下载体积、延迟、内存、benchmark） python scripts/manifest/enrich_manifest.py \ --manifest models.jsonl \ --results benchmark-results.json \ --output models.enriched.jsonl # 4. 重新生成所有提交的发布面（README 计数、注册表卡片、MkDocs 目录表） python scripts/manifest/regenerate_surfaces.py

第 4 步 regenerate_surfaces.py 只读取本地已提交的输入、不访问网络，CI 会以相同命令校验生成结果是否有 diff。因此修改模型元数据的正确姿势是改models.jsonl后重新生成，而不是手改 docs/model-cards/registry 下的卡片——这也是本文所分析的卡片与它的姊妹卡片 pii-small-mlx-fp-latest.md 在内容上同构的原因。

Manifest 摘要逐项解读

模型卡中的 Manifest Summary 表格完整对应 models.jsonl 中第 1887 行OpenMed/OpenMed-PII-SuperClinical-Small-44M-v1-mlx的行数据，逐项含义如下：

值得注意的是，同一条模型族谱还有第三个兄弟检查点OpenMed/OpenMed-PII-SuperClinical-Small-44M-v1-onnx-android（models.jsonl 第 1888 行），它走onnx格式、面向 Android 端侧，formats只列onnx，与本文的 MLX 检查点形成"同一基座、多运行时不发"的格局。

last-green 指针：注册表槽位与回滚语义

模型卡标题中的 "last-green" 不是模型名的一部分，而是**发布通道指针（pointer）**的名称。OpenMed 的注册表状态存放在 gates/registry_state.json（schema v2），按family::tier::format归一化键划分稀疏发布槽位。本文模型对应的槽位内容如下：

{ "schema_version": 2, "slots": { "pii::small::mlx-fp": { "checkpoints": { "OpenMed/OpenMed-PII-SuperClinical-Small-44M-v1-mlx": "1.0.0" }, "lineage": [], "pointers": { "canary": null, "last_green": "OpenMed/OpenMed-PII-SuperClinical-Small-44M-v1-mlx", "latest": "OpenMed/OpenMed-PII-SuperClinical-Small-44M-v1-mlx" } } } }

结合 模型注册表 的说明可以读出三层语义：

• 槽位键pii::small::mlx-fp：(family, tier, format) = (PII, Small, mlx-fp)，只有当检查点以 RELEASABLE 门禁报告晋升、且其 manifest 行坐标匹配时才创建该通道；
• SemVer 分配：每个检查点在槽位内被分配1.0.0（首个目标），后续新目标做 minor 递增；版本从不从 repo id 解析，-v1是上游模型名的一部分而非版本序列；
• 三个指针：canary（金丝雀，当前为 null）、latest（当前对外发货目标）、last_green（最近一次绿灯回滚目标）。本检查点同时占据latest与last_green，说明它既是当前首选、也是安全的回滚点；模型注册表 中同时发布了 latest 卡片 与其 last-green 回滚卡片。

基准证据：从 "Not reported" 到 golden 套件

模型卡中的 Benchmark 小节如实写道：

这与 manifest 行中的benchmark字段（dataset/micro_f1/recall均为 null）一致——即清单层未登记聚合指标，卡片照实渲染，没有编造数字。

但仓库中存在更细粒度的基准证据链，可以作为补充参考：

• docs/benchmarks/golden.md 中的 golden 基准卡，针对的正是OpenMed/OpenMed-PII-SuperClinical-Small-44M-v1-mlx，设备mlx-fp，报告时间戳2026-06-14T00:00:00Z，exact_span_f1各项（precision/recall/F1）均为 1，leakage.overall为 0；
• docs/eval/benchmark-leaderboard/leaderboard.json 中该模型位列 PII 分组第一名，f1: 1.0、recall: 1.0、leakage: 0.0、release_tag: v2.0.0、run_date: 2026-06-14，reproducibility hash 与卡片完全一致。

需要指出的是，golden 基准卡标注Fixtures 1、总字符 4，从源码结构看这是发布门禁级的冒烟样例，而非大规模评测集；引用时应保持这一谨慎口径。manifest 支持的 benchmark 形态有两种：旧的{"dataset": "...", "micro_f1": ..., "recall": ..., "leakage": ...}对象，以及包含suite字段的套件列表，二者在 模型清单 中都有示例。

Tokenizer 脚本覆盖审计：11 个脚本的 unclaimed 判定

卡片用一整张表记录了该模型在 11 个脚本目标上的 tokenizer 覆盖审计结果，这是 PII 家族清单行的强制要求：

三个指标的含义与判定规则（详见 模型清单 与 PII Tokenizer 脚本覆盖审计）：

• UNK rate：该脚本样本中被映射为 UNK token 的比例。此处全部为 100.00%，说明该模型的 DeBERTa 词表对中文/印地语系脚本完全没有覆盖；
• Byte fallback rate：回退到字节级编码的比例，本模型为 0.00%；
• Tokens / grapheme：每个字素平均消耗的 token 数，数值都远小于 1，反映脚本字符无法被正常分词；
• Verdict：判定结果。规则是"UNK 率严格大于 1% 且该脚本被模型所宣称语言认领"时标记为unsupported；而本模型只宣称en，这 11 个 Han/Indic 脚本不属于认领范围，因此审计保留其指标但标记为unclaimed，不会把模型从英语检索中排除。

整个仓库级审计覆盖 654 个 PII 家族模型 × 11 个脚本目标，其中 4114 对超过 UNK 阈值、76 对"已认领但 unsupported"（docs/model-tokenizer-script-coverage.md）。在注册表层面，get_pii_models_by_language会把"宣称语言脚本被明确判定 unsupported"的模型从结果中剔除，UNK/字节回退/每字素 token 数等原始指标仍保留在ModelInfo.script_coverage上供 UI 告警与诊断使用。

Canonical Labels：50 个规范 PII 实体类型

卡片最后列出了该模型支持的全部规范实体标签，它们是 OpenMed 跨模型统一的实体命名空间（manifest 行canonical_labels字段），可按语义归类：

• 身份：PERSON、FIRST_NAME、LAST_NAME、MIDDLE_NAME、PREFIX、USERNAME、GENDER
• 联系方式：EMAIL、PHONE、URL、IP_ADDRESS、MAC_ADDRESS、USER_AGENT
• 位置：LOCATION、STREET_ADDRESS、BUILDING_NUMBER、ZIPCODE、GPS_COORDINATES、ORDINAL_DIRECTION
• 时间：DATE、DATE_OF_BIRTH、TIME、AGE
• 证件与金融：ID_NUM、SSN、ACCOUNT_NUMBER、PASSWORD、PIN、API_KEY、CREDIT_CARD、CREDIT_CARD_ISSUER、CVV、IBAN、BIC、AMOUNT、CURRENCY、BITCOIN_ADDRESS、ETHEREUM_ADDRESS、LITECOIN_ADDRESS、MASKED_NUMBER、VIN、VEHICLE_REGISTRATION、IMEI
• 职业/组织：ORGANIZATION、JOB_TITLE、JOB_DEPARTMENT、OCCUPATION
• 生理特征：EYE_COLOR、HEIGHT
• 兜底：OTHER

合计 50 个标签，覆盖了 HIPAA Safe Harbor 常见的直接标识符（姓名、SSN、电话、日期、地址等）以及当代隐私风险点（API Key、加密货币地址、MAC 地址、VIN、IMEI 等），可作为前端筛选器（filter chips）或下游审计逻辑的枚举来源。

选择与使用：如何在本地接入该模型

技能：选择 PII 模型 给出了离线选型的标准流程：先识别输入语言与脚本 → 选择运行时（pytorch用于 CPU/导出源，mlx-fp或mlx-8bit用于 Apple Silicon）→ 以get_default_pii_model(language)为基线 → 按运行时与设备预算过滤 → 上线前必须做召回验证。其可运行的离线短名单代码如下：

from openmed import get_default_pii_model, get_pii_models_by_language LANGUAGE = "en" TARGET_FORMAT = "mlx-fp" # Use "pytorch" for CPU or as an export source. MAX_PARAMETERS_M = 150 baseline_id = get_default_pii_model(LANGUAGE) models = get_pii_models_by_language(LANGUAGE) shortlist = [ (key, info) for key, info in models.items() if TARGET_FORMAT in info.formats and info.size_mb is not None and info.size_mb <= MAX_PARAMETERS_M ] shortlist.sort( key=lambda item: ( item[1].model_id != baseline_id, item[1].size_mb, item[0], ) ) if not shortlist: raise RuntimeError("No compatible PII model fits the requested budget") registry_key, selected = shortlist[0]

这段代码只读取打包进仓库的 manifest，不会下载权重，因此天然离线安全。此外还可以用 CLI 在落地数据前规划下载体积与内存预算（默认路径不访问 Hugging Face）：

OPENMED_OFFLINE=1 openmed models size disease_detection_tiny openmed models size --budget-mb 100 openmed models size --budget-mb 100 --format json openmed models size disease_detection_tiny --remote # 显式选择时才联网刷新估算

ModelInfo上的size_category、size_mb、latency_ms、peak_ram_mb、recommended_tier可用来判断模型是否适配 CPU-only 或目标设备层级；recommended_confidence可作为 API 调用的默认阈值传入analyze_text。注意尺寸单位是十进制 MB（1 MB = 1,000,000 字节），联网刷新需要可选依赖openmed[hf]。

许可、可复现性与供应链

该检查点声明apache-2.0许可，与仓库整体许可一致。卡片中的 reproducibility hashsha256:4818bdef...不是权重字节的哈希，而是把目录行绑定到仓库修订与文件清单的稳定性哈希；模型工件字节本身由独立的缓存完整性清单（cache integrity manifest）校验，相关机制见 供应链控制 中的模型工件完整性一节。

另一个值得注意的约束来自 manifest 规范：基准与设备结果文件中只允许存放聚合指标，严禁写入原始 PHI、提示词、文档或样例（模型清单），这保证了这张面向 HIPAA 场景的模型卡在发布链路上也不会泄露患者数据。

小结

从 pii-small-mlx-fp-last-green.md 一张卡片出发，可以完整看到 OpenMed 模型治理的闭环：models.jsonl清单 → 强制 tokenizer 审计 → 门禁晋升与 SemVer 分配 →latest/last_green指针管理 → 模型卡等发布面自动生成。OpenMed-PII-SuperClinical-Small-44M-v1-mlx作为pii::small::mlx-fp槽位的唯一检查点，是一款面向英语临床文本、基于 DeBERTa-v2 的 44M token 分类 PII 模型，支持 50 个规范实体，以全精度 MLX 格式面向 Apple Silicon 设备端部署；其"未认领 11 个非英语脚本"的审计结果既是诚实的边界声明，也为多语言场景下改用其他 PII 模型提供了依据。

【免费下载链接】openmedLocal-first healthcare AI: clinical NER & HIPAA PII de-identification that runs 100% on-device. 2,200+ medical models, 21 languages, Apple MLX + Python, no cloud, no patient data leaving your network. Apache-2.0项目地址: https://gitcode.com/GitHub_Trending/ope/openmed