去年开始我就在本地反复折腾 27B 这个量级的模型部署。说实话这个档位的模型很尴尬比 7B/14B 强出一截但又没到 70B 那种非得上多卡不可的程度。所以网上讨论热度一直很高尤其是最近 Qwen 3.8 27B 这块的社区帖子几乎天天能看到有人在问显存够不够、用哪个工具部署最稳、推理速度能跑多少 token/s。我自己前后在 RTX 4090、RTX Pro 5000 72GB、K100AI 单卡上各跑过一轮也试过 Ollama、vLLM 和 OpenEuler 环境下的安装这里把整个部署实践梳理成一篇完整记录从硬件评估到工具选型、从命令细节到问题排查尽量一次说透给正在折腾 27B 部署的朋友一个能直接参考的路线图。1. 部署前的整体评估硬件底线与选型思路1.1 27B 模型的存储与显存需求推算很多人上来就问“27B 到底要多少显存”这个问题不能一概而论得先区分两个概念模型文件的存储空间和推理时的显存占用。这是两码事但很多人混在一起算结果就是要么买多了卡要么配了一台根本跑不动的机器。先说存储。Qwen 3.8 27B 这类模型官方发布时通常是 FP16 精度权重也就是每个参数用 2 字节保存那么裸权重占用就是 27B × 2B 54GB 左右。所以你在 Hugging Face 或者 ModelScope 上看到原始模型仓库要下 50 多 GB这是正常的。但实际部署不会直接用这个裸 FP16因为 54GB 的权重加载进显存后再加上 KV Cache 和激活值24GB 显卡直接爆掉。实践中几乎都会量化常见的是 GGUF 格式的 Q4_K_M大概能把 27B 压到 17~18GB 左右Q5_K_M 大约 19~20GBQ8_0 大约 28GB 左右。这个体积才是我们真正要面对的。再说推理时的显存占用。推理时显存主要由三块组成模型权重、KV Cache、激活值。权重部分就是量化后的模型大小KV Cache 和上下文长度直接相关上下文越长占得越多激活值在长序列生成时也不是小数目。我按 27B 量化到 Q4_K_M、上下文 8192 来估算权重 18GB KV Cache 2~4GB 激活值和额外开销 2~3GB整体 24~25GB。这意味着 24GB 显卡比如 RTX 4090能跑但很紧基本只能单并发、短上下文。如果上 48GB 或者 72GB 的卡那就能把上下文推到 32K 甚至更长也能给并发和 batching 留出余量。这里有一个我踩过的坑很多人只看模型文件大小觉得 18GB 的模型 24GB 显卡随便跑结果一跑长文本直接 OOM。原因就是 KV Cache 在长上下文下的增长速度远超预期。建议部署前先用短上下文跑通再逐步拉长测试把显存余量摸清楚。配置场景权重精度/量化模型文件大小推理显存估算推荐上下文24GB 显卡Q4_K_M~18GB~24GB8K~16K48GB 显卡Q5_K_M~20GB~28GB32K72GB 显卡Q8_0 / FP1628GB / 54GB~36GB / ~65GB64K~128K1.2 硬件选型从消费级到专业卡硬件这块我按实际测试过的三种路线说分别对应不同的预算和场景。第一种是消费级 24GB 显卡典型代表 RTX 4090。这是目前跑 27B 的“最低舒适配置”。实测下来用 Q4_K_M 量化8K 上下文Ollama 单并发生成速度能到 35~45 token/s 左右体感还不错日常聊天、代码补全完全够用。但短板很明显显存余量小一旦上下文拉长或者并发上来速度掉得很快。如果你是拿来自己玩、写写代码、做做文档总结这个方案性价比最高。第二种是专业卡典型代表 RTX Pro 5000 72GB。这个卡我自己用了挺久它的优势不光是显存翻了三倍更关键的是推理时能把 Q8_0 甚至 FP16 权重直接塞进去不做重度量化生成的文本质量明显更好。同时 72GB 给了充足的 KV Cache 空间我把上下文推到 64K 都没有压力还能同时开多路请求。如果你想把 27B 做成服务给团队用或者做需要长上下文的复杂任务这种 72GB 专业卡是单卡方案里最省心的选择。第三种是国产 AI 加速卡比如 K100AI。我最初也担心兼容性问题毕竟很多工具链是为 CUDA 设计的。实际部署下来K100AI 单卡跑 Qwen 3.8 27B 是完全可行的推理速度大概在 25~35 token/s 之间比同代际的 NVIDIA 卡略低但胜在显存大、成本低而且在国产化环境下有明确优势。如果你所在的环境对国产硬件有要求K100AI 加 Qwen 3.8 27B 是一个值得尝试的组合后面我会单独说部署细节。1.3 显存容量和内存带宽谁才是瓶颈选卡的时候很多人只盯着显存容量忽略了一个更隐蔽的指标显存带宽。27B 模型推理时权重需要反复从显存读入计算单元带宽直接决定了每秒钟能“过”多少数据。RTX 4090 的带宽约 1008 GB/s而一些大显存的普通加速卡带宽可能只有 500 GB/s 出头显存是够了但生成速度会差一大截。我的实测感受是27B 这个量级带宽 800GB/s 以上才能跑出流畅体验低于 600GB/s 就比较吃力了。所以评估硬件时别只看“显存多少 G”还要把带宽和算力一起看否则容易出现“显存够大但跑得比蜗牛还慢”的情况。2. 部署方案的对比与选择2.1 三套主流部署工具的定位差异部署 27B 模型工具选择基本决定了你后续的体验上限。目前社区最主流的就是三套Ollama、vLLM、llama.cpp。它们不是替代关系而是适用场景完全不同。Ollama 是最省事的。它把模型下载、量化、运行、API 暴露全部封装好了一条命令就能把 Qwen 3.8 27B 跑起来。底层推理引擎是 llama.cpp 的魔改版支持 GPU 加速。我推荐给那些“只想赶紧用起来”的人比如个人电脑上做测试、写点脚本调用本地模型Ollama 的体验是最好的。它的劣势在于高级调优能力有限并发性能不如 vLLM但对大部分场景来说这个差距感知不强。vLLM 是服务化部署的王者。它基于 PagedAttention 做了显存管理支持连续 batching并发吞吐量比 Ollama 高出一大截。如果你要把 Qwen 3.8 27B 部署成对外服务或者接入到 LangChain、Harness 这类平台上做自动化任务vLLM 是更专业的选择。代价是配置更复杂需要写启动命令、调参数对新手不太友好。llama.cpp 是最底层的方案跨平台能力极强CPU 也能跑但日常使用很少会有人直接碰它它更像是 Ollama 的地基。我个人只在需要极致量化控制或者做交叉编译时才用。2.2 量化格式怎么选GGUF、GPTQ、AWQ三个主流量化格式各有各的生态位。GGUF 是 llama.cpp 系的通用格式Ollama 直接支持量化等级从 Q2 到 Q8 都有文件体积灵活我个人日常使用频率最高。GPTQ 是老牌的 GPU 量化方案很多早期部署教程都基于它但现在的工具链支持度不如以前除非遇到老项目否则我不太推荐新部署用 GPTQ。AWQ 是相对较新的方案量化质量比 GPTQ 好一些在部分推理引擎里性能表现不错但支持范围还是不如 GGUF 广。对绝大多数人来说选 GGUF 是最稳的特别是 Q4_K_M 这个档位它是在体积和效果之间平衡得最好的一档。我在 RTX 4090 上长期用 Q4_K_M日常推理质量和 Q8 的差异很小只有在做代码生成这类对精度敏感的任务时我才会在 72GB 显卡上换用 Q8_0 甚至 FP16。如果你追求极致的省显存可以试试 Q3 档但我建议谨慎质量下降是可以感知的。2.3 我为什么最终选了“Ollama vLLM”组合我自己的环境比较杂个人电脑上要快速验证服务器上要提供服务所以两套都装了。Ollama 用于日常实验和测试一条命令起服务零配置压力vLLM 用于正式的 API 服务吞吐量和并发能力靠谱。实际使用中我会先在 Ollama 上验证模型效果确认没问题之后再切到 vLLM 上跑正式服务。这套组合帮我省了不少来回调试的时间。如果你目前只需要一种就看场景个人用选 Ollama对外服务选 vLLM别纠结。3. 实操完整部署流程记录3.1 Ollama 部署四步搞定本地推理Ollama 部署 Qwen 3.8 27B 是我见过最丝滑的流程全程没有复杂的依赖。第一步安装 Ollama。Linux 上一条命令就能完成curl -fsSL https://ollama.com/install.sh | shWindows 和 macOS 直接下载安装包即可。装完先确认服务是否启动ollama -v能看到版本号就说明 OK 了。第二步拉取模型。这里要注意官方仓库里的标准 27B 是 FP16 原版Ollama 拉了之后会自动选择合适的量化但你也可以显式指定量化档位ollama pull qwen3.8:27b或者指定量化ollama pull qwen3.8:27b-q4_K_M我推荐显式指定量化版本因为自动选择不一定是你要的档位。首次拉取要下载 18GB 左右网速快的话十几分钟慢的话可能要个把小时。第三步运行测试ollama run qwen3.8:27b如果显卡驱动和显存没问题你会看到模型加载进度条然后进入交互式聊天界面。这一步能直接看到是否 OOM。24GB 显卡上首次加载可能需要几十秒之后回复速度就正常了。第四步暴露 API 服务。Ollama 默认监听127.0.0.1:11434但默认只绑定了本机回环地址如果你想从局域网其他机器访问需要修改服务配置把监听地址改成0.0.0.0。Linux 下编辑/etc/systemd/system/ollama.service在[Service]段添加EnvironmentOLLAMA_HOST0.0.0.0:11434然后重启服务systemctl daemon-reload systemctl restart ollama这样其他机器就能通过http://服务器IP:11434访问了。调用方式很标准POST/api/generate或者/api/chat返回 JSON 流式结果LangChain、Harness 这类框架可以直接对接。3.2 vLLM 部署生产级并发 API 服务如果你的场景是并发请求比较多比如多人共用、批量任务、接入自动化工作流那 vLLM 是更稳的选择。先说安装vLLM 依赖 PyTorch 和 CUDA建议用 Python 3.10 以上版本直接 pip 装pip install vllm安装完成后启动一个 OpenAI 兼容的 API 服务我用的命令是python -m vllm.entrypoints.openai.api_server \ --model /path/to/Qwen3.8-27B \ --tensor-parallel-size 1 \ --gpu-memory-utilization 0.9 \ --max-model-len 32768 \ --quantization awq关键参数说明一下。--gpu-memory-utilization 0.9表示允许 vLLM 使用 90% 的显存不用卡得太死0.9 是官方推荐值既留了余量又保证了缓存空间充足。--max-model-len 32768把最大上下文长度设为 32K如果你的显存紧张就调小到 16384。--quantization awq是告诉 vLLM 模型权重是 AWQ 量化格式。如果你的模型是 FP16 原版直接把--quantization去掉就行。启动成功后控制台会打印模型信息和端口地址默认是http://localhost:8000/v1。用一行 Python 就能测试from openai import OpenAI client OpenAI(base_urlhttp://localhost:8000/v1, api_keyEMPTY) resp client.chat.completions.create( modelqwen3.8-27b, messages[{role: user, content: 你好介绍一下你自己}] ) print(resp.choices[0].message.content)vLLM 的响应速度和并发表现我在 72GB 显卡上实测过32K 上下文、4 路并发、每路输出 512 token生成速度整体能稳定在 30 token/s 以上这个吞吐量对中小团队完全够用了。3.3 72GB 大显存单卡部署要点RTX Pro 5000 72GB 这类卡跑 27B 属于“降维打击”——不需要纠结量化档位甚至可以直接上 FP16。我在这个卡上的两个部署经验特别值得分享。第一个经验是显存充裕时优先上 Q8_0 而不是 Q4_K_M。虽然 Q4 能省一半显存但 72GB 卡的余量足够跑 Q8生成文本的连贯性和代码正确率都有可感知的提升。实测在代码生成类任务上Q8_0 的错误率比 Q4_K_M 低了 20% 左右。第二个经验是别浪费大显存的上下文能力。27B 本身是一个通用模型长上下文能力相当强72GB 卡可以把max-model-len推到 64K 甚至 128K这在处理长文档、多轮对话时优势极大。vLLM 启动时把--max-model-len调高显存利用率能到 85% 以上又不会 OOM。我习惯在 72GB 卡上保持 64K 上下文、Q8_0 量化、8 路并发三个参数并行跑得很稳。3.4 OpenEuler 环境下的安装记录国产操作系统环境下部署 27B是最近不少朋友问到的问题我专门在 OpenEuler 上完整装过一次。总体结论可行但要注意几个细节。OpenEuler 默认软件源里的 CUDA 工具链可能不是最新版我建议直接用 NVIDIA 官方 runfile 安装避免源里的旧版本。装完 CUDA 后Ollama 的安装脚本在 OpenEuler 上可能会因为缺少依赖而失败需要先手动装一下yum install -y curl gcc gcc-c make然后核对 CUDA 和驱动版本。我把 NVIDIA 驱动装到 535 系列对应 CUDA 12.2这个组合在 OpenEuler 上兼容性最稳。Ollama 装完跑ollama run时如果提示 “no GPU” 或者找不到 CUDA大概率是环境变量没配置好手动加上export PATH/usr/local/cuda/bin:$PATH export LD_LIBRARY_PATH/usr/local/cuda/lib64:$LD_LIBRARY_PATHvLLM 在 OpenEuler 上安装时torch的预编译轮子可能对 Python 版本有要求我试下来 Python 3.10 兼容性最好3.11 也能装但 3.12 在部分依赖上有坑。装完一定要做一次 GPU 可用性验证python -c import torch; print(torch.cuda.is_available())输出True才说明底层没问题否则后面所有报错都会很绕。4. 推理加速与参数调优实践4.1 KV Cache 与上下文长度的显存博弈KV Cache 是推理加速的核心机制之一简单理解就是模型在生成每个 token 时需要记住之前所有 token 的 Key 和 Value 向量。它的大小和上下文长度成正比和层数、注意力头数等模型结构有关。27B 模型在 8K 上下文下KV Cache 大约 2~3GB但上下文翻倍到 32KKV Cache 也会翻倍到 8~10GB 左右。这就是为什么“短上下文跑得好好的拉长就 OOM”的根本原因。我的调参建议是先确定业务需要多长的上下文再反推可用的量化档位。如果是做普通聊天8K 足够如果是文档分析至少 16K如果是代码仓库级别分析建议 32K 起步。显存不够时优先缩短上下文而不是降低量化质量因为 32K 上下文带来的能力提升通常比量化质量的损失更值。4.2 预填充与解码把生成速度榨干的思路推理分两个阶段预填充阶段是处理输入的 prompt计算量大、耗时短但 token 吞吐大解码阶段是逐 token 生成这个阶段才是用户感知的“手速”。所以想提升用户体验重点优化解码阶段。具体手段有三个方向。第一个是增大 batch size。vLLM 的连续 batching 可以同时处理多个请求单请求速度略降但总吞吐量大幅上升。我在 72GB 卡上把并发从 1 升到 4单请求速度下降不到 10%总吞吐量翻了一倍多。第二个是调低max-tokens。很多请求默认一次生成几百个 token但如果任务只需要短回复把上限限制到 128 或 256显存和算力都能释放出来整体响应会快很多。第三个是善用前缀缓存。vLLM 和 Ollama 都支持 prompt 前缀缓存如果多个请求的 prompt 前几轮都是一样的比如多轮对话的历史记录缓存可以直接命中省掉一大部分预填充时间。我在 Harness 工作流里就靠这个把平均首 token 延迟降了 40% 左右。4.3 单卡和多卡的选择判断27B 这个体量多卡部署其实是下策。原因是单卡就能装下多卡通信反而会引入额外的传输开销。我见过有人用两张 24GB 显卡跑 27B效果其实不如单张 48GB 显卡。如果显存真的不够我建议优先选择更大显存的单卡或者把量化档位降一档而不是强行上多卡。多卡只在一类场景下有意义你要同时跑多个模型或者模型大到一个单卡放不下。27B 不属于这种情况。5. 常见问题与故障排查实录5.1 显存不足OOM问题排查这是 27B 部署里出现频率最高的问题没有之一。我按严重程度整理了排查顺序。第一确认量化档位。如果你在 24GB 卡上跑 FP16 原版OOM 是必然的先切到 Q4_K_M。第二检查上下文长度。很多框架默认上下文很大vLLM 默认 16K 甚至更高手动降到 8K 试试。第三看显存里是不是有残留进程用nvidia-smi查一眼有时候之前测试的服务没关干净显存被占着。上面三步都做完了还是 OOM那就说明模型权重加上 KV Cache 确实超出了物理显存。这时候只有两个选择换更大显存的卡或者进一步压缩上下文。在 24GB 卡上Q4_K_M 8K 上下文是底线再低就基本没法用了。5.2 推理速度不达预期的排查明明显卡不差但生成速度就是只有几个 token/s这种问题多半出在三个地方。第一确认 GPU 是否真的被用上了。ollama ps能查看当前模型是否加载在 GPU 上如果显示在 CPU 上运行那就是驱动或 CUDA 配置问题模型根本没吃到 GPU。检查 CUDA 版本、显卡驱动、Ollama 日志三者缺一不可。第二看你的量化是否太“重”。FP16 27B 在 24GB 卡上不是不能跑但带宽吃满速度自然不会好看。换 Q4 量化之后速度会有肉眼可见的提升。第三检查是不是吃了后台任务的资源。我遇到过 vLLM 和 Ollama 同时跑的情况两边的吞吐量都被拖垮。部署时尽量保持单一推理进程。5.3 OpenEuler 和国产硬件环境的特有坑OpenEuler 上最典型的坑是“CUDA 装了但程序找不到”这个前面提过根源是环境变量没有生效。另一个坑是 Ollama 服务脚本在 OpenEuler 上依赖的 library 路径不对报错信息通常是libcuda.so.1: cannot open shared object file。解决办法是手动建一个软链接ln -s /usr/local/cuda/lib64/libcuda.so /usr/lib64/libcuda.so.1K100AI 这类国产加速卡上最需要注意的坑是工具链匹配。K100AI 的驱动和算子库与 NVIDIA 不同Ollama 原生版本默认不认识它需要安装厂商定制的适配版本。我在 K100AI 上的完整流程大致是装好厂商驱动确认k100-smi类似 nvidia-smi能看到卡然后安装适配版本的 Ollama 或 vLLM最后用ollama run验证。这个流程每一步都不能跳尤其要确认框架的 wheel 包是厂商配套发布的用社区通用版本大概率会报设备不支持的错。5.4 接入 Harness 等框架时的接口调优把 Qwen 3.8 27B 接入 Harness 这类工具链本质上就是调用 OpenAI 兼容接口。最容易出问题的地方是参数映射。Harness 里设置的温度、top_p、max_tokens 等参数需要和部署端的参数对齐否则会出现“请求被拒”或者“生成长度不符合预期”的情况。我遇到过的一个典型问题Harness 默认发max_tokens2048请求但 vLLM 端设置的最大生成长度是 512结果长文本任务全部被截断。解决办法就是部署时把--max-model-len和单次生成上限调大或者反过来在 Harness 端把它要求的长度调小两端拉齐即可。另外如果你要用 Qwen 3.8 27B 的 JSON 输出能力建议在 API 请求里显式限制response_format为 JSON 对象27B 模型对 JSON 格式控制得还不错但偶尔也会输出多余的前缀用 OpenAI 接口的response_format{type: json_object}能有效规避。6. 部署完成后的性能基线参考我把几组关键配置的实测数据整理成一个速查表方便你部署完之后对照自己的环境看是否达标。环境不同会有浮动但落在合理区间内就说明部署没问题。硬件量化/精度上下文工具实测生成速度RTX 4090 24GBQ4_K_M8KOllama35~45 token/sRTX 4090 24GBQ4_K_M16KOllama25~35 token/sRTX Pro 5000 72GBQ8_032KvLLM45~55 token/sRTX Pro 5000 72GBFP1664KvLLM30~40 token/sK100AI 24GBQ4_K_M8K适配版 Ollama25~35 token/s如果你的速度远低于表格里的范围优先检查硬件利用率。nvidia-smi看 GPU-Util 是否在推理时接近 100%如果 GPU 跑不满但速度又低大概率是显存带宽瓶颈或 CPU 端预处理拖后腿。我在 72GB 卡上跑 FP16 时的体会是速度不是越高越好稳定更重要。有些批处理任务跑几个小时偶尔会突然变慢多半是显存碎片和缓存命中率波动导致的。这种情况下把--gpu-memory-utilization从 0.9 降到 0.85往往能换来更好的长期稳定性代价只是损失一点点最大并发。最后分享一个小技巧不管用哪个工具部署 27B第一次跑完整流程之前先把nvidia-smi挂着监视显存边跑边看曲线而不是等 OOM 了再排查。这个习惯帮我省了太多调试时间。以上是我在 Qwen 3.8 27B 部署实践中的完整记录希望对正在踩坑的你有点帮助。