2026年年初我接手了一个把7B参数大模型从开发机推到生产环境的任务。团队里最先提的方案是“先装个Ollama跑起来”——这确实是当下最常见的思路但当我问出“预计日均调用多少次”“首Token响应要控制在多少毫秒”“数据能不能出内网”这三个问题时会议室安静了。大模型服务器部署从来不是把模型文件拷到服务器上、敲一条启动命令那么简单。框架选型、云服务形态、生产级流程每一步背后都是成本和稳定性之间的取舍。这篇指南就是我跑完一整套流程之后把踩过的坑和验证过的方案整理出来的完整记录适合准备把大模型真正跑上线、而不是只停留在Demo阶段的团队参考。1. 2026年部署大模型先回答三个决定架构的问题1.1 业务形态是“管道组件”还是“面向用户的API”很多人一上来就比框架、比显存但我建议先想清楚一个问题这个模型在你系统里到底扮演什么角色如果它只是RAG流水线里的一个底层组件输入是固定的文档片段输出要喂给下游解析引擎那么你的核心诉求是“低延迟高稳定性”并发不需要太高但每次调用都不能超时。这时候框架选型要偏向vLLM这类调度成熟、可精确控制显存和并发参数的方案。如果它是直接面向终端用户的API比如一个对话助手那你还要考虑鉴权、限流、多租户隔离、按流量计费这些事。模型服务本身只是最内层的一个节点外面需要套网关、套监控、套日志链路。如果它只是给团队内部用的提效工具比如写代码辅助、内部知识库问答那Ollama可能就够用了。一台24GB显存的机器拉一个14B量化模型配好OLLAMA_NUM_PARALLEL并发参数内部几十个人用完全没问题。没必要为了这种场景上一套K8s。1.2 流量模型与上下文分布决定显存和调度参数第二个问题是流量模型。我见过一个团队直接把max-model-len设到32768以为“越大越先进”结果压测时一上来就把显存吃穿服务直接OOM。你要先搞清楚你们业务的上下文分布是平均几千token的短问答还是动不动几万token的长文档分析KV cache占用的显存是随着token数线性增长的计算公式大概是KV cache显存 ≈ 2 × 模型层数 × KV头数 × 头维度 × 序列长度 × 字节数以7B模型为例32层、32个KV头、头维度128、FP16精度每元素2字节每个token大约占用2 × 32 × 32 × 128 × 2 524,288 字节 ≈ 0.5 MB也就是说支持4096 token上下文理论KV cache要预留约2GB显存。如果max-model-len设成32768那就是16GB。一个7B模型权重本身才14GB左右你直接给KV cache留16GB单卡24GB根本装不下。所以部署之前一定要拉一份真实的请求日志统计上下文长度分布再决定max-model-len和显存比例。没有日志的就先按平均长度的2倍估算留出缓冲。1.3 数据边界与合规能不能用云GPU要不要私有化第三个问题最容易被技术团队忽略数据能不能出内网。大模型服务有个特殊性——你喂进去的每一段prompt和拿回来的generated text都会经过模型厂商的推理链路。如果你们的业务涉及客户合同、员工信息、未公开的财务数据或者有合同明文约定数据不能出内网的场景那“公有云上按量调用”这条路就被堵死了。这时候要么选私有化部署要么选云厂商提供的专属节点/托管专区。这一步不是技术选型是商务和合规选型。我建议在项目启动时就让法务或业务负责人签字确认数据边界否则等你把服务部署到公有云上再被安全审计拦下来返工成本非常高。2. 推理框架选型vLLM、Ollama、TGI、SGLang、llama.cpp到底选谁2.1 一张表理清框架定位2026年的推理框架格局已经比较稳定主流的五个选手各有各的生态位。我做了一张对比表按生产环境适配度排序框架核心优化最适合的场景运维成本模型格式vLLMPagedAttention、continuous batching高并发生产API、多LoRA动态加载中HuggingFace原生权重、AWQ/GPTQ量化Ollama一键安装、模型管理、CPU/GPU通吃开发调试、内部工具、Demo演示低GGUF量化格式为主TGIHuggingFace官方、与HF生态深度集成已经是HF全家桶的团队中HF原生权重SGLangRadixAttention、结构化输出优化高吞吐、多轮对话前缀复用较高HF原生权重llama.cpp纯CPU推理、极致量化无GPU的机器、边缘设备低GGUF量化格式补充一个容易混淆的点Ollama和llama.cpp不是完全替代关系Ollama只是把llama.cpp这类运行时包了层壳让你能用ollama qwen2.5:7b这种命令一行拉模型、一行启动服务。它解决的痛点是“模型分发和进程管理”而不是新的推理引擎。2.2 vLLM生产级首选但PagedAttention不是开箱即用我现在的生产环境全部跑在vLLM上没有例外。vLLM的核心卖点是PagedAttention这个机制借鉴了操作系统虚拟内存的分页思想——KV cache不再要求连续的大块显存而是按固定大小的块block分配满了就换出需要了再换入。配合continuous batching一批请求可以在prefill和decode阶段动态插队新请求不需要等当前整批decode完就能插入调度。这个设计直接决定了它的高吞吐表现。但vLLM有几个参数你必须理解否则很容易“装起来能跑压测就崩”。第一个是gpu-memory-utilization。它控制GPU显存里有多少比例可以用来动态分配KV cache默认是0.9。如果你的机器还要跑别的进程或者你的模型权重加载后剩余显存本来就不多这个值要往下调。我自己的习惯是先按0.6启动看日志里实际“KV cache size”有多少GB再慢慢加到0.85。第二个是max-num-seqs。它限制一个批次里最多同时处理的请求数默认值在不同版本里不太一样。并发上来之后如果发现延迟暴增多半就是这一项在作怪。压测时我会先跑一个基准值再逐档上调找到当前显存配置下的甜点位。第三个是max-model-len。这个参数我前面已经强调过别拍脑袋设大数字。配置的时候要把“权重显存 预留KV cache显存 推理临时buffer”一起算进去三者加起来不能超过物理显存。2.3 Ollama开发环境神器生产环境需要额外加固Ollama在2026年依然是个人开发者和中小团队最顺手的工具。我自己的开发流程是先在本地装Ollamaollama pull qwen2.5:7b-instruct跑一个Demo验证模型效果确认没问题再谈生产环境。但Ollama直接上生产有几个隐患你绕不开。第一Ollama默认拉下来的模型大多是GGUF量化格式Q4_K_M这种4bit量化对推理质量的影响在通用对话场景下不明显但在涉及数值抽取、格式解析、代码生成的场景里误差会被放大。如果业务对输出精度要求高我建议用safetensors原格式跑vLLM而不是在GGUF上做文章。第二Ollama的并发模型比较粗粒度。OLLAMA_NUM_PARALLEL环境变量能控制并行请求数OLLAMA_MAX_LOADED_MODELS控制同时加载几个模型但它没有vLLM那种细粒度的batch调度策略。并发一高延迟曲线会异常难看。第三Ollama的进程管理很简单没有真正的健康检查、优雅退出、请求排队机制。你需要在前面套一层负载均衡和超时控制否则模型进程僵死时你的API调用方会一直等下去。所以我的建议是Ollama用来做开发验证、内部工具、单机部署的轻量场景一旦服务要对外提供SLA承诺直接切换到vLLM或TGI。2.4 TGI、SGLang、llama.cpp各自的生态位TGI是HuggingFace官方出的推理服务和transformers、datasets这些库的兼容性最好。如果你的团队本来就重度使用HF生态用TGI可以少碰很多权重格式兼容的坑。但它的迭代速度明显比vLLM慢一些新特性比如细粒度的显存控制、多LoRA调度支持得不如vLLM及时。SGLang最近几年在特定场景里表现很亮眼核心是RadixAttention——它会把多轮对话里的公共前缀复用起来避免重复计算。如果你的业务大量存在“同一个长文档被反复提问”的情况SGLang的吞吐量优势会很可观。代价是它的配置项和调度逻辑比vLLM更复杂团队需要有人专门啃它的文档和源码。llama.cpp则完全是另一个维度它把推理优化做到了CPU和边缘设备上。我测试过在一台纯CPU的16核机器上跑7B Q4量化模型生成速度大概能到每秒3~5个token做离线批量处理是够用的。它的定位不是高并发在线服务而是“没有GPU也能跑起来”。选型逻辑总结一句话别被框架的star数绑架。你团队里有人能读懂vLLM的日志就用vLLM没有GPU预算就用Ollama或llama.cpp业务强依赖HF生态TGI可能更省心。3. 云服务形态对比云GPU实例、容器托管、Serverless还是裸金属3.1 四种主流形态的边界框架选完之后下一个问题是机器从哪来。2026年主流的形态还是这四种一是云GPU实例。这是最通用的方案任意主流云厂商都能买到带A10、L40S、A100甚至H100的实例按小时计费灵活扩缩容。缺点是环境要自己搭CUDA驱动、Python、依赖库、模型文件都要自己管理。我最早测试阶段就是开一台按量的GPU实例跑vLLM测完就释放。二是GPU容器托管服务。把模型镜像传上去平台负责拉起容器、暴露API通常自带简单的监控和扩缩容。这个方案的优点是省运维不用自己管驱动和环境缺点是单次请求的成本比裸机按量高而且平台上能调的参数有限。如果你们团队没有专职运维这个方案最容易起步。三是裸金属GPU服务器。整台物理机租给你没有虚拟化层损耗性能最稳定。适合持续高负载、7x24跑满的场景。缺点是贵而且扩缩容不灵活至少要签几个月。四是Serverless GPU。按调用次数付费看起来性价比极高但大模型场景有个致命伤冷启动。一个7B模型启动到可以推理需要10~30秒Serverless平台很难接受这个时延。除非你的调用量是极低频的日常任务否则我不推荐把它作为在线服务的底座。3.2 成本模型GPU只是开头带宽和存储才是隐形杀手很多团队算成本只算GPU小时单价这是大坑。以7B模型为例权重BF16精度大约是14GB加上KV cache和推理buffer单卡24GB显存勉强够跑。如果选按量付费的A10实例算下来每个小时几十块看起来不贵。但你还要算三笔账第一笔是模型加载的存储成本。14GB的权重文件要放在高性能云盘或对象存储上存储费用不高但每次冷启动要把文件从存储拉到GPU显存跨地域拉取的流量费会吓你一跳。我的做法是把模型全部放在同一地域的对象存储里并且保留一个常驻的GPU实例做热备避免频繁冷启动。第二笔是出网流量。LLM的响应是流式的一个请求如果需要输出1024个token大约生成2KB~6KB的文本数据。日活一万的API服务光响应流量就可能是几个GB到几十GB。如果你的云厂商出网流量不是按量免费这笔费用会占据总成本的相当比例。第三笔是日志和监控。大模型服务的日志量远大于普通API因为一次请求就会产生完整的prompt和response文本。这些日志要么进对象存储冷备要么进日志检索服务都是按存储量和查询次数计费。建议在日志入库前做一下敏感信息脱敏和裁剪控制单条日志大小。3.3 没有公网IP怎么把内网的服务暴露出去这个场景在团队里很常见模型服务跑在公司内网的一台GPU工作站上但前端应用部署在云上需要通过公网访问内网接口。如果你没有公网IP或者不想直接暴露内网端口最常用的两种方式一种是用frp这类反向代理工具。在有公网IP的云主机上跑frps服务端在内网GPU机器上跑frpc客户端frpc主动拨号到云主机把内网的vLLM服务端口映射到云主机的公网端口。这样外部访问云主机的8000端口就等于访问到了内网的推理服务。frpc配置大致是这样[common] server_addr 你的云主机公网IP server_port 7000 token 猜不到的随机字符串 [llm] type tcp local_ip 127.0.0.1 local_port 8000 remote_port 8000注意两点token一定要设不设等于给公网所有人开了一个隧道访问入口远程端口不要选22、3389这类容易被扫描的端口宁可选高位随机端口。另一种是直接在云主机上起Nginx反向代理把云主机的公网端口转发到内网服务。这种适合内网IP可达、只是缺公网入口的场景。Nginx配置本质上就是个stream或http代理但要做一层限流和流量白名单防止公网上的扫描器把你的推理服务当免费API薅。3.4 混合部署开发用Ollama测试用按量GPU生产用预留实例2026年做下来我越来越认同一个“三段式”的部署节奏。开发阶段本机或办公室内网一台GPU机器装Ollama把模型效果验证透锁定提示词模板和参数配置。测试阶段云上开一台按量GPU实例用vLLM起一套和最终生产一致的环境跑完整的压测脚本确认并发、延迟、显存曲线都达标。生产阶段购买预留实例或包月GPU服务器部署正式服务前面套网关、监控和告警。这个节奏能帮你省下不少钱——开发阶段的机器可以复用测试阶段的按量实例用完就释放真正花钱的只有生产环境那台。4. 生产级部署实操从模型文件到稳定API服务的完整链路4.1 模型获取与仓库目录管理框架和云服务定完之后接下来的全流程都围绕“稳定”两个字展开。首先是模型文件怎么管理。不要直接在服务器上临时下载模型也不要把模型文件散落在home目录里。我习惯建一个独立的模型仓库目录每个模型一个文件夹命名规范是“模型名-参数量-精度-版本”/models/ qwen2.5-7b-instruct-bf16-v1/ config.json generation_config.json model.safetensors tokenizer.json tokenizer_config.json llama3-8b-instruct-fp16-v1/ ...下载模型用HuggingFace CLI或ModelScope的SDK提前把文件拉到对象存储再批量分发到各台GPU服务器。这样做的原因是大模型权重文件动不动十几个GB直接在服务器上执行python -c from transformers import ...会让每个人各自下载一份既慢又乱。统一目录、统一版本号后面做回滚和多版本灰度时你只需要改一个软链接或环境变量。4.2 环境准备CUDA、Python、依赖的版本对齐模型文件就位后环境配置是另一个反复出问题的环节。我踩过最深的坑是服务器上已经装了一套公共的CUDA和Python环境而我的模型需要另一种版本组合最后被迫在容器里重新隔离。所以在生产环境里我强烈建议用Docker镜像来固化整套运行时而不是在宿主机上折腾。环境组合参考这套基线操作系统Ubuntu 22.04GPU驱动满足CUDA 12.4的最低版本要求通常是550系列或更新CUDA12.4Python3.10PyTorch2.4vLLM0.8.xTransformers4.45如果你选择直接在宿主机部署而不是容器请务必用virtualenv或conda创建一个独立的虚拟环境绝不要把vLLM装到系统全局Python里。全局环境一旦被某个人pip install一个不兼容版本的transformers所有依赖这个环境跑的服务全会受到牵连。4.3 用vLLM启动服务关键参数详解这是整个部署流程的核心步骤。以我生产环境常用的启动命令为例python -m vllm.entrypoints.openai.api_server \ --model /models/qwen2.5-7b-instruct-bf16-v1 \ --served-model-name qwen2.5-7b \ --api-key 你的随机APIKey \ --max-model-len 8192 \ --gpu-memory-utilization 0.85 \ --max-num-seqs 32 \ --tensor-parallel-size 1 \ --host 0.0.0.0 \ --port 8000参数逐个说--served-model-name是暴露给调用方的模型名。客户端请求时传这个模型名内部路径传实际模型路径两者可以解耦。这样以后你内部换模型权重只要保持served-model-name不变上游业务代码一行都不用改。--api-key是vLLM自带的鉴权开关开启后所有/v1接口都要求Authorization: Bearer 请求头。这个参数建议一定打开哪怕服务只在内网访问。内网也不代表绝对安全。--max-model-len我前面讲过按业务真实上下文分布来定。不是越大越好尤其在单卡显存有限时它直接决定了能分配多少KV cache。--gpu-memory-utilization 0.85表示把85%的显存给KV cache动态池用剩下的留给模型权重和推理临时buffer。这个值不能设成1.0否则一旦并发请求的临时buff叠加超过预留空间后端会直接报线分配错误。--max-num-seqs 32控制单批次最大并行请求数。这个值调优的直接影响是延迟和吞吐的平衡调大吞吐更高但单请求延迟会被拉长调小延迟更稳但总吞吐上不去。7B模型在A10单卡上32是我实测比较甜的值。--tensor-parallel-size是并行度配置。单卡设12卡设24卡设4。注意如果你用两张卡并行一个7B模型显存确实够但通信开销会吃掉一部分性能。当模型权重单卡放得下时建议tensor-parallel-size就设1。启动后用一条curl验证服务是否正常curl http://127.0.0.1:8000/v1/models返回的JSON列表里如果有qwen2.5-7b说明服务已经起来了。再发一个最简单的补全请求确认生成链路正常。4.4 并发量快速估算你当前配置能扛多少请求很多人部署完不关心“这台机器到底能扛多少并发”直接压测脚本一把梭。我建议先做一个理论估算心里有底再压测。单实例并发能力大致是可并行处理请求数 ≈ (KV cache可用显存) / (单请求平均KV显存占用)注意这里的“KV cache可用显存”指的是gpu-memory-utilization划出来的那部分实际值看vLLM启动日志里打印的“KV cache size”。假设日志显示KV cache size是8GB而业务平均请求长度是4096 token单请求KV cache约2GB那并行上限大约是4个。如果同时有人调用长上下文比如8192 token单请求占用翻倍上限就降到2个。这就是为什么我前面强调要拉真实日志两个请求就能打满显存的配置跟能同时跑32个请求的配置网关层和负载均衡的策略完全不一样。如果理论并发达不到业务目标优先做两件事一是缩小平均上下文长度二才是加机器。很多团队为了支持“偶尔出现的超长文档”把max-model-len设得很大结果绝大多数请求是短对话白白浪费了大部分KV cache空间。更合理的做法是主实例用短max-model-len扛日常流量另起一台长上下文实例处理极端请求通过网关层按参数路由。4.5 网关层Nginx、鉴权、限流、监控推理服务本身只负责生成内容对外流量治理要单独一层网关来做。我的标准组合是vLLM监听内网8001端口Nginx监听公网8000端口做反向代理Nginx层统一做鉴权、限流和日志。Nginx限流配置示例limit_req_zone $binary_remote_addr zonellm_api:10m rate2r/s; server { listen 8000; location /v1/ { limit_req zonellm_api burst10 nodelay; proxy_pass http://127.0.0.1:8001/v1/; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_read_timeout 300s; } }这里有两个容易忽略的点。第一个是proxy_read_timeoutLLM生成是流式的一个长响应的耗时可能超过60秒Nginx默认超时会把连接断掉。我一般设300秒起步如果你们业务经常输出几千token就设600秒。第二个是限流参数rate2r/s并不是硬性上限burst10允许短时突发10个请求nodelay表示突发也立即处理而不是排队。这个策略适合“平均流量低、偶尔有并发尖峰”的典型对话业务。监控方面vLLM自带/metrics端点暴露了token生成速率、排队请求数、显存利用率等指标。我用Prometheus拉取这些指标配上一套基本的告警规则GPU显存使用率超过85%持续5分钟就告警、平均首Token延迟超过2秒告警、队列长度超过10告警。这套配置部署完基本能做到“问题发生前主动介入”。5. 部署后第一周必踩的四个坑5.1 显存OOM不是显存不够是碎片化第一个坑几乎人人都会遇到服务启动时明明显示显存够用压测跑了一会儿突然报CUDA out of memory。我排查过几次这类问题根因几乎都不是“显存总容量不够”而是KV cache池碎片化。vLLM的分页分配机制虽然能处理不连续内存但当大量不同长度请求交织、反复申请释放块时可用块会变得零散。如果再同时打开多个并发批次某个时刻需要一块较大的连续空间就可能触发OOM。遇到这个问题我的排查顺序是看vLLM启动日志里“KV cache size”还剩多少确认不是权重就把显存占满。把gpu-memory-utilization从0.85下调到0.8给推理buffer留更多余量。把max-num-seqs下调一档减少同时处理的请求数量。如果仍然OOM把max-model-len缩短20%到30%释放更多KV cache空间。这套组合拳基本能解决99%的显存OOM问题。剩下那1%通常是因为同时加载了多个模型或者有别的进程占用显存。5.2 首Token延迟高问题不一定在GPU第二个坑是延迟排查。有一次我压测时发现首Token延迟平均要3秒直觉觉得是GPU算力不够把instance从A10升到L40S结果毫无变化。后来我用curl拆分耗时curl -w connect: %{time_connect}s, ttfb: %{time_starttransfer}s, total: %{time_total}s \ http://内网服务地址/v1/chat/completions -d {model:qwen2.5-7b,messages:[{role:user,content:hi}],stream:true}结果发现time_connect在1.2秒左右也就是说请求从测试机到推理服务本身就要花1秒以上。顺着网络链路排查发现是跨地域访问、中间经过了好几层网关和防火墙规则。把测试环境迁到同一地域后首Token延迟立刻降到800毫秒以内。这个教训是遇到延迟问题先分网络层和计算层。GPU再强也救不了跨地域的网络往返。5.3 并发一高就变慢prefill和decode的调度权重第三个坑是并发规格上不去。我的服务在单并发时响应很漂亮一旦并发升到16延迟立刻翻了倍。这是在连续批处理机制下很典型的现象。当多个请求同时到达vLLM会把它们的prefill阶段一起调度prefill阶段需要整批计算输入token算力占用远高于decode阶段的一步一token输出。短时间大量prefill会造成计算资源抢用表现为首Token延迟突然拉高。解决办法分两步一是压榨参数把max-num-seqs调整到符合业务并发量的值。如果大多数请求是短文本200~500 tokenprefill负担小并发可以设高一点如果经常输入长文档2000 token以上prefill负担大并发要降下来。二是前置缓冲。在网关层加一个简单的请求队列把瞬时并发削峰填谷避免vLLM一次性收到大量长请求。Nginx自带的limit_req能挡流量但更精细的队列要用Redis或MQ在业务网关里做。5.4 模型热更新与回滚预案第四个坑出现在上线后进行模型升级时。我遇到过团队直接在生产环境rm掉旧模型目录然后把新模型上传到同名路径VLLM服务热加载时读了一半文件直接崩溃。模型文件更新绝不能原地覆盖。我的标准做法是新模型先放到新目录比如/models/qwen2.5-7b-instruct-bf16-v2。用新目录启动一台新的vLLM实例监听另一个端口做一轮冒烟测试。通过网关层把流量灰度切换一部分到新实例观察延迟和错误率。确认稳定后把旧实例停掉再清理旧目录。这个流程本质上是“先增加一台再减少一台”避免任何时刻出现文件被覆盖、服务读半截文件的情况。回滚也同样简单只要网关层把流量切回旧实例就完成了回滚。我们线上当前就是这么做的。Nginx的upstream里配置两个server一个v1、一个v2通过权重调整流量比例整个过程中业务方完全无感。6. 微调模型和本地部署的额外一课6.1 微调产物LoRA、QLoRA怎么部署如果你做的是大模型微调部署环节会比直接拉通用模型多一层考虑。微调产物通常分两类全量微调full fine-tuning和参数高效微调LoRA/QLoRA。全量微调后的权重可以直接覆盖基础模型目录部署方式和前面讲的vLLM启动流程一样没有区别。LoRA是另一个玩法。它不修改基础模型权重只是额外记录了一套增量矩阵。部署时有两条路第一是合并权重。用微调框架自带的merge脚本把LoRA权重合并进基础权重生成一个新的safetensors文件。这个方案部署简单启动时就是个普通模型但任何任务切换都需要重新生成整个权重文件很笨重。第二是动态加载LoRA。vLLM对LoRA有原生支持启动时加--enable-lora参数指定一个存放多个LoRA适配器的目录。这样基础模型只加载一份多个微调任务共享同一份基础权重每次请求时通过参数指定加载哪个LoRA适配器。多任务场景下显存节省非常明显代价是推理时多一层适配计算吞吐会有轻微下降。我的建议是如果你们只有一个微调任务合并部署最简单如果有多个业务线共用同一个底座动态加载LoRA更值得。6.2 本地部署的常见误区最后聊一下本地部署和“个人电脑智能化”这个热门话题。很多读者可能不是团队部署者而是想把模型跑在自己的电脑上。如果你没有独立GPU优先用Ollama加GGUF量化模型。一个7B模型用Q4_K_M量化后大约4GB左右16GB内存的电脑可以跑起来生成速度肉眼能接受。但要有心理准备量化模型在文字创作、通用问答上问题不大在数学计算、信息抽取这类对精度敏感的任务上会明显比非量化版本差。如果你有独立GPU配置也跑得动原版权重可以直接用Ollama原格式或vLLM。但一个常见误区是不看显存就拉最大模型。比如花几千块买了个大模型卡拉了一个70B模型发现显存放不下只能用4bit量化最后精度损失惨重。一个相对通用的经验是4bit量化模型模型体积大约只有BF16权重的四分之一但实际部署时优先看“权重KV cache”的总和。你在选模型之前先查一下目标模型的体积再对照自己的显存预留至少30%给KV cache和推理buffer剩下的才是模型能占用的空间。这条规则同样适用于个人电脑和服务器——别让你的显存清单超载。拉模型的时候建议用模型管理工具而不是浏览器下载例如ollama pull qwen2.5:7b-instruct-q4_K_M这个命令会自动处理模型文件、校验完整性、存放到统一的模型目录。比你在浏览器里开着多线程下载器一个个文件手动放靠谱得多。我这套流程跑完之后最大的体会是框架选型、云服务对比这些环节看起来是纯技术决策本质上却都是业务决策。团队如果连“模型是给内部用还是给外部用”“并发峰值长什么样”“数据能不能出内网”都没想清楚再先进的框架也救不了。如果你现在正准备部署一套大模型服务我的建议是先在开发机上用Ollama把模型效果验透再用vLLM跑一轮完整压测最后才去谈云服务选型和成本。这个顺序能帮你省掉至少一个月的试错时间。