1. 从训练完的模型到可用的服务中间到底隔着什么很多人第一次接触LLM脑子里想的都是训练——数据怎么洗、参数怎么调、loss怎么降。但真到了要把模型用起来的那一步你会发现一个尴尬的现实训练完的模型文件躺在磁盘上它什么也干不了。你没法直接把它丢给前端调用也没法让业务系统去访问它。这中间隔着一整层东西就是我们说的模型服务。我刚开始接触这块的时候也走过弯路。当时手里有一个微调好的模型想着直接写个Python脚本加载权重然后接收请求返回结果不就行了结果一上线就崩——并发一上来显存直接爆掉请求排队排到天荒地老偶尔还会因为输入长度超限直接报错退出。后来才明白模型服务不是简单地“加载模型接收请求”它要解决的是怎么让模型稳定、高效、可控地对外提供推理能力。这篇文章适合谁看如果你已经了解Transformer的基本结构知道什么是权重文件但还没真正把一个大模型部署成服务对外提供API那这篇就是写给你的。我会从最基础的概念讲起把“模型服务”这件事拆开揉碎说清楚它到底包含哪些环节、每个环节在干什么、为什么需要这些环节。不会一上来就堆工具名和命令而是先把逻辑理清楚后面再谈具体怎么选、怎么配。核心关键词先摆出来LLM、模型服务、推理、部署、优化。这五个词基本串起了从模型到服务的整条链路。下面我按自己的理解把这几个概念之间的关系先理一遍。1.1 训练、推理、服务三个容易混淆的概念先说训练。训练是让模型从数据中学习参数的过程产出的是一个包含权重和配置的文件集合。这个过程计算密集、耗时长通常离线完成。训练完之后你得到一个“死”的模型——它只是一堆数值没有对外交互的能力。再说推理。推理是用训练好的模型对新的输入进行计算、产出输出的过程。你给模型一句话它给你续写一段你给一张图它给你一个分类标签。推理是“活”的但它本身只是一个计算动作不涉及网络通信、并发管理、请求调度这些事情。最后说服务。服务是把推理能力包装成一个可被外部调用的接口通常基于HTTP或gRPC协议。服务层要处理的事情包括接收请求、解析参数、调度推理、管理资源、返回结果、处理异常、记录日志、做鉴权限流等等。推理是内核服务是外壳。没有服务层推理只能在本机跑跑demo有了服务层推理才能变成业务系统可以依赖的能力。这三者的关系可以用一个类比来理解训练是造发动机推理是发动机点火运转服务是把发动机装进车里、配上方向盘和油门刹车、让普通人也能开上路。你光有发动机车跑不起来你光会点火也没法载人。1.2 为什么不能直接拿脚本当服务用有人可能会想我写个Flask应用加载模型写个接口不就完事了小规模自用确实可以但一旦要对外提供服务问题就来了。第一并发问题。Python的GIL限制了多线程并行执行一个请求在推理时其他请求只能等着。你可能会说用多进程但每个进程都加载一份模型权重显存直接翻倍成本扛不住。第二显存管理。LLM的权重动辄几个GB到几十个GB加载一次就要占住显存。如果多个请求同时进来KV Cache会迅速膨胀没有合理的管理机制OOM是迟早的事。第三请求调度。不同请求的输入长度不同、期望的输出长度也不同。如果按先来先服务处理一个长请求会把后面所有短请求堵死。需要更聪明的调度策略比如连续批处理Continuous Batching把多个请求的动态计算合并到一起。第四可观测性。服务跑起来之后你需要知道QPS是多少、延迟分布如何、显存占用多少、有没有请求失败。这些都需要在服务层埋点、采集、暴露指标。第五版本管理与灰度。模型更新了怎么在不中断服务的情况下切换新版本有问题怎么快速回滚这些都不是一个简单脚本能解决的。所以模型服务是一个系统工程它把推理能力工程化、产品化让模型真正能被业务用起来。这也是为什么现在有那么多专门的推理服务框架比如vLLM、SGLang、TensorRT-LLM等等它们本质上都在解决上面这些问题。2. 模型服务的核心组件拆解理解了“为什么需要服务层”之后我们来看一个典型的LLM服务到底由哪些部分组成。我把它拆成五个核心模块模型加载器、推理引擎、请求调度器、API网关、监控与运维。每个模块各司其职缺一不可。2.1 模型加载器把权重变成可计算的对象模型加载器负责把磁盘上的权重文件读进内存/显存构建出可执行推理的计算图。听起来简单但里面有不少门道。首先是格式问题。训练框架产出的权重格式各不相同PyTorch的.pt、SafeTensors的.safetensors、GGUF的.gguf等等。不同格式的加载方式、内存占用、加载速度都不一样。SafeTensors因为内存映射和零拷贝的特性加载速度比传统PyTorch格式快不少而且更安全不会执行任意代码。GGUF则主要用于llama.cpp这类CPU推理场景做了量化压缩。其次是量化。原始权重通常是FP16或BF16加载后显存占用很大。实际部署时往往会用量化技术把权重压到INT8、INT4甚至更低。量化的好处是显存占用小、推理速度快代价是精度会有一定损失。常见的量化方案有GPTQ、AWQ、GGUF的Q4_K_M等。选择哪种量化方式要看你的精度要求和硬件条件。第三是设备放置。模型可能太大单卡放不下需要切分到多卡上。这就涉及张量并行Tensor Parallelism和流水线并行Pipeline Parallelism。张量并行是把单个矩阵运算切到多卡上流水线并行是把不同层放到不同卡上。加载器需要根据并行策略把权重正确地分配到各个设备。实操心得加载大模型时如果显存刚好卡在边界上建议留出至少10%的余量给KV Cache和中间激活值。我见过太多因为显存算得太紧、一跑起来就OOM的情况。2.2 推理引擎真正干活的计算核心推理引擎是模型服务的心脏负责执行前向计算。它的核心任务有两个算得快和算得省。算得快靠的是算子优化和计算图优化。比如FlashAttention把注意力计算融合成一个算子减少了显存读写PagedAttention把KV Cache按页管理避免了显存碎片CUDA Graph把一系列小算子捕获成一个大图减少了kernel launch的开销。这些优化叠加起来能让推理速度提升几倍甚至十几倍。算得省靠的是批处理Batching和缓存复用。批处理是把多个请求合并成一个批次一起计算提高GPU利用率。缓存复用是让相同前缀的请求共享KV Cache避免重复计算。比如系统提示词System Prompt通常很长且固定如果每个请求都重新算一遍浪费巨大。Prefix Caching就是解决这个问题的。这里要特别提一下连续批处理Continuous Batching也叫迭代级调度。传统的静态批处理要等一个批次里所有请求都生成完才能处理下一批而连续批处理在每个解码步decode step结束后就可以把已完成的请求踢出、把新请求加进来。这样GPU几乎不会空闲吞吐量能提升好几倍。vLLM和SGLang都实现了这个机制是目前高吞吐场景的标配。2.3 请求调度器决定谁先算、怎么算调度器负责管理请求的生命周期接收、排队、分配资源、执行、返回。它的核心挑战是在延迟和吞吐之间找平衡。如果追求低延迟那就一个请求一个请求地处理GPU利用率低但响应快。如果追求高吞吐那就尽量攒大批次但单个请求的等待时间会变长。实际生产环境需要根据业务场景来调。比如对话场景对首Token延迟敏感而批量摘要场景更看重整体吞吐。调度策略也有很多种。FCFS先来先服务最简单但容易被长请求阻塞。优先级调度可以保证重要请求先处理。公平调度则尽量让每个请求都得到均等的资源。还有一些高级策略比如根据输入长度预估计算量、动态调整批次大小等。注意调度器的配置直接影响用户体验。如果你的服务面向C端用户首Token延迟超过2秒就会明显感觉卡顿。这时候要优先保证调度器能快速响应新请求而不是一味追求大批次。2.4 API网关对外暴露的接口层API网关是用户和模型服务之间的桥梁。它负责协议转换、参数校验、鉴权、限流、日志记录等。协议方面最常见的是HTTP RESTful API兼容OpenAI接口格式的居多。这样做的好处是生态兼容性好很多客户端工具可以直接对接。也有用gRPC的性能更好但接入成本高一些。鉴权方面API Key是最简单的方式但要注意密钥管理。密钥不能硬编码在代码里要用环境变量或密钥管理服务。传输层要启用TLS加密防止密钥在网络上被截获。另外建议给每个调用方分配独立的Key方便追踪和吊销。限流方面要防止单个用户把服务打满。常见的策略有QPS限制、并发数限制、Token速率限制等。限流阈值要根据服务容量来定太松起不到保护作用太紧会影响正常使用。2.5 监控与运维让服务跑得稳、看得见服务上线只是开始后续的运维才是重头戏。你需要监控的指标包括延迟指标首Token延迟TTFT、每Token延迟TPOT、端到端延迟吞吐指标QPS、Token吞吐量、批处理大小分布资源指标GPU利用率、显存占用、CPU使用率、网络带宽质量指标请求成功率、错误码分布、超时率这些指标要接入监控系统如PrometheusGrafana设置告警阈值。比如显存占用超过90%就要告警延迟P99超过阈值也要告警。日志方面要记录每个请求的输入输出摘要、耗时、Token数等信息方便排查问题。但要注意脱敏不能把用户的敏感数据原样记下来。3. 从零搭建一个最小可用服务实操过程理论说了一堆现在来点实际的。我以最简化的方式走一遍从模型文件到可用服务的流程。这里不依赖重型框架用Python写一个最小实现目的是把每个环节都暴露出来让你看清楚里面发生了什么。实际生产肯定要用成熟框架但理解原理之后再用框架你会知道每个配置项在调什么。3.1 环境准备与依赖安装先确定硬件和软件环境。假设你有一张显存足够的GPU操作系统是LinuxPython版本3.10以上。需要安装的核心依赖pip install torch transformers fastapi uvicorn pydantictorchPyTorch加载模型和推理的基础transformersHuggingFace的模型加载和推理库fastapiWeb框架提供HTTP接口uvicornASGI服务器跑FastAPI应用pydantic请求/响应数据校验如果要用量化模型还需要安装auto-gptq或autoawq。如果要上生产建议直接用vLLM或SGLang它们把上面这些活都干了而且性能好得多。实操心得安装PyTorch时一定要选对CUDA版本。用nvidia-smi看驱动支持的CUDA版本然后去PyTorch官网找对应的安装命令。版本不匹配的话要么装不上要么跑起来报各种奇怪的错误。3.2 模型加载与推理封装先写一个最简单的模型加载和推理类import torch from transformers import AutoModelForCausalLM, AutoTokenizer class LLMEngine: def __init__(self, model_path: str, device: str cuda): self.tokenizer AutoTokenizer.from_pretrained(model_path) self.model AutoModelForCausalLM.from_pretrained( model_path, torch_dtypetorch.float16, device_mapdevice, ) self.model.eval() torch.no_grad() def generate(self, prompt: str, max_new_tokens: int 256, temperature: float 0.7): inputs self.tokenizer(prompt, return_tensorspt).to(self.model.device) outputs self.model.generate( **inputs, max_new_tokensmax_new_tokens, temperaturetemperature, do_sampletemperature 0, ) text self.tokenizer.decode(outputs[0], skip_special_tokensTrue) return text这段代码做了几件事加载tokenizer和模型、把模型设为评估模式、封装生成函数。torch.no_grad()关闭梯度计算减少显存占用。device_map指定模型放在哪个设备上。但这段代码有几个明显问题没有批处理、没有KV Cache管理、没有并发控制。它只能串行处理请求而且每次都要重新编码输入。实际生产环境不能这么用但作为理解原理的起点足够了。3.3 用FastAPI包装成HTTP服务接下来用FastAPI把上面的推理类包装成HTTP接口from fastapi import FastAPI, HTTPException from pydantic import BaseModel from typing import Optional app FastAPI() engine LLMEngine(model_path/path/to/your/model) class GenerateRequest(BaseModel): prompt: str max_new_tokens: Optional[int] 256 temperature: Optional[float] 0.7 class GenerateResponse(BaseModel): text: str tokens_generated: int app.post(/v1/generate, response_modelGenerateResponse) async def generate(req: GenerateRequest): if not req.prompt: raise HTTPException(status_code400, detailprompt is required) try: result engine.generate( req.prompt, max_new_tokensreq.max_new_tokens, temperaturereq.temperature, ) return GenerateResponse(textresult, tokens_generatedlen(result)) except Exception as e: raise HTTPException(status_code500, detailstr(e))启动命令uvicorn main:app --host 0.0.0.0 --port 8000 --workers 1注意--workers只能设为1因为每个worker都会加载一份模型显存扛不住。这也是为什么需要专门的推理框架——它们能在单进程内实现并发。3.4 参数选择与性能调优上面代码里有几个关键参数直接影响服务质量和性能max_new_tokens控制生成的最大长度。设得太小回答可能被截断设得太大显存占用高、延迟长。建议根据业务场景定对话场景一般512够了长文生成可能需要2048以上。temperature控制生成的随机性。0表示贪婪解码输出最确定的结果大于0则按概率采样。对话场景一般0.7左右代码生成建议0.2以下创意写作可以到1.0。批处理大小上面的代码没有批处理每个请求单独推理。如果要支持并发需要把多个请求攒成一批。但批处理会增大显存占用需要根据显存容量和请求长度动态调整。KV Cache上面的代码每次生成都重新计算所有Token的KV没有缓存。实际部署中相同前缀的请求应该共享KV Cache。vLLM的PagedAttention就是专门做这个的。注意temperature设为0时do_sample要设为False否则会报错。这个坑我踩过当时调了半天才发现是参数冲突。4. 常见问题与排查技巧实录服务跑起来之后总会遇到各种问题。我把自己和同事踩过的坑整理成一张速查表覆盖大部分常见故障。4.1 显存相关问题的排查思路显存问题是LLM服务最常见的故障。表现包括OOM报错、服务突然挂掉、推理速度骤降。排查步骤用nvidia-smi看显存占用确认是模型权重占的多还是KV Cache占的多检查是否有内存泄漏——长时间运行后显存是否持续增长检查批处理大小是否过大尝试调小检查是否有请求的输入长度异常大导致KV Cache膨胀现象可能原因解决方法启动时OOM模型权重太大用量化模型或张量并行运行中OOMKV Cache膨胀限制max_new_tokens启用PagedAttention显存持续增长内存泄漏检查是否有未释放的中间变量推理速度骤降显存碎片重启服务启用显存池化4.2 延迟波动的典型原因延迟忽高忽低用户体验很差。常见原因有批处理策略不当大批次导致新请求等待时间长。解决方法是启用连续批处理让新请求能插队。长请求阻塞一个超长生成请求占住GPU后面全等着。解决方法是设置单请求最大Token数或者用优先级调度。GPU降频温度过高导致GPU降频推理变慢。检查散热必要时限制功耗。网络抖动如果服务和调用方不在同一机房网络延迟会影响端到端时间。4.3 输出质量异常的调试方法有时候服务不报错但输出质量明显下降。可能的原因量化损失过大INT4量化在某些模型上会导致明显的质量下降。可以对比FP16和量化版本的输出如果差异大就换量化方案。温度参数不当温度太高输出胡言乱语太低输出重复呆板。根据场景调整。提示词格式错误不同模型对提示词格式要求不同。比如Llama系列需要特定的s和/s标记格式不对会影响效果。截断问题max_new_tokens太小回答被截断。检查输出是否在句子中间突然结束。实操心得调试输出质量时固定随机种子torch.manual_seed(42)可以让结果可复现方便对比不同参数的效果。4.4 服务安全与鉴权的注意事项API Key泄露是常见的安全隐患。几个必须做的防护措施密钥通过环境变量注入不要写在代码或配置文件里启用HTTPS防止密钥在传输中被截获给每个调用方分配独立Key方便审计和吊销设置调用频率限制防止Key被盗后被滥用定期轮换密钥降低泄露风险另外输入内容要做长度限制和内容过滤防止恶意请求消耗资源或产生不当输出。5. 工具选型什么时候用框架什么时候自己写最后聊聊工具选型。我见过两种极端一种是什么都自己写从HTTP服务器到推理调度全手撸另一种是什么都用现成框架连个简单demo都要上Kubernetes。这两种都不太对。自己写适合的场景学习原理、极简需求、特殊定制。比如你只是想在本机跑个demo或者业务逻辑非常特殊现成框架满足不了。自己写的好处是可控性高坏处是要处理的细节太多容易出bug。用框架适合的场景生产环境、高并发、需要快速上线。vLLM适合通用高吞吐场景SGLang适合复杂推理流程比如多轮对话、结构化输出TensorRT-LLM适合追求极致性能的NVIDIA显卡场景llama.cpp适合CPU或边缘设备部署。选型时重点看几个维度吞吐量、延迟、显存效率、易用性、社区活跃度。没有哪个框架在所有维度都最好要根据自己的业务特点来权衡。我个人的建议是先用vLLM或SGLang快速搭起来跑通业务流程。等遇到性能瓶颈了再针对性地优化。不要一上来就追求极致性能那样容易陷入过度工程的陷阱。提示选框架之前先看它的GitHub Issue区看看最近的问题多不多、维护者响应快不快。一个活跃的社区比文档更重要因为你会遇到很多文档里没写的问题。模型服务这件事入门容易精通难。把模型跑起来可能只要几行代码但要让它稳定、高效、安全地对外服务需要理解的东西很多。我自己的经验是不要怕踩坑每个坑踩过一次就记住了。先从最小可用版本开始跑起来之后再逐步优化比一开始就追求完美架构要靠谱得多。 LLM模型服务从零到一：推理部署与性能优化实战指南
1. 从训练完的模型到可用的服务中间到底隔着什么很多人第一次接触LLM脑子里想的都是训练——数据怎么洗、参数怎么调、loss怎么降。但真到了要把模型用起来的那一步你会发现一个尴尬的现实训练完的模型文件躺在磁盘上它什么也干不了。你没法直接把它丢给前端调用也没法让业务系统去访问它。这中间隔着一整层东西就是我们说的模型服务。我刚开始接触这块的时候也走过弯路。当时手里有一个微调好的模型想着直接写个Python脚本加载权重然后接收请求返回结果不就行了结果一上线就崩——并发一上来显存直接爆掉请求排队排到天荒地老偶尔还会因为输入长度超限直接报错退出。后来才明白模型服务不是简单地“加载模型接收请求”它要解决的是怎么让模型稳定、高效、可控地对外提供推理能力。这篇文章适合谁看如果你已经了解Transformer的基本结构知道什么是权重文件但还没真正把一个大模型部署成服务对外提供API那这篇就是写给你的。我会从最基础的概念讲起把“模型服务”这件事拆开揉碎说清楚它到底包含哪些环节、每个环节在干什么、为什么需要这些环节。不会一上来就堆工具名和命令而是先把逻辑理清楚后面再谈具体怎么选、怎么配。核心关键词先摆出来LLM、模型服务、推理、部署、优化。这五个词基本串起了从模型到服务的整条链路。下面我按自己的理解把这几个概念之间的关系先理一遍。1.1 训练、推理、服务三个容易混淆的概念先说训练。训练是让模型从数据中学习参数的过程产出的是一个包含权重和配置的文件集合。这个过程计算密集、耗时长通常离线完成。训练完之后你得到一个“死”的模型——它只是一堆数值没有对外交互的能力。再说推理。推理是用训练好的模型对新的输入进行计算、产出输出的过程。你给模型一句话它给你续写一段你给一张图它给你一个分类标签。推理是“活”的但它本身只是一个计算动作不涉及网络通信、并发管理、请求调度这些事情。最后说服务。服务是把推理能力包装成一个可被外部调用的接口通常基于HTTP或gRPC协议。服务层要处理的事情包括接收请求、解析参数、调度推理、管理资源、返回结果、处理异常、记录日志、做鉴权限流等等。推理是内核服务是外壳。没有服务层推理只能在本机跑跑demo有了服务层推理才能变成业务系统可以依赖的能力。这三者的关系可以用一个类比来理解训练是造发动机推理是发动机点火运转服务是把发动机装进车里、配上方向盘和油门刹车、让普通人也能开上路。你光有发动机车跑不起来你光会点火也没法载人。1.2 为什么不能直接拿脚本当服务用有人可能会想我写个Flask应用加载模型写个接口不就完事了小规模自用确实可以但一旦要对外提供服务问题就来了。第一并发问题。Python的GIL限制了多线程并行执行一个请求在推理时其他请求只能等着。你可能会说用多进程但每个进程都加载一份模型权重显存直接翻倍成本扛不住。第二显存管理。LLM的权重动辄几个GB到几十个GB加载一次就要占住显存。如果多个请求同时进来KV Cache会迅速膨胀没有合理的管理机制OOM是迟早的事。第三请求调度。不同请求的输入长度不同、期望的输出长度也不同。如果按先来先服务处理一个长请求会把后面所有短请求堵死。需要更聪明的调度策略比如连续批处理Continuous Batching把多个请求的动态计算合并到一起。第四可观测性。服务跑起来之后你需要知道QPS是多少、延迟分布如何、显存占用多少、有没有请求失败。这些都需要在服务层埋点、采集、暴露指标。第五版本管理与灰度。模型更新了怎么在不中断服务的情况下切换新版本有问题怎么快速回滚这些都不是一个简单脚本能解决的。所以模型服务是一个系统工程它把推理能力工程化、产品化让模型真正能被业务用起来。这也是为什么现在有那么多专门的推理服务框架比如vLLM、SGLang、TensorRT-LLM等等它们本质上都在解决上面这些问题。2. 模型服务的核心组件拆解理解了“为什么需要服务层”之后我们来看一个典型的LLM服务到底由哪些部分组成。我把它拆成五个核心模块模型加载器、推理引擎、请求调度器、API网关、监控与运维。每个模块各司其职缺一不可。2.1 模型加载器把权重变成可计算的对象模型加载器负责把磁盘上的权重文件读进内存/显存构建出可执行推理的计算图。听起来简单但里面有不少门道。首先是格式问题。训练框架产出的权重格式各不相同PyTorch的.pt、SafeTensors的.safetensors、GGUF的.gguf等等。不同格式的加载方式、内存占用、加载速度都不一样。SafeTensors因为内存映射和零拷贝的特性加载速度比传统PyTorch格式快不少而且更安全不会执行任意代码。GGUF则主要用于llama.cpp这类CPU推理场景做了量化压缩。其次是量化。原始权重通常是FP16或BF16加载后显存占用很大。实际部署时往往会用量化技术把权重压到INT8、INT4甚至更低。量化的好处是显存占用小、推理速度快代价是精度会有一定损失。常见的量化方案有GPTQ、AWQ、GGUF的Q4_K_M等。选择哪种量化方式要看你的精度要求和硬件条件。第三是设备放置。模型可能太大单卡放不下需要切分到多卡上。这就涉及张量并行Tensor Parallelism和流水线并行Pipeline Parallelism。张量并行是把单个矩阵运算切到多卡上流水线并行是把不同层放到不同卡上。加载器需要根据并行策略把权重正确地分配到各个设备。实操心得加载大模型时如果显存刚好卡在边界上建议留出至少10%的余量给KV Cache和中间激活值。我见过太多因为显存算得太紧、一跑起来就OOM的情况。2.2 推理引擎真正干活的计算核心推理引擎是模型服务的心脏负责执行前向计算。它的核心任务有两个算得快和算得省。算得快靠的是算子优化和计算图优化。比如FlashAttention把注意力计算融合成一个算子减少了显存读写PagedAttention把KV Cache按页管理避免了显存碎片CUDA Graph把一系列小算子捕获成一个大图减少了kernel launch的开销。这些优化叠加起来能让推理速度提升几倍甚至十几倍。算得省靠的是批处理Batching和缓存复用。批处理是把多个请求合并成一个批次一起计算提高GPU利用率。缓存复用是让相同前缀的请求共享KV Cache避免重复计算。比如系统提示词System Prompt通常很长且固定如果每个请求都重新算一遍浪费巨大。Prefix Caching就是解决这个问题的。这里要特别提一下连续批处理Continuous Batching也叫迭代级调度。传统的静态批处理要等一个批次里所有请求都生成完才能处理下一批而连续批处理在每个解码步decode step结束后就可以把已完成的请求踢出、把新请求加进来。这样GPU几乎不会空闲吞吐量能提升好几倍。vLLM和SGLang都实现了这个机制是目前高吞吐场景的标配。2.3 请求调度器决定谁先算、怎么算调度器负责管理请求的生命周期接收、排队、分配资源、执行、返回。它的核心挑战是在延迟和吞吐之间找平衡。如果追求低延迟那就一个请求一个请求地处理GPU利用率低但响应快。如果追求高吞吐那就尽量攒大批次但单个请求的等待时间会变长。实际生产环境需要根据业务场景来调。比如对话场景对首Token延迟敏感而批量摘要场景更看重整体吞吐。调度策略也有很多种。FCFS先来先服务最简单但容易被长请求阻塞。优先级调度可以保证重要请求先处理。公平调度则尽量让每个请求都得到均等的资源。还有一些高级策略比如根据输入长度预估计算量、动态调整批次大小等。注意调度器的配置直接影响用户体验。如果你的服务面向C端用户首Token延迟超过2秒就会明显感觉卡顿。这时候要优先保证调度器能快速响应新请求而不是一味追求大批次。2.4 API网关对外暴露的接口层API网关是用户和模型服务之间的桥梁。它负责协议转换、参数校验、鉴权、限流、日志记录等。协议方面最常见的是HTTP RESTful API兼容OpenAI接口格式的居多。这样做的好处是生态兼容性好很多客户端工具可以直接对接。也有用gRPC的性能更好但接入成本高一些。鉴权方面API Key是最简单的方式但要注意密钥管理。密钥不能硬编码在代码里要用环境变量或密钥管理服务。传输层要启用TLS加密防止密钥在网络上被截获。另外建议给每个调用方分配独立的Key方便追踪和吊销。限流方面要防止单个用户把服务打满。常见的策略有QPS限制、并发数限制、Token速率限制等。限流阈值要根据服务容量来定太松起不到保护作用太紧会影响正常使用。2.5 监控与运维让服务跑得稳、看得见服务上线只是开始后续的运维才是重头戏。你需要监控的指标包括延迟指标首Token延迟TTFT、每Token延迟TPOT、端到端延迟吞吐指标QPS、Token吞吐量、批处理大小分布资源指标GPU利用率、显存占用、CPU使用率、网络带宽质量指标请求成功率、错误码分布、超时率这些指标要接入监控系统如PrometheusGrafana设置告警阈值。比如显存占用超过90%就要告警延迟P99超过阈值也要告警。日志方面要记录每个请求的输入输出摘要、耗时、Token数等信息方便排查问题。但要注意脱敏不能把用户的敏感数据原样记下来。3. 从零搭建一个最小可用服务实操过程理论说了一堆现在来点实际的。我以最简化的方式走一遍从模型文件到可用服务的流程。这里不依赖重型框架用Python写一个最小实现目的是把每个环节都暴露出来让你看清楚里面发生了什么。实际生产肯定要用成熟框架但理解原理之后再用框架你会知道每个配置项在调什么。3.1 环境准备与依赖安装先确定硬件和软件环境。假设你有一张显存足够的GPU操作系统是LinuxPython版本3.10以上。需要安装的核心依赖pip install torch transformers fastapi uvicorn pydantictorchPyTorch加载模型和推理的基础transformersHuggingFace的模型加载和推理库fastapiWeb框架提供HTTP接口uvicornASGI服务器跑FastAPI应用pydantic请求/响应数据校验如果要用量化模型还需要安装auto-gptq或autoawq。如果要上生产建议直接用vLLM或SGLang它们把上面这些活都干了而且性能好得多。实操心得安装PyTorch时一定要选对CUDA版本。用nvidia-smi看驱动支持的CUDA版本然后去PyTorch官网找对应的安装命令。版本不匹配的话要么装不上要么跑起来报各种奇怪的错误。3.2 模型加载与推理封装先写一个最简单的模型加载和推理类import torch from transformers import AutoModelForCausalLM, AutoTokenizer class LLMEngine: def __init__(self, model_path: str, device: str cuda): self.tokenizer AutoTokenizer.from_pretrained(model_path) self.model AutoModelForCausalLM.from_pretrained( model_path, torch_dtypetorch.float16, device_mapdevice, ) self.model.eval() torch.no_grad() def generate(self, prompt: str, max_new_tokens: int 256, temperature: float 0.7): inputs self.tokenizer(prompt, return_tensorspt).to(self.model.device) outputs self.model.generate( **inputs, max_new_tokensmax_new_tokens, temperaturetemperature, do_sampletemperature 0, ) text self.tokenizer.decode(outputs[0], skip_special_tokensTrue) return text这段代码做了几件事加载tokenizer和模型、把模型设为评估模式、封装生成函数。torch.no_grad()关闭梯度计算减少显存占用。device_map指定模型放在哪个设备上。但这段代码有几个明显问题没有批处理、没有KV Cache管理、没有并发控制。它只能串行处理请求而且每次都要重新编码输入。实际生产环境不能这么用但作为理解原理的起点足够了。3.3 用FastAPI包装成HTTP服务接下来用FastAPI把上面的推理类包装成HTTP接口from fastapi import FastAPI, HTTPException from pydantic import BaseModel from typing import Optional app FastAPI() engine LLMEngine(model_path/path/to/your/model) class GenerateRequest(BaseModel): prompt: str max_new_tokens: Optional[int] 256 temperature: Optional[float] 0.7 class GenerateResponse(BaseModel): text: str tokens_generated: int app.post(/v1/generate, response_modelGenerateResponse) async def generate(req: GenerateRequest): if not req.prompt: raise HTTPException(status_code400, detailprompt is required) try: result engine.generate( req.prompt, max_new_tokensreq.max_new_tokens, temperaturereq.temperature, ) return GenerateResponse(textresult, tokens_generatedlen(result)) except Exception as e: raise HTTPException(status_code500, detailstr(e))启动命令uvicorn main:app --host 0.0.0.0 --port 8000 --workers 1注意--workers只能设为1因为每个worker都会加载一份模型显存扛不住。这也是为什么需要专门的推理框架——它们能在单进程内实现并发。3.4 参数选择与性能调优上面代码里有几个关键参数直接影响服务质量和性能max_new_tokens控制生成的最大长度。设得太小回答可能被截断设得太大显存占用高、延迟长。建议根据业务场景定对话场景一般512够了长文生成可能需要2048以上。temperature控制生成的随机性。0表示贪婪解码输出最确定的结果大于0则按概率采样。对话场景一般0.7左右代码生成建议0.2以下创意写作可以到1.0。批处理大小上面的代码没有批处理每个请求单独推理。如果要支持并发需要把多个请求攒成一批。但批处理会增大显存占用需要根据显存容量和请求长度动态调整。KV Cache上面的代码每次生成都重新计算所有Token的KV没有缓存。实际部署中相同前缀的请求应该共享KV Cache。vLLM的PagedAttention就是专门做这个的。注意temperature设为0时do_sample要设为False否则会报错。这个坑我踩过当时调了半天才发现是参数冲突。4. 常见问题与排查技巧实录服务跑起来之后总会遇到各种问题。我把自己和同事踩过的坑整理成一张速查表覆盖大部分常见故障。4.1 显存相关问题的排查思路显存问题是LLM服务最常见的故障。表现包括OOM报错、服务突然挂掉、推理速度骤降。排查步骤用nvidia-smi看显存占用确认是模型权重占的多还是KV Cache占的多检查是否有内存泄漏——长时间运行后显存是否持续增长检查批处理大小是否过大尝试调小检查是否有请求的输入长度异常大导致KV Cache膨胀现象可能原因解决方法启动时OOM模型权重太大用量化模型或张量并行运行中OOMKV Cache膨胀限制max_new_tokens启用PagedAttention显存持续增长内存泄漏检查是否有未释放的中间变量推理速度骤降显存碎片重启服务启用显存池化4.2 延迟波动的典型原因延迟忽高忽低用户体验很差。常见原因有批处理策略不当大批次导致新请求等待时间长。解决方法是启用连续批处理让新请求能插队。长请求阻塞一个超长生成请求占住GPU后面全等着。解决方法是设置单请求最大Token数或者用优先级调度。GPU降频温度过高导致GPU降频推理变慢。检查散热必要时限制功耗。网络抖动如果服务和调用方不在同一机房网络延迟会影响端到端时间。4.3 输出质量异常的调试方法有时候服务不报错但输出质量明显下降。可能的原因量化损失过大INT4量化在某些模型上会导致明显的质量下降。可以对比FP16和量化版本的输出如果差异大就换量化方案。温度参数不当温度太高输出胡言乱语太低输出重复呆板。根据场景调整。提示词格式错误不同模型对提示词格式要求不同。比如Llama系列需要特定的s和/s标记格式不对会影响效果。截断问题max_new_tokens太小回答被截断。检查输出是否在句子中间突然结束。实操心得调试输出质量时固定随机种子torch.manual_seed(42)可以让结果可复现方便对比不同参数的效果。4.4 服务安全与鉴权的注意事项API Key泄露是常见的安全隐患。几个必须做的防护措施密钥通过环境变量注入不要写在代码或配置文件里启用HTTPS防止密钥在传输中被截获给每个调用方分配独立Key方便审计和吊销设置调用频率限制防止Key被盗后被滥用定期轮换密钥降低泄露风险另外输入内容要做长度限制和内容过滤防止恶意请求消耗资源或产生不当输出。5. 工具选型什么时候用框架什么时候自己写最后聊聊工具选型。我见过两种极端一种是什么都自己写从HTTP服务器到推理调度全手撸另一种是什么都用现成框架连个简单demo都要上Kubernetes。这两种都不太对。自己写适合的场景学习原理、极简需求、特殊定制。比如你只是想在本机跑个demo或者业务逻辑非常特殊现成框架满足不了。自己写的好处是可控性高坏处是要处理的细节太多容易出bug。用框架适合的场景生产环境、高并发、需要快速上线。vLLM适合通用高吞吐场景SGLang适合复杂推理流程比如多轮对话、结构化输出TensorRT-LLM适合追求极致性能的NVIDIA显卡场景llama.cpp适合CPU或边缘设备部署。选型时重点看几个维度吞吐量、延迟、显存效率、易用性、社区活跃度。没有哪个框架在所有维度都最好要根据自己的业务特点来权衡。我个人的建议是先用vLLM或SGLang快速搭起来跑通业务流程。等遇到性能瓶颈了再针对性地优化。不要一上来就追求极致性能那样容易陷入过度工程的陷阱。提示选框架之前先看它的GitHub Issue区看看最近的问题多不多、维护者响应快不快。一个活跃的社区比文档更重要因为你会遇到很多文档里没写的问题。模型服务这件事入门容易精通难。把模型跑起来可能只要几行代码但要让它稳定、高效、安全地对外服务需要理解的东西很多。我自己的经验是不要怕踩坑每个坑踩过一次就记住了。先从最小可用版本开始跑起来之后再逐步优化比一开始就追求完美架构要靠谱得多。