零一万物模型写中文长文，先确认显存和量化方式

想用零一万物（Yi 系列）写中文长文，卡住你的通常不是模型本身多大，而是三件事叠加：量化后的权重占用、KV 缓存的预留、以及你打算一次喂进去的中文长度。合理顺序是先看模型卡确认要下载什么、跑 nvidia-smi 数清空闲显存、按位宽把权重体积算一遍，最后用一次真实加载去验证估算。跳过前三步直接下载，往往会在加载阶段才发现放不下。

判断方向：本地写中文长文前先算权重占用加 KV 预留，再决定量化档位，不要先下载再试。操作动作是读模型卡、记录空闲显存、按位宽换算、跑一次加载；验证方式是看加载日志里的显存与首字耗时；边界是不同框架和量化工具会带来额外开销，估算只能给你余量，不能给保证。

在模型卡里确认参数量与权重文件格式

模型卡页面先看两处：Overview 里写明的参数量规模（例如 6B、34B 这类标注），以及 Files and versions 标签页下的文件列表，那里每个文件右侧的 Size 列就是实际下载体积。下载前把它们扫一遍，比下载完再看磁盘更省事。

单文件权重：整个模型放在一个 safetensors 或 bin 文件里，体积就是它的 Size。
分片权重：文件名形如 model-00001-of-00008.safetensors 或 pytorch_model-00001-of-00003.bin，编号表示第几片、共几片，必须全部下载。
索引与配置：model.safetensors.index.json 记录每个参数落在哪一片；config.json 里的 torch_dtype、层数、注意力头数、KV 头数是后面换算 KV 缓存的依据；如果模型卡标了量化版本，配置里一般还会出现 quantization_config。

参数量和文件体积的对应关系可以直接估：权重字节数约等于参数量乘以每个参数占用的字节数。看到 34B 的 fp16 权重，就是 34 乘以 10 的 9 次方再乘 2，量级在几十 GB，这种体积不可能塞进一张小显存卡。

用 nvidia-smi 记录本机可用显存

先区分“总显存”和“你现在真正能用的显存”。总显存是卡的规格，空闲显存才是这次加载能支配的量。图形界面、其他推理进程、训练残留都会占着显存不放。

nvidia-smi
nvidia-smi -L
nvidia-smi `--query-gpu`=index,name,memory.total,memory.used,memory.free `--format`=csv

输出里要盯的字段：Memory-Used（已被占用）和 Memory-Free（当前空闲），以及下方 Processes 表里的 PID、进程名和各自的显存用量。如果 Memory-Free 明显小于 Memory-Total，先在下半部分找出占用进程，确认是不是你自己还挂着的服务；不确定时不要直接杀进程，用 PID 反查归属更稳妥。

多卡机器注意 CUDA_VISIBLE_DEVICES 只会让程序看到部分卡，别把其他卡的空闲显存算进预算。记录时用同一时刻的数字，边加载边看会变。

按量化档位换算权重占用并留出余量

通用换算方式：权重字节数 ≈ 参数量 × 每参数字节数。常见位宽对应的每参数字节数可以这样记：fp16 约 2 字节，int8 约 1 字节，4bit 理论 0.5 字节，实际因分组量化、零点等开销，通常按 0.55 到 0.6 字节估更稳。

举个算法示例，不针对任何具体模型：假设要加载的权重是 N 亿参数，fp16 就是 N × 10 的 8 次方 × 2 字节，8bit 约减半，4bit 再减到四分之一上下。算出结果后，别忘了再留一层余量给框架的激活、临时缓冲和对齐开销。

KV 缓存必须单独预留，原因是它随输入长度线性增长，而写中文长文恰恰是输入很长的场景。粗略公式：KV ≈ 2（K 和 V）× 批大小 × 序列长度 × 层数 × KV 头数 × head_dim × 每元素字节数，参数全部从 config.json 里取。先按你打算跑的最大长度代入算一遍，再决定权重能不能占掉那么多显存。只想跑一小段文字和想一口气塞进整篇稿子，KV 需求差得很远。

加载一次并观察实际占用与首字延迟

估算完用一次真实加载验证。下面是一个通用启动骨架，参数要按你下载的权重格式替换，尤其 `--quantization` 必须和权重类型匹配，写错通常直接报错退出。

python -m vllm.entrypoints.openai.api_server \
  `--model` /path/to/your-model \
  `--dtype` auto \
  `--quantization` gptq \
  `--max-model-len` 8192 \
  `--gpu-memory-utilization` 0.90

加载过程中另开一个终端反复跑 nvidia-smi，观察显存爬升到哪个台阶停住。日志里重点看：权重分片加载进度、KV cache blocks 的分配数量、实际生效的 max_model_len，以及是否回退到别的执行后端。这些都能反映前面的估算偏乐观还是偏保守。

报错性质要分清：显存不足通常表现为 “CUDA out of memory” 或 torch 的 OutOfMemoryError，往往在加载权重或分配 KV 阶段直接中断；加载慢则表现为进度长时间不动、磁盘读写高而 GPU 利用率低，它不报错，只是权重反量化或磁盘读取耗时。首字延迟方面，看请求日志里的 prompt tokens 和首 token 时间，或者用一次真实中文请求计时，不要凭感觉判断。

按中文长文长度选择量化档位

把前面的结论落回写作任务。中文的 token 数不能直接拿字数当等号，需要用自己的分词器跑一段样文确认比例，再做选型。

写短文、单次输出可控：显存宽裕时优先保精度，用 fp16 或 8bit，把余量留给 KV。
写中等长度、上下文几千 token：可以降到 4bit 权重，但要保证 max-model-len 留够你最长的那次输入，并预留与 KV 同量级的显存。
写长文、上下文上万 token：KV 占比明显上升，这时优先降权重占用，而不是把 max-model-len 一味拉满；长度设得过大，加载阶段就会失败。

质量下降时的退回顺序要提前想好：4bit 输出出现重复、术语漂移或段落结构崩掉，先退回 8bit 再试同一段输入；8bit 仍不稳定，就用 fp16 但缩短单次输入，把长文改成分段生成再拼接。降档和缩长度是两种不同手段，前者换显存，后者换上下文压力，别混在一起判断。