企业官网建设流程全解析

Hulu-Med是一个面向整体医疗视觉-语言理解的开源多模态大模型，能同时处理医疗文本、2D 影像、3D 体数据（CT/MRI 的 NIfTI 文件）和手术视频。很多新手第一次喂给它 3D CT 时都会卡壳：nii_slice_axis该填什么？nii_num_slices设多少合适？merge_size又是什么？本文用一个真实的 3D 推理示例，把这三个关键参数讲透，帮你快速上手 Hulu-Med 的 3D CT 报告生成任务。

一、核心思路：把 3D CT 当成"视频"来喂

Hulu-Med 处理 3D 数据的底层逻辑非常巧妙：它把 3D 体数据统一建模为"时间或空间维度上的扩展"，也就是把一摞 CT 切片当作一段"视频帧"序列送入模型。

官方注释原文："We unify the modeling of video and 3D inputs as extensions along the temporal or spatial dimension"

这意味着两件事：

1. 3D CT 会被切成一叠 2D 切片图，按顺序排列成帧序列；
2. 3D 场景复用的是video模态，所以推理时modal参数要写'video'，并且merge_size通常设为2（单张 2D 图像则设为1）。

这一"视频化"设计让 Hulu-Med 无需改造视觉编码器，就能复用成熟的时间建模能力理解整个 3D 结构。

二、参数实战 1：nii_slice_axis—— 从哪个轴切？

3D 数据加载函数是load_images，当传入.nii或.nii.gz文件时，会自动调用slice_nifti_to_images进行切片，核心实现在 mm_utils.py：

axis_map = {'axial': 2, 'coronal': 1, 'sagittal': 0}

三个可选值对应医学影像的三个标准平面：

对于常规腹部 CT 报告生成（如仓库示例中的 AMOS 数据），用默认的axial即可；当你想考察特定方向（如脊柱侧面形态）时再切换轴。

三、参数实战 2：nii_num_slices—— 切多少帧？

切片数量由nii_num_slices控制，默认180。切分方式不是简单取前 N 帧，而是用np.linspace在整个轴上均匀采样指定帧数（mm_utils.py）：

num_total_slices = image_data.shape[slice_axis] sampled_indices = np.linspace(0, num_total_slices - 1, num_slices, dtype=int)

同时每张切片会被做逐帧归一化（0~255 拉伸转 RGB），所以不同窗宽窗位的 CT 也能被稳定读取。

怎么设置帧数？记住两个权衡：

• 📉帧数越多→ 空间覆盖越完整，细节越多，但视觉 token 暴涨，显存和推理时间线性上升；
• 📈帧数越少→ 快而省，但可能漏掉关键层面（比如病灶恰好落在被跳过的层面）。

仓库官方示例中，AMOS 腹部 CT 用的是nii_num_slices=160，手术视频用max_frames=1800（见 Inference.ipynb）。新手建议：

• 腹部/胸腔 CT 报告：120 ~ 180帧起步
• 显存紧张（如 24G 显卡跑 14B 模型）：降到80 ~ 120
• 精细定位任务：适当加帧，配合merge_size=2控制 token 量

四、参数实战 3：merge_size—— 视觉 token 的"压缩开关"

merge_size是 Hulu-Med 视觉编码器的空间合并参数：视觉特征图上的每merge_size × merge_size个 patch 合并为 1 个 token 送入 LLM。它直接影响：

• token 数量：merge_size=2时视觉 token 量约为merge_size=1的 1/4；
• 显存占用与推理速度：token 越少越快。

处理逻辑在 image_processing_hulumed.py 中，merge_size会参与目标尺寸计算（factor = patch_size * merge_size），保证图像被缩放为合并后整除的尺寸；processor 层在 processor.py 将其透传给图像处理器。

官方惯例非常明确（README 与推理示例中一致）：

inputs = processor( images=[slices] if modal != "text" else None, text=conversation, merge_size=2 if modal == "video" else 1, # 3D 和视频用 2，2D 图像用 1 return_tensors="pt" )

也就是说：3D CT（video 模态）固定merge_size=2。因为 3D 帧数多，若不合并 token 会爆炸；而单张 2D 图像 token 少，用1可保留最细粒度。

五、完整 3D CT 推理流程速览

以仓库示例 Inference.ipynb 的 3D 场景为例，流程只有四步（完整示例见 README.md）：

① 加载 NIfTI 并切片

slices = load_images( "./demo/amos_0013.nii", # 支持 .nii / .nii.gz nii_num_slices=160 # 沿默认 axial 轴均匀采样 160 帧 )

② 构造对话（模态标为 video）

conversation = [ { "role": "user", "content": [ {"type": "video", "num_frames": len(slices)}, {"type": "text", "text": "This is a medical 3D scenario. Please generate a medical report for the given 3D medical images, including both findings and impressions."}, ] } ]

③ Processor 编码（3D 用 merge_size=2）

④ 生成：model.generate(..., modals=['video'], ...)得到包含 findings 和 impressions 的结构化报告。

如果走 vLLM 加速推理，可参考 Hulumed_VLLM.ipynb；Qwen3 版本模型的调用方式见 Inference_qwen3.ipynb。

六、新手常见问题

Q1：为什么我的 3D 推理特别慢/爆显存？先降nii_num_slices（如 160 → 100），这是最直接的杠杆；merge_size=2是官方推荐值，不建议为 3D 场景改成 1。

Q2：切片后每张图是什么格式？slice_nifti_to_images会逐帧做 min-max 归一化并转成uint8RGB 图像，模型输入始终是标准 2D 图像序列，无需额外预处理。

Q3：轴选错了会怎样？不会报错，但看到的"帧序列"方向变了（如 coronal 轴每帧是纵向断面）。报告类任务建议保持axial，与临床阅片习惯一致。

Q4：视频和 3D 参数一样吗？模态处理一致（都用video+merge_size=2），区别只在于帧来源：视频用load_video按fps抽帧，3D 用load_images按轴切片。

七、小结

掌握这三个参数，你就能灵活地在"覆盖度、速度、显存"之间做平衡，用 Hulu-Med 稳定跑通 3D CT 报告生成任务。更多模型与评测细节可查阅 README.md，批量评测代码位于 MedUniEval/ 目录。