这几天我一共换了几台机器来折腾 Qwen 3.8 27B 的部署从 24G 显存的消费级显卡一路试到 72G 的专业卡踩了不少坑也把显存账彻底算明白了。如果你正准备把这个 27B 模型跑起来不管是用在私有知识库、代码助手还是简单的对话应用我的建议都是动手之前先把账算清楚再选路线。这篇文章就把整个部署实践完整记录下来包括环境准备、推理框架选型、量化压测、并发验证和几段让我印象深刻的排错经历适合单卡用户也适合准备上多卡服务的朋友参考。1. 27B 需要多少显存先算账再动手1.1 为什么是 27B 这个规格先说为什么偏偏盯上 27B。7B 和 14B 其实消费级显卡也能轻松跑起来但复杂一点的推理链、长文档总结、带格式要求的代码生成效果能明显感到天花板72B 没得说效果好可单卡基本没戏最少也要两张 48G普通工作室和小团队根本扛不住。27B 正好卡在中间参数量足够支撑复杂的指令跟随和结构化输出部署成本又不像 72B 那样离谱。这里要提醒一句27B 只是参数量级别的粗略描述不同量化方式下显存差异非常大。我最开始直接用 FP16 权重试跑被 CUDA out of memory 当场劝退后来切到 4bit 量化才在 24G 卡上顺利跑起来。所以第一步不是急着装环境而是把显存账算明白搞清楚自己手里的卡到底能撑起什么配置。1.2 显存账本怎么算模型权重体积有一个非常简单的公式模型文件大小约等于 参数量 × 位宽 ÷ 8。27B 参数在 FP16 下就是 27 × 2 54GB光权重就把 48G 卡占满了如果跑 8bit 量化权重约 27GB4bit 量化约 14~16GB再加上量化格式的额外开销实际占用通常落在 17~19GB。这几个数字建议直接背下来后面选卡、选量化都用得上。配置权重占用可用显存要求说明FP16 原始权重约 54GB72G 级基本告别单卡 24G/48G8bitQ8_0 等约 27GB48G 级质量接近原始24G 卡放不下4bitQ4_K_M 等约 17GB24G 级消费级显卡的实际主力选择2bitQ2_K 等约 10GB12G~16G 级质量损失明显不建议做主力但权重只是第一部分。真正跑起来之后还有两块显存开销KV cache 和计算激活值。KV cache 随上下文长度线性增长以我这次部署的 27B 模型为例16K 上下文时约占 1~2GB如果开到 128K这块要预留 5GB 以上。很多人部署完发现能加载但一跑就 OOM基本都是忽略了 KV cache 这部分的占用。算完这笔账结论就很清晰24G 显存卡在 4bit 量化和中等上下文48G 可以上 8bit 和长上下文72G 基本能做到接近 FP16 的原生部署。我最终稳定的主力配置是一张 24G 卡 Q4_K_M 量化 16K 上下文日常使用很舒服另用 72G 卡验证过接近原生的精度表现。1.3 推理框架怎么选框架选型没有标准答案关键是匹配使用场景。只想本地快速跑起来验证效果Ollama 是首选一条命令就能拉起来要做成 API 服务给业务调用vLLM 的连续批处理和 PagedAttention 在并发吞吐上优势明显需要在更小显存或者 CPU 上跑llama.cpp 生态的 GGUF 量化格式最灵活。这次实践我把 Ollama 和 vLLM 两条路线都完整跑了一遍后面分开讲你可以依据自己场景直接选。2. 环境准备驱动、Python 和模型文件三件套2.1 系统与驱动基线先讲环境。我主力测试机是 24G 显存 128G 内存 Ubuntu 22.04另一台 72G 卡跑的是 OpenEuler 系统两个环境都踩过一遍。有一个经验必须提前说部署前先把 NVIDIA 驱动和 CUDA 版本确认好不要上来就装框架。nvidia-smi右上角显示的 CUDA Version 是驱动支持的上限而 PyTorch 自带 CUDA runtime两者只要匹配就行不是必须完全一致。nvidia-smi --query-gpuname,memory.total,driver_version --formatcsv python3 --versionPython 版本建议 3.10 或 3.11太老的版本装新版依赖时会很折腾。我一直习惯为部署单独建虚拟环境避免和系统 Python 打架。OpenEuler 上的坑主要是系统自带 Python 版本偏低编译依赖时需要先装开发工具包这一步在 Ubuntu 上基本不用管。2.2 模型文件从哪拿、怎么校验模型权重优先从官方仓库下载如果网络拉取速度不理想可以设置镜像环境变量再拉文件速度会快很多。下载工具我推荐使用huggingface-cli因为它自带断点续传比裸用 git lfs 在弱网环境下稳妥得多。export HF_ENDPOINThttps://hf-mirror.com huggingface-cli download Qwen/Qwen3.8-27B --local-dir ./qwen38-27b下载完别急着推理。先做两件事一是核对文件数量和大小二是用 sha256sum 校验关键分片权重。前者能发现断点续传留下的半截文件后者能发现静默损坏。我第二次部署时就漏掉了校验这一步跑到一半才知道某个分片文件损坏浪费了一整个下午。2.3 推理引擎安装Ollama 安装很简单官方脚本一条命令curl -fsSL https://ollama.com/install.sh | sh装完先用systemctl status ollama看看服务有没有正常起来。vLLM 建议在虚拟环境里独立安装pip install vllm它会顺带拉入匹配版本的 PyTorch。装完检查 CUDA 是否可用python -c import torch; print(torch.cuda.is_available(), torch.cuda.get_device_name(0))看到True和显卡型号再继续。如果这一步就挂了基本是驱动和 PyTorch 版本匹配的问题排查方向要回到显卡驱动本身而不是模型文件。3. 两条部署路线Ollama 快速体验与 vLLM 服务化3.1 Ollama 一条命令拉起先讲最省事的 Ollama 路线。终端执行ollama pull qwen3.8:27b拉完之后ollama run qwen3.8:27b就能进入对话它会根据你的显卡自动选择默认量化版本。不过自动拉取只适合快速验证真要固定配置建议自己写 Modelfile。我常用的配置是这样的FROM /data/models/qwen3.8-27b-q4_k_m.gguf PARAMETER num_gpu 99 PARAMETER num_ctx 16384 PARAMETER temperature 0.7这里num_gpu 99表示把所有层都放到 GPU 上跑如果显存紧张也可以改成 30 之类的数字把部分层留给 CPU但生成速度会明显掉一截。num_ctx就是上下文长度我特意设成 16K 而不是 32K原因就是省显存第 4 章会说。保存为 Modelfile 后执行ollama create qwen38-27b-local -f Modelfile即可。如果 Ollama 官方库还没收录对应的标签或者你想用特定量化版本也可以先下载 GGUF 文件再用 Modelfile 导入本地。这个流程很多人不会用其实只是把 FROM 路径指向本地文件就行非常简单。3.2 vLLM 服务化部署vLLM 路线适合对外提供 API 的场景。启动命令比较直观vllm serve Qwen/Qwen3.8-27B \ --tensor-parallel-size 1 \ --gpu-memory-utilization 0.9 \ --max-model-len 16384 \ --quantization awq \ --dtype half如果权重是 AWQ 格式--quantization awq会走专门优化过的算子效率和显存占用都优于通用反量化如果不指定量化格式vLLM 会当成 FP16 加载显存不够时会在启动阶段直接报错。--max-model-len一定按实际需要来设置不要盲目调大它直接影响每一批请求的 KV cache 预算也是 OOM 的高发诱因。3.3 接口与功能验证启动完成后vLLM 默认在 8000 端口起一个 OpenAI 兼容接口用 curl 就能验证curl http://localhost:8000/v1/chat/completions \ -H Content-Type: application/json \ -d {model:Qwen/Qwen3.8-27B,messages:[{role:user,content:用三句话介绍你自己}],max_tokens:128}我做的关键测试是中文长文档总结。把一篇 5000 字左右的文档塞进对话历史看模型能不能稳定输出而不是扯到一半开始复读。实测在 16K 上下文内表现稳定一旦超过设定长度就会出现明显的内容遗忘。这不是模型本身的问题而是部署参数对上下文长度的硬约束所以一定要按业务实际用量设置。4. 显存不够怎么办量化级别与上下文长度权衡4.1 量化级别该选哪一档量化是 27B 部署绕不开的话题。常见的几个级别和实际体感差异我直接整理成一张表量化级别权重大小约体感质量适用显存Q2_K10GB 级明显可感知的退化长文本容易混乱12GQ3_K_M12GB 级日常对话还行复杂推理不够稳16GQ4_K_M17GB 级质量接近原始复杂任务也能扛24GQ5_K_M19GB 级进一步减少量化误差差异细微24G~48GQ8_027GB 级几乎无损中文表现尤其稳48G 级我在同样的 20 个问题集上做过 A/B 对比Q4_K_M 和 Q5_K_M 的回答差别非常小但 Q4_K_M 比 Q5_K_M 少占约 2GB 显存。这 2GB 在 24G 卡上可能就决定了能不能开 32K 上下文。所以我的结论是24G 卡优先 Q4_K_M48G 卡直接上 Q8_0 或 8bit没必要在低档量化上纠结太多。4.2 上下文长度是隐藏的显存刺客很多人只盯着权重大小忽略了 KV cache 是随上下文长度线性增长的。还是以我这次部署的数据为例同样 Q4_K_M 量化上下文从 16K 调到 32K可用并发数和生成速度明显下降拉到 128K 后即使在 72G 卡上也会限制到非常低的并发。模型上下文能力再强部署时也要按实际业务需求来定不要盲目把max-model-len拉满。这里有一个判断技巧如果业务以 QA 和代码生成为主12K~16K 的上下文足够覆盖绝大多数场景只有长文档解析和全局代码分析才需要 32K 以上。把省下来的显存留给 batch size 和并发整体性价比会高得多。4.3 不同显存下的推荐配置结合这几天的实测我整理了三档可以直接抄作业的配置12G~16G 卡Q3_K_M 或 Q4_K_Mnum_ctx8K用 Ollama 或 llama.cpp适合个人尝鲜。24G 卡Q4_K_Mnum_ctx16K~32KvLLM 可支撑小规模 API 服务。48G~72G 卡Q8_0 或接近原生的 FP16/FP8num_ctx32K 起适合团队服务。如果你用的是 RTX Pro 5000 这类 72G 专业卡甚至可以尝试不量化直接部署原生权重那才是真正意义上的满血体验。不过要注意满血体验代价是显存占用极高多路并发时要预留好余量。5. 跑起来之后性能实测与并发调优5.1 三个关键指标首 token 延迟、吞吐和稳定性部署完成只是第一步真正上线前你得知道三件事首 token 延迟、生成吞吐和并发下的稳定性。首 token 延迟影响用户等待的体感生成吞吐tokens/s决定业务成本并发稳定性则决定能不能用于生产。我在 24G 卡 Q4_K_M 16K 上下文的环境下实测单请求首 token 延迟大约在 300~500ms连续生成速度稳定在 22~28 tokens/s换到 72G 卡用 8bit 量化速度提升到 35~45 tokens/s。这个量级对私有化工具完全可用。不过要提醒一点性能测试别用刚跑完长任务的卡来做长时间满载后的降频会带走 10% 左右的性能测出来的数据会偏悲观。5.2 并发场景下 vLLM 的优势如果只有一两个人在用Ollama 和 vLLM 的差距不明显但并发请求一上来vLLM 的连续批处理优势就非常突出。默认参数下它会把多条请求的生成阶段合并在同一次前向计算中整体吞吐能线性增长到某个点。我实测 8 并发时vLLM 的累计吞吐比 Ollama 高出大约 2 倍这也是我坚持 API 服务用 vLLM 的核心原因。并发也不是越高越好。max-num-seqs设置太高共享显存一旦不够就会 OOM设置太低又浪费算力。我的基准配置是 24G 卡上把它控制在 16 以内超过 16 之后首 token 延迟会明显恶化。建议你用压测工具逐步加压找到延迟曲线开始陡增的拐点那才是这台机器最合理的并发水位。5.3 常见的卡死和超时跑起来之后最常见的两个问题一是显卡被其他进程占了显存推理直接 OOM二是响应时间太长客户端超时。前者要靠监控及时发现后者要检查是不是并发过高导致请求排队。我的经验是给服务端设置合理的超时和重试策略比如客户端 30 秒连接超时、120 秒读超时避免调用方一直挂在那里。还有一个容易被忽略的细节如果服务器内存只有 32G而模型文件有 17G再被其他杂项进程占用大半模型加载时进程很可能被系统 OOM killer 直接杀掉。纯部署机建议内存至少 64G如果内存确实紧张至少把 swap 打开慢一点但至少不会让进程凭空消失。6. 踩坑记录OOM、下载中断与重启失联6.1 第一次 OOM 的完整排查链路第一次在这台 24G 卡上加载 Qwen 3.8 27B报错非常经典CUDA out of memory。我的排查过程是这样的先nvidia-smi确认有没有别的进程占用显存结果发现有一个残留的推理服务进程还占着 14G。把旧进程 kill 掉重新拉取模型结果还是 OOM。这时候才意识到默认加载的可能是 FP16 权重54G 显然放不进 24G必须手动切换量化版本。换成 Q4_K_M 的 GGUF 文件重新加载这次顺利启动。这个过程说明一个很基础的道理报错信息只会告诉你表面原因真实原因往往要往上追一层。如果你也遇到 OOM按残留进程 → 加载格式 → 量化级别的顺序排查基本能定位问题。6.2 下载中断导致的模型损坏第二次翻车更隐蔽。模型文件下载到一半网络断了重连后工具提示续传完成看文件大小也都对但加载到 80% 时直接报 decode error。这说明断点续传能恢复下载进度但不保证文件一定完整某个分片可能在传输过程中就静默损坏了。解决方法很简单把本地缓存清掉重新下载或者先按仓库提供的 sha256 校验值核对所有分片。我现在养成了一个习惯下载完先跑一遍sha256sum确认没问题再部署。虽然多花了半分钟但省下了很多排错时间。6.3 服务重启与命令行失联第三个坑是重启服务器后 Ollama 服务没有自动拉起或者 API 地址变了导致调用方连不上。解决方法是写一个 systemd 服务设置开机自启[Unit] DescriptionOllama Service Afternetwork.target [Service] ExecStart/home/user/bin/ollama serve Restartalways RestartSec3 EnvironmentOLLAMA_HOST0.0.0.0 EnvironmentOLLAMA_MODEL/data/models [Install] WantedBymulti-user.target把文件放到/etc/systemd/system/ollama.service执行systemctl daemon-reload systemctl enable ollama systemctl start ollama之后重启服务器服务就会自动恢复。OpenEuler 上用 systemctl 的操作方式和 Ubuntu 基本一致这个守护脚本可以直接通用。最后说点个人体会。部署 27B 这个规模的模型真正难的不是敲那几行命令而是理解每一步背后的显存和带宽账。我踩过最大的坑就是只想快点跑起来结果在错误配置上浪费的时间反而更多。如果你准备长期用建议部署完先做一套自己的性能基线固定问题集、固定并发数、记录延迟和吞吐后面再换量化或调参的时候有对照心里就有底。至于 27B 后面还能做什么我最近正在试 lora 微调让模型更贴合自己的业务语言风格等跑通了再单独写一篇分享。 
长河君 · 2026/9/30 18:14:03 · 阅读 1.2k Qwen 27B 部署实战：从显存计算到量化选型与推理框架对比
这几天我一共换了几台机器来折腾 Qwen 3.8 27B 的部署从 24G 显存的消费级显卡一路试到 72G 的专业卡踩了不少坑也把显存账彻底算明白了。如果你正准备把这个 27B 模型跑起来不管是用在私有知识库、代码助手还是简单的对话应用我的建议都是动手之前先把账算清楚再选路线。这篇文章就把整个部署实践完整记录下来包括环境准备、推理框架选型、量化压测、并发验证和几段让我印象深刻的排错经历适合单卡用户也适合准备上多卡服务的朋友参考。1. 27B 需要多少显存先算账再动手1.1 为什么是 27B 这个规格先说为什么偏偏盯上 27B。7B 和 14B 其实消费级显卡也能轻松跑起来但复杂一点的推理链、长文档总结、带格式要求的代码生成效果能明显感到天花板72B 没得说效果好可单卡基本没戏最少也要两张 48G普通工作室和小团队根本扛不住。27B 正好卡在中间参数量足够支撑复杂的指令跟随和结构化输出部署成本又不像 72B 那样离谱。这里要提醒一句27B 只是参数量级别的粗略描述不同量化方式下显存差异非常大。我最开始直接用 FP16 权重试跑被 CUDA out of memory 当场劝退后来切到 4bit 量化才在 24G 卡上顺利跑起来。所以第一步不是急着装环境而是把显存账算明白搞清楚自己手里的卡到底能撑起什么配置。1.2 显存账本怎么算模型权重体积有一个非常简单的公式模型文件大小约等于 参数量 × 位宽 ÷ 8。27B 参数在 FP16 下就是 27 × 2 54GB光权重就把 48G 卡占满了如果跑 8bit 量化权重约 27GB4bit 量化约 14~16GB再加上量化格式的额外开销实际占用通常落在 17~19GB。这几个数字建议直接背下来后面选卡、选量化都用得上。配置权重占用可用显存要求说明FP16 原始权重约 54GB72G 级基本告别单卡 24G/48G8bitQ8_0 等约 27GB48G 级质量接近原始24G 卡放不下4bitQ4_K_M 等约 17GB24G 级消费级显卡的实际主力选择2bitQ2_K 等约 10GB12G~16G 级质量损失明显不建议做主力但权重只是第一部分。真正跑起来之后还有两块显存开销KV cache 和计算激活值。KV cache 随上下文长度线性增长以我这次部署的 27B 模型为例16K 上下文时约占 1~2GB如果开到 128K这块要预留 5GB 以上。很多人部署完发现能加载但一跑就 OOM基本都是忽略了 KV cache 这部分的占用。算完这笔账结论就很清晰24G 显存卡在 4bit 量化和中等上下文48G 可以上 8bit 和长上下文72G 基本能做到接近 FP16 的原生部署。我最终稳定的主力配置是一张 24G 卡 Q4_K_M 量化 16K 上下文日常使用很舒服另用 72G 卡验证过接近原生的精度表现。1.3 推理框架怎么选框架选型没有标准答案关键是匹配使用场景。只想本地快速跑起来验证效果Ollama 是首选一条命令就能拉起来要做成 API 服务给业务调用vLLM 的连续批处理和 PagedAttention 在并发吞吐上优势明显需要在更小显存或者 CPU 上跑llama.cpp 生态的 GGUF 量化格式最灵活。这次实践我把 Ollama 和 vLLM 两条路线都完整跑了一遍后面分开讲你可以依据自己场景直接选。2. 环境准备驱动、Python 和模型文件三件套2.1 系统与驱动基线先讲环境。我主力测试机是 24G 显存 128G 内存 Ubuntu 22.04另一台 72G 卡跑的是 OpenEuler 系统两个环境都踩过一遍。有一个经验必须提前说部署前先把 NVIDIA 驱动和 CUDA 版本确认好不要上来就装框架。nvidia-smi右上角显示的 CUDA Version 是驱动支持的上限而 PyTorch 自带 CUDA runtime两者只要匹配就行不是必须完全一致。nvidia-smi --query-gpuname,memory.total,driver_version --formatcsv python3 --versionPython 版本建议 3.10 或 3.11太老的版本装新版依赖时会很折腾。我一直习惯为部署单独建虚拟环境避免和系统 Python 打架。OpenEuler 上的坑主要是系统自带 Python 版本偏低编译依赖时需要先装开发工具包这一步在 Ubuntu 上基本不用管。2.2 模型文件从哪拿、怎么校验模型权重优先从官方仓库下载如果网络拉取速度不理想可以设置镜像环境变量再拉文件速度会快很多。下载工具我推荐使用huggingface-cli因为它自带断点续传比裸用 git lfs 在弱网环境下稳妥得多。export HF_ENDPOINThttps://hf-mirror.com huggingface-cli download Qwen/Qwen3.8-27B --local-dir ./qwen38-27b下载完别急着推理。先做两件事一是核对文件数量和大小二是用 sha256sum 校验关键分片权重。前者能发现断点续传留下的半截文件后者能发现静默损坏。我第二次部署时就漏掉了校验这一步跑到一半才知道某个分片文件损坏浪费了一整个下午。2.3 推理引擎安装Ollama 安装很简单官方脚本一条命令curl -fsSL https://ollama.com/install.sh | sh装完先用systemctl status ollama看看服务有没有正常起来。vLLM 建议在虚拟环境里独立安装pip install vllm它会顺带拉入匹配版本的 PyTorch。装完检查 CUDA 是否可用python -c import torch; print(torch.cuda.is_available(), torch.cuda.get_device_name(0))看到True和显卡型号再继续。如果这一步就挂了基本是驱动和 PyTorch 版本匹配的问题排查方向要回到显卡驱动本身而不是模型文件。3. 两条部署路线Ollama 快速体验与 vLLM 服务化3.1 Ollama 一条命令拉起先讲最省事的 Ollama 路线。终端执行ollama pull qwen3.8:27b拉完之后ollama run qwen3.8:27b就能进入对话它会根据你的显卡自动选择默认量化版本。不过自动拉取只适合快速验证真要固定配置建议自己写 Modelfile。我常用的配置是这样的FROM /data/models/qwen3.8-27b-q4_k_m.gguf PARAMETER num_gpu 99 PARAMETER num_ctx 16384 PARAMETER temperature 0.7这里num_gpu 99表示把所有层都放到 GPU 上跑如果显存紧张也可以改成 30 之类的数字把部分层留给 CPU但生成速度会明显掉一截。num_ctx就是上下文长度我特意设成 16K 而不是 32K原因就是省显存第 4 章会说。保存为 Modelfile 后执行ollama create qwen38-27b-local -f Modelfile即可。如果 Ollama 官方库还没收录对应的标签或者你想用特定量化版本也可以先下载 GGUF 文件再用 Modelfile 导入本地。这个流程很多人不会用其实只是把 FROM 路径指向本地文件就行非常简单。3.2 vLLM 服务化部署vLLM 路线适合对外提供 API 的场景。启动命令比较直观vllm serve Qwen/Qwen3.8-27B \ --tensor-parallel-size 1 \ --gpu-memory-utilization 0.9 \ --max-model-len 16384 \ --quantization awq \ --dtype half如果权重是 AWQ 格式--quantization awq会走专门优化过的算子效率和显存占用都优于通用反量化如果不指定量化格式vLLM 会当成 FP16 加载显存不够时会在启动阶段直接报错。--max-model-len一定按实际需要来设置不要盲目调大它直接影响每一批请求的 KV cache 预算也是 OOM 的高发诱因。3.3 接口与功能验证启动完成后vLLM 默认在 8000 端口起一个 OpenAI 兼容接口用 curl 就能验证curl http://localhost:8000/v1/chat/completions \ -H Content-Type: application/json \ -d {model:Qwen/Qwen3.8-27B,messages:[{role:user,content:用三句话介绍你自己}],max_tokens:128}我做的关键测试是中文长文档总结。把一篇 5000 字左右的文档塞进对话历史看模型能不能稳定输出而不是扯到一半开始复读。实测在 16K 上下文内表现稳定一旦超过设定长度就会出现明显的内容遗忘。这不是模型本身的问题而是部署参数对上下文长度的硬约束所以一定要按业务实际用量设置。4. 显存不够怎么办量化级别与上下文长度权衡4.1 量化级别该选哪一档量化是 27B 部署绕不开的话题。常见的几个级别和实际体感差异我直接整理成一张表量化级别权重大小约体感质量适用显存Q2_K10GB 级明显可感知的退化长文本容易混乱12GQ3_K_M12GB 级日常对话还行复杂推理不够稳16GQ4_K_M17GB 级质量接近原始复杂任务也能扛24GQ5_K_M19GB 级进一步减少量化误差差异细微24G~48GQ8_027GB 级几乎无损中文表现尤其稳48G 级我在同样的 20 个问题集上做过 A/B 对比Q4_K_M 和 Q5_K_M 的回答差别非常小但 Q4_K_M 比 Q5_K_M 少占约 2GB 显存。这 2GB 在 24G 卡上可能就决定了能不能开 32K 上下文。所以我的结论是24G 卡优先 Q4_K_M48G 卡直接上 Q8_0 或 8bit没必要在低档量化上纠结太多。4.2 上下文长度是隐藏的显存刺客很多人只盯着权重大小忽略了 KV cache 是随上下文长度线性增长的。还是以我这次部署的数据为例同样 Q4_K_M 量化上下文从 16K 调到 32K可用并发数和生成速度明显下降拉到 128K 后即使在 72G 卡上也会限制到非常低的并发。模型上下文能力再强部署时也要按实际业务需求来定不要盲目把max-model-len拉满。这里有一个判断技巧如果业务以 QA 和代码生成为主12K~16K 的上下文足够覆盖绝大多数场景只有长文档解析和全局代码分析才需要 32K 以上。把省下来的显存留给 batch size 和并发整体性价比会高得多。4.3 不同显存下的推荐配置结合这几天的实测我整理了三档可以直接抄作业的配置12G~16G 卡Q3_K_M 或 Q4_K_Mnum_ctx8K用 Ollama 或 llama.cpp适合个人尝鲜。24G 卡Q4_K_Mnum_ctx16K~32KvLLM 可支撑小规模 API 服务。48G~72G 卡Q8_0 或接近原生的 FP16/FP8num_ctx32K 起适合团队服务。如果你用的是 RTX Pro 5000 这类 72G 专业卡甚至可以尝试不量化直接部署原生权重那才是真正意义上的满血体验。不过要注意满血体验代价是显存占用极高多路并发时要预留好余量。5. 跑起来之后性能实测与并发调优5.1 三个关键指标首 token 延迟、吞吐和稳定性部署完成只是第一步真正上线前你得知道三件事首 token 延迟、生成吞吐和并发下的稳定性。首 token 延迟影响用户等待的体感生成吞吐tokens/s决定业务成本并发稳定性则决定能不能用于生产。我在 24G 卡 Q4_K_M 16K 上下文的环境下实测单请求首 token 延迟大约在 300~500ms连续生成速度稳定在 22~28 tokens/s换到 72G 卡用 8bit 量化速度提升到 35~45 tokens/s。这个量级对私有化工具完全可用。不过要提醒一点性能测试别用刚跑完长任务的卡来做长时间满载后的降频会带走 10% 左右的性能测出来的数据会偏悲观。5.2 并发场景下 vLLM 的优势如果只有一两个人在用Ollama 和 vLLM 的差距不明显但并发请求一上来vLLM 的连续批处理优势就非常突出。默认参数下它会把多条请求的生成阶段合并在同一次前向计算中整体吞吐能线性增长到某个点。我实测 8 并发时vLLM 的累计吞吐比 Ollama 高出大约 2 倍这也是我坚持 API 服务用 vLLM 的核心原因。并发也不是越高越好。max-num-seqs设置太高共享显存一旦不够就会 OOM设置太低又浪费算力。我的基准配置是 24G 卡上把它控制在 16 以内超过 16 之后首 token 延迟会明显恶化。建议你用压测工具逐步加压找到延迟曲线开始陡增的拐点那才是这台机器最合理的并发水位。5.3 常见的卡死和超时跑起来之后最常见的两个问题一是显卡被其他进程占了显存推理直接 OOM二是响应时间太长客户端超时。前者要靠监控及时发现后者要检查是不是并发过高导致请求排队。我的经验是给服务端设置合理的超时和重试策略比如客户端 30 秒连接超时、120 秒读超时避免调用方一直挂在那里。还有一个容易被忽略的细节如果服务器内存只有 32G而模型文件有 17G再被其他杂项进程占用大半模型加载时进程很可能被系统 OOM killer 直接杀掉。纯部署机建议内存至少 64G如果内存确实紧张至少把 swap 打开慢一点但至少不会让进程凭空消失。6. 踩坑记录OOM、下载中断与重启失联6.1 第一次 OOM 的完整排查链路第一次在这台 24G 卡上加载 Qwen 3.8 27B报错非常经典CUDA out of memory。我的排查过程是这样的先nvidia-smi确认有没有别的进程占用显存结果发现有一个残留的推理服务进程还占着 14G。把旧进程 kill 掉重新拉取模型结果还是 OOM。这时候才意识到默认加载的可能是 FP16 权重54G 显然放不进 24G必须手动切换量化版本。换成 Q4_K_M 的 GGUF 文件重新加载这次顺利启动。这个过程说明一个很基础的道理报错信息只会告诉你表面原因真实原因往往要往上追一层。如果你也遇到 OOM按残留进程 → 加载格式 → 量化级别的顺序排查基本能定位问题。6.2 下载中断导致的模型损坏第二次翻车更隐蔽。模型文件下载到一半网络断了重连后工具提示续传完成看文件大小也都对但加载到 80% 时直接报 decode error。这说明断点续传能恢复下载进度但不保证文件一定完整某个分片可能在传输过程中就静默损坏了。解决方法很简单把本地缓存清掉重新下载或者先按仓库提供的 sha256 校验值核对所有分片。我现在养成了一个习惯下载完先跑一遍sha256sum确认没问题再部署。虽然多花了半分钟但省下了很多排错时间。6.3 服务重启与命令行失联第三个坑是重启服务器后 Ollama 服务没有自动拉起或者 API 地址变了导致调用方连不上。解决方法是写一个 systemd 服务设置开机自启[Unit] DescriptionOllama Service Afternetwork.target [Service] ExecStart/home/user/bin/ollama serve Restartalways RestartSec3 EnvironmentOLLAMA_HOST0.0.0.0 EnvironmentOLLAMA_MODEL/data/models [Install] WantedBymulti-user.target把文件放到/etc/systemd/system/ollama.service执行systemctl daemon-reload systemctl enable ollama systemctl start ollama之后重启服务器服务就会自动恢复。OpenEuler 上用 systemctl 的操作方式和 Ubuntu 基本一致这个守护脚本可以直接通用。最后说点个人体会。部署 27B 这个规模的模型真正难的不是敲那几行命令而是理解每一步背后的显存和带宽账。我踩过最大的坑就是只想快点跑起来结果在错误配置上浪费的时间反而更多。如果你准备长期用建议部署完先做一套自己的性能基线固定问题集、固定并发数、记录延迟和吞吐后面再换量化或调参的时候有对照心里就有底。至于 27B 后面还能做什么我最近正在试 lora 微调让模型更贴合自己的业务语言风格等跑通了再单独写一篇分享。