PaliGemma 不是拿来聊天的。Google 自己的模型卡写得很直白：它不是多轮对话机器人，只服务「一张图 + 一句指令」的单轮调用。它的输入是固定正方形分辨率的图像（224、448、896 三选一）加一段前缀，输出是描述、答案、边界框坐标，或者分割码字。整个家族用 PaliGemmaForConditionalGeneration 这一个类加载，参数量按 safetensors 实测是 3,033,127,152（3B）、9,663,523,568（10B）、27,651,371,760（28B），语言塔对应 Gemma 2 的 2B / 9B / 27B。
PaliGemma 的最新一代就是 PaliGemma 2，没有 PaliGemma 3。Gemma 家族的通用多模态能力已经并进了主线模型——Gemma 3 起就原生带视觉，Gemma 4 全系支持可变长宽比图像乃至视频和音频。所以如果你要的是一个能对话、能读长文档、能多图推理的助手，PaliGemma 不是答案。它今天仍然被大量下载，是因为另一件事：它是一个专门为「迁移」设计的底座。词表里预留了 1024 个 <loc0000>–<loc1023> 位置 token 和 128 个 <seg000>–<seg127> 分割码字，任务用文本前缀切换（cap、caption、describe、ocr、answer、question、detect、segment），把一个视觉任务微调成一个只干这件事的小模型，PaliGemma 2 3B 是目前性价比最高的起点之一。Hub 上下载量最高的 PaliGemma 2 检查点是 paligemma2-3b-ft-docci-448，一个专做长细粒度图像描述的 ft 版本，这就是它真实的使用姿势。
自建时要先知道三件事。第一，Hub 上是 gated 仓库，必须先在页面上同意 Gemma 使用条款并用 token 登录，CI 里直接 wget 是拉不动的。第二，官方权重只发 bf16，Turing 的 Tesla T4 和 Volta 的 V100 没有原生 bf16，Gemma 系在 fp16 下又容易把激活值撑到溢出，所以别拿这两张卡跑原生精度。第三，GGUF 这条路基本是空的——Hub 上只有几个初代 PaliGemma 的社区转换，下载量三位数，真正能用的量化路线是 bitsandbytes NF4、torchao int4（transformers 官方文档里就用 28B 做了 int4_weight_only 的示例）以及 Mac 上的 MLX 4-bit 社区权重。想上生产服务，vLLM 已经把 PaliGemmaForConditionalGeneration 列进支持清单，LoRA 和流水线并行都打勾。
01 —
PaliGemma 全部检查点与显存对照
mix 开箱即用，pt 只是底座，ft 是成品——这三个后缀选错一个，你拿到的就是一串乱码。
| 版本 | 参数量 | 显存 | 上下文 | 说明 |
|---|---|---|---|---|
| google/paligemma2-3b-mix-448 | 3.03B（SigLIP-So400m + Gemma 2 2B） | bf16 权重 ≈6.1GB，整卡建议留 10GB；int4 量化后权重 ≈1.6GB | 448×448 → 1024 个图像 token | 最常用的起手式。mix 是多任务混合微调过的，caption / ocr / detect / segment 前缀全部开箱可用，24GB 卡上还能开大 batch 做流水线打标。 |
| google/paligemma2-10b-mix-448 | 9.66B（Gemma 2 9B 语言塔） | bf16 权重 ≈19.3GB，加 KV 与激活约 21–22GB；int4 ≈5GB | 448×448 → 1024 个图像 token | 3B 在图表、表格、密集小字上吃力时的下一档。19.3GB 卡在 24GB 上会很紧，32GB 才算舒服。 |
| google/paligemma2-28b-mix-448 | 27.65B（Gemma 2 27B 语言塔） | bf16 权重 ≈55.3GB，必须 80GB 单卡；torchao int4 后 ≈15GB | 448×448 → 1024 个图像 token | 家族天花板，下载量只有 3B 的百分之一——绝大多数人用不上，但它是 transformers 官方 int4 量化示例里点名的那个模型。 |
| google/paligemma2-3b-pt-896（pt 系列，224 / 448 / 896 三种分辨率） | 3.03B / 9.66B / 27.65B 三档都有 pt | 3B-896 权重仍是 ≈6.1GB，但 4096 个图像 token 会把预填充显存与算力顶上去 | 896×896 → 4096 个图像 token | 纯预训练底座，只给你微调用。直接拿它提问会输出无意义内容，这不是模型坏了。896 分辨率是做发票、公式、乐谱、分子式这类密集识别时才值得付的代价。 |
| google/paligemma2-3b-ft-docci-448 / paligemma2-10b-ft-docci-448 | 3.03B / 9.66B | bf16 ≈6.1GB / ≈19.3GB | 448×448 → 1024 个图像 token | 在 DOCCI 上微调过的长细粒度描述专用版，也是 Hub 上下载量最高的 PaliGemma 2 检查点。要「把一张图写成一段准确的长描述」，直接用它，别自己从 pt 训。 |
| google/paligemma-3b-mix-448（初代 PaliGemma） | 2.92B（Gemma 1 2B 语言塔） | main 分支存的是 fp32，下载就是 ≈11.7GB；加 revision='bfloat16' 只要 ≈5.8GB | 448×448 → 1024 个图像 token；896 版本同样存在 | 初代只有 3B 一个尺寸。除非要复现旧论文结果或用它的 ft-docvqa / ft-refcoco-seg 等老检查点，新项目直接上 PaliGemma 2。 |
02 —
按场景选卡：PaliGemma 到底需要多大显存
权重体积按 safetensors 实测参数量 × 2 字节算，剩下的留给图像 token、KV cache 和激活。
3B mix / ft-docci 批量推理，给几万到几十万张图打 caption、ocr、detect 标签
RTX 3090 24GB$0.193/卡·时
6.1GB 权重之外还剩 17GB 以上，可以把 batch 开满做流水线，而且 Ampere 原生支持 bf16，不用担心 Gemma 在 fp16 下溢出。
10B mix-448 单卡 bf16 推理，或 3B 上 896 分辨率跑密集文档
RTX 5090 32GB$0.723/卡·时
19.3GB 权重放在 24GB 上余量不足以支撑 4096 个图像 token 的全注意力预填充，32GB 是这一档最省的安全线。
3B / 10B LoRA 微调，把 detect 或 ocr 训成自己场景的专用头
RTX A6000 48GB$0.817/卡·时
LoRA 只训适配器，显存主要吃在激活和 448/896 的长图像序列上，48GB 能同时容下更大 batch 和梯度检查点关闭时的峰值。
28B mix-448 原生 bf16 推理，或 3B 全参数微调（AdamW 优化器状态）
A100 PCIE 80GB$0.824/卡·时
28B 光权重就 55.3GB；3B 全参微调按 bf16 权重 + 梯度 + fp32 主权重与两组动量粗算也在 48GB 以上，80GB 单卡是唯一不用切分的选择。
03 —
从零把 PaliGemma 2 跑起来
四步：拉权重、跑第一条推理、把边界框解出来、上 vLLM 服务。
- 01
开机器、装依赖、登录 Hub
在 NexGPU 控制台选一台 RTX 3090 24GB，直接用 PyTorch 预置镜像开机，SSH 或 Jupyter 进去。PaliGemma 2 是从 transformers 4.47 起进主干的，版本别太旧。仓库是 gated 的，必须先在 Hugging Face 网页上同意 Gemma 条款，再用 token 登录，否则下载会 403。
pip install -U 'transformers>=4.47' accelerate pillow && huggingface-cli login - 02
bf16 加载，跑通第一条单轮调用
用 PaliGemmaForConditionalGeneration 加 PaliGemmaProcessor。注意 PaliGemma 的提示词末尾必须带一个换行符，这是它训练时的输入格式的一部分，processor 会替你补上——所以请走 processor，不要自己手搓 input_ids。任务靠前缀切换：cap {lang}、describe {lang}、ocr、answer {lang} {question}、detect {对象}、segment {对象}，多个对象之间用分号隔开。
model = PaliGemmaForConditionalGeneration.from_pretrained('google/paligemma2-3b-mix-448', torch_dtype=torch.bfloat16, device_map='auto').eval() - 03
把 detect 输出的 loc token 还原成像素坐标
detect 前缀返回的不是 JSON，而是一串 <loc0000>–<loc1023> 位置 token 后面跟标签。四个数一组，顺序是 ymin、xmin、ymax、xmax，取值是 0–1023 的归一化格；先除以 1024，再把 y 乘图像高度、x 乘图像宽度，才是真实像素。segment 前缀多返回 16 个 <seg000>–<seg127> 码字，需要配套的 VQ-VAE 解码器才能还原成掩码，这一步官方示例经常被跳过，是自建时最容易卡住的地方。
vals = [int(v) / 1024 for v in re.findall(r'<loc(\d{4})>', out)] # ymin, xmin, ymax, xmax - 04
上 vLLM，把它变成一个 HTTP 服务
vLLM 的支持清单里 PaliGemmaForConditionalGeneration 明确在列，PaliGemma 和 PaliGemma 2 都算数，LoRA 和流水线并行都支持。因为它是单轮、单图、短输出的模型，max-model-len 给到 2048 就够——图像 token 在 448 分辨率下占 1024，剩下的留给前缀和答案。10B 这一档建议直接开在 RTX 5090 32GB 上。
vllm serve google/paligemma2-10b-mix-448 --dtype bfloat16 --max-model-len 2048
一次真实的打标任务要花多少钱
假设你要把 10 万张单据图跑成结构化标签。租 1 张 RTX 3090 24GB（$0.193/卡·时）跑 paligemma2-3b-mix-448：先用 LoRA 在自有的 8000 张标注样本上微调 10 小时，再批量推理 20 小时打完 detect + ocr 标签。算力 =（10 + 20）× $0.193 = $5.79。存储按 30GB 的卷（6.1GB 权重 + 数据集 + 产物）留半个月算 = 30 × $0.414 × 0.5 = $6.21；导出 2GB 结果 = 2 × $0.0081 = $0.016。合计约 $12.02——注意存储比算力还贵，因为 NexGPU 的算力是按秒计量、实例一停就不再计费，而存储要到你销毁卷为止都在走，所以跑完记得销毁。如果精度不够要换 10B，改用 RTX 5090 32GB（$0.723/卡·时），同样 30 小时是 30 × $0.723 = $21.69，仍然不到一杯咖啡钱乘以二十。没有起租时长、没有开通费、没有配额申请。
04 —