深入 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的行数据逐项含义如下字段值说明RepositoryOpenMed/OpenMed-PII-SuperClinical-Small-44M-v1-mlxHugging Face 模型 ID-mlx后缀表示 MLX 转换检查点FamilyPII模型家族manifest 中还包括NER、Vision、ZeroShot、GeneralTasktoken-classification管道任务类型即逐 token 打标签的序列标注LanguagesenBCP 47 风格语言码本模型仅宣称英语TierSmall发布尺寸层级另有 Tiny / Base / Large 等Parameters44M (44,000,000)param_count整数44,000,000Architecturedeberta-v2骨干架构其上游 models.jsonl 第 1886 行显示 PyTorch 基座OpenMed/OpenMed-PII-SuperClinical-Small-44M-v1的 base model 为microsoft/deberta-v3-smallBase modelOpenMed/OpenMed-PII-SuperClinical-Small-44M-v1本次 MLX 转换的源检查点Formatsmlx-fp, pytorch可用产物格式mlx-fp为 Apple Silicon 全精度 MLX 权重Licenseapache-2.0声明许可arXivarXiv:2508.01630关联论文编号卡片声明值注意 manifest 行的arxiv字段当前为 nullReproducibility hashsha256:4818bdef580eb406f5cc665cc0892aefab1fd90c8743822d843dd48f135bde34仓库/来源哈希将目录行绑定到某个仓库修订与文件清单Released2026-04-14发布日期YYYY-MM-DD值得注意的是同一条模型族谱还有第三个兄弟检查点OpenMed/OpenMed-PII-SuperClinical-Small-44M-v1-onnx-androidmodels.jsonl 第 1888 行它走onnx格式、面向 Android 端侧formats只列onnx与本文的 MLX 检查点形成同一基座、多运行时不发的格局。last-green 指针注册表槽位与回滚语义模型卡标题中的 last-green 不是模型名的一部分而是**发布通道指针pointer**的名称。OpenMed 的注册表状态存放在 gates/registry_state.jsonschema 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 小节如实写道DatasetMicro F1RecallNot reportedNot reportedNot reported这与 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:00Zexact_span_f1各项precision/recall/F1均为 1leakage.overall为 0docs/eval/benchmark-leaderboard/leaderboard.json 中该模型位列 PII 分组第一名f1: 1.0、recall: 1.0、leakage: 0.0、release_tag: v2.0.0、run_date: 2026-06-14reproducibility hash 与卡片完全一致。需要指出的是golden 基准卡标注Fixtures 1、总字符 4从源码结构看这是发布门禁级的冒烟样例而非大规模评测集引用时应保持这一谨慎口径。manifest 支持的 benchmark 形态有两种旧的{dataset: ..., micro_f1: ..., recall: ..., leakage: ...}对象以及包含suite字段的套件列表二者在 模型清单 中都有示例。Tokenizer 脚本覆盖审计11 个脚本的 unclaimed 判定卡片用一整张表记录了该模型在 11 个脚本目标上的 tokenizer 覆盖审计结果这是 PII 家族清单行的强制要求ScriptUNK rateByte fallback rateTokens / graphemeVerdictHan Simplified100.00%0.00%0.1000unclaimedHan Traditional100.00%0.00%0.1096unclaimedDevanagari100.00%0.00%0.3425unclaimedBengali100.00%0.00%0.3151unclaimedTamil100.00%0.00%0.3108unclaimedTelugu100.00%0.00%0.3286unclaimedKannada100.00%0.00%0.3582unclaimedMalayalam100.00%0.00%0.3158unclaimedGujarati100.00%0.00%0.3151unclaimedGurmukhi100.00%0.00%0.3108unclaimedOdia100.00%0.00%0.2933unclaimed三个指标的含义与判定规则详见 模型清单 与 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 对已认领但 unsupporteddocs/model-tokenizer-script-coverage.md。在注册表层面get_pii_models_by_language会把宣称语言脚本被明确判定 unsupported的模型从结果中剔除UNK/字节回退/每字素 token 数等原始指标仍保留在ModelInfo.script_coverage上供 UI 告警与诊断使用。Canonical Labels50 个规范 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( keylambda 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 FaceOPENMED_OFFLINE1 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。注意尺寸单位是十进制 MB1 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创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考