1. 大模型推理到底在做什么很多人第一次听到“大模型推理”这个词脑子里浮现的是一台机器在“思考”。这个理解方向没错但不够准确。我更喜欢用一个生活化的类比来解释训练像是把一个学生从小学教到大学推理则是这个学生毕业后坐在工位上面对客户提出的每一个问题当场给出回答的过程。训练阶段烧的是海量数据和成千上万张显卡推理阶段烧的是你每一次提问后等待的那几秒钟。从技术定义上讲大模型推理LLM Inference指的是给定一个已经训练好的模型权重输入一段文本prompt模型通过前向计算逐token生成输出文本的完整过程。这里面有两个关键词值得拆开说。第一个关键词是逐token生成。大模型不是一次性把整段回答“想好了”再吐出来而是一个字一个字往外蹦。每蹦一个字都要把之前所有的内容重新过一遍计算。这就是为什么你看到ChatGPT的回答是一个字一个字出现的——不是故意做特效是它真的只能这样算。第二个关键词是前向计算。推理阶段只做前向传播不做反向传播不更新权重。这意味着推理的计算量比训练小得多但对内存带宽的要求反而更高。因为训练可以批量处理推理往往要实时响应batch size上不去GPU利用率就容易拉胯。那推理任务到底解决什么问题说白了就三件事让模型能跑起来、跑得快、跑得省。跑起来是部署问题跑得快是性能问题跑得省是成本问题。这三个问题贯穿了大模型推理的整个技术栈从底层的CUDA kernel优化到上层的推理框架选型再到服务层的调度策略全都是在围绕这三个目标做权衡。适合谁来了解这些内容我大致分三类一是刚入门的算法工程师想搞清楚推理和训练的区别以及怎么把模型部署到生产环境二是有一定经验的后端或全栈工程师需要在自己的系统里集成大模型能力三是技术管理者需要判断团队该用什么推理方案、成本大概在什么量级。不管你是哪一类下面这些内容都是我实际踩过坑之后总结出来的不是纸上谈兵。2. 推理框架选型别一上来就追新2.1 主流推理框架的定位差异选推理框架这件事我的经验是先看你的场景是“自己玩”还是“上生产”再看你的硬件是什么。很多人一上来就问“哪个框架最好”这个问题没有标准答案因为每个框架的设计目标不一样。目前市面上常见的推理框架我按使用场景大致分几类框架核心定位适合场景上手难度llama.cpp极致轻量、CPU友好本地开发、边缘设备、Mac低Ollama开箱即用、模型管理个人本地部署、快速验证极低vLLM高吞吐、PagedAttention生产环境、高并发API中SGLang结构化生成、RadixAttention复杂推理任务、Agent场景中高TensorRT-LLM极致性能、NVIDIA优化大规模GPU集群高这张表不是让你照着选而是让你先有个全局观。我见过太多人上来就装vLLM结果发现自己只有一张消费级显卡显存根本不够折腾半天跑不起来最后换回Ollama五分钟搞定。2.2 为什么我建议从Ollama或llama.cpp起步如果你刚开始接触大模型推理我强烈建议先用Ollama或llama.cpp跑通一个模型。原因很简单你需要先建立“模型能跑”的体感再去追求“跑得快”。Ollama的安装和启动极其简单基本就是下载、安装、一行命令拉模型、一行命令跑起来。它帮你处理了模型格式转换、量化、显存分配这些琐事你只需要关心“我想跑哪个模型”。llama.cpp稍微底层一点但胜在可控性强支持GGUF格式的量化模型在CPU上也能跑出可用的速度。这里插一句关于量化的说明。量化是把模型权重从高精度比如FP16压缩到低精度比如INT4、Q4_K_M的过程。量化的好处是显存占用大幅降低坏处是精度会有损失。我实测下来Q4_K_M级别的量化在大多数对话任务上几乎感觉不到质量下降但显存占用能降到原来的四分之一左右。对于消费级显卡来说量化几乎是必选项。2.3 什么时候该上vLLM或SGLang当你需要同时服务多个用户、要求高吞吐低延迟的时候Ollama就不够用了。这时候vLLM和SGLang是更合适的选择。vLLM的核心卖点是PagedAttention简单说就是把KV Cache键值缓存像操作系统管理内存页一样管理起来避免了显存碎片化大幅提升了显存利用率和吞吐量。我实测过同样的硬件配置下vLLM的吞吐量能比朴素实现高出好几倍。SGLang则在结构化生成上做了很多优化。它的RadixAttention可以复用多个请求之间的公共前缀这在Agent场景下特别有用——因为Agent往往会带着一大段系统提示词反复调用模型公共前缀复用能省下大量计算。另外SGLang对JSON格式输出、函数调用这类结构化任务的支持也更自然。注意vLLM和SGLang都对显卡有一定要求建议至少有一张显存16GB以上的NVIDIA显卡。消费级显卡虽然也能跑但batch size上不去吞吐优势发挥不出来。3. 推理服务的启动与配置实战3.1 用SGLang serve启动一个推理服务SGLang的启动命令设计得比较直观基本格式是python -m sglang.launch_server \ --model-path /path/to/your/model \ --host 0.0.0.0 \ --port 30000 \ --tp 1 \ --mem-fraction-static 0.85逐参数解释一下。--model-path指向模型权重目录可以是HuggingFace格式的本地路径。--host 0.0.0.0表示监听所有网卡方便局域网内其他机器访问。--port指定端口默认是30000。--tp 1表示张量并行度为1也就是用一张卡如果你有多张卡可以设为2或4。--mem-fraction-static 0.85表示静态分配85%的显存给模型权重和KV Cache留15%给其他开销。这个mem-fraction-static参数很关键。设得太高容易OOM设得太低KV Cache空间不够并发能力上不去。我的经验是如果是专用推理服务器可以设到0.85到0.9如果还要跑其他任务降到0.7左右比较稳妥。启动之后SGLang会暴露一个兼容OpenAI API的接口你可以直接用OpenAI的SDK去调用from openai import OpenAI client OpenAI( base_urlhttp://localhost:30000/v1, api_keyEMPTY ) response client.chat.completions.create( modelyour-model-name, messages[ {role: system, content: 你是一个专业的助手。}, {role: user, content: 解释一下什么是KV Cache。} ], temperature0.7, max_tokens512 ) print(response.choices[0].message.content)这里api_key填EMPTY就行因为本地服务不做鉴权。但如果你要把服务暴露到公网务必加上鉴权层否则你的推理服务就是裸奔状态。3.2 显存不够怎么办几个实用的降显存手段显存不够是推理部署中最常见的问题。我整理了几个按优先级排序的手段第一量化。这是最直接有效的手段。把FP16模型量化到INT8或INT4显存占用直接减半甚至降到四分之一。GGUF格式的Q4_K_M量化在llama.cpp和Ollama里是默认推荐vLLM也支持AWQ和GPTQ量化。第二限制上下文长度。KV Cache的大小和上下文长度成正比。如果你不需要模型记住很长的对话历史把max_model_len调小能省下大量显存。比如从8192降到4096KV Cache直接减半。第三调整batch size。推理时的batch size越大吞吐越高但显存占用也越大。如果显存紧张把并发请求数限制住宁可排队也不要OOM。第四CPU offload。把部分层放到CPU上跑显存不够内存来凑。但代价是速度会明显下降只适合对延迟不敏感的场景。第五换更小的模型。7B跑不动就换3B3B跑不动就换1.5B。很多时候一个小模型加上好的prompt工程效果不比大模型差多少。3.3 温度参数到底在调什么temperature这个参数几乎每个推理接口都有但很多人只是模糊地知道“调高更随机调低更确定”。我试着把这个事情说透。模型输出的本质是一个概率分布。给定上文模型会为词表中的每个token算一个logit值然后通过softmax转成概率。temperature就是在softmax之前对logit做缩放logit / temperature。当temperature1时就是原始分布。当temperature1时logit之间的差距被放大高概率的token更容易被选中输出更确定、更保守。当temperature1时logit之间的差距被缩小低概率的token也有机会被选中输出更多样、更有创意。极端情况下temperature趋近于0就等价于贪心解码每次都选概率最高的token。temperature趋近于无穷大就变成均匀分布输出完全随机。我的实操建议是做事实性问答、代码生成temperature设0.1到0.3做创意写作、头脑风暴设0.7到1.0做需要多样性的探索任务可以到1.2。但不要设太高超过1.5之后输出质量会明显下降容易出现胡言乱语。4. 思维链与推理能力的那些事4.1 思维链为什么有效思维链Chain of Thought是这两年推理领域最热的话题之一。它的核心思想很简单让模型在给出最终答案之前先把推理过程写出来。为什么这样有效我的理解是大模型的“思考”是通过token生成来实现的。模型每生成一个token就相当于做了一次计算。如果直接让模型输出答案它只有很少的token预算来完成推理。但如果让它先写推理步骤它就获得了更多的“计算空间”能把复杂问题拆解成多个简单步骤逐步求解。这就像让你心算一道复杂的数学题直接报答案很容易错但如果给你一张草稿纸让你把中间步骤写下来正确率会大幅提升。思维链就是给模型的“草稿纸”。在实际使用中触发思维链最简单的方式就是在prompt里加一句“Lets think step by step”或者“请一步一步推理”。对于中文模型后者效果通常更好。更高级的做法是few-shot思维链也就是给几个带推理步骤的示例让模型模仿这种格式。4.2 强化微调与推理能力提升思维链解决的是“怎么让模型把推理过程写出来”而强化微调Reinforcement Fine-Tuning解决的是“怎么让模型推理得更准”。强化微调的基本思路是让模型对同一个问题生成多个答案然后根据答案的正确性给不同的奖励信号用这些信号去更新模型权重。这个过程会强化那些能导向正确答案的推理路径弱化那些容易出错的路径。这和传统的监督微调不一样。监督微调是告诉模型“这个输入对应的正确输出是什么”强化微调是告诉模型“你这次的输出好/不好”让模型自己去探索什么样的推理路径更好。后者更接近人类学习复杂技能的方式——不是背答案而是通过反馈不断调整策略。不过强化微调的门槛不低。它需要一套可靠的奖励机制怎么判断答案对不对需要大量的采样计算每个问题要生成多个答案还需要稳定的训练流程。对于大多数团队来说先把prompt工程和思维链做好性价比更高。4.3 推理任务中的常见陷阱在做推理任务时我踩过几个典型的坑这里分享一下。第一个坑过度依赖思维链。不是所有任务都需要思维链。简单的分类、抽取、改写任务加思维链反而会让输出变长、变慢甚至引入不必要的错误。我的判断标准是如果这个任务人类需要“想一下”才能做对那就加思维链如果人类可以脱口而出那就不加。第二个坑忽略输出格式约束。推理任务的输出往往需要被程序解析。如果模型输出的JSON格式不稳定下游系统就会崩。解决办法是在prompt里明确给出格式示例并且在推理框架层面开启结构化输出约束。SGLang和vLLM都支持通过正则表达式或JSON Schema来约束输出格式。第三个坑上下文太长导致推理质量下降。模型对上下文中间部分的信息往往关注不够这就是所谓的“lost in the middle”现象。如果推理任务依赖的關鍵信息在很长的上下文中间模型可能会忽略它。解决办法是把关键信息放在上下文的开头或结尾或者在prompt里显式提醒模型关注某段内容。5. 本地部署与成本控制5.1 本地部署的硬件门槛“本地部署大模型”是很多人的执念但硬件门槛确实存在。我按显存大小给个粗略的参考显存能跑的模型规模量化级别体验8GB7BQ4能跑速度一般12GB7B-13BQ4/Q5比较流畅16GB13B-20BQ4流畅24GB30B-34BQ4流畅可上更高精度48GB70BQ4生产可用这张表是经验值实际能跑什么模型还取决于模型结构、上下文长度、并发数等因素。比如同样是7B模型有的架构就是比别人吃显存。如果你没有独立显卡用CPU跑也不是不行但速度会慢很多。llama.cpp在CPU上的优化做得不错7B Q4模型在现代CPU上大概能跑到每秒几个token做个人助手勉强够用做生产服务就别想了。5.2 云上部署的成本账本地部署搞不定那就上云。云上部署大模型推理的成本主要由三块构成GPU实例费用、存储费用、网络费用。其中GPU实例是大头。以一张A100 40GB为例按需实例每小时大概几美元到十几美元不等包月会便宜不少。如果你要7x24小时跑服务包月比按需划算得多。但如果你只是做实验、跑demo按需实例用完就关反而更省。这里有个容易被忽略的点推理服务的成本不只是GPU还有闲置成本。如果你的服务流量波动很大高峰期需要多张卡低谷期卡闲着也是要付钱的。这时候可以考虑用Serverless推理服务按实际调用量计费流量低谷时自动缩容到零。5.3 防止鉴权信息泄露的实操建议使用大模型API时密钥泄露是个真实存在的风险。我见过有人把API Key硬编码在前端代码里结果被人扒出来刷了几千美元的账单。这里给几条实操建议。第一密钥永远不要出现在客户端。所有API调用都应该经过你自己的后端服务器中转客户端只和你的后端通信不直接和模型服务商通信。第二用环境变量或密钥管理服务。不要把密钥写在代码里更不要提交到代码仓库。用环境变量注入或者用云服务商提供的密钥管理服务。第三设置用量上限和告警。大多数模型服务商都支持设置每日/每月消费上限达到阈值自动停止服务。这个一定要设是最后一道防线。第四定期轮换密钥。即使没有泄露迹象也建议定期更换密钥。万一之前泄露了但你没发现轮换能及时止损。第五日志脱敏。如果你在日志里记录了请求内容确保密钥等敏感信息被脱敏处理。很多泄露事故不是密钥被直接偷走而是日志里不小心打出来了。6. 常见问题与排查技巧实录6.1 推理服务启动失败排查表现象可能原因排查方法启动时报OOM显存不足降低mem-fraction-static或换更小模型启动时报CUDA错误驱动/CUDA版本不匹配检查nvidia-smi和CUDA版本启动后无法访问端口被占用或防火墙检查端口监听状态和防火墙规则请求返回超时模型加载慢或显存不足查看日志确认模型是否加载完成输出乱码tokenizer不匹配确认模型和tokenizer版本一致输出重复解码参数问题调整repetition_penalty和temperature这张表是我在实际运维中总结出来的覆盖了大部分常见问题。遇到问题先查表能省不少时间。6.2 输出质量不稳定的排查思路输出质量不稳定是另一个高频问题。同样的prompt有时候回答很好有时候答非所问。排查思路如下。先看temperature。如果temperature设得太高输出波动大是正常的。做确定性任务时把temperature降到0.1以下。再看prompt。prompt里如果有歧义模型输出就会不稳定。把prompt写得更明确、更具体给出输出格式示例能显著提升稳定性。然后看上下文长度。如果上下文接近模型的max length模型可能会“忘记”前面的内容。适当缩短上下文或者把关键信息放在更靠前的位置。最后看模型本身。有些模型在某些任务上就是不稳定这是模型能力问题换模型比调参数更有效。6.3 几个我踩过的坑坑一以为batch size越大越好。实际上batch size太大会导致单个请求的延迟上升用户体验反而变差。生产环境要根据延迟要求来定batch size不是越大越好。坑二忽略预热。推理服务刚启动时第一次请求会特别慢因为要加载模型、编译kernel。生产环境一定要做预热启动后先跑几个请求把服务“热”起来再接入流量。坑三不监控显存碎片。长时间运行后显存碎片会导致明明还有空闲显存却分配不出来。vLLM的PagedAttention就是解决这个问题的但如果用其他框架要定期重启服务来清理碎片。坑四prompt里放了太多无关信息。上下文越长推理越慢成本越高。prompt要精简只放必要的信息。我见过有人把整个知识库塞进prompt结果每次请求都要处理几万token成本和延迟都爆炸。坑五不做输出校验。模型输出不一定可靠尤其是结构化输出。下游系统一定要做校验格式不对就重试或报错不要盲目信任模型输出。7. 推理能力的边界与扩展7.1 当前推理能力的真实水平说句实在话当前大模型的推理能力被高估了。在数学、逻辑、代码这些有明确规则的任务上模型表现不错但在需要常识、因果推断、多步规划的任务上模型还差得远。我做过一个简单的测试让模型解一道需要三步推理的应用题。如果直接问正确率大概六成加上思维链能到八成但如果把题目里的数字换成不常见的组合正确率又掉回五成。这说明模型的推理能力很大程度上依赖训练数据里的模式匹配而不是真正的逻辑推演。所以我的建议是把模型当成一个能力很强但不太可靠的助手而不是一个可以完全信任的专家。关键决策要人工复核重要输出要交叉验证。7.2 Agent场景下的推理挑战Agent是大模型推理的一个重要应用方向。Agent的核心是让模型自主规划、调用工具、完成多步任务。这对推理能力提出了更高要求。在Agent场景下推理面临的挑战主要有三个。一是错误累积多步任务中每一步都可能出错错误会逐步放大。二是工具调用格式模型需要输出结构化的工具调用请求格式不对就执行不了。三是上下文管理Agent的对话历史会越来越长怎么在有限的上下文里保留关键信息是个难题。应对这些挑战我的经验是给Agent设计清晰的工具接口用结构化输出约束格式在每一步之后做校验和纠错并且定期总结和压缩上下文。这些工程手段比单纯提升模型能力更有效。7.3 推理优化的未来方向从技术趋势看推理优化有几个方向值得关注。一是更高效的注意力机制比如FlashAttention、RadixAttention通过减少内存访问来提速。二是更好的量化方法在保持精度的同时进一步压缩模型。三是推测解码用一个小模型来“打草稿”大模型来“审核”提升生成速度。四是硬件专用优化针对特定芯片做kernel级别的优化。这些方向离普通开发者有点远但了解它们有助于你判断技术选型。比如你在选推理框架时如果框架已经支持了FlashAttention和推测解码那它的性能上限就更高。8. 一些个人体会写了这么多最后分享几点我在实际工作中的体会。第一不要追求一步到位。推理部署是个迭代过程。先用最简单的方式跑起来再逐步优化。我见过太多人想一开始就搭一个完美的推理系统结果卡在环境配置上就放弃了。第二性能优化要有数据支撑。不要凭感觉调参数。用压测工具测出baseline然后每次只改一个参数看效果。盲目调参只会浪费时间。第三成本意识要贯穿始终。推理是要花钱的而且花起来很快。每次做技术选型时都要算一下成本账。有时候用大模型API比自建更划算有时候反过来关键看你的调用量和延迟要求。第四保持学习。这个领域变化太快了半年前的最佳实践可能现在已经过时。多关注社区动态多动手实验比看多少篇文章都管用。第五别忘了用户体验。推理速度、输出质量、稳定性最终都是为体验服务的。技术指标再好看用户用着不爽就是白搭。做技术决策时多从用户角度想一想。