连续帮几个团队把大模型从能演示搬到能上线之后我最大的感受是大模型服务器部署这门技术难点从来不在启动一个模型而在后面那一整条看不见的链路——框架选型怎么定、云服务器怎么配、生产流程怎么走。2026年这个节点模型权重的获取已经极其简单网上随便一搜就是现成的下载地址和启动命令但真正把部署做成生产级的团队仍然少得可怜。这篇文章我按自己的实战经验把推理框架选型、云服务对比、生产级部署流程一次性讲透适合准备把模型从实验室拉上线的同学也适合正在做选型评估的技术负责人参考。1. 为什么2026年的部署逻辑变了从跑通到抗住的分水岭先说一个判断2026年的部署场景和两三年前完全不是一回事。两三年前大家关心的是这个模型能不能在单卡上跑起来跑通就算胜利现在的标配讨论是同时能扛多少并发、单token延迟多少、上下文多长、GPU利用率能到多少、成本符合预期吗。这背后是模型形态的变化——7B到70B的跨度MoE结构、超长上下文、多模态任务开始成为常态部署的复杂度也随之跨越了一个量级。1.1 Demo环境与生产环境的真实差距我们内部曾经用一台自带4090的机器跑开源7B做演示效果不错。后来团队内部开始真用三个人同时提问就明显感觉到排队。等到要接外部用户时连最基础的可靠性问题都压不过去API超时、缓存撑不住、显存涨到不能释放。这就是我觉得必须区分开的两类目标。Demo环境里单并发、短上下文、可以接受失败重试生产环境里多并发、长会话、要求可观测、可回滚、可扩容。你在选型阶段如果只按Demo的模型来决策后面基本要推倒重来。我见过不止一个团队先买了最高配的卡然后把模型一装发现并发能力远低于预期最后回头改量化、改框架、改架构折腾一圈成本翻倍。所以部署这件事第一步不是下载模型而是先想清楚你要服务谁、服务多少人、接受多高的延迟。需求目标不清晰后续所有选型都是碰运气。1.2 部署对象的改变从一个模型变成一条链路现在的大模型部署早已不是启动一个HTTP服务那么简单。一个稍微像样的系统至少要包含模型推理服务、API网关、鉴权、限流、监控、日志以及更上层的数据处理和Agent编排。模型推理只是最核心的一块但它是整个系统的发动机。框架选型选得好后面所有环节都会顺手选得不好后面全是补救。举个实际例子我们有个业务场景是文档问答用户上传长文档后要连续追问多轮。这种场景对前缀缓存、上下文管理的要求特别高普通部署方式每个请求都从头算一遍历史显存和延迟都扛不住。同样是跑一个7B模型选的框架不同最终体验能差出去好几倍。1.3 2026年的三个关键变量第一个变量开源模型能力已经抬到相当高的水准。Qwen系列、Llama系列、DeepSeek系列在不少任务上和商业API差距不大自己部署的性价比明显提升。第二个变量云GPU供给比前两年宽松国内外厂商都有大量按量、竞价、包年实例可以选择门槛降下来了。第三个变量推理框架的成熟度完全不同了vLLM这类项目已经成为事实标准曾经需要自己写批处理、手动管理显存的工作现在框架已经替你解决。这三个变量合在一起导致一个结果选型决策变成了主要矛盾。卡和模型都有选错框架、选错云厂商、选错部署姿势成本差好几倍。后面几个部分我就沿着这三件事往下拆。2. 推理框架选型先看性格再看热度框架选型是整个部署流程里最容易被低估的一环。很多人看着GitHub Star数选框架哪个火用哪个结果发现自己的场景根本不在那个框架的优势区间里。我按自己真实用下来的经验先把主流框架的性格差异说清楚。2.1 五个主流框架的实际体验vLLM是万金油。PagedAttention加continuous batching这套组合让它在绝大多数场景下都有漂亮的吞吐表现而且API接口直接兼容OpenAI接入成本极低。SGLang的思路是共享前缀和结构化输出对长上下文、多轮对话、Agent这类场景非常有利前缀命中时延迟优势明显。TensorRT-LLM是NVIDIA官方的东西性能优化空间最大但需要你把模型构建成engine构建过程慢迭代也不如前两个灵活。LMDeploy对国产硬件生态做得不错昇腾、寒武纪这些都能跑团队如果有多样化硬件需求会省心很多。Ollama则完全是另一条路线它定位在人人可跑GGUF格式加一键安装个人电脑、内网小团队用起来最舒服但高并发和生产级控制力偏弱。框架核心卖点适合场景上手难度备注vLLM高吞吐、OpenAI兼容对外API、标准推理低生态最活跃迭代快SGLang前缀共享、结构化输出长上下文、Agent、多轮中和LMCache组合更佳TensorRT-LLMNVIDIA官方深度优化固定模型、极致性能高engine构建耗时LMDeploy国产硬件适配广信创、多硬件中支持多卡自动切分Ollama一键装、本地友好个人、小内网很低高并发控制偏弱这里需要说明表格里列出来的适合场景只是我自己的经验值。你完全可以在Ollama外面套一层高并发网关也没问题只是控制力不如在推理框架层面做来得直接。2.2 我的场景选择逻辑如果让我给团队一个默认方案没有特殊要求先用vLLM跑起来它是容错率最高的选择。具体到不同情况我的选择大概是这样的。对外提供API产品vLLM默认长文档问答、工具调用密集的Agent应用优先SGLang需要极致压榨GPU、模型长期固定不变再考虑TensorRT-LLM公司有国产卡或者要过信创LMDeploy个人机器或者小团队内部工具Ollama就够了别上重框架。我用vLLM跑过7B和70B两种规模的模型也在SGLang上跑过Agent场景两者的吞吐表现都不错但SGLang在长对话前缀复用时确实更省显存。如果你的业务里每条请求都带一大段相同的系统提示或者历史上下文SGLang的优势是会直接体现在账单上的。2.3 选型时的三个决策依据第一是卡型。CUDA生态下的框架选择最自由但昇腾这些卡就得看框架对硬件的适配程度能跑和跑得好是两回事选型前先查Supported Hardware列表。第二是并发和延迟指标。如果目标是单用户低延迟很多框架都行如果目标是一卡同时服务几十个请求vLLM、SGLang这类专门优化的框架优势就很明显。第三是社区迭代速度。部署这件事劝你别押宝在冷门但性能好的框架上因为大模型领域变化太快框架停更意味着安全问题、新模型适配问题都会砸到你头上。vLLM活跃度高SGLang有LMSYS背书选择有明显生态的框架后续团队招人也好上手。3. 云服务选型GPU实例参数、厂商对比与预算策略框架定了接下来就是卡从哪来。自己做服务器还是买云服务这个选择在2026年已经不太需要犹豫主流团队基本都是上云最多留一台本地机器做开发和临时测试。原因是云GPU的规格选择、灵活性和整体成本已经明显优于自建。但云上的坑也不少最典型的就是不会看实例参数和计费模式。3.1 GPU实例核心参数解读选云服务器先别急着比价格把下面几个参数看懂。显存是第一约束模型能不能放进去看它同时放多少并发也看它。算力看FP16和FP8的TFLOPS但实际吞吐更重要的是框架和内存带宽。网络带宽在多卡并行时是命门8卡机器如果互联带宽不足数据同步会拖慢训练和长上下文推理。存储方面模型文件动不动几十GB建议单独挂一块高速数据盘别和系统盘抢。给出一个我自己常用的显存估算公式模型权重显存约等于参数量乘以每参数字节数再乘以1.2到1.3的余量给CUDA上下文和激活值除此之外还要预留KV cache空间或者把KV cache上限明确设给框架。举几个具体例子。7B模型BF16权重约14GB总显存建议32GB7B用INT4量化后权重约4到5GB16GB卡可以轻松跑。70B模型BF16权重约140GB需要2张80GB卡或者4张40GB卡70B用AWQ INT4量化后约40GB单张80GB的A100、H100、H20就能服务。这段计算一定要自己做一遍因为很多关于多少卡能跑多少B模型的说法已经过时了量化成熟后同尺寸模型的显存需求能差出3到4倍。3.2 主流云厂商与实例横向对比国内我接触最多的是阿里云和腾讯云。阿里云的优势是GPU型号全、PAI-EAS托管平台对部署友好T4、A10、A100、H20、H100都有竞价实例的价格能压得很低。腾讯云在8卡A100、A800这类大规格实例上资源比较充足配合TI-ONE做深度学习训练推理也更顺手。华为云如果用的是昇腾生态910B配合MindIE做推理性能完全不弱尤其是推理场景的性价比有时比NVIDIA卡还香但迁移成本要想清楚。海外方面AWS的p4d、p5系列是全球用得最多的按秒计费灵活Azure和OpenAI绑定深如果团队同时用微软系产品会很顺。云厂商代表实例显存/规格计费方式适合场景阿里云ECS GPU实例、PAI-EASA10、A100、H20、H100可选按量、竞价、包年标准推理、微调腾讯云GPU计算型GN系列、TI-ONEA100、A800等包周、包月、竞价训练与大模型微调华为云昇腾云服务昇腾910B等包年、按量信创环境、推理AWSp4d.24xlarge、p5.48xlarge8×A100 40GB、8×H100 80GB按秒全球化部署、大规模训练AzureNC A100 v4、ND H100 v5A100、H100按量微软生态、OpenAI系表格里没有写死价格因为GPU价格变化太快而且不同地域差很多。我的建议是别只看单价把迁移成本、生态集成、运维复杂度一起算进去综合成本往往比单价更重要。比如某些云厂商的GPU按量单价看着便宜但跨地域流量费、快照费、网络负载均衡费用加起来一个月下来可能比贵一点的包月还花得多。3.3 计费模式与省钱组合拳三种计费模式我实际都踩过。包年包月适合长期稳定负载比如一个模型服务固定跑三个月以上按量付费适合验证和临时任务开机测试一下框架、跑个压测用完关机竞价实例是真便宜但有可能随时被回收所以只适合无状态或者能自动恢复的任务。省钱组合拳我常用的核心服务用包月保底弹性扩容任务挂竞价实例配合镜像和模型数据持久化即使被回收也能在两三分钟内重新拉起。另外冷启动时间很关键容器镜像里把模型路径和依赖都准备好不要每次启动现场下权重。我见过一个团队每次扩容都要花半小时重新下载模型扩了个寂寞。4. 生产级部署流程从权重文件到可运维服务接下来是一套我自己跑过几十次的固定流程。顺序很重要别跳步也别偷懒。4.1 模型选型与权重准备部署第一步是把模型文件拿到手这一步看着简单坑也不少。开源模型首选HuggingFace和ModelScope国内团队强烈建议用ModelScope下载速度快得多。# ModelScope 下载 modelscope download --model Qwen/Qwen2.5-7B-Instruct --local_dir ./models/qwen7b # 或者用 huggingface-cli huggingface-cli download Qwen/Qwen2.5-7B-Instruct --local-dir ./models/qwen7b下下来的模型可能是safetensors格式也可能是GGUF。safetensors是推理框架最通用的格式GGUF则主要给Ollama这类工具用。另外一定要确认模型的license尤其商用场景有些模型限制商用或者衍生发布这个只能自己看协议。我建议在项目启动时就建一个模型清单记录模型版本、来源、格式、License、量化状态后面所有流程都跟着这个清单走。4.2 量化方案精度、显存、速度怎么取量化是生产部署绕不开的一环尤其当你想用更小的显存扛更大的模型。我在生产环境用下来最主流的三个方向是FP8、AWQ和GPTQ。方案精度显存占用速度特点适用场景原生BF16/FP16最高参数量×2字节带宽压力大显存充足、精度敏感FP8高参数量×1字节显存减半H100最佳高端卡、高吞吐AWQ INT4较高参数量×0.5字节以上速度快、显存友好性价比首选GPTQ INT4较高参数量×0.5字节以上老牌成熟兼容性广GGUF Q4中高同上本地友好Ollama、个人部署具体选哪种看卡。如果你有H100、A100FP8是首选训练和推理都能受益如果是消费级显卡或者想压成本AWQ和GPTQ都很成熟AWQ对推理加速效果更好一些。千万不要为了省显存盲目量化到2bit精度损失一旦在业务里暴露代价远大于省下的那点GPU钱。4.3 框架部署与API封装以vLLM为例跑一个7B模型服务最小启动命令是这样的vllm serve Qwen/Qwen2.5-7B-Instruct \ --host 0.0.0.0 \ --port 8000 \ --gpu-memory-utilization 0.9 \ --max-model-len 32768 \ --served-model-name qwen7b \ --api-key sk-prod-xxx--gpu-memory-utilization这个参数要特别说下默认值0.9意味着给GPU保留10%显存做CUDA context和临时计算。如果你的模型很满可以把0.9调低一点留出更多KV cache空间给并发。--max-model-len决定了最长上下文设得越大KV cache占用越多并发能力反而下降需要根据业务实际权衡。启动后验证接口curl http://127.0.0.1:8000/v1/chat/completions \ -H Authorization: Bearer sk-prod-xxx \ -H Content-Type: application/json \ -d {model:qwen7b,messages:[{role:user,content:你好}],max_tokens:1024}生产环境下我建议用systemd或Kubernetes管理这个进程而不是简单nohup。因为模型服务一旦异常退出需要自动拉起、健康检查、滚动更新这些只有进程管理器才能给。4.4 压测上线前自己先打一顿我从来不敢把没压测过的模型服务直接给业务用。压测至少要拿到三个数字TTFT首token延迟、TPOT每token生成耗时、整体吞吐每秒token数。并发从1、4、8、16逐级往上打观察显存占用和延迟曲线如果并发加到某个值后延迟突然飙升说明已经超过KV cache的承受能力。一个小建议压测脚本不要用那种只发一个短提问的要混合长上下文、多轮对话、超长max_tokens否则很容易上线后被真实流量打穿。我们曾经用一条只有20个token的短问题压测一切正常上线后用户上传了几千字的文档服务直接超时。4.5 监控、告警与模型更新监控层面GPU利用率、显存占用、GPU温度这些用DCGM exporter加Prometheus就能采集模型服务自身的TTFT、TPOT、请求量则通过vLLM的metrics接口直接暴露。告警至少要覆盖四类显存快满、GPU利用率长时间为0但服务还在、请求失败率上升、延迟超阈值。模型更新是目前大模型部署里很常见的需求。现在团队普遍采用LoRA做微调生产上可以用vLLM的LoRA动态加载能力直接挂一个新的LoRA adapter而不动基座模型切换成本很低。微调工具链现在也很成熟LLaMA-Factory这类工具可以一站式完成数据处理、训练、导出导出后的模型直接丢给vLLM跑省掉很多格式转换的麻烦。我建议把base模型、微调数据集、LoRA权重、推理框架版本四项都纳入版本管理每次发版记录对应的Commit出问题能快速回滚。5. 几乎每个团队都会踩的五个部署坑流程说完了最后分享几个踩坑记录。这些坑不会写在官方文档里但几乎每个把模型搬到生产环境的人都会遇到。5.1 显存看着够一上并发就OOM这个坑我踩了不止一次。模型权重只占一部分显存KV cache才是吃显存的大户而且它随着并发和上下文长度动态增长。解决办法是把gpu-memory-utilization调保守一点或者明确设置KV cache上限再或者限制每请求最大输入长度。上线前用渐进式并发压测把显存曲线拉出来比事后看报错强一百倍。5.2 冷启动导致首请求超时大模型服务的加载很慢大一点的模型光加载权重就要一两分钟如果前面挂了负载均衡健康检查不通过就会把请求分到别的节点或者直接超时。我的做法是启动后先发一个确定性的预热请求把权重和CUDA kernel全部加载完再标记为健康。这个预热请求很便宜但能避免大部分首请求超时问题。5.3 磁盘和临时文件位置下载模型、解压模型、存日志都在抢同一块盘。模型文件放机械盘或网络盘上首次加载可能慢到离谱。实践上是单独配一块NVMe数据盘放模型镜像里不要塞模型文件否则每次发布都会重新拖文件。另外日志也要留意大模型服务的访问日志量很大不加轮转的话一张盘几天就能被打满。5.4 API安全暴露风险公网暴露的大模型服务常见问题是默认没有鉴权就裸奔然后被人扫到疯狂调用。哪怕只是内网服务我建议也加上API key或者网关层面的鉴权同时做好限流。内容安全方面生产服务要配套内容审核你不想自己的模型生成违规内容后再去救火。还有一个容易忽略的点不要让模型服务直接面对不可信网络而是通过网关转发这样还可以方便地做请求日志、审计和问题复现。5.5 微调模型与基座之间的版本管理团队开始微调之后经常出现跑得好好的微调模型换上去后效果不对劲的问题。这类问题排查起来特别费劲因为很难判断是数据变了、权重变了还是推理框架版本变了。建议把base模型、微调数据集、LoRA权重、推理框架版本四项都纳入版本管理每次发版记录对应的Commit出问题能快速回滚。最后说点个人体会。部署大模型这件事真正难的不是技术本身的深度而是它在2026年已经变成一项系统工程。你既要有扎实的工程能力又要对各种新框架、新卡型保持敏感。我的习惯是所有选型决策都要落在能不能用半年以上这个标准上热门框架优先、成熟方案优先、可运维优先。如果你正准备把自己的模型服务搬上生产我的建议是先从小规格跑通全链路再逐步加并发、加监控、加弹性别一上来就追求配置拉满。很多团队最后翻车不是模型不行而是部署的姿势有问题。 
长河君 · 2026/9/30 5:22:16 · 阅读 1.2k 大模型生产级部署实战：框架选型、云服务与全流程指南
连续帮几个团队把大模型从能演示搬到能上线之后我最大的感受是大模型服务器部署这门技术难点从来不在启动一个模型而在后面那一整条看不见的链路——框架选型怎么定、云服务器怎么配、生产流程怎么走。2026年这个节点模型权重的获取已经极其简单网上随便一搜就是现成的下载地址和启动命令但真正把部署做成生产级的团队仍然少得可怜。这篇文章我按自己的实战经验把推理框架选型、云服务对比、生产级部署流程一次性讲透适合准备把模型从实验室拉上线的同学也适合正在做选型评估的技术负责人参考。1. 为什么2026年的部署逻辑变了从跑通到抗住的分水岭先说一个判断2026年的部署场景和两三年前完全不是一回事。两三年前大家关心的是这个模型能不能在单卡上跑起来跑通就算胜利现在的标配讨论是同时能扛多少并发、单token延迟多少、上下文多长、GPU利用率能到多少、成本符合预期吗。这背后是模型形态的变化——7B到70B的跨度MoE结构、超长上下文、多模态任务开始成为常态部署的复杂度也随之跨越了一个量级。1.1 Demo环境与生产环境的真实差距我们内部曾经用一台自带4090的机器跑开源7B做演示效果不错。后来团队内部开始真用三个人同时提问就明显感觉到排队。等到要接外部用户时连最基础的可靠性问题都压不过去API超时、缓存撑不住、显存涨到不能释放。这就是我觉得必须区分开的两类目标。Demo环境里单并发、短上下文、可以接受失败重试生产环境里多并发、长会话、要求可观测、可回滚、可扩容。你在选型阶段如果只按Demo的模型来决策后面基本要推倒重来。我见过不止一个团队先买了最高配的卡然后把模型一装发现并发能力远低于预期最后回头改量化、改框架、改架构折腾一圈成本翻倍。所以部署这件事第一步不是下载模型而是先想清楚你要服务谁、服务多少人、接受多高的延迟。需求目标不清晰后续所有选型都是碰运气。1.2 部署对象的改变从一个模型变成一条链路现在的大模型部署早已不是启动一个HTTP服务那么简单。一个稍微像样的系统至少要包含模型推理服务、API网关、鉴权、限流、监控、日志以及更上层的数据处理和Agent编排。模型推理只是最核心的一块但它是整个系统的发动机。框架选型选得好后面所有环节都会顺手选得不好后面全是补救。举个实际例子我们有个业务场景是文档问答用户上传长文档后要连续追问多轮。这种场景对前缀缓存、上下文管理的要求特别高普通部署方式每个请求都从头算一遍历史显存和延迟都扛不住。同样是跑一个7B模型选的框架不同最终体验能差出去好几倍。1.3 2026年的三个关键变量第一个变量开源模型能力已经抬到相当高的水准。Qwen系列、Llama系列、DeepSeek系列在不少任务上和商业API差距不大自己部署的性价比明显提升。第二个变量云GPU供给比前两年宽松国内外厂商都有大量按量、竞价、包年实例可以选择门槛降下来了。第三个变量推理框架的成熟度完全不同了vLLM这类项目已经成为事实标准曾经需要自己写批处理、手动管理显存的工作现在框架已经替你解决。这三个变量合在一起导致一个结果选型决策变成了主要矛盾。卡和模型都有选错框架、选错云厂商、选错部署姿势成本差好几倍。后面几个部分我就沿着这三件事往下拆。2. 推理框架选型先看性格再看热度框架选型是整个部署流程里最容易被低估的一环。很多人看着GitHub Star数选框架哪个火用哪个结果发现自己的场景根本不在那个框架的优势区间里。我按自己真实用下来的经验先把主流框架的性格差异说清楚。2.1 五个主流框架的实际体验vLLM是万金油。PagedAttention加continuous batching这套组合让它在绝大多数场景下都有漂亮的吞吐表现而且API接口直接兼容OpenAI接入成本极低。SGLang的思路是共享前缀和结构化输出对长上下文、多轮对话、Agent这类场景非常有利前缀命中时延迟优势明显。TensorRT-LLM是NVIDIA官方的东西性能优化空间最大但需要你把模型构建成engine构建过程慢迭代也不如前两个灵活。LMDeploy对国产硬件生态做得不错昇腾、寒武纪这些都能跑团队如果有多样化硬件需求会省心很多。Ollama则完全是另一条路线它定位在人人可跑GGUF格式加一键安装个人电脑、内网小团队用起来最舒服但高并发和生产级控制力偏弱。框架核心卖点适合场景上手难度备注vLLM高吞吐、OpenAI兼容对外API、标准推理低生态最活跃迭代快SGLang前缀共享、结构化输出长上下文、Agent、多轮中和LMCache组合更佳TensorRT-LLMNVIDIA官方深度优化固定模型、极致性能高engine构建耗时LMDeploy国产硬件适配广信创、多硬件中支持多卡自动切分Ollama一键装、本地友好个人、小内网很低高并发控制偏弱这里需要说明表格里列出来的适合场景只是我自己的经验值。你完全可以在Ollama外面套一层高并发网关也没问题只是控制力不如在推理框架层面做来得直接。2.2 我的场景选择逻辑如果让我给团队一个默认方案没有特殊要求先用vLLM跑起来它是容错率最高的选择。具体到不同情况我的选择大概是这样的。对外提供API产品vLLM默认长文档问答、工具调用密集的Agent应用优先SGLang需要极致压榨GPU、模型长期固定不变再考虑TensorRT-LLM公司有国产卡或者要过信创LMDeploy个人机器或者小团队内部工具Ollama就够了别上重框架。我用vLLM跑过7B和70B两种规模的模型也在SGLang上跑过Agent场景两者的吞吐表现都不错但SGLang在长对话前缀复用时确实更省显存。如果你的业务里每条请求都带一大段相同的系统提示或者历史上下文SGLang的优势是会直接体现在账单上的。2.3 选型时的三个决策依据第一是卡型。CUDA生态下的框架选择最自由但昇腾这些卡就得看框架对硬件的适配程度能跑和跑得好是两回事选型前先查Supported Hardware列表。第二是并发和延迟指标。如果目标是单用户低延迟很多框架都行如果目标是一卡同时服务几十个请求vLLM、SGLang这类专门优化的框架优势就很明显。第三是社区迭代速度。部署这件事劝你别押宝在冷门但性能好的框架上因为大模型领域变化太快框架停更意味着安全问题、新模型适配问题都会砸到你头上。vLLM活跃度高SGLang有LMSYS背书选择有明显生态的框架后续团队招人也好上手。3. 云服务选型GPU实例参数、厂商对比与预算策略框架定了接下来就是卡从哪来。自己做服务器还是买云服务这个选择在2026年已经不太需要犹豫主流团队基本都是上云最多留一台本地机器做开发和临时测试。原因是云GPU的规格选择、灵活性和整体成本已经明显优于自建。但云上的坑也不少最典型的就是不会看实例参数和计费模式。3.1 GPU实例核心参数解读选云服务器先别急着比价格把下面几个参数看懂。显存是第一约束模型能不能放进去看它同时放多少并发也看它。算力看FP16和FP8的TFLOPS但实际吞吐更重要的是框架和内存带宽。网络带宽在多卡并行时是命门8卡机器如果互联带宽不足数据同步会拖慢训练和长上下文推理。存储方面模型文件动不动几十GB建议单独挂一块高速数据盘别和系统盘抢。给出一个我自己常用的显存估算公式模型权重显存约等于参数量乘以每参数字节数再乘以1.2到1.3的余量给CUDA上下文和激活值除此之外还要预留KV cache空间或者把KV cache上限明确设给框架。举几个具体例子。7B模型BF16权重约14GB总显存建议32GB7B用INT4量化后权重约4到5GB16GB卡可以轻松跑。70B模型BF16权重约140GB需要2张80GB卡或者4张40GB卡70B用AWQ INT4量化后约40GB单张80GB的A100、H100、H20就能服务。这段计算一定要自己做一遍因为很多关于多少卡能跑多少B模型的说法已经过时了量化成熟后同尺寸模型的显存需求能差出3到4倍。3.2 主流云厂商与实例横向对比国内我接触最多的是阿里云和腾讯云。阿里云的优势是GPU型号全、PAI-EAS托管平台对部署友好T4、A10、A100、H20、H100都有竞价实例的价格能压得很低。腾讯云在8卡A100、A800这类大规格实例上资源比较充足配合TI-ONE做深度学习训练推理也更顺手。华为云如果用的是昇腾生态910B配合MindIE做推理性能完全不弱尤其是推理场景的性价比有时比NVIDIA卡还香但迁移成本要想清楚。海外方面AWS的p4d、p5系列是全球用得最多的按秒计费灵活Azure和OpenAI绑定深如果团队同时用微软系产品会很顺。云厂商代表实例显存/规格计费方式适合场景阿里云ECS GPU实例、PAI-EASA10、A100、H20、H100可选按量、竞价、包年标准推理、微调腾讯云GPU计算型GN系列、TI-ONEA100、A800等包周、包月、竞价训练与大模型微调华为云昇腾云服务昇腾910B等包年、按量信创环境、推理AWSp4d.24xlarge、p5.48xlarge8×A100 40GB、8×H100 80GB按秒全球化部署、大规模训练AzureNC A100 v4、ND H100 v5A100、H100按量微软生态、OpenAI系表格里没有写死价格因为GPU价格变化太快而且不同地域差很多。我的建议是别只看单价把迁移成本、生态集成、运维复杂度一起算进去综合成本往往比单价更重要。比如某些云厂商的GPU按量单价看着便宜但跨地域流量费、快照费、网络负载均衡费用加起来一个月下来可能比贵一点的包月还花得多。3.3 计费模式与省钱组合拳三种计费模式我实际都踩过。包年包月适合长期稳定负载比如一个模型服务固定跑三个月以上按量付费适合验证和临时任务开机测试一下框架、跑个压测用完关机竞价实例是真便宜但有可能随时被回收所以只适合无状态或者能自动恢复的任务。省钱组合拳我常用的核心服务用包月保底弹性扩容任务挂竞价实例配合镜像和模型数据持久化即使被回收也能在两三分钟内重新拉起。另外冷启动时间很关键容器镜像里把模型路径和依赖都准备好不要每次启动现场下权重。我见过一个团队每次扩容都要花半小时重新下载模型扩了个寂寞。4. 生产级部署流程从权重文件到可运维服务接下来是一套我自己跑过几十次的固定流程。顺序很重要别跳步也别偷懒。4.1 模型选型与权重准备部署第一步是把模型文件拿到手这一步看着简单坑也不少。开源模型首选HuggingFace和ModelScope国内团队强烈建议用ModelScope下载速度快得多。# ModelScope 下载 modelscope download --model Qwen/Qwen2.5-7B-Instruct --local_dir ./models/qwen7b # 或者用 huggingface-cli huggingface-cli download Qwen/Qwen2.5-7B-Instruct --local-dir ./models/qwen7b下下来的模型可能是safetensors格式也可能是GGUF。safetensors是推理框架最通用的格式GGUF则主要给Ollama这类工具用。另外一定要确认模型的license尤其商用场景有些模型限制商用或者衍生发布这个只能自己看协议。我建议在项目启动时就建一个模型清单记录模型版本、来源、格式、License、量化状态后面所有流程都跟着这个清单走。4.2 量化方案精度、显存、速度怎么取量化是生产部署绕不开的一环尤其当你想用更小的显存扛更大的模型。我在生产环境用下来最主流的三个方向是FP8、AWQ和GPTQ。方案精度显存占用速度特点适用场景原生BF16/FP16最高参数量×2字节带宽压力大显存充足、精度敏感FP8高参数量×1字节显存减半H100最佳高端卡、高吞吐AWQ INT4较高参数量×0.5字节以上速度快、显存友好性价比首选GPTQ INT4较高参数量×0.5字节以上老牌成熟兼容性广GGUF Q4中高同上本地友好Ollama、个人部署具体选哪种看卡。如果你有H100、A100FP8是首选训练和推理都能受益如果是消费级显卡或者想压成本AWQ和GPTQ都很成熟AWQ对推理加速效果更好一些。千万不要为了省显存盲目量化到2bit精度损失一旦在业务里暴露代价远大于省下的那点GPU钱。4.3 框架部署与API封装以vLLM为例跑一个7B模型服务最小启动命令是这样的vllm serve Qwen/Qwen2.5-7B-Instruct \ --host 0.0.0.0 \ --port 8000 \ --gpu-memory-utilization 0.9 \ --max-model-len 32768 \ --served-model-name qwen7b \ --api-key sk-prod-xxx--gpu-memory-utilization这个参数要特别说下默认值0.9意味着给GPU保留10%显存做CUDA context和临时计算。如果你的模型很满可以把0.9调低一点留出更多KV cache空间给并发。--max-model-len决定了最长上下文设得越大KV cache占用越多并发能力反而下降需要根据业务实际权衡。启动后验证接口curl http://127.0.0.1:8000/v1/chat/completions \ -H Authorization: Bearer sk-prod-xxx \ -H Content-Type: application/json \ -d {model:qwen7b,messages:[{role:user,content:你好}],max_tokens:1024}生产环境下我建议用systemd或Kubernetes管理这个进程而不是简单nohup。因为模型服务一旦异常退出需要自动拉起、健康检查、滚动更新这些只有进程管理器才能给。4.4 压测上线前自己先打一顿我从来不敢把没压测过的模型服务直接给业务用。压测至少要拿到三个数字TTFT首token延迟、TPOT每token生成耗时、整体吞吐每秒token数。并发从1、4、8、16逐级往上打观察显存占用和延迟曲线如果并发加到某个值后延迟突然飙升说明已经超过KV cache的承受能力。一个小建议压测脚本不要用那种只发一个短提问的要混合长上下文、多轮对话、超长max_tokens否则很容易上线后被真实流量打穿。我们曾经用一条只有20个token的短问题压测一切正常上线后用户上传了几千字的文档服务直接超时。4.5 监控、告警与模型更新监控层面GPU利用率、显存占用、GPU温度这些用DCGM exporter加Prometheus就能采集模型服务自身的TTFT、TPOT、请求量则通过vLLM的metrics接口直接暴露。告警至少要覆盖四类显存快满、GPU利用率长时间为0但服务还在、请求失败率上升、延迟超阈值。模型更新是目前大模型部署里很常见的需求。现在团队普遍采用LoRA做微调生产上可以用vLLM的LoRA动态加载能力直接挂一个新的LoRA adapter而不动基座模型切换成本很低。微调工具链现在也很成熟LLaMA-Factory这类工具可以一站式完成数据处理、训练、导出导出后的模型直接丢给vLLM跑省掉很多格式转换的麻烦。我建议把base模型、微调数据集、LoRA权重、推理框架版本四项都纳入版本管理每次发版记录对应的Commit出问题能快速回滚。5. 几乎每个团队都会踩的五个部署坑流程说完了最后分享几个踩坑记录。这些坑不会写在官方文档里但几乎每个把模型搬到生产环境的人都会遇到。5.1 显存看着够一上并发就OOM这个坑我踩了不止一次。模型权重只占一部分显存KV cache才是吃显存的大户而且它随着并发和上下文长度动态增长。解决办法是把gpu-memory-utilization调保守一点或者明确设置KV cache上限再或者限制每请求最大输入长度。上线前用渐进式并发压测把显存曲线拉出来比事后看报错强一百倍。5.2 冷启动导致首请求超时大模型服务的加载很慢大一点的模型光加载权重就要一两分钟如果前面挂了负载均衡健康检查不通过就会把请求分到别的节点或者直接超时。我的做法是启动后先发一个确定性的预热请求把权重和CUDA kernel全部加载完再标记为健康。这个预热请求很便宜但能避免大部分首请求超时问题。5.3 磁盘和临时文件位置下载模型、解压模型、存日志都在抢同一块盘。模型文件放机械盘或网络盘上首次加载可能慢到离谱。实践上是单独配一块NVMe数据盘放模型镜像里不要塞模型文件否则每次发布都会重新拖文件。另外日志也要留意大模型服务的访问日志量很大不加轮转的话一张盘几天就能被打满。5.4 API安全暴露风险公网暴露的大模型服务常见问题是默认没有鉴权就裸奔然后被人扫到疯狂调用。哪怕只是内网服务我建议也加上API key或者网关层面的鉴权同时做好限流。内容安全方面生产服务要配套内容审核你不想自己的模型生成违规内容后再去救火。还有一个容易忽略的点不要让模型服务直接面对不可信网络而是通过网关转发这样还可以方便地做请求日志、审计和问题复现。5.5 微调模型与基座之间的版本管理团队开始微调之后经常出现跑得好好的微调模型换上去后效果不对劲的问题。这类问题排查起来特别费劲因为很难判断是数据变了、权重变了还是推理框架版本变了。建议把base模型、微调数据集、LoRA权重、推理框架版本四项都纳入版本管理每次发版记录对应的Commit出问题能快速回滚。最后说点个人体会。部署大模型这件事真正难的不是技术本身的深度而是它在2026年已经变成一项系统工程。你既要有扎实的工程能力又要对各种新框架、新卡型保持敏感。我的习惯是所有选型决策都要落在能不能用半年以上这个标准上热门框架优先、成熟方案优先、可运维优先。如果你正准备把自己的模型服务搬上生产我的建议是先从小规格跑通全链路再逐步加并发、加监控、加弹性别一上来就追求配置拉满。很多团队最后翻车不是模型不行而是部署的姿势有问题。