1.1 开源模型推理的定义、边界与核心价值
我自己刚开始接触大模型那会儿，总觉得"推理"这个词特别玄乎。后来折腾久了才慢慢摸清楚，所谓开源模型推理，说白了就是把训练好的开源大模型跑起来，让它根据你的输入生成输出。训练阶段模型在海量数据上学规律，推理阶段就是拿学到的本事解决实际问题。你问一句它答一句，你丢一段文本它给你摘要，这些动作背后全是推理在干活。
边界这块得说清楚。推理不包含训练、微调、对齐这些环节，那些是让模型变聪明的过程。推理关注的是模型已经定型之后怎么高效地用起来。有人把模型量化、格式转换也算进推理范畴，这个说法我认可，这些操作确实是为推理服务的。有人把数据预处理、后处理也塞进来，我觉得看场景，端到端的推理服务里这些环节跑不掉，单独讨论推理引擎的时候它们又在外面。
核心价值我总结成三个层面。成本层面，开源模型推理让你不用按 token 给闭源厂商交钱，自己买卡自己部署，用得多省得多。可控层面，模型权重在你手里，数据不出你的机房，敏感业务敢往上放。灵活层面，你能改推理参数、换量化方案、接自己的业务逻辑，闭源 API 给不了这种自由度。我见过不少团队从调 API 起步，量一上来就转自建推理，算下来一年省的钱够养一个小团队。
1.2 推理关键指标与典型应用场景
聊推理绕不开几个硬指标。延迟是我最在意的一个，用户问完问题等三秒和等三十秒，体验完全是两码事。首 token 延迟和整体生成延迟要分开看，前者决定"它开始回答"的速度，后者决定"它说完"的速度。吞吐量是另一个维度，单位时间能处理多少请求，直接关系到你的服务能扛多少并发。这两个指标经常打架，批处理开大了吞吐上去了延迟也上去了，调参就是找平衡点。
显存占用和成本也得盯着。模型参数再多，塞不进卡里就是空谈。量化能把显存压下来，精度掉多少得自己测。每百万 token 的推理成本是个很实在的指标，云上按小时计费和自建按折旧摊销算出来的数不一样，我建议两种都算一遍心里才有底。质量指标容易被忽略，困惑度、任务准确率这些，量化之后掉点厉害的话，省下来的成本可能还不够补业务损失。
应用场景这块我按自己踩过的坑分几类。对话助手是最常见的，客服、问答、陪伴类产品都在用，这类场景对首 token 延迟敏感，对吞吐要求中等。内容生成类比如写文案、做摘要、翻译，批量跑任务，吞吐优先。代码补全和 RAG 检索增强是这两年的大热门，前者要求极低延迟，后者要求长上下文处理能力。还有一类是离线批处理，夜里跑数据标注、文档解析，延迟无所谓，成本压到最低就行。场景不同，选框架和调参数的思路完全不一样。
1.3 开源模型推理生态与全文结构导览
生态这块我画过一张自己的地图。底层是硬件和驱动，NVIDIA、AMD、Apple Silicon 各有各的玩法。中间层是推理框架，vLLM、TensorRT-LLM、llama.cpp、Ollama、SGLang、TGI 这些名字你肯定见过，它们解决的是怎么把模型高效跑起来的问题。上层是模型本身，Llama 系、Qwen 系、DeepSeek 系、Mistral 系，开源社区每个月都有新东西冒出来。再往上就是应用和工具链，API 网关、监控、编排，把推理服务接进业务系统。
这个生态变化快得吓人。半年前好用的方案今天可能就被新框架比下去了，我自己的习惯是盯着几个核心项目的 release notes，再逛逛 Reddit 和 Hugging Face 的讨论区，保持手感。别指望一次选型管三年，留好切换成本比选对某个框架更重要。
后面几章我打算这么展开。第2章把主流框架拉出来横向对比，给你一张能力地图和选型方法。第3章手把手走一遍本地部署，从环境准备到 API 调用再到排错。第4章聊优化和落地，批处理、KV Cache、量化这些关键技术，还有成本安全和生产实践。你现在读的这一章是地基，把概念和指标理清楚，后面看对比和教程才不费劲。我自己写这些内容的时候也在一路复盘，希望对你有点用。
2.1 主流开源推理框架能力地图：vLLM、TensorRT-LLM、llama.cpp、Ollama、SGLang、TGI 等
我一开始选框架的时候挺懵的，GitHub 上搜一圈，每个项目都说自己快、说自己省显存，到底该信谁。后来用多了才明白，这些框架压根不是同一个物种，有的冲着服务端高并发去的，有的就是给你笔记本上跑着玩的。把它们放在一张能力地图上看，思路会清楚很多。我按自己理解的定位把它们粗略分了三档：服务端重型武器、本地轻量工具、还有夹在中间专门啃特定场景的。
vLLM：PagedAttention 打出来的服务端主力
vLLM 是伯克利那帮人搞出来的，我最早注意到它就是因为 PagedAttention 这个点子。传统推理那套 KV Cache 管理，显存碎片化特别严重，vLLM 把操作系统的虚拟内存分页思路搬了过来，KV Cache 按块管理，显存利用率一下子上去了。我实测过一个 7B 模型，同样一张 24G 的卡，vLLM 能扛的并发数比朴素实现高好几倍，这个差距挺震撼的。
它的生态也做得顺，Hugging Face 上的模型基本拿来就能跑，OpenAI 兼容的 API 服务开箱就有，接现有业务代码改动很小。社区活跃度在开源推理框架里是第一梯队的，issue 回复快，新模型支持跟得紧。我个人的感觉，云端部署、要扛并发、又想少折腾，vLLM 是默认选项之一。它也不是没短板，对非 NVIDIA 硬件的支持在持续补，某些新卡新特性的跟进速度还是得看上游。
TensorRT-LLM：NVIDIA 亲儿子，性能天花板但要耐心
TensorRT-LLM 是 NVIDIA 自己下场做的，走的路线跟 vLLM 完全不一样。它把模型编译成 TensorRT 引擎，算子融合、kernel 调优全在编译期做掉，跑起来那叫一个快。我在 A100 上对比过，同样的模型同样的 batch，TensorRT-LLM 的吞吐经常能把 vLLM 甩开一截，首 token 延迟也压得更低。冲着极致性能去的话，绕不开它。
它的门槛也摆在那。模型得先转换、编译，这个过程动不动几十分钟，换个模型或者改个配置又得重来。版本耦合比较紧，TensorRT、CUDA、驱动之间的兼容矩阵得对着文档查半天。我踩过一次坑，驱动版本差一个小版本，引擎就是加载不起来。适合什么人呢，硬件固定、模型固定、追求极致性价比的生产环境，有专人维护的话它很香。临时实验、模型天天换的场景，用它就是给自己找麻烦。
llama.cpp：C++ 老炮，本地和边缘的万金油
llama.cpp 是 Georgi Gerganov 发起的项目，纯 C++ 实现，不依赖一堆 Python 生态，编译出来一个可执行文件就能跑。它最厉害的地方是硬件覆盖面，CPU、Apple Silicon、各种消费级 GPU 都能用，GGUF 格式的量化模型在社区里流通得特别广。我在 MacBook 上跑过 7B 的 Q4 量化模型，速度谈不上飞快，日常问答够用，风扇都不怎么转。
这个项目对量化的支持是我见过最细的，从 Q2 到 Q8，还有 K-quants 各种变体，精度和体积的取舍空间很大。嵌入式设备、边缘盒子、没独立显卡的办公电脑，llama.cpp 往往是唯一能跑起来的选择。它的服务端能力相对弱一些，连续批处理这些高级特性支持得晚，高并发场景不是它的主场。我一般把它定位成"让模型在哪儿都能跑"的兜底方案。
Ollama：一层好用的壳，本地实验的上手神器
Ollama 底层用的就是 llama.cpp，外面套了一层特别顺手的命令行和模型管理。ollama run qwen2 一条命令，模型自动下载、自动加载，直接就能对话。我推荐给好几个非技术背景的朋友，他们十分钟内都能在自己电脑上跑起大模型，这个体验别的框架给不了。模型库里预置了一堆常见开源模型，拉取方便，版本管理也省心。
它的定位很清楚，就是本地实验和轻量应用的快速通道。你想调底层参数、换复杂的并行策略、做精细的性能调优，Ollama 会把很多细节藏起来，反而不方便。我见过有人拿 Ollama 做小团队内部工具，几十个人用着挺舒服。真要上生产扛流量，还是得往下挖一层，换成 vLLM 或者 TGI 这类。
SGLang：结构化生成和前缀共享的巧劲
SGLang 这两年冒出来得很快，它的切入点跟前面几个不太一样。RadixAttention 这个机制专门优化前缀共享，多轮对话、few-shot 提示、agent 反复调工具这些场景，大量 prompt 前缀是重复的，SGLang 能把这些 KV Cache 复用起来，省显存也省算力。我做过一个带长系统提示的客服场景，换成 SGLang 之后显存占用降了快一半。
它还带了一套结构化生成的语言，约束输出格式特别方便，JSON、正则、语法约束都能直接写。做 agent 或者需要严格输出格式的业务，这个特性很实用。社区规模比 vLLM 小一些，文档还在完善中，遇到冷门问题得自己翻源码。我把它当成特定场景的加速器，不是所有任务都适合，前缀复用收益大的时候它很亮眼。
TGI：Hugging Face 出品，生产部署的老牌选手
TGI 全称 Text Generation Inference，Hugging Face 做的，Rust 写的服务端，Docker 镜像用起来很顺。它的特点是生产属性强，指标暴露、健康检查、tensor 并行、token 流式输出这些企业级功能给得比较全。HF 生态里的模型支持基本不用操心，新模型发布经常当天就能跑。
我早期做推理服务的时候 TGI 是主力，稳定性没得说，文档也全。这两年 vLLM 在吞吐上的优势比较明显，TGI 的热度被分走了一些。它的迭代节奏还在，功能和性能一直在补。团队已经在用 Hugging Face 全家桶、想要一个稳当的生产服务端，TGI 仍然是很合理的选择。选型这事有时候不只看跑分，生态契合度和团队熟悉程度也很重要。
把这几家摆在一起看，我的感受是没有全能冠军。vLLM 在通用服务端场景最均衡，TensorRT-LLM 在 NVIDIA 硬件上性能最猛但最挑环境，llama.cpp 覆盖硬件最广，Ollama 上手最快，SGLang 在特定负载下有奇效，TGI 生产属性扎实。选哪个，取决于你手头的卡、要跑的模型、扛的流量，还有团队愿意投入多少维护精力。这几个问题想清楚了，答案基本自己就浮出来了。
3.1 环境准备与硬件评估：GPU、内存、显存与操作系统依赖
我干过最蠢的一件事，是拿到一张新卡就急着拉模型开跑，结果驱动版本太老，cuda 编译那一步直接卡了俩小时。后面才养成习惯，动手之前先把这套环境盘一遍。硬件评估先看显存，模型的参数量和量化位宽基本能算出个数。7B 模型 FP16 大概要 14G 显存，Q4 量化能压到 4G 出头。你要开长上下文、拉大 batch，这个数还得往上翻。我习惯留 20% 的余量，别让显存跑到崩。
内存这块不少人容易忽略。模型加载的时候会先读到内存再进显存，量化转换、格式转换这些操作对内存的要求也不低。我试过在一台 16G 内存的机器上转 13B 的模型，操作系统直接开始频繁 swap，转换速度慢到怀疑人生。CPU 有没有 AVX2、AVX512 指令集，也影响 llama.cpp 这类纯 CPU 推理的体验，差一档指令集速度能差出一倍。
操作系统依赖是我踩坑最多的地方。CUDA 驱动、CUDA Toolkit、cuDNN 三者之间的版本对应关系，NVIDIA 官方那张兼容表最好工工整整对着查一遍。Docker 部署能绕开不少依赖地狱，NVIDIA Container Toolkit 装好之后镜像里的环境一般都比较干净。我现在的做法是，物理机上只留驱动，剩下全扔进容器，出了问题删掉重建，心理负担小很多。Python 虚拟环境也别省，conda 或者 venv 建一个隔离的，省得跟系统 Python 打架。
3.2 模型获取、量化与格式转换
模型从哪拿，国内国外两条路。Hugging Face 上模型最全，huggingface-cli download 或者 git lfs 拉都行，网络条件不好的话挂个镜像站。ModelScope 上的版本对国内网络友好一些，很多国产模型第一时间会同步上去。我一般会看一眼模型的 license，商用和研究的边界差别挺大，有些模型写着开源但加了商用限制，这条线最好提前弄清楚，别等做出东西了才发现踩雷。
量化这事得单独说说。原始 FP16 模型体积大、跑起来吃资源，量化是用一点点精度换体积和速度。GPTQ、AWQ 这俩是 GPU 上常用的，AWQ 对激活值的量化更细腻一些，实际体感精度损失更小。GGUF 是 llama.cpp 那套生态的格式，Q4_K_M 是我用得最多的档位，体积和精度平衡得不错。转换的时候我习惯先在验证集上跑一遍，看困惑度或者任务指标掉多少，掉得狠就往上换一档量化。
格式转换的工具有几个得备着。llama.cpp 仓库里带了 convert_hf_to_gguf.py，能直接把 Hugging Face 格式转过去。AWQ 和 GPTQ 走 AutoAWQ、AutoGPTQ 这些包，几行代码的事，不过转换过程对显存有要求，7B 模型至少得留 20G 才稳。我踩过的坑是忘看模型配置文件，有的模型带自定义层，转换脚本不认，得手动改代码。转换完记得拿个刁钻的问题测一下，确认没变成一个只会说胡话的模型。
3.3 本地推理服务部署与 API 调用
本地跑推理服务，我走了两条路。一条是 Ollama，一条是 vLLM。Ollama 装完 ollama serve 一起，默认 11434 端口，后面接个 ollama run qwen2:7b 就能对话。它自己也暴露了 API，不过格式跟 OpenAI 那套不完全一样。小工具、个人实验用它最舒服，模型管理全给你包了，改个 Modelfile 就能调温度、系统提示这些参数。
vLLM 的路子更正经一点。pip 装好之后一行命令起服务，vllm serve Qwen/Qwen2-7B-Instruct --port 8000，它默认就给你开一个 OpenAI 兼容的接口。这个兼容性太重要了，我之前写的那些调 OpenAI 的代码一行不改就能指过来，换个 base_url 换个 key 的事。参数上我一般会显式指定 --gpu-memory-utilization 0.9、--max-model-len，把显存上限钉死，免得它贪吃把系统搞崩。
API 调起来其实很朴素。curl 一把梭，POST 一个 JSON，model、messages、temperature、stream 这几个字段就够用了。Python 侧用 openai 官方库直接指到本地端口，client.chat.completions.create 该怎么写怎么写。流式输出记得把 stream=True 打开，前端体验完全是两个档次。我做内部 demo 的时候，后端 vLLM，前端一个简单网页，流式打字机效果出来，领导觉得这事儿挺高级，其实代码量少得可怜。
3.4 性能验证、监控指标与常见问题排查
服务起来之后别急着喊完工，先拿数据说话。我一般会盯三个数：首 token 延迟（TTFT）、每 token 输出时间（TPOT）、还有整体吞吐（tokens/s）。前两个决定用户体感，第三个决定你一张卡能扛多少活。压测工具我用过 vllm bench、locust，懒得搭就用一段循环脚本灌并发，看 QPS 和 P99 延迟的曲线。曲线开始往上翘的那个点，就是你当前配置的极限。
监控这块，基础的是 GPU 利用率和显存占用，nvidia-smi 一行命令能看，长时间跑的话挂个 nvitop 或者 Prometheus + Grafana 舒服很多。vLLM 自己会暴露 /metrics 接口，队列长度、KV Cache 使用率、命中率这些指标都在里面，KV Cache 快满的时候就是准备扩容的信号。我遇到过吞吐突然掉一半的情况，翻指标发现是 KV Cache 反复换出，把 max-model-len 调小或者换更高位宽的卡就解决了。
常见问题我列几个自己撞过的。OOM 最常见，原因一般是 max-model-len 设太大、并发数超了、或者显存预分配没留余量。模型加载报错，先看版本，transformers、torch、vllm 三者版本打架的概率不低。响应特别慢但不报错，多半是量化模型落在了不支持的 kernel 上，回退到了慢速路径。还有一次让我折腾半天的问题，是端口被占用了但日志没明说，连接一直超时。排查这事我现在的习惯是，从日志最上面开始看，别一上来就翻到底部找异常，很多线索都藏在启动信息里。
4.1 推理性能优化关键技术
我到现在都记得第一次把服务推到预发环境那个下午。本地单条请求跑得好好的，一上并发，P99 延迟直接窜到十几秒，监控面板上 GPU 利用率连一半都没摸到。那天之后我才算真正理解，模型能跑通只是拿到了入场券，后面怎么把这张卡的算力榨干，才是分水岭。批处理是最先要动的地方，单条请求进来，GPU 大把时间耗在等数据搬来搬去，矩阵乘的并行度根本填不满。continuous batching 这个机制我依赖得最多，请求进进出出不用等整批凑齐才发车，vLLM 和 SGLang 在这个方向上都做得比较扎实。调参的时候我盯着 max-num-seqs 和 max-num-batched-tokens 这两个数来回试，前者管并发请求数量，后者管单次前向的 token 总量，两个参数一块儿拧，才能把显存和吞吐的甜点区找出来。
KV Cache 这块是另一个战场。自回归生成每吐一个 token，前面所有 token 的 key 和 value 都得留着，上下文一拉长，显存占用涨得让人心慌。PagedAttention 算是把这件事管明白了，把缓存切成固定大小的块，按需分配，碎片率一下就压下去了。prefix caching 我基本是默认开着的，系统提示词、few-shot 示例这些每次请求都一模一样的前缀，缓存住之后直接复用，首 token 延迟能从 800ms 掉到 300ms 出头，这个提升在交互场景里体感非常直接。量化在推理阶段的价值也值得单独拎出来说，AWQ 的 4bit 权重量化在 vLLM 里有专门的 kernel，7B 模型实测吞吐翻倍，精度掉的幅度在多数任务上都能接受。FP8 在 H100 上表现更均衡，权重和激活一起压到 8 位，精度损失比 INT4 小，速度提升也扎实。KV Cache 量化是另一个维度，把缓存本身从 FP16 压到 FP8，长上下文下能省出可观的显存，不过精度敏感的活儿我一般会先拿评测集过一遍再上线。
并行和编译优化，得看你手头是什么硬件家底。模型塞得进单卡，数据并行最省心，每张卡一份完整模型，请求分着来。塞不进去先试张量并行，把一层里的矩阵切开放到多张卡上，通信开销大但能扛住大模型。流水线并行切的是层，跨节点部署的时候用得多，延迟会比 TP 高一些，调度上的坑也不少。编译这块 CUDA Graph 是我认为性价比最高的一个，把一串 kernel 启动动作录下来直接回放，省掉大量 CPU 侧调度开销，小 batch 场景效果尤其明显。FlashAttention 系列现在基本是标配，新版 vLLM 默认就带，torch.compile 我也试过，编译时间不短，模型一变就得重来，生产环境里我只在稳定版本上开。
4.2 成本、安全与合规考量
算成本这件事，不能只盯着 GPU 小时单价。我见过不少团队拿着云厂商的按需价格一算，觉得贵得离谱，转头自建，结果运维人力、闲置浪费、故障处理这些隐性开支加起来，TCO 反而更高。我的做法是先按业务峰值和均值分别算两条线，峰值用弹性实例顶，均值用预留实例或者自建兜底，中间再拿竞价实例填谷。模型层面能省的地方也不少，7B 能干的事别上 70B，量化能接受的场景别硬扛 FP16，推理框架的显存利用率参数调好，一张卡多塞几个实例，单位 token 成本能砍下来一大截。
安全这块，做推理服务的人很容易只盯着模型效果，把外围防线给漏了。prompt 注入是我现在最警惕的一类问题，用户输入里夹带指令，把系统提示词给覆盖掉，轻则输出跑偏，重则把内部工具调用链给带出来。我的习惯是在网关层做输入清洗和长度限制，敏感系统提示跟用户输入之间加明确的分隔标记，工具调用权限按最小化原则收口。数据脱敏也不能省，日志里别把完整 prompt 和用户隐私字段原样落盘，该打码的打码。API 密钥管理走统一的密钥服务，别在代码里硬编码，访问控制按角色切分，生产环境的推理接口跟内部实验环境物理隔离，这些事做起来不复杂，真出事的时候能救命。
合规这条线，我踩过坑之后才学会提前看。模型 license 是最先要确认的，有些开源模型写着 Apache 2.0，有些挂着自定义协议，商用边界差别很大，做产品之前把这条捋清楚，比事后补救成本低太多。生成内容合规现在监管越来越细，面向公众的服务该做的内容审核、日志留存、备案流程一样不能少。数据层面，用户输入的存储期限、跨境传输这些事得跟法务对齐，别等审计来了才发现问题。我现在的习惯是每接一个新模型，先拉一张合规清单过一遍，license、训练数据来源、已知偏见、输出限制，一项一项打勾，心里踏实。
4.3 从本地实验到生产部署的实践路径
本地实验跟生产部署之间隔着一条挺宽的河。我在笔记本上跑通的 demo，搬到服务器上第一件事就是压测，拿 vllm bench 或者自己写个循环脚本灌并发，把 QPS、P99 延迟、GPU 利用率这三条曲线画出来，找到曲线开始往上翘的那个拐点，那就是当前配置的天花板。压测环境尽量贴近生产，硬件型号、驱动版本、模型量化档位都对齐，别在本地用 Q4 跑得好好的，生产上换成了 FP16，性能数据全对不上。我一般会留出 20% 到 30% 的容量冗余，流量高峰上来的时候不至于手忙脚乱。
灰度发布是我现在雷打不动的流程。新模型或者新配置先切 5% 的流量，盯着错误率、延迟分布、用户反馈这几个指标跑上一两天，没问题再逐步放量。监控得提前搭好，GPU 显存、KV Cache 使用率、队列长度、首 token 延迟这些指标都接到 Grafana 上，配好告警阈值。KV Cache 快满的时候就是扩容信号，别等 OOM 了才反应过来。我遇到过一次半夜吞吐掉一半的情况，翻指标发现是缓存反复换出，把 max-model-len 调小之后恢复正常，这种事有监控和没监控，处理时间差出好几个小时。
再往后就是工程化的活儿了。模型版本管理得有一套，权重文件、量化配置、推理框架版本三者绑定成一个发布单元，回滚的时候能整体切回去。CI/CD 流水线里我把压测和基础评测跑成卡点，指标不达标不让进生产。A/B 测试也在做，新老模型各接一部分流量，用业务指标说话，别光看 benchmark 分数。这套东西搭起来费点功夫，跑顺之后每次发版的心理负担小很多，不用再靠人肉盯盘。
4.4 开源模型推理趋势展望与学习资源
这两年推理侧的变化速度比我预想的快。MoE 架构的模型越来越多，推理时只激活一部分专家，单位 token 的算力成本降下来了，怎么把专家路由和批处理调度配合好，成了框架层的新课题。投机解码也在落地，小模型先草稿几个 token，大模型批量验证，接受率调好了延迟能砍掉三四成。端侧推理是另一条线，手机、PC 上跑小参数模型的需求涨得很快，llama.cpp 这套生态在量化格式和 CPU 优化上积累很深，值得持续跟。
硬件侧的变化同样值得关注。推理专用芯片这两年冒出来不少，FP8、INT4 这些低精度格式在硬件层面的支持越来越完整，框架对新型加速卡的适配也在提速。异构计算的路子开始多了，GPU 负责大模型主体，CPU 或者 NPU 分担一部分预处理和后处理，整体 pipeline 的效率能再往上走一截。我个人的判断是，未来一两年推理优化的重心会从单卡性能往集群调度和成本控制上偏，谁能在保证体验的前提下把单位 token 成本压得更低，谁就有优势。
学习资源我平时翻得比较多的几个方向。vLLM、SGLang、TensorRT-LLM 这几个仓库的 issue 区和 release notes 质量很高，很多优化细节和踩坑经验都在里面。论文方面 PagedAttention、FlashAttention、Speculative Decoding 这几篇是基础，读完再看框架源码会顺很多。社区里 LMSYS、Anyscale 的博客更新挺勤，工程实践的分享比较多。我自己的习惯是每看到一个感兴趣的优化点，就在本地搭个小环境跑一遍对比，数字落在自己手里才踏实，光看文章容易停留在“好像懂了”的阶段。
