最近一年几乎每周都会有人问我同一个问题模型部署到底该怎么做尤其当“模型部署”从“把单个模型包装成一个API”变成“搭建一个LLM推理平台”之后很多团队以前习惯的那套方案一下子就不够用了。以前你可能只需要把训练好的模型用FastAPI包起来暴露一个/predict接口能扛住几千QPS就算成功现在你面对的是多并发、流式输出、KV Cache、量化、多模型路由、网关、可观测性甚至还要对接知识库和可视化界面。这篇文章我会把这几年从单模型服务到LLM推理平台的部署框架做一次全景梳理把我实际踩过的坑、验证过的选型和可直接抄的配置一起聊透适合正在规划模型落地的工程师、技术负责人也包括刚准备在本地跑通第一套大模型服务的同学。1. 模型部署的技术演进与核心思路1.1 从单模型服务到推理平台究竟发生了什么先聊“单模型服务”。这个阶段的技术栈非常轻一个模型文件、一个推理脚本、一个轻量Web框架再加一个容器。典型的例子是图像分类或目标检测输入是一张图片模型加载后执行一次前向计算返回结构化结果。这里的关键指标是单请求延迟和最大并发数因为每个请求的输入输出长度固定显存占用也基本不变所以容量规划很好做。你甚至可以提前算好一张卡能同时跑多少个实例。但LLM来了之后这套逻辑直接被打破。第一输入输出长度是动态的同一个模型处理一句“你好”和生成一篇长文占用的显存和耗时天差地别第二生成式推理不是一次前向而是一个逐步解码的过程单个请求可能持续几秒甚至几十秒第三业务上通常需要流式返回用户想看到的不是30秒后的一整段答案而是像ChatGPT那样一个字一个字往外蹦。这三个变化让“拉起来一个服务”彻底不够用你需要考虑一个完整的推理平台模型仓库、推理引擎、网关路由、弹性伸缩、配额管理、监控告警以及面向业务系统的OpenAI兼容接口。所以我的理解是单模型服务解决的是“模型能不能被调用”LLM推理平台解决的是“模型能不能被稳定、高效、安全地当作基础设施来用”。如果没有平台化思路直接把模型接口丢到生产环境很快会被并发、显存和故障隔离打得措手不及。1.2 部署框架全景图自研、开源、托管方案怎么选模型部署框架 Today 非常多不是越火越好而是得分层看。我习惯把它分成三层推理引擎层、服务封装层、平台调度层。推理引擎层最贴近硬件负责把模型真正跑起来。这个赛道里vLLM是目前社区热度最高的核心是PagedAttention和Continuous Batching能大幅提升吞吐Hugging Face推出了TGIText Generation Inference主打和Transformers生态无缝衔接NVIDIA的TensorRT-LLM则是专门针对自家GPU做了极致优化上线生产前一般要编译engine调优成本高但上限也高还有llama.cpp和基于它的Ollama走的是GGUF格式路线在小显存和CPU环境下特别友好。服务封装层解决的是“怎么把模型暴露成接口”。TorchServe和Triton Inference Server是老牌力量它们支持多框架、动态批处理、模型版本管理但针对LLM的优化比较有限更多是被当成一个稳定的后端来用新一点的BentoML可以把模型、预处理、依赖一起打包成一个服务体验很好适合中小团队。平台调度层负责把多个模型服务编排成平台。如果你用Kubernetes可以选KServe、Seldon Core它们提供Serverless模型服务、自动伸缩、灰度发布如果你不想背上K8s用Ray Serve或容器编排也能搭出轻量方案。托管给云厂商也可以但很多场景下数据合规和成本控制让团队更倾向于私有化开源方案。选型决策我放在一张表里方便对照维度轻量实验/单卡多个模型/中等规模大规模生产集群推理引擎Ollama、llama.cppvLLM、TGITensorRT-LLM、vLLM服务封装内置API、FastAPI自研BentoML、TritonTriton、TGI平台调度Docker ComposeDocker Nginx/ALBK8s KServe/Seldon典型难度低当天能跑通中需要一些运维高需要专门团队别一上来就照着最重的方案去搭先想清楚当前阶段要解决什么问题。我也是从单机Ollama开始后来才一步步走到vLLM和网关侧的。2. 核心组件拆解与选型要点2.1 模型后端从TorchServe/Triton到vLLM/Ollama模型后端是整个平台的心脏选错后面全难受。传统CV或推荐模型时代我常用TorchServe和Triton。TorchServe偏PyTorch原生部署的时候把.pt或.onnx放进去再写个handler定义输入输出Triton则更通用支持TensorFlow、PyTorch、ONNX、TensorRT等一堆runtime而且有动态批处理Dynamic Batching在传统模型上的吞吐优化非常显著。但到LLM上传统框架的问题就暴露了它们把一次请求当作一个固定batch里的一个样本缺乏对“生成过程”的感知。LLM推理的特点是计算密集但访存又很敏感每一次解码都要读取全部权重如果不做缓存和批处理GPU利用率低得惨不忍睹。vLLM之所以火是因为它用PagedAttention把KV Cache按页管理显存碎片和浪费大幅减少配合Continuous Batching新的请求可以在前一个请求解码间隙插入进来大大提高了吞吐。TGI也有类似思路从实用角度两个都值得尝试。Ollama这个后起之秀本质是把llama.cpp的能力封装成了对用户极其友好的本地服务。它支持直接拉取qwen2.5、llama3等模型底层自动处理GGUF量化格式一条命令起服务适合开发机和个人电脑。GGUF这种格式的价值在于它是为CPU/小显存推理设计的它把量化后的权重打包成一个文件连分片都省了。如果业务需要私有化部署到一台只有16GB显存的机器上Ollama加q4_k_m量化版本通常是最快的出路。我总结的选型原则是优先看“是否能原生支持动态批处理、前缀缓存、量化推理”再看“是否兼容OpenAI接口”。vLLM和Ollama都做到了而TorchServe和Triton要做LLM需要做大量胶水工作除非你已经有成熟的传统模型集群否则对新项目我不推荐原地硬套。2.2 网关与路由为什么需要LLM网关很多团队在部署vLLM之后直接把http://localhost:8000丢给前端调用短期能跑但到了多个模型、多个副本、多个租户共存的阶段就会失控。这时候你需要一个LLM网关它能解决四类问题路由、安全、可观测、成本控制。路由方面网关可以根据业务来源把请求分到不同的模型比如简单问答走小模型复杂推理走大模型也可以做模型副本间的负载均衡比如后端起了两个vLLM实例网关轮询分发。安全方面网关是统一的认证入口避免每个模型服务各自做鉴权还能做API Key管理、请求体校验、敏感信息过滤。可观测方面网关是天然的埋点位置记录每个请求的模型名、输入输出token数、延迟、失败原因。成本控制方面网关可以做限流、配额防止某个业务方把推理资源全打满。开源方案里LiteLLM非常轻量直接封装了一堆模型的OpenAI兼容接口做“模型路由Key管理”够用如果需要更细粒度的流量治理可以选择Higress或APISIX这类云原生网关它们都推出了AI原生的插件能力如果团队以Kubernetes为核心Envoy AI Gateway或Kong AI Gateway也值得尝试。我个人经验是不要为了“AI原生网关”这个词而引入一个全新的重组件前期可以用Nginx加Lua脚本实现限流和路由等模型数量和调用方真正多了再平滑迁移到专用网关。2.3 前端可视化与知识库让模型被真正用起来一个推理引擎如果没有可聊天的前端它只是裸接口业务方用起来门槛很高。所以在正式环境的部署框架里我通常会把“可视化界面”和“知识库增强”也纳入进来这不是锦上添花而是决定平台能不能被业务用起来的关键。最经典的组合是Ollama加Open WebUI。Open WebUI是一个开源聊天界面支持管理多个模型、多用户、会话历史还能绑文档做简单RAG。Docker一条命令就能跑起来模型服务指向Ollama的地址即可。如果你需要更强大的知识库能力可以接Dify、RAGFlow或MaxKB它们都支持对接本地推理服务内置文档解析、向量化、召回和重排流程。这里有一个容易被忽略的点大模型本身的聊天能力不等于企业知识问答能力你必须把文档切片、Embedding、向量存储这些“外挂”搭好模型的回答才会贴合自己业务。向量数据库选型也值得多说一句。小规模场景直接用Chroma或Qdrant单机版本数据量上去后可以换Milvus或Weaviate。另外如果你在网上看到“RAG、GraphRAG、LLM Wiki”这类概念不用被名字吓住核心都是一样的把知识变成可检索的内容在调用大模型前先检索相关内容再拼进提示词里。这部分其实就是把纯模型平台升级成“业务知识平台”的关键一步。3. 实操部署从零搭建一套可用的LLM推理服务3.1 环境准备与加速器配置正式环境部署前先把GPU、驱动、容器环境理清楚否则后面都是玄学排障。第一步是检查硬件是否可见执行nvidia-smi确认驱动已装好能看到卡和显存。然后确认CUDA和容器运行时。我强烈建议用Docker跑模型服务因为宿主机装一堆Python依赖很容易把环境搞乱而容器可以隔离一切。安装好NVIDIA Container Toolkit后跑docker run --rm --gpus all nvidia/cuda:12.1.0-base-ubuntu22.04 nvidia-smi验证容器内能看见GPU。显存估算也要提前做。一个7B参数模型FP16精度的权重大约7 * 2 14GB但“权重放进去”不等于“能推理”KV Cache还要占一份额外的显存。粗略算法是显存 ≈ 权重大小 输入输出token数 × 层数 × hidden_size × 2注意精度实际项目里更快的办法是直接用transformers的model.get_memory_footprint()看或者用Ollama/vLLM启动时的报错来判断。经验值7B Q4量化版在16GB显存的消费卡上可以跑7B FP16要24GB才稳13B量化版也建议24GB起步。配置环境变量的时候注意几个坑。Ollama默认占满所有显存可以在启动脚本里设置OLLAMA_MAX_LOADED_MODELS1和OLLAMA_GPU_OVERHEADvLLM则要显式指定--gpu-memory-utilization我通常设为0.9留一点余量给其他进程。另外不要在容器里再装一套CUDA Toolkit尽量依赖基础镜像已有的runtime除非你有非常特殊的算子编译需求。3.2 用OllamaDocker快速部署本地模型如果你的目标是快速把一个大模型在本地或单机上跑起来Ollama是最省力的选择。安装Ollama官方镜像后直接启动docker run -d --gpus all \ -v ollama:/root/.ollama \ -p 11434:11434 \ --name ollama \ ollama/ollama拉取模型用命令行docker exec -it ollama ollama pull qwen2.5:7b-instruct拉完之后可以先用CURL测试curl http://localhost:11434/api/generate \ -d {model:qwen2.5:7b-instruct,prompt:你好,stream:false}Ollama默认的/api/generate和/api/chat接口可以满足简单的调用需求但如果你想用OpenAI SDK去连接记得Ollama也提供/v1/chat/completions这个兼容接口很多框架直接写base_urlhttp://localhost:11434/v1就行。还有一个容易被低估的功能是自定义Modelfile。你可以把本地下载的GGUF文件拿进来用Modelfile指定FROM /path/to/model.gguf和PARAMETER temperature等然后执行ollama create mymodel -f Modelfile这比硬改代码灵活得多。比如你有自研模型的GGUF量化版想统一从Ollama这里管理就特别方便。实操中常遇到的问题有两个第一拉模型很慢建议先在国内镜像源或离线包方式下载好.gguf文件再导入Ollama而不是直接ollama pull第二磁盘空间。Ollama会把模型放在/root/.ollama/models一个7B量化版通常是4~5GB7B原版要14GB以上部署前先df -h看清楚。3.3 用vLLM部署生产级推理服务当你的业务需要高并发、长上下文、稳定吞吐时Ollama就不够顶了这时候我通常直接上vLLM。安装很简单如果服务器能联网pip install vllm但更推荐用官方Docker镜像避免编译依赖把自己折腾崩溃。启动一个7B模型的例子docker run -d --gpus all \ -v /data/models:/models \ -p 8000:8000 \ vllm/vllm-openai \ --model /models/Qwen2.5-7B-Instruct \ --served-model-name my-llm \ --dtype bfloat16 \ --gpu-memory-utilization 0.9 \ --max-model-len 8192 \ --enable-prefix-caching启动之后它对外暴露的就是OpenAI兼容接口使用/v1/chat/completions业务方几乎不用改代码就可以从真实OpenAI切过来。生产环境下有几点建议第一模型路径建议挂在独立的磁盘上不要放在系统盘因为模型文件超大第二--max-model-len直接影响显存占用别拍脑袋设一个很大的数根据业务场景最长输入输出token来定没必要为极端情况浪费显存第三量化选项。如果显存是瓶颈可以用AWQ或GPTQ量化后的模型启动参数加--quantization awq --model /path/to/awq-model通常能省一半显存代价是精度和速度可能稍微下降第四如果有多张GPU可以用--tensor-parallel-size 2开启张量并行相当于把模型分到两张卡上共同推理。我在第一次用vLLM部署时踩过一个很蠢的坑默认的--host是0.0.0.0没问题但我忘了设置--trust-remote-code导致某些自定义模型加载失败。如果你用的模型不是当前HuggingFace上热门的架构可能也需要这个参数具体看模型的repo说明。3.4 网关、监控与日志接入模型服务起来了不等于平台稳了。我会在模型服务前面加一个轻量网关层最简单的做法是Nginx反代加一层健康检查和限流。可以用如下配置示例upstream llm_backend { server 127.0.0.1:8000; keepalive 32; } server { listen 80; location /v1/ { proxy_pass http://llm_backend; proxy_http_version 1.1; proxy_set_header Connection ; proxy_set_header Host $host; proxy_read_timeout 300s; proxy_send_timeout 300s; limit_req zonellm burst20 nodelay; } }注意这里proxy_read_timeout、proxy_send_timeout必须调大LLM生成动辄几十秒甚至几分钟如果保持默认的60秒前端就会看到超时。监控这一层不要拖到最后再补。vLLM本身会暴露/metrics接口格式是Prometheus标准我直接用node-exporter模式的抓取方式接入。关键指标有gpu_cache_usage_perc、num_requests_running、num_requests_waiting、time_to_first_token_seconds、generation_tokens_total。每一项都对应一个具体的体验问题首字延迟高说明排队或模型加载慢cache使用率高说明需要扩容生成token总量可以用来做成本核算。日志也要在网关层统一做结构化JSON至少包含request_id、model、prompt_tokens、completion_tokens、ttft、total_time和status_code。有这些数据后你可以轻松回答老板的经典三连问“平台性能怎么样”“哪个模型最费钱”“今天为什么有报错”4. 性能调优、容量规划与问题排查实录4.1 吞吐量与延迟关键指标和优化手法模型服务上线后最常被追问的其实是性能数字。LLM推理的延迟指标和传统接口完全不一样。传统接口只看P95延迟LLM还得拆成TTFTTime To First Token首Token时间和ITLInter-Token Latency相邻Token间隔时间。TTFT影响“感觉快不快”ITL决定“生成长度固定的情况下整体要多长时间”。而吞吐量用Tokens/s描述可以按并发请求的累计生成token数除以耗时计算。优化手法里收益最大的是“连续批处理”和“前缀缓存”。连续批处理是vLLM的看家本领不需要你额外改代码前缀缓存是--enable-prefix-caching如果大批请求共享系统提示词或知识库前缀缓存能直接跳过重复的前缀计算TTFT有肉眼可见的下降。另一个常用手段是量化。我实测下来用AWQ 4bit量化一个7B模型显存占用从14GB降到5GB左右同一张卡上可以支撑更大的并发生成速度基本持平甚至因为batch更大了反而更快。这里给一个不好看的真相不要只看单请求的benchmark要看“在目标并发和延迟要求下系统整体能跑多少TTFT”。我用过很多框架的官方基准效果都很好看但放到自己业务流里受上下文长度、停用词、业务后处理影响真实吞吐可能要打个五折。所以性能调优的第一步是先做压测用locust或ghz打一个符合业务比例的数据集再结合监控指标调整。4.2 并发与排队估算需要几张卡很多团队低估了容量规划的复杂度。LLM推理的容量不是“一张卡能跑多少并发”而是“一张卡在目标延迟下能每秒生成多少token”。我一般用一个简化模型估算假设单卡比如A100 40GB部署一个7B量化模型实测生成吞吐大概在800~1500 Tokens/s取决于量化、批大小和上下文。一个用户的请求平均输入500 token输出1500 token那一个请求总生成时长约1500 / 1000 1.5秒。如果希望同时支撑50个用户请求单卡每秒需要生成50 × 1500 / 1.5 50000 Tokens/s这显然一张卡不够。哪怕目标是同时排队20个请求也要大概20 × 1500 / 1.5 / 1000 20张卡。当然这个算法很粗糙实际中还要考虑排队等待、上下文峰值和前缀命中率。多卡部署时我想强调“张量并行”不等于“数据并行”。张量并行是把一个模型切到多张卡上解决显存单卡放不下的问题数据并行才是启动多个模型副本分散请求解决吞吐不够的问题。很多新手一上来就想用--tensor-parallel-size 4跑一个7B模型结果每张卡都在协作处理同一个请求显存资源被白白占用吞吐反而不高。正确的思路是显存够放单模型副本就优先数据并行跑多个副本再在前面用网关负载均衡只有模型单卡放不下才用张量并行。排队策略也要提前定。vLLM默认会在请求过多时排队等待但如果不设置超时业务方可能挂起很久。我在网关层会把等待上限设为30秒超过直接返回503同时用num_requests_waiting指标监控排队深度排队一旦超过10就触发扩容告警。4.3 常见问题速查表与避坑经验汇总把我在正式环境里遇到过的典型问题和排查方法整理成一张速查表希望能帮你们少走弯路现象可能原因排查思路启动时CUDA OOM模型权重 KV Cache超出显存看gpu-memory-utilization换量化模型减小max-model-len容器内看不到GPU缺少NVIDIA Container Toolkit在宿主机跑docker run --rm --gpus all ... nvidia-smi验证Ollama拉模型老是断网络问题或镜像未配置改用离线GGUF导入或配置国内镜像源vLLM报“ValueError: Tensor parallelism”模型参数量无法被TP整除换成--tensor-parallel-size 1或换卡数请求长时间卡住无返回网关超时太短或模型排队过深调大proxy_read_timeout检查vLLM的waiting队列流式输出断断续续启用了代理缓冲或响应压缩Nginx关掉gzip关闭proxy buffering确保SSE正常模型加载后立刻退出代码需要trust_remote_code增加--trust-remote-code并按模型repo说明操作返回结果全是空或乱码模版使用错误或分词器不匹配确认chat template测试前先跑一遍vllm.entrypoints.openai.api_server里的docs页除了这些还有几个经验我每次都会强调。第一上线前先在测试环境完整跑一遍压测 长稳测试LLM服务最怕的不是慢而是内存泄漏和单卡退化长时间运行一两天后性能下降多半跟前缀缓存或动态批处理的碎片有关重启往往只能治标要盯着指标才能定位根因。第二模型的版本和权重文件要做不可变管理不要在服务运行的时候原地覆盖模型文件否则会引发莫名其妙的推理结果漂移我习惯用类似model-repo/my-llm/20250101/这种带时间戳的目录来组织。第三启动参数要固化成配置文件并入库我见过不止一次某天服务崩了接手的人一头雾水只记得当时“随便敲了几个参数”结果很难复现。最后分享一个我个人坚持的小习惯无论项目多小我都会在部署文档里写清楚三件事——模型服务怎么拉起的、依赖哪些显存和磁盘资源、监控面板看哪些指标。这套文档价值极大因为LLM推理平台不是一次建完就结束的模型会换、流量会涨、框架会升级只有让“架构成文字”后人才敢动它。从单模型服务一路走到今天我最大的体会是稳定永远比炫技重要一个能长期跑在正式环境里的框架远比一个几天就要重搭一遍的“高级方案”有价值。