Hugging Face 5 月 8 日发了一篇 MedQA 项目 walkthrough。

开发者在 AMD Instinct MI300X 上，用 ROCm 6.1、PyTorch 和 Hugging Face 工具链，微调 Qwen/Qwen3-1.7B。任务很具体：回答 MedMCQA 医学选择题，输出答案字母，同时给出医学解释。

这件事容易被读偏。

它不是在宣布一个可靠医疗 AI 诞生了。更准确的看点是：在一个小样本项目里，AMD ROCm 跑通了 Hugging Face 生态下很常见的 LLM 微调流程，而且不需要 CUDA，也没有依赖 bitsandbytes 量化。

这才是工程师会关心的地方。

这次 MedQA 到底做了什么

项目用的数据集是 openlifescienceai/medmcqa。它来自医学考试类选择题，每条样本包含题干、A-D 四个选项、正确答案索引，以及可选解释字段。

但训练规模很小。原文只用了 2000 条训练样本，不是完整 MedMCQA 训练。

基础模型是 Qwen/Qwen3-1.7B。训练方式是 PEFT 的 LoRA，只在 q_proj、v_proj 等注意力模块中注入可训练参数。原文给出的可训练参数约 222 万，占总参数约 0.15%。

在 MI300X 上，这次训练大约 5 分钟。

项目原文配置现实判断
基础模型Qwen/Qwen3-1.7B小模型微调演示，便宜快，但能力上限有限
数据MedMCQA 2000 条样本只能说明流程可跑，不能代表完整医学评测
方法LoRA，约 222 万可训练参数适合快速适配，不等于注入完整医学知识
输出答案字母 + 医学解释演示效果更完整，但解释不自动等于可靠
产物HF 模型、Spaces Demo、GitHub 仓库对开发者有复现价值，不只是截图展示

这里有个细节值得留意：输出不只是一枚选项字母，还包含解释。

对 Demo 来说，这会更像一个问答系统。对医疗场景来说，这也更危险。因为解释写得顺，不代表解释对。医学问答最怕的不是“不知道”，而是一本正经地错。

所以，MedQA 更像一次工程验证，不是一次临床验证。

ROCm 的进展在于常规工具链能跑

过去几年，开源大模型微调的默认路线基本围着 NVIDIA CUDA 转。

很多开发者写训练脚本时，默认会碰到 CUDA、bitsandbytes、FlashAttention、各类 4-bit 或 8-bit 量化。生态先支持 NVIDIA，再考虑其他硬件，这是很现实的路径依赖。

AMD 要进入 AI 训练主流工作流，难点不只是芯片参数。软件栈能不能少折腾，才是开发者会不会留下来的关键。

这次项目给出的信号是：至少在 Qwen3-1.7B + LoRA + Hugging Face 常规组件这条路上，ROCm 已经能跑通。

训练路线常见 CUDA 路线这次 ROCm 路线
硬件依赖NVIDIA GPUAMD Instinct MI300X
软件底座CUDA + PyTorchROCm 6.1 + PyTorch
HF 组件Transformers / PEFT / TRL / Accelerate同样使用这些组件
量化依赖常见 bitsandbytes 4-bit/8-bit未使用 bitsandbytes
关键约束CUDA 生态成熟，但硬件绑定强可绕开 CUDA，但仍有兼容性问题

MI300X 的 192GB HBM3 很关键。

这个显存容量让 Qwen3-1.7B 的 LoRA 训练可以直接用 fp16 跑，不必为了省显存上 4-bit 或 8-bit 量化。这样也绕开了 bitsandbytes 在 ROCm 上不支持的问题。

对工程团队来说，这不是一个小差别。

少一个量化依赖，就少一类环境排查、算子兼容和精度问题。训练能不能跑起来，很多时候就卡在这些地方。

但这条结论不能放大。

MI300X 是数据中心级 GPU，不能把它的显存优势泛化到所有 AMD GPU。原文也没有说 ROCm 对所有模型、所有库都已经顺滑。

它还列出了具体坑：bf16 曾出现 NaN loss，需要改用 fp16；GPU 检测依赖 ROCR_VISIBLE_DEVICES、HIP_VISIBLE_DEVICES、HSA_OVERRIDE_GFX_VERSION 等环境变量；Transformers 版本也需要放在合适范围。

这是一条已经能走的路。

还不是一条不用看路的路。

谁该因此调整判断

最该看这篇 walkthrough 的，不是医疗产品团队。

医疗团队当然可以参考任务形式，比如选择题、答案、解释如何组织。但这次项目没有临床验证，也没有完整 held-out accuracy benchmark。原文提到 baseline MedMCQA accuracy 约 45%，也不能当作充分训练后的医学能力证明。

真正受影响的是两类人。

一类是已经采购或正在评估 MI300X 的 AI 工程团队。对他们来说，这篇文章提供了一个现实动作：可以拿 Hugging Face 这套常规微调链路做内部 smoke test，而不是只看硬件参数表。

另一类是做小模型 LoRA 微调、又不想把训练栈完全绑在 NVIDIA 上的开发者。他们可以更早把 ROCm 纳入实验矩阵，但不宜直接迁移生产训练。

更现实的做法是分三步：先复现这类小模型 LoRA；再换成自己的数据和评测集；最后再看更大模型、更复杂训练库和更长任务是否稳定。

接下来要观察的变量也很具体。

观察点为什么重要现在能下的判断
完整 MedMCQA 训练效果2000 条样本太小，无法代表医学问答能力目前看不清
更大模型训练稳定性小模型 LoRA 跑通，不等于大模型训练稳定需要单独验证
ROCm 对复杂库的兼容真实训练常会叠加量化、加速、分布式组件不能假设全无痛
医疗可信度机制医学问答需要评测、校准、RAG 或人工审查Demo 解释不能替代验证

这也是我更在意的分界线。

如果只看医学问答，MedQA 还只是一个样例。如果看非 CUDA 训练栈，它至少表明：Hugging Face 主流工具链和 AMD ROCm 之间，已经不再只是“理论上能适配”。

但信任不是靠一篇 walkthrough 建起来的。

开发者最终看的是迁移成本、报错密度、训练稳定性和复现难度。能跑通是第一步。能少折腾，才是真进展。