BLOOM 全称 BigScience Large Open-science Open-access Multilingual Language Model，2022 年 7 月 11 日由 BigScience 工作坊在法国 Jean Zay 超算的 384 张 A100 80GB 上训练完成，参数量精确到 176,247,271,424。架构是 Megatron-LM GPT2 血统的 decoder-only：70 层、隐藏维 14336、112 个注意力头，用 ALiBi 相对位置偏置替代绝对位置编码，激活函数 GeLU，并在词嵌入层后额外加了一层 LayerNorm（StableEmbedding）。预训练语料 ROOTS 共 1.6TB 文本、350B 去重 token，实际训练看过 366B token，序列长度全程 2048。词表是多语种 byte-level BPE，tokenizer 实际 250,680 个 token，config 里补齐到 250,880 以便张量并行整除。
对中文团队来说，BLOOM 有一个别的同期开源模型给不了的数字：ROOTS 语料里简体中文占 16.16%，仅次于英语的 30.03%，高过法语 12.9%、西班牙语 10.85%、葡萄牙语 4.91% 和阿拉伯语 4.6%。这就是当年国内 BELLE 直接拿 bloomz-7b1-mt 当底座、用 100 万条中文指令微调的原因。反过来也要看清它的盲区：46 种自然语言里没有俄语、日语、韩语、德语——BLOOM+1 那篇 ACL 论文就是专门研究怎么给它补这几种语言的。真正稀缺的是另一头：Wolof、Bambara、Twi、Kikuyu、Fon、Tumbuka 这些低资源语言，至今仍少有百亿级模型覆盖。
自托管 BLOOM 的难点不在下载而在显存结构。bigscience/bloom 仓库总体积 705GB，权重切成 72 个 safetensors 分片，纯 bf16 权重 329GB。更容易被忽略的是 KV 缓存：BLOOM 早于 GQA/MQA，用的是完整的多头注意力，70 层 × 14336 维意味着每个 token 的 KV 约 4MB，一条跑满 2048 上下文的序列就要 8.2GB 显存——batch 开到 8 就是 66GB 只用来存 KV。另外 112 个注意力头决定了张量并行度必须整除 112，TP=8 可以，TP=6 直接起不来。vLLM 的 BloomForCausalLM 支持流水线并行但不支持 LoRA 适配器，想做参数高效微调得走 PEFT + transformers 那条路。
01 —
BLOOM / BLOOMZ 全系版本与显存对照
参数量为官方模型卡数值，GGUF 体积取社区实测文件大小，全系上下文均为 2048。
| 版本 | 参数量 | 显存 | 上下文 | 说明 |
|---|---|---|---|---|
| bigscience/bloom（BLOOM-176B） | 176,247,271,424（70 层 / 14336 维 / 112 头） | bf16 ~329GB / Q8_0 191.2GB / Q4_K_M 114.8GB / Q2_K 68.2GB | 2048 | 原始预训练基座，只做续写不跟随指令。仓库共 72 个 safetensors 分片、705GB。GGUF 需要多段拼接后才能加载。 |
| bigscience/bloomz、bloomz-mt（BLOOMZ-176B） | 176,247,271,424 | 与 BLOOM-176B 同量级：bf16 ~329GB / Q4_K_M ~115GB | 2048 | 在 xP3 跨语言任务集上指令微调，能零样本跟随指令。bloomz-mt 用 xP3mt 训练，面向非英文提示词，中文场景优先选它。 |
| bigscience/bloom-7b1、bloomz-7b1、bloomz-7b1-mt | 7,069,016,064（30 层 / 4096 维 / 32 头） | bf16 ~14.1GB / Q8_0 8.62GB / Q6_K 6.66GB / Q4_K_M 5.27GB / Q2_K 3.44GB | 2048 | 全系最实用的一档，单张 24GB 卡 bf16 直接跑。词嵌入独占 1,027,604,480 参数（14.5%），量化文件因此比同尺寸 Llama 略胖。 |
| bigscience/bloom-3b、bloomz-3b | 3,002,557,440（30 层 / 2560 维 / 32 头） | bf16 ~6.0GB / Q4 量化约 2.4GB | 2048 | 做多语种消融实验和 tokenizer 分析的甜点尺寸，KV 缓存每 token 仅约 0.3MB，能开很大的 batch 批量跑评测集。 |
| bigscience/bloom-1b7、bloomz-1b7 | 1,722,408,960（24 层 / 2048 维 / 16 头） | bf16 ~3.4GB | 2048 | 词嵌入 513,802,240 参数就占了整整 30%。全参数微调也只要一张 24GB 卡，适合做低资源语言的继续预训练试验。 |
| bigscience/bloom-560m、bloomz-560m | 559,214,592（24 层 / 1024 维 / 16 头） | bf16 ~1.1GB | 2048 | 250,880 × 1024 的词嵌入独占 256,901,120 参数，接近整个模型的一半——这是研究多语种词表如何吞噬小模型容量的最佳标本。 |
02 —
按场景选卡：NexGPU 实际配置建议
显存匹配按 bf16 权重 + KV 缓存实算，不做乐观估计。
跑 560M / 1B7 / 3B 小尺寸做多语种基线、tokenizer 与词表分析
RTX 3090 24GB$0.193/卡·时
最贵的 3B bf16 也只要 6GB，24GB 显存足够同时驻留模型和大 batch 评测数据，全网最低单价把重复实验成本压到可以忽略。
BLOOMZ-7B1 / 7B1-mt bf16 全精度推理，或 LoRA / QLoRA 中文指令微调
RTX 4090 24GB$0.540/卡·时
14.1GB 权重 + 每序列约 1GB 的 KV 装得下，Ada 架构的 bf16 吞吐比上一代快近一倍，微调迭代不用干等。
单卡跑 BLOOM/BLOOMZ-176B 的 Q4_K_M 量化（114.8GB），做能力摸底或离线批处理
H200 141GB$6.660/卡·时
141GB 一张卡吃下 114.8GB 权重，省掉所有张量并行的通信与调参；剩余约 26GB 够放 3 条满上下文序列的 KV。
BLOOM/BLOOMZ-176B bf16 全精度在线服务或论文复现基准
A100 SXM4 80GB × 8（合 640GB）$1.088/卡·时（整机 $8.704/时）
TP=8 正好整除 112 个注意力头，329GB 权重装载后仍余约 310GB 给 KV，可稳定支撑数十路 2048 上下文并发。
03 —
四步把 BLOOM 部署起来
全部基于 NexGPU 预置的 vLLM / PyTorch 镜像，SSH 连上就能照抄。
- 01
开实例、挂卷、拉权重
控制台选 vLLM 预置镜像开机，先把存储卷开够：BLOOMZ-7B1 留 40GB，176B 的 bf16 权重 329GB 建议直接开 400GB。用 hf CLI 拉分片会自动断点续传，176B 的 72 个分片大约要一到两小时。注意计算按秒停，存储卷会一直计费到销毁为止。
hf download bigscience/bloomz-7b1 --local-dir /workspace/bloomz-7b1 - 02
vLLM 起 OpenAI 兼容服务（单卡 7B1 路线）
必须显式指定 --max-model-len 2048。BLOOM 的 config 里没有 max_position_embeddings，ALiBi 让它不会因超长直接报错，但预训练全程都在 2048 上做，放任 vLLM 自己推断上下文长度会导致 KV 预留失真、质量悄悄崩掉。启动后即是标准 /v1/completions 接口。
vllm serve /workspace/bloomz-7b1 --dtype bfloat16 --max-model-len 2048 --gpu-memory-utilization 0.90 --port 8000 - 03
176B 走张量并行（TP=8）
112 个注意力头必须被 TP 度整除，可用的只有 1/2/4/7/8/14/16/28/56/112，实践中 8 张 A100 80GB 是最稳的落点。加载 329GB 权重本身要十几分钟，建议把 --download-dir 指到持久卷，下次开机免重下。vLLM 的 BloomForCausalLM 支持流水线并行但不支持 LoRA，别在这里挂适配器。
vllm serve bigscience/bloomz --tensor-parallel-size 8 --dtype bfloat16 --max-model-len 2048 --download-dir /workspace/hf - 04
想省卡就转 GGUF 量化
llama.cpp 的 convert_hf_to_gguf.py 原生支持 bloom 架构。7B1 转出来 Q4_K_M 只有 5.27GB，Q8_0 8.62GB，一张 3090 绰绰有余。176B 也能转，Q4_K_M 114.8GB 分成三段，下载后需先按顺序 cat 拼接再加载——这一步在文档里容易被跳过，但不做就直接加载失败。
python convert_hf_to_gguf.py /workspace/bloomz-7b1 --outfile bloomz-7b1-f16.gguf --outtype f16 && ./llama-quantize bloomz-7b1-f16.gguf bloomz-7b1-Q4_K_M.gguf Q4_K_M
三条路线的真实账单
全部用 NexGPU 挂牌价直接算。路线一，摸 BLOOMZ-7B1（bf16 14.1GB）：RTX 3090 24GB $0.193/卡·时，连开 24 小时 = 24 × $0.193 = $4.63；再挂一块 40GB 卷存权重和 GGUF，按 $0.414/GB·月折算 40 × $0.414 ÷ 30 = $0.55/天，一整天合计 $5.18。路线二，单卡跑 176B 的 Q4_K_M（114.8GB）：H200 141GB $6.660/卡·时，下载与分片拼接约 1.5 小时、评测跑 3 小时，(1.5 + 3) × $6.660 = $29.97。路线三，176B bf16 全精度复现：A100 SXM4 80GB × 8 = 640GB，8 × $1.088 = $8.704/时；拉权重加载 2 小时 = $17.41，跑 3 小时基准 = $26.11，一轮完整评测 $43.52。对照一下，路线三这 640GB 显存如果自己采购，是六位数美元的资本开支，而这里只按秒收 43 块多。计算在实例停止的那一秒停止计费，存储卷则一直算到你销毁它——跑完记得顺手把 400GB 的 176B 卷删掉。
04 —