cat README.md | head -20
OpenMed
本地优先的医疗 AI 框架。1000+ 专业模型、12 种语言、HIPAA 级去标识化。患者数据永不离开设备——从一行 Python 到原生 iPhone App，全链路本地运行。
// 目录
// 概览
// 一个 Spark NLP 七年老兵，为什么自己出来干
每天跑 GitHub AI 日报快三个月了，见过的"医疗 AI"项目一只手数得过来。不是没有，是大部分看一眼就知道是玩具——搭个 LangChain 套 OpenAI 接口，加个白大褂 emoji，就叫医疗 AI 了。
所以当我看到 maziyarpanahi/openmed 的时候，第一反应不是兴奋，是困惑。这项目今天在 GitHub Trending 上只涨了 426 个 Star，总数才 2800。但它有一个我很少在 AI 开源项目里看到的标签——on-device。零数据上传。所有处理跑在本地。
Maziyar Panahi。这个名字你可能不熟，但如果你在医疗 NLP 领域待过，大概率用过他的东西。他是 John Snow Labs 的 Spark NLP 技术负责人，干了七年。在他手里，Spark NLP 从三位数下载量涨到 1.5 亿次，模型从几十个扩展到 13 万多个预训练管道，覆盖 200 多种语言。他是全球最懂"怎么把 NLP 模型做得又好又快"的那几个人之一。
2025 年初，他从 John Snow Labs 离职，开始搞 OpenMed。离职原因他没写得太直白，但把 Spark NLP 的商业模式和 OpenMed 的定位放在一起看，答案挺清楚的：Spark NLP 是一个企业级商业产品，功能全，但天然倾向于跑在服务器上。而医疗数据，在地球上任何一个国家，都不应该随便离开医院的网络。
OpenMed 做的事情其实很简单：把 Spark NLP 七年里最好的方法论（领域自适应预训练 + LoRA 微调 + 多语言覆盖），放进一个 pip install 就能跑、数据永远不出设备的 Python 包里。
// "数据不上传"不是口号，是医院能不能用 AI 的唯一前提
我认识几个在国内做医疗 AI 落地的朋友。他们的统一反馈是：医院对 AI 的态度已经从"这东西行不行"变成了"这东西安不安全"。不是模型精度的安全。是数据的安全。
你能想象一个三甲医院把几千份病人病历传到一个云端 API 上去做实体识别吗？在中国不行。在美国也不行。在欧盟，GDPR 条款写得清清楚楚——患者数据的跨境传输必须经过一系列审批，违规罚款可以到全球营收的 4%。这不是技术问题。这是合规问题。
OpenMed 给出的方案非常直接：所有模型跑在你的设备上。 CPU 能跑，CUDA 能跑，Apple Silicon 能跑（MLX 加速 24-33 倍），甚至 iPhone 上也能跑（通过 OpenMedKit）。没有 API 调用。没有数据上传。没有供应商锁定。
这就是为什么一个只有 2800 Star 的项目值得认真看——它解决的不是"怎么让 AI 更聪明"，而是"怎么让 AI 能用"。 在医疗这个领域，后一个问题比前一个问题重要得多。
// 实测：拿一段中文病历跑了一下
两分钟装完，直接上手。
准确率可以。但它真正戳中我的是 PII 去标识化：
注意看 use_smart_merging=True 这个参数。它不是默认开启的，但非常重要。很多 NLP 工具的 PII 识别会把"110101196001011234"拆成碎片——"110101""1960""0110""1234"各成一个实体。这在实际使用中是废的。OpenMed 的智能合并让它保持为一个完整的身份证号和电话号码。
这个细节，说明作者真的在医疗行业干过。
// 1000+ 模型是亮点，但不是最亮的
OpenMed 的 Hugging Face 仓库里有 1000+ 个精选的生物医学和临床模型。几个核心的：
| 模型 | 识别类型 | 典型场景 | 参数 |
|---|---|---|---|
| disease_detection_superclinical | 疾病、症状、诊断 | 病历结构化、入组筛选 | 434M |
| pharma_detection_superclinical | 药物、剂量、治疗方案 | 用药审核、安全监测 | 434M |
| anatomy_detection_electramed | 解剖结构、器官 | 影像报告解析 | 109M |
| gene_detection_genecorpus | 基因、蛋白质 | 精准医学、基因组学 | 109M |
| pii_superclinical_large | 姓名、日期、身份证、电话等 | HIPAA/GDPR 合规去标识化 | 434M |
Privacy Filter 系列（基于 OpenAI 开源的 gpt-oss 架构）有三个变体：OpenAI 原版 → NVIDIA Nemotron 微调版 → OpenMed 多语言版。每个都有 PyTorch/MLX/MLX 8-bit 三套权重。总计 247 个 PII 检测检查点，覆盖 12 种语言。
但说实话，1000+ 模型这个数字本身对我来说不是最吸引人的点。Spark NLP 有 13 万个模型，AWS 和 Google 的模型更多。真正让我觉得这个项目"能成"的，是三件事：
1. 12 种语言的 PII 检测。 中文虽然还不是一等公民，但葡萄牙语、阿拉伯语、印地语、日语、土耳其语这些"冷门"语言已经覆盖了。不是"英语项目顺便支持其他语言"，而是把多语言当核心功能做的。
2. Apple Silicon 原生支持。 MLX 后端在 Apple Silicon 上推理速度是 CPU PyTorch 的 24-33 倍。批量处理吞吐量最高提升 3.3 倍（CPU）和 2.2 倍（MLX）。OpenMedKit 是完整的 Swift 包，可以直接集成到 iOS/iPadOS/macOS 应用里。做医疗 AI 的人都知道，医生用的设备大概率是 iPad。
3. 作者有 7 年医疗 NLP 实战经验。 开源项目最怕的不是代码写得不好，是作者不懂这个领域。Maziyar Panahi 在 Spark NLP 七年把医疗 NLP 模型送进了辉瑞、罗氏、克利夫兰诊所。他不是在"玩玩"。
// 架构：四步流水线
// 性能基准
// 竞品对比
| 方案 | 定位 | 本地运行 | 开源 | 医疗专用 | iOS 支持 | 备注 |
|---|---|---|---|---|---|---|
| OpenMed | 本地医疗 NER + PII | ✅ | ✅ Apache-2.0 | ✅ 1000+ 模型 | ✅ OpenMedKit | 12 基准 10 SOTA |
| Spark NLP | 全栈 NLP（含医疗） | ✅ 企业版 | 部分开源 | ✅ 13 万+ 模型 | ❌ | 商业支持强，安装门槛高 |
| scispaCy | 生物医学 NLP | ✅ | ✅ | 中等 | ❌ | 学术界首选，轻量 |
| medspaCy | 临床 NLP | ✅ | ✅ | 中等 | ❌ | Beta 阶段，社区较小 |
| AWS Comprehend Medical | 云端医疗 NLP | ❌ | ❌ | ✅ | ❌ | 需要 BAA 协议，按量计费 |
| Google Cloud Healthcare | 云端医疗 NLP | ❌ | ❌ | ✅ | ❌ | 数据上传至 GCP |
| Azure Text Analytics for Health | 云端医疗 NLP | ❌ | ❌ | ✅ | ❌ | 数据上传至 Azure |
Spark NLP 是 OpenMed 最直接的竞争对手，但关系更像是"上一代平台 vs 下一代工具"。Spark NLP 胜在全——Java/Scala/Python 都支持、13 万个模型、商业支持。但安装门槛高（需要 Java 环境），部署偏服务器端，真正的医疗专用功能在企业付费版里。scispaCy 和 medspaCy 是学术界好选择——轻量、免费、基于 spaCy——但模型精度和数量跟 OpenMed 不在一个量级。
三大云厂商精度不低，但每次调用都意味着患者数据离开医院网络。OpenMed 在精度上不输商业方案（12 基准 10 SOTA），在合规上天然占优（数据不出设备），而且 Apache-2.0 完全免费可商用。
// 综合评分
• 100% 本地运行，零数据上传——这是医疗 AI 的底线，不是加分项
• 作者 7 年 Spark NLP 实战经验，不是"玩玩"的项目
• 12 基准 10 个 SOTA，轻量训练方案性价比极高
• Apple Silicon MLX 24-33x 加速 + 原生 iOS/macOS（OpenMedKit）
• 12 语言 PII 检测 + HIPAA 全 18 安全港标识符
• Apache-2.0 完全免费可商用
• Bus Factor = 1，单人维护是核心风险，没有之一
• 65 Issues / 19 PRs 积压，作者精力有限
• 强项是 NER + PII 检测，不是 Med-PaLM 那种临床问答大模型
• 中文临床 NER 还不是一等公民
• 2800 Star 说明社区还在早期，真实医院案例待验证
// 跟我在做的事有什么关系
我每天跑 GitHub AI 日报，偶尔会有读者问：你能不能别只写代码工具，写点其他行业的？其实我也想。但有一个现实的问题：不是每个行业都能在"数据不出本地"的前提下用 AI。
OpenMed 让我看到了一种可能性——在一个对数据安全要求最严格的行业里，有人用本地优先的方案，做到了不输商业产品的效果。
这个思路和我现在做的内容创作工具是通的。我做 MangaVideo（AI 短剧流水线）的时候，最头疼的其实是配音环节。把稿子喂给一个云端 TTS 服务，生成语音，没问题——但我的稿子是我的知识产权。如果每天都把几十份稿子传到云上，哪天服务条款一改，我的内容安全谁来保证？OpenMed 的答案很直接：把模型下载下来，在自己的设备上跑。不需要信任任何人。
VoxCPM2（清华 OpenBMB 的本地 TTS 大模型，我上个月写过）也是这个思路。48kHz 录音棚级输出，完全本地运行。如果"本地 AI + 行业垂直"这个模式能在医疗这个最难攻克的领域站稳脚跟，那它在内容创作、法律服务、财务审计这些领域只会更容易。这也是为什么我愿意花时间写一个只有 2800 Star 的项目。
// links
GitHub — maziyarpanahi/openmed
OpenMed 官网 — openmed.life
arXiv 论文 — OpenMed NER (2508.01630)
Hugging Face 模型仓库 — @OpenMed
PyPI — openmed
PII 检测完整指南 (Jupyter Notebook)
我会持续记录一个不会编程的产品经理如何用 AI 写代码、做开源工具、搭 AI 视频流水线，也会每天跑 GitHub 挖掘真正值得看的 AI 开源项目。如果你不想错过下一篇，可以关注我——我不写"保姆级教程"，只写那些我自己试过、花过时间、觉得值得让你也知道的判断。