企业官网建设流程全解析

上周有位同行甩过来一张截图：一张 24G 显存的卡，模型文件明明有 47GB，却稳稳当当地在跑，界面右下角显示生成速度 2.6 t/s。评论区第一句是"假的吧"，第二句是"求配置"。这其实就是Qwen-72B 单卡运行这个话题最能勾人的地方——它看起来违反了常识，实际上只是把"显存"和"内存"这两本账算清楚了而已。

72B 级别的稠密模型，半精度满载要 140GB 以上的显存，这确实不是单卡能碰的。但量化把权重压到 4bit 之后，体积掉到 40GB 出头，再配合 CPU+GPU 混合推理，把一部分层放在显存、一部分层放在内存，中间用 PCIe 搬数据，单张消费级卡跑起来是完全成立的。代价是速度从"打字机"退化成"手写体"，每秒两三个 token，能读、能用、能出活，但别指望它做高并发服务。

这篇东西写给三类人：手里只有一张卡、想验证大模型私有化可行性的；预算有限、在"租算力"和"买硬件"之间摇摆的；以及已经在跑、但速度慢得想砸键盘的。我会把显存预算的计算过程、量化格式的取舍逻辑、-ngl层数怎么定、以及那些只有真跑过才会知道的坑，一条条拆开讲。参数怎么算、命令怎么敲、出问题看哪里，都给你摆明白。

1. 先把账算明白：72B 单卡到底卡在哪

1.1 参数量、量化位宽与显存的三次换算

很多人一上来就问"我这卡能不能跑 72B"，这个问题没法直接回答，因为"跑"这个字背后藏着三笔完全不同的开销：权重、KV cache、运行时缓冲。三笔账任何一笔算漏了，结果就是启动即崩或者跑到一半被系统干掉。

第一笔是权重。参数量乘以每参数字节数就是理论体积：FP16 是 2 字节，72B × 2 = 144GB；INT8 是 1 字节，72GB；4bit 理论上是 0.5 字节，36GB。但实际文件会比理论值大一圈，因为量化不是所有张量都用同一个位宽——embedding 层和输出层通常保精度，attention 的某些投影矩阵会用更高位宽，加上每块的 scale 和 min 值元数据。所以 Qwen-72B 的 Q4_K_M 实际落在 47GB 上下，Q4_0 约 41GB，Q3_K_M 约 36GB，Q2_K 能压到 28GB 左右。

第二笔是 KV cache，这笔账最容易被忽略。Qwen-72B 用了 GQA，64 个注意力头只配 8 组 KV 头，head_dim 是 128，一共 80 层。单 token 单层的 KV 开销是 2 × 8 × 128 × 2 字节 = 4096 字节，也就是 4KB。乘 80 层，每 token 约 320KB。看着不多，但你开 8192 上下文就是 2.6GB，开满 32768 就是 10.5GB。很多人把层数 offload 算得刚刚好，结果一跑长对话就爆显存，问题就出在这。

第三笔是运行时缓冲。CUDA context 本身要吃掉 300~500MB，计算图、临时张量、cuBLAS 的工作区加起来通常 1~2GB，Windows 的 WDDM 驱动还会额外预留一部分显存。所以一张标称 24GB 的卡，实际能给你自由支配的大概是 21.5~22GB，剩下的都被系统和驱动占着。你在任务管理器里看到"显存占用 23.8G"却还能跑，就是这个原因——预算要按可用量算，不是按标称量算。

把三笔账加起来，你就会发现一个残酷的事实：4bit 的 72B 权重是 47GB，任何一张单卡都装不下。所以"单卡运行"这个词，准确的表述应该是"单卡 + 内存的混合运行"，显卡只是这套系统里的一个加速部件，不是全部。

1.2 显存不是唯一变量：内存带宽才是单卡方案的命门

搞清楚混合推理的原理，你就知道为什么速度上不去了。大模型生成一个 token 的过程，本质是把整个模型的权重从存储介质里完整读一遍，然后做一次前向计算。读得有多快，决定了你每秒能吐几个字。

GPU 侧的带宽是恐怖的：一张 4090 有 1008GB/s，一张 A6000 有 768GB/s。如果 47GB 权重全在显存里，光算读取时间就是 47/1008 ≈ 47 毫秒，理论上一秒能出二十几个 token，这还没算算力瓶颈。但现实是大部分层被迫放在内存里，内存带宽就成了木桶最短的那块板。

普通桌面平台双通道 DDR5 的实测带宽大约 80~100GB/s，双通道 DDR4 只有 45~55GB/s。假设 28GB 权重落在内存侧，DDR5 平台光读取就要 0.3 秒左右，折算下来 3 t/s 上下；DDR4 平台要 0.55 秒，直接掉到 1.8 t/s。这就是为什么同样的卡、同样的模型文件，换台机器速度能差一倍。

再往下推一层，你会发现 offload 的分配策略变得非常关键。GPU 上的层算得快，CPU 上的层算得慢，而这两部分是串行的——第 1 层在 CPU 上算完才能算第 2 层。所以整体速度大致由"最慢的那部分"决定，GPU 快也带不动 CPU 端的拖累。这也是为什么把-ngl从 30 拉到 35，速度提升往往不成正比，因为多搬过去的几层省下的时间，可能还不够显存吃紧导致的额外开销。

理解了这个模型，后面所有的调优动作都有了统一的解释框架：任何操作,要么在减少"每 token 需要读取的总字节数"（更低比特量化、更短上下文），要么在减少"从慢速介质读取的比例"（更多层 offload、更高带宽内存）。

1.3 硬件分档：哪类机器值得折腾

不是所有机器都适合硬上 72B。我按实际体验把常见配置分成几档，你可以直接对号入座。

有一点要提醒：统一内存平台（比如大内存的一体机）虽然带宽看着不如独显，但因为不存在 PCIe 往返和分层调度的开销，实际体验往往比"24G 卡 + 桌面内存"更顺。它的短板在预填充阶段——处理长 prompt 时速度会明显慢于独显，如果你经常要喂几万字的文档，这一点要提前想清楚。

至于纯 CPU、无独显的机器，我的建议是别折腾 72B。单靠双通道内存跑 Q4，速度会掉到 1 t/s 以下，一个 500 字的回答要等十分钟，人会被磨到放弃。真要玩，起步得是 8 通道的服务器平台，而且只适合做离线批处理，不适合交互。

2. 三条技术路线怎么选：量化格式决定一切

2.1 GGUF 路线：把模型切成能搬的积木

GGUF 是这套玩法里最主流的选择，原因很直白：它天生支持分层加载，可以把模型的 80 层拆开，一部分扔显存、一部分留内存，中间用统一的内存映射调度。这是"单卡跑 72B"能够成立的技术前提，其他格式要么做不到，要么做得很难受。

它的工作方式可以类比成搬砖。模型文件在磁盘上是一个整体，但 GGUF 的元数据里记录了每一层的偏移量。启动时，推理引擎根据你给的-ngl参数，把最后 N 层（注意是最后，不是最前）复制到显存，剩下的层通过 mmap 映射进内存。前向计算时，数据在 GPU 和 CPU 之间来回倒，PCIe 带宽就成了额外的一层税。

这个设计的好处是灵活度极高。同一份 47GB 的文件，你在 24G 卡上可以-ngl 30，在 48G 卡上可以-ngl 55，在大内存机器上直接-ngl 999全部放内存里跑，配置文件一行不用改。坏处是量化位宽的档位太多，Q2_K、Q3_K_S、Q3_K_M、Q4_0、Q4_K_S、Q4_K_M、Q5_K_M、Q6_K、Q8_0 十几种，选错一档可能就是"能用"和"不能用"的差别。

选档的经验法则：24G 卡优先 Q4_K_M，实在放不下退到 Q3_K_M，但要清楚 Q3 已经开始明显掉质量；48G 卡上 Q4_K_M 可以基本全放，追求质量可以试 Q5_K_M 但得接受层数下降。Q2_K 我基本不推荐，72B 在 2bit 下的语言能力退化很明显，中文尤其容易出问题，省下的那点空间不值得。

2.2 GPTQ/AWQ 路线：纯 GPU 的豪赌

GPTQ 和 AWQ 是另一条线，它们的设计假设是"权重全在显存里"。两者都是 4bit 量化，体积和 GGUF 的 Q4 差不多，但加载框架不同，主要跑在 GPU 推理引擎上。

这条路线的问题是显而易见的：47GB 的权重，单卡装不下就是装不下，没有 offload 这个选项。你可以用一些框架的 CPU offload 功能硬撑，但那个实现路径比 GGUF 别扭得多，速度也更差，实践中很少有人这么干。

那它适合谁？适合 48G 及以上的卡。在 A6000 这类卡上，AWQ 4bit 的 72B 可以完整驻留显存，配合 FlashAttention 和 paged attention，预填充速度能比 GGUF 快好几倍，做批量文档处理时优势明显。我实测过同等硬件下 AWQ 的 prompt 处理速度接近 GGUF 的两倍，但生成阶段差距不大，都不受带宽之外的瓶颈限制。

还有一点值得说：AWQ 的量化质量通常略好于同 bit 的 GPTQ，尤其在低 bit 下。如果你的显存刚好卡在临界点、又想保住质量，优先试 AWQ。但如果你只有 24G 卡，这条路线直接放弃，别浪费时间。

2.3 bitsandbytes 4bit：最省事也最难受

第三种是直接用训练框架加载时的 4bit 量化，底层是 bitsandbytes。它的好处极其明显：不用找量化好的文件，加载原始权重时加两个参数就行，几行代码搞定。

代价也很明显。第一，加载慢，因为它要在启动时现场做量化，72B 的模型加载一次十几分钟很正常。第二，内存峰值高，量化过程中需要把原始 FP16 权重读进来，峰值占用可能超过 150GB 内存，内存小的机器直接 OOM。第三，推理速度最慢，它的反量化是在 kernel 里做的，开销比 GGUF 的块量化大不少，同样硬件下能慢 30%~50%。

我一般只在这两种情况下用它：一是需要微调，需要在训练框架里加载模型；二是临时验证某个模型的输出质量，手边没有现成的量化文件。做稳定的推理服务，这条路不是好选择。

顺带说一个常见误区：有人以为 4bit 加载之后显存占用就是权重的 47GB，其实不是。它会额外保留一部分高精度的计算副本和量化状态，实际占用往往比纯推理格式高 10%~20%。24G 卡加载 72B 4bit，基本没戏。

2.4 横向对比与选型建议

把三条路线的关键指标摊在一张表里，选型就一目了然了。

结论很清楚：单卡跑 72B，GGUF 是唯一务实的选择。48G 以上想要吞吐，再加上 AWQ 作为候补。bitsandbytes 就留给训练和临时验证。

注意：不要在同一台机器上混用不同来源的量化文件。有些社区文件是用不同版本工具链导出的，元数据字段不一致，加载时报错信息会非常误导人，让你以为是显存不够，其实是格式不兼容。

3. 单卡实操：从零把 Qwen-72B 跑起来

3.1 环境准备与编译参数

我以最常见的场景为例：一张 24G 消费级卡，Linux 环境。Windows 也能跑，但可用显存会少 1~2GB，某些驱动的内存管理策略也会让速度波动更大，条件允许还是上 Linux。

先装基础工具链：CMake 3.21 以上、gcc 11 以上、CUDA Toolkit 12.x。CUDA 版本要和驱动匹配，用nvidia-smi看右上角的 CUDA Version，装的 toolkit 不能超过这个版本。

编译 llama.cpp 时的关键参数是这个：

cmake -B build \ -DGGML_CUDA=ON \ -DCMAKE_CUDA_ARCHITECTURES=89 \ -DGGML_CUDA_F16=ON \ -DCMAKE_BUILD_TYPE=Release cmake --build build --config Release -j $(nproc)

CMAKE_CUDA_ARCHITECTURES一定要填对，89 对应 4090/6000 Ada，86 对应 3090/A6000，80 对应 A100。填错了能编译通过，但会退回到兼容模式，速度损失可能有 20%。不确定的话可以不填这个参数让 CMake 自己探测，代价是编译时间变长。

GGML_CUDA_F16这个开关用 FP16 做矩阵乘累加，对支持 Tensor Core 的卡有加速效果。极少数老卡上可能引入精度问题，如果你发现输出开始胡言乱语，先把这个关掉试试。

编译完先跑一下./build/bin/llama-cli --version，确认能看到 CUDA 设备信息被正确识别。这一步没通过，后面全是白费。

3.2 模型文件获取与完整性校验

72B 的 Q4_K_M 文件大约 47GB，通常会被切成两到三个分片。这里有几个坑必须提前说。

第一，分片必须齐全。文件名一般形如xxx-00001-of-00003.gguf，少一个都加载不了，报错信息通常是"failed to load model"，看不出是分片缺失。下载完先核对文件数量和命名连续性。

第二，校验哈希。几十 G 的文件下载中断很常见，断点续传偶尔也会产生静默损坏。下载后对每个分片算一遍校验值，和发布方给的对比。这一步花五分钟，能省掉后面几小时的排查。

第三,磁盘空间要留够。加载时引擎可能会在临时目录里做转换或缓存，我习惯性留出文件体积 1.5 倍的空间。有位同行就是因为磁盘只剩 40GB，加载到一半报错，折腾了半天以为是内存问题。

第四，存放介质最好是 NVMe SSD。用机械盘的话，mmap 加载会把每一层的读取都变成随机 IO，首次加载时间可能从三分钟变成二十分钟，而且运行时的换页惩罚会非常严重。这一点在内存不够、系统频繁换页的时候尤其致命。

3.3 -ngl 层数怎么算：一步一步推给你看

这是整个流程里最需要动脑的地方。-ngl是"放进 GPU 的层数"，填多了爆显存，填少了慢。我按 24G 卡 + Q4_K_M 的组合给你完整推一遍。

第一步，算每层的平均大小。47GB ÷ 80 层 ≈ 0.59GB/层。注意这只是平均值，实际分布不均匀——前几层和 embedding 相关的部分更大，中间层较均匀。所以预算要留余量。

第二步，算可用显存。标称 24GB，扣掉 CUDA context 约 0.5GB、运行时缓冲 1.5GB、系统桌面占用 0.5GB（Linux 无桌面可省），剩大约 21.5GB。

第三步，扣掉 KV cache。假设你要开 4096 上下文，KV 开销是 4096 × 320KB ≈ 1.3GB，如果用 q8_0 量化 KV 可以减半到 0.65GB。为稳妥起见，我先按不量化算，留 1.5GB。

第四步，做除法。21.5 - 1.5 = 20GB 可用于权重，20 ÷ 0.59 ≈ 33 层。

但这只是理论上限。实践中要往下调 2~3 层留出碎片余量，所以我会先试-ngl 30，跑通之后再往上加 1 层试，直到出现显存告警或速度下降为止。这个"逐层试探"的过程大概花十分钟，但能精准找到你机器的甜点值，比照抄别人的配置靠谱得多。

一个反直觉的现象：层数加到某个点之后，继续加反而变慢。原因是显存被填满后，驱动开始把一部分数据换到共享内存（也就是走 PCIe 访问内存），这部分访问的延迟比正常显存高一个数量级，会把整个前向计算拖慢。所以"显存占用 99%"听起来很爽，实际可能是性能最差的配置。稳定在 90%~95% 是最舒服的区间。

3.4 完整启动命令逐项拆解

下面这条命令是我在 24G 卡上跑 72B 的常用配置，每一项都有讲究：

./build/bin/llama-server \ -m ./models/qwen72b-q4_k_m-00001-of-00002.gguf \ -ngl 30 \ -c 8192 \ -t 16 \ -b 512 \ -ub 128 \ -fa \ -ctk q8_0 \ -ctv q8_0 \ --mlock \ --host 0.0.0.0 \ --port 8080

逐项说：

-ngl 30是 GPU 层数，算法上面讲过。

-c 8192是上下文长度。这里有个取舍：开得越大，KV cache 越大，能 offload 的层就越少。如果你的任务都是短问答，开 4096 反而能多放 4 层，生成速度更快。反过来，长文档摘要就必须开大，这时候得主动减层保平安。

-t 16是 CPU 线程数。填物理核心数，不要填逻辑线程数，超线程在矩阵乘这种场景下没有收益，还会因为抢缓存而变慢。16 核的机器填 16，8 核的填 8。

-b 512 -ub 128分别是逻辑批和微批。生成阶段影响不大，但预填充阶段（处理 prompt）会明显受影响。显存紧张时把-ub降到 64 甚至 32，能降低峰值占用。

-fa开启 FlashAttention。这个既是加速手段也是省显存手段，开了之后 KV 的访问模式更高效，长上下文下优势明显。注意只有开了它，-ctk/-ctv的 KV 量化才生效。

-ctk q8_0 -ctv q8_0把 KV cache 量化到 8bit，体积减半。对 72B 这种 GQA 模型来说质量损失几乎感知不到，但省下的 1~5GB 显存可能正好够你多 offload 七八层。这是我最推荐的一个开关。

--mlock把内存锁住，防止被换到交换分区。这个必须开，尤其是内存吃紧的机器。一旦发生换页，速度会掉到 0.1 t/s，看起来像死机。代价是需要相应的权限，某些系统上要配ulimit -l。

--host 0.0.0.0让服务对外可访问，只在本机用的话改成127.0.0.1更安全。

3.5 跑通之后先验证这几件事

服务起来了不代表跑对了。我一般会做四步验证。

第一步看启动日志里的设备分配信息。它会明确打印出"多少层分配到 CUDA 设备、多少层留在 CPU"，和你给的-ngl是否一致。如果不一致，说明显存不够，引擎自动降级了，这时候你去测速会发现慢得离谱，还以为是模型问题。

第二步发一个短 query 看响应。用中文问一个需要推理的小问题，比如"三个人三天喝三桶水，九个人九天喝几桶"，正确答案是 27 桶。答对了说明 chat template 正确。如果输出里带着<|im_start|>这种标记，说明模板没配对，需要在请求里明确指定，或者在服务端用--chat-template参数。

第三步测生成速度。注意要区分预填充速度和生成速度，前者是处理输入的时间，后者是逐字输出的时间。很多工具显示的是总耗时，看着还挺快，实际上全是预填充在撑，生成慢得要命。我一般会发一个"请写 500 字"的请求，用总时间减预填充，再除以实际输出字数，得到真实的 t/s。

第四步压长上下文。发一个接近上下文上限的请求，观察显存占用和速度变化。如果显存直接飙满或者速度断崖，说明 KV 预算算少了，回头把-c降下来或者把-ngl减两层。

4. 调优：从"能跑"到"能用"的那 30%

4.1 层数甜点区：不是拉满就快

这是最容易踩的坑。直觉告诉我们显存用得越多越快，实际曲线不是这样的，而是一条先升后降的抛物线。

上升段的逻辑很好理解：每多 offload 一层，就少一层走内存读取，而 GPU 带宽是内存的十倍以上，所以速度提升明显。这个阶段每加一层，速度可能涨 3%~5%。

拐点出现在显存占用 90% 左右。过了这个点，显存分配器开始吃力，碎片变多，某些张量申请不到连续空间，驱动就会把一部分数据挪到共享内存。这部分访问走 PCIe，延迟是显存的几十倍。更麻烦的是这种挪动是动态的、不可预测的，导致速度波动很大——同样的问题，有时 2.5 t/s，有时 0.8 t/s。

我遇到过最极端的例子：一台机器-ngl 33时速度 1.9 t/s，降到-ngl 30反而涨到 2.7 t/s。差了 40%，就因为少了三层，避开了显存临界点。

所以调优的正确姿势是：从保守值开始（建议从理论上限的 85% 起步），逐层往上加，每加一层测三次生成速度取平均，一旦发现速度下降超过 10%，就退回上一档。这个值就是你机器的最优解，而且要记下来，因为换模型、改上下文长度都会让它变化。

4.2 KV cache 量化与上下文预算

上下文长度和 offload 层数是一对天然矛盾，因为它们抢同一块显存。这里有个预算公式可以帮你快速决策。

可用显存 = 总显存 - CUDA context(0.5G) - 运行时缓冲(1.5G) - KV cache - 碎片余量(1G)

KV cache = 上下文长度 × 每 token 开销

72B GQA 模型的每 token 开销是 320KB（FP16）或 160KB（q8_0）。按这个公式，24G 卡在 8192 上下文 + q8_0 KV 的情况下，KV 占 1.3GB，可用权重空间约 18.2GB，能放 30 层左右。如果上下文提到 32768，KV 涨到 5.2GB，权重空间只剩 14.3GB，能放的层数掉到 24 层，速度会明显下滑。

所以我的建议是分层配置：日常短对话用 4096 上下文 + 33 层，速度最优；需要处理长文档时切到 16384 上下文 + 26 层，牺牲速度换能力。不要一套配置打天下。

还有个细节：KV 量化到 q8_0 之后，cache 的对齐方式会变，某些版本上会触发额外的拷贝，速度可能略有下降。实测下来这个损失通常在 2% 以内，远小于多 offload 几层带来的收益，所以还是划算的。q4_0 的 KV 量化我不推荐，长上下文下质量退化能感知到，会出现前后文指代混乱。

4.3 线程、批处理与 NUMA 这些细节

线程数这个参数看起来简单，坑却不少。默认值往往是逻辑核心数，在超线程机器上会导致线程争抢同一个物理核的缓存，速度下降 10%~15%。正确做法是填物理核数，可以通过lscpu看"Core(s) per socket × Socket(s)"。

如果你用的是双路服务器平台，还得考虑 NUMA。进程跑在 node 0，但内存分配在 node 1，跨节点访问延迟翻倍。这时候要用numactl --cpunodebind=0 --membind=0把进程和内存绑在同一个节点上，实测能提升 15%~25%。这个细节几乎没人提，但在服务器上跑 72B 时非常关键。

批处理参数-b和-ub主要影响预填充。-ub是真正一次送进计算图的 token 数，它决定了峰值显存的临时占用。显存紧张时把它降到 64，往往就能从"启动失败"变成"正常启动"。代价是处理长 prompt 的时间变长，但生成速度不受影响。我一般先用 128 试，不行就 64。

还有一个参数是--no-mmap。默认情况下引擎用内存映射加载模型，好处是加载快、多个进程可共享；坏处是第一次访问某层时会有磁盘 IO 延迟。如果你的内存足够大（能装下整个模型文件并且有余量），加上--mlock和--no-mmap把模型完整读进物理内存，运行时的抖动会小很多。内存不够时千万别加，会直接 OOM。

4.4 被忽略的磁盘和散热

这两个因素和模型本身没关系，但对体验的影响一点不小。

磁盘方面，前面提过机械盘不行。还有一个隐蔽问题：如果模型放在网络挂载的存储上，mmap 的随机读会变成网络请求，速度能慢到令人发指。我见过有人把模型放在 NAS 上跑，测得 0.3 t/s，以为是显卡不行，其实是千兆网卡拖的。

散热方面，长时间满载推理会让显卡跑到温度墙，然后自动降频。一张本来能跑 2.8 t/s 的卡，跑二十分钟后掉到 2.2 t/s，很多人以为是"跑久了会变慢"的玄学，其实就是在降频。用nvidia-smi -q -d TEMPERATURE看实时温度，如果贴着温度上限，考虑提高风扇曲线或者加强机箱风道。CPU 侧同理，offload 到内存的那些层是靠 CPU 算的，CPU 降频同样掉速度。

内存频率也值得一提。同样是 DDR5，4800 和 6000 的带宽差 25%，在 offload 比例高的场景下速度差得很明显。如果主板支持开 XMP/EXPO，务必打开——这是零成本的性能提升，很多人装了高频内存却跑在默认频率上。

5. 踩坑实录：单卡 72B 的高频故障与排查

5.1 启动阶段：OOM、卡死、加载中断

启动阶段最常见的三种失败，症状和成因完全不同，混在一起排查会走很多弯路。

第一种是显存 OOM，报错里带out of memory或CUDA error。这个好判断，直接降-ngl或者降-c。但要注意一个陷阱：报错发生在加载后期，可能只差一两层。这时候别急着大砍，减 2 层试试就够了。还有一种情况是显存看着还有空余却报 OOM，那是碎片问题，把-ngl减 1~2 层通常能过。

第二种是内存 OOM，系统直接杀进程，日志里什么都没有，或者只有一行Killed。这通常发生在内存不够大的机器上，模型文件 47GB，加上系统和其他进程，64GB 内存会很紧张。解决办法是减小-b/-ub，或者关掉--no-mmap让系统用按需加载。如果内存只有 32GB，那基本没戏，除非上更激进的量化。

第三种是加载卡住不动，日志停在某个百分比十几分钟。这多半是磁盘 IO 问题——机械盘、网络存储、或者文件损坏。先换本地 SSD 试，如果还是卡，重新校验文件哈希。我遇到过一次是下载的分片其实是 HTML 错误页，文件大小看着差不多，实际内容完全不对，加载时解析元数据就卡住了。

注意：排查启动问题时，先看日志的最后 20 行而不是第一行。第一行报错往往是被后面失败引发的连锁反应，真正的根因在最后。

5.2 运行阶段：速度断崖式下跌

跑到一半突然变慢，比一开始就慢更让人抓狂。我总结了几种典型模式。

模式一：前几个问题快，后面越来越慢。这是上下文累积导致的——对话历史越来越长，KV cache 不断增长，最终把显存吃掉，触发前面说的"溢出到共享内存"。解决办法是限制历史轮数，或者开启上下文滑窗，把老对话裁掉。有些前端框架默认保留全部历史，跑十几轮之后速度掉一半很正常。

模式二：速度呈现周期性波动，快慢交替。这是内存换页的典型特征。检查free -h看 swap 使用量，如果有增长，说明物理内存不够。加内存或者减-ngl（让更多层留在显存反而省内存？不是，是反过来——减-ngl会增加内存占用）。正确做法是加--mlock锁住内存，或者干脆减少上下文和批大小。

模式三：白天快晚上慢，或者随机变慢。这在共享机器上很常见，其他进程在抢 GPU 或内存带宽。用nvidia-smi看是否有其他进程占用显存，用htop看 CPU 和内存的实时占用。有个隐蔽的元凶是浏览器的硬件加速，一个开着几十个标签页的 Chrome 能占掉 1~2GB 显存。

模式四：温度上来之后稳定变慢。这个前面说过，看温度曲线就能确认。

5.3 输出质量：乱码、复读、截断

跑起来之后，质量问题比速度问题更影响可用性。

输出带特殊标记，比如<|im_start|>、<|endoftext|>，是 chat template 没配对。Qwen 系列用的是 ChatML 格式，需要明确指定。有些推理框架会自动识别，有些需要手动加--chat-template chatml参数。用 API 调用时，要在消息体里按标准格式构造，别把整个对话拼成一个字符串塞进 prompt。

复读和死循环，通常是采样参数的问题。Qwen 官方推荐的是 temperature 0.7、top_p 0.8、repetition_penalty 1.05。如果你把 temperature 调得太低（比如 0.1），模型会陷入确定性循环，一句话反复说。调高到 0.7~0.9 通常能缓解。反过来，如果输出太发散、答非所问，说明温度太高，往下调。

中文夹英文、词语错乱，在低比特量化下比较常见。Q3 及以下的量化对中文词表的影响最大，因为中文 token 在词表里分布密集，量化误差会放大。如果你主要处理中文，建议至少用 Q4_K_M，别为了多 offload 几层牺牲到 Q3。

回答在中途断掉，是被 max_tokens 截断了。这个参数要设得比预期回答长度大一些，中文一个字大约 1~1.5 个 token，500 字的回答要留 700~800 的预算。有些框架默认只给 256，跑长回答必然截断。

5.4 故障速查表

把上面这些整理成一张表，出问题时对着查会快很多。

6. 边界感：单卡 72B 该用在哪、不该用在哪

6.1 它真正擅长的三类任务

速度慢不等于没价值。2~3 t/s 的生成速度，如果任务是异步的、不需要人盯着等，那完全够用。我总结了三类最适合的场景。

第一类是离线批处理。比如一批几百份的合同条款抽取、一批技术文档的结构化整理、一批客服记录的归类打标。这类任务一次跑几小时，速度从 2 t/s 提到 5 t/s 对你没有任何意义，重要的是结果质量和数据不出内网。72B 在理解复杂指令和长文本逻辑关系上，明显强于 7B、14B 这个量级，处理需要多步推理的任务时差距更大。

第二类是质量敏感的生成任务。写正式文档、做技术方案初稿、把散乱的需求整理成结构化描述，这些场景下慢一点可以接受，但输出质量差一点就要返工。72B 相比小模型的优势在于指令遵循的稳定性和长文连贯性，它不容易跑题，也不容易在长输出里前后矛盾。

第三类是对数据流向有严格要求的场景。某些行业的数据不能出本地，公有 API 用不了，这时候单卡方案就是唯一解。虽然慢，但它能完成任务，而且整套系统在你自己手里，可控。

反过来，如果你的任务是高并发问答、实时对话、需要秒级响应的客服系统，那 72B 单卡是错误的选择。2 t/s 的速度支撑不了任何交互式体验，用户等三秒没反应就关页面了。这类场景老老实实用小模型，或者加钱上多卡。

6.2 别硬上的四类场景

第一类是超长文档的全量分析。有人想一次性喂进去 10 万字让它总结，先不说上下文能不能撑住，光是预填充就要跑十几分钟，CPU 侧的层处理长 prompt 的效率极低。真要做长文档，正确做法是分段处理再汇总，用 RAG 做检索增强，别指望一次性怼进去。

第二类是需要频繁调用的服务。如果一个业务流程里要调用模型二十次，每次两分钟，那就是四十分钟，整个流程没法用。这种要重新设计，要么合并调用，要么换小模型做路由。

第三类是代码补全这类延迟敏感的任务。补全要求 100 毫秒级响应，72B 单卡差了两个数量级。这块该用专门的补全模型，别拿大模型硬套。

第四类是多轮复杂对话。上下文越长越慢，而且显存压力越大。多轮场景下 KV cache 会迅速吃掉本来就不宽裕的显存，跑到后面几轮速度可能掉到 1 t/s 以下，体验极差。如果一定要做多轮，记得限制历史长度，把早期的对话摘要压缩。

6.3 折中方案：什么时候该换思路

硬上 72B 单卡之前，先问自己一个问题：你是需要"72B 这个能力"，还是需要"一个大模型"？

如果只是需要一个能处理中文、能理解指令、能做一些推理的模型，那 32B 级别的模型在 4bit 下只要 20GB 左右，24G 卡可以几乎全放，速度能到 15~25 t/s，体验完全是另一个层次。在多数实际任务上，32B 和 72B 的差距远小于"能不能流畅用"这个差距。

如果确实需要 72B 的能力，那可以考虑分层架构：用一个小模型做意图识别和简单问答，把复杂问题路由到 72B。这样 80% 的请求在毫秒级返回，20% 的复杂请求走慢通道，整体体验和成本都能接受。

还有一种思路是 MoE 架构的模型。同样是"大参数量"，MoE 在推理时只激活一部分专家，实际计算量和显存带宽压力都小得多。这类模型在单卡上的表现往往比稠密 72B 好一个数量级，如果你的任务对模型的知识广度要求高于对推理深度的要求，值得优先考虑。

我在实际使用中的体会是，72B 单卡这个方案最大的价值不在"日常用"，而在"验证"和"兜底"。验证是指你可以用很低的成本确认某个业务场景到底需不需要这么大的模型，跑两周就知道答案了；兜底是指在数据不能外流的硬约束下，它至少提供了一个可用的选项。至于日常生产，老老实实按任务难度分层部署，别指望一张卡扛下所有。

最后再分享一个小技巧：如果你要长期跑这个配置，把启动参数写进一个脚本，并且在脚本里先用nvidia-smi --query-gpu=memory.used --format=csv检查显存是否被其他进程占用，占用超过 1GB 就提示用户先清理。我因为这个吃过好几次亏——浏览器没关、上次的进程没退干净，结果新进程自动降级到很少的层数，速度慢得莫名其妙，排查了半小时才发现是显存被占了。