企业官网建设流程全解析

1. 一次"调接口"的活，怎么干成了AI-Infra的活

去年我们内部知识库要上AI问答，领导拍板时说得很轻松："后端调一下大模型接口就行了。"我一开始也是这么以为的，结果一摊子事砸下来：并发一上来，推理服务直接超时；同一个模型在不同卡上表现天差地别；GPU显存看着够用，跑两个实例就OOM；账单月底一看，比预期贵了三倍不止。做了一圈下来我发现，自己其实已经在干AI-Infra的活了。

AI-Infra这个词这两年很热，但如果用一句话说到底，就是"让大模型跑得更快、更稳、更便宜"的所有工程手段。它不是某一个具体框架，也不是一套固定工具链，而是一整套从GPU资源到模型服务化再到业务接入的基础设施建设。对于一线工程师来说，这意味着两件事：第一，日常开发会遇到大量和"模型怎么跑起来"相关的活，显存、并发、延迟、成本全都绕不开；第二，这些技能现在非常稀缺，懂的人往往能在团队里承担关键角色。

这篇是"一线工程师的AI-Infra之路"的第一章，我不会堆概念，就按我自己从业务后端转过来、一点点把AI工程链路摸通的过程来讲。第一章先把全景图和最常见的计算账理清楚，后续章节再分别展开推理引擎、调度、成本优化这些具体方向。如果你现在正处于"要接大模型但不知道从哪下手"的阶段，或者已经在跑模型但被显存、性能、成本问题反复折磨，这篇会很对路。

2. AI-Infra四层全景：从GPU到token的完整链路

AI-Infra看着很玄，其实可以拆成清清楚楚的四层：硬件资源层、模型运行层、开发训练层、交付产品层。这个分层不是我发明的，是几乎所有做AI平台的公司都会对团队进行的职责切分。一线工程师不需要每层都精通，但必须知道每一层解决什么问题、哪些环节容易出幺蛾子、出了问题该找谁或者往哪个方向排查。

2.1 硬件资源层：一切从GPU和显存说起

这一层是整个AI-Infra的地基，核心资源就是GPU、显存和它们之间的互联带宽。现在跑推理最主流的卡，国内云上最常见的是A100、H100、H系列国产卡，个人和中小团队也大量用4090撑小模型。选卡只有一个硬道理：模型权重加运行时开销能不能塞进显存。7B模型用FP16精度，光权重就要约14GB，一张80GB的卡能装下还能留出推理空间；70B模型光权重就140GB，单卡肯定放不下，就得靠多卡张量并行切分，这时候卡间带宽就非常重要，NVLink、IB这些高速互联的价值就在这——带宽不够，多卡协同反而比单卡还慢。

我在这个层踩过最典型的坑是"看着显存够，实际一跑就炸"。普通应用看内存使用量，看的是均值；大模型推理看显存，看的是峰值和碎片。你以为是80GB总容量够用，但推理框架会预留KV cache，会留激活值缓冲区，还会有一大块不可控的碎片，所以真实的显存规划和裸权重大小之间，往往要差出30%到50%的余量。这一层的工程师日常就是查nvidia-smi、做显存巡检、规划NPU/GPU的分时调度，说白了就是给模型腾地方、找地方。

2.2 模型运行层：推理引擎才是真正的日常战场

这一层是AI-Infra里最核心、也是绝大多数工程师天天打交道的部分。解决的核心问题是：模型权重有了，怎么变成一个高并发、低延迟、成本可控的在线服务。

早期不少人直接拿Transformers库的Python接口上线，简单是简单，但吞吐低得离谱，并发一高就排队，显存还利用不起来。后来社区主流方案变成了专门为推理优化的引擎，典型代表有vLLM、TensorRT-LLM、SGLang。这里有一个概念必须理解：它们性能碾压朴素方案的关键，是把静态批处理改成了连续批处理。传统方式是一批请求齐了再统一算，像一辆大巴必须等人坐满才发车；连续批处理是只要有请求进来就发车，某个请求生成完token就下车，下一个请求立刻补位，GPU每一刻都在算，不空转。就这一个改变，推理吞吐能翻好几倍。

选引擎也是个讲究事。vLLM生态最全、上手最快，支持HuggingFace模型格式，兼容性最好，适合绝大多数在线推理场景；TensorRT-LLM速度上限最高，但要做模型编译和格式转换，工程链路长，适合把延迟压到极致、且模型结构比较固定的场景；SGLang在前缀缓存和复杂提示词场景下表现非常亮眼，适合RAG这类高并发前缀重复的负载。我一般建议新团队一律先从vLLM起步，别一上来就折腾TensorRT-LLM的门头。

2.3 开发与训练层：不只是算法团队的事

这一层包括数据清洗、模型微调、分布式训练、实验管理这些偏算法的工作，看起来跟基础设施关系不大，但真做微调时问题就来了。DeepSpeed、Megatron-LM这些框架里，ZeRO分片怎么配、梯度检查点开不开、批量大小怎么设，全都直接影响显存占用和训练速度。一线工程师未必亲自写训练脚本，但必须看得懂训练框架在干什么，否则连"为什么这张卡显存不够用"都解释不了。

我自己的体会是，只做推理接入的工程师常常忽视这层，直到团队开始微调领域模型才发现问题：数据上一秒能跑，下一秒加大批量就OOM；多机训练时网卡带宽不够，GPU利用率直接掉到30%以下。这些都是典型的AI-Infra问题，只不过发生在训练阶段。这层有一条很实用的经验：任何训练任务跑起来之前，先搞清楚单卡显存能容纳的模型加优化器状态有多大，再决定张量并行还是数据并行，不要盲目堆资源。

2.4 交付产品层：网关、容量与成本的控制台

模型服务化之后，它面对的还是普通流量，所以Kubernetes、网关、弹性伸缩、监控告警、成本分析这些传统基础设施技能依然是刚需。需要特别注意的是，LLM服务和普通Web服务的模式完全不同：每次请求的耗时不固定，生成长度从几十到几千token都有可能；显存是稀缺资源，不能简单按QPS来扩容；GPU卡又贵又不好买，多扩一台意味着多一大笔钱。

这层的核心工作包括：用KEDA这类组件按队列深度而不是QPS来扩缩容；用推理引擎自身的排队状态做容量评估；把token级别的用量接入成本核算系统；在网关层做超时控制和流控，防止一个长尾请求拖垮整批推理。和上面几层相比，交付层离业务最近，也最考验综合能力，因为你既要懂推理引擎内部机制，还得接得住业务方的各种奇怪需求。

我把四层的关键信息整理成一张表，方便对照自己当前在哪一层：

3. 一个7B模型从启动到上线：先把显存账算明白

聊完全景，来点实际的。很多工程师第一次接触AI-Infra，就是从"把模型跑起来"开始的。这里我用一个小模型——7B级别，比如Llama-3.1-8B，作为例子，完整走一遍从显存估算到服务启动再到看指标的过程。这一节的重点不是教你怎么用某个框架，而是告诉你"为什么这些参数要这么设"。

3.1 权重显存：最基础的账

模型显存占用的第一笔账是权重。以7B模型为例，7B是参数量，7后面跟9个零。FP16精度下每个参数占2个字节，所以权重显存 = 参数量 × 每个参数字节数 = 7 × 2 = 约14GB。如果是FP8或INT8量化，就是约7GB；如果是BF16，和FP16一致，还是约14GB。权重是必须常驻显存的，没有任何优化能绕过它。

但14GB只是起点。推理过程中还需要为每个请求计算中间激活值，这部分根据批量大小、序列长度上下浮动；还需要预留KV cache（下面细讲）；还有框架本身、CUDA context这些固定开销。以我实测的经验，在vLLM里跑7B模型，如果设gpu-memory-utilization=0.9，一张80GB的卡，留给KV cache的空间大约是60GB上下，这在绝大多数场景下都够支撑几十路的并发推理。很多新手只看到"权重14GB"就觉得20GB的卡够用了，实际跑起来立刻就OOM，就是漏算了KV cache和激活值这两大块。

3.2 KV cache：每个并发请求都在"抄便签"

KV cache是理解LLM推理成本的关键。大模型生成token是一个个来的：每生成一个新token，都要再看一遍前面所有历史token。为了不重复计算历史token的注意力结果，推理框架会把已经算出的Key和Value缓存下来，这就是KV cache。你可以把它理解成开会时每个人面前的便签本，前面的内容抄下来了，后来说的话只需要基于便签本接下去写，不用重新从头听一遍。

KV cache怎么算？公式是：单token KV cache字节数 = 2（K和V各一份）× 层数 × KV头数 × 注意力头维度 × 数据类型字节数。以一个典型的7B GQA模型为例，假设40层、8个KV头、每个头维度128、FP16存储，那么每个token需要 2 × 40 × 8 × 128 × 2 = 约163KB。看着不多，但乘上序列长度和并发数就变了：2K上下文单请求约320MB，32并发同时打过来就是约10GB。我见过很多人把显存规划只算了权重，没算KV cache，结果"明明装得下模型，一上量就炸"，怀疑是框架问题，其实纯粹是这笔账没算明白。

3.3 用vLLM把模型跑起来

账算清楚了，就可以用vLLM启动服务了。先装依赖，再启动：

pip install vllm vllm serve meta-llama/Llama-3.1-8B-Instruct \ --served-model-name qa-llama \ --gpu-memory-utilization 0.9 \ --max-model-len 8192 \ --tensor-parallel-size 1 \ --port 8000

这里几个参数值得细说。--gpu-memory-utilization是控制显存利用率的，0.9表示把90%的显存交给推理框架，剩下10%留给CUDA context和系统开销。如果你设得偏低，比如0.5，模型能跑但KV cache空间小，并发稍高就排队；设成0.95以上，又会增加OOM风险。--max-model-len是模型能处理的最大上下文长度，8192意味着8K token，如果设得过高，比如32K，KV cache预留空间巨大，会严重压低并发上限。--tensor-parallel-size是张量并行卡数，7B在单卡能放下，设1就行；70B模型至少设8，让8张卡一起扛。

启动后就可以用了：

curl http://localhost:8000/v1/chat/completions \ -H "Content-Type: application/json" \ -d '{"model":"qa-llama","messages":[{"role":"user","content":"介绍一下AI网关"}]}'

返回里会带usage字段，包含prompt_tokens和completion_tokens，这两个数字后面做成本核算会反复用。

3.4 压测时该看的三个指标

服务跑起来后，第一件事不是马上接业务，而是压测。LLM服务压测和普通接口压测看的指标完全不同，核心是这三个：

TTFT，首token延迟，指从请求发出到返回第一个token的时间。这个指标直接决定用户"有没有感觉到卡顿"。一般在线交互场景希望TTFT在1秒以内，超过3秒用户明显不耐烦。

TPOT，每个输出token的延迟，指生成一个token需要多少时间。它决定整段回答的流畅度。读起来像正常语速的对话，大概每秒生成10到30个token，也就是TPOT在30到100毫秒之间。

还有一个是整体吞吐，tokens/s，指服务每秒能生成多少token。这个指标用于衡量服务的总处理能力，决定你需要几台实例。压测时我习惯先固定并发数从1打到64，观察TTFT和TPOT的拐点在哪里，那个拐点就是这台服务的稳定边界。我曾经测过一个服务，并发从8涨到16时TTFT直接翻了5倍，但TPOT几乎没变——这说明瓶颈在排队调度而不是生成速度，优先应该调的是队列和并发上限，而不是盲目加卡。

4. 一线踩坑最深的三个地方：调度、观测、成本核算

全景和基础计算讲完，这一节说点真刀真枪的坑。我接触AI-Infra以来，团队里反复出问题的基本集中在三个地方：GPU调度碎片化、观测指标错位、成本核算缺失。这三个坑是"调接口心态"转向"基础设施心态"的分水岭。

4.1 GPU调度碎片：明明有卡，却装不下一个模型

传统微服务部署，容器调度粒度很小，CPU资源可以按0.1核切分，内存可以按M切分，碎片化影响不大。但GPU调度完全是另一回事。默认情况下，Kubernetes里一张GPU卡只能整卡调度，nvidia.com/gpu: 1就代表一整张卡。问题来了：跑一个需要20GB显存的小模型，放在80GB的卡上，剩下60GB就这么空着，但其他任务因为要独占整卡也调度不进来，于是集群出现大量"有显存但用不了"的碎片。

我见过最典型的场景：集群有20张A100，监控一看平均利用率只有35%，但新任务调度时显示"资源不足"。原因就是碎片化。解法有几条路：一是用支持显存隔离的能力，像MIG把物理卡切成多个小实例；二是换用支持显存虚拟化或池化的方案，把多张小卡混成一个池子；三是优化调度策略，vLLM这类引擎支持在单卡上跑多个模型实例，把不同模型按显存需求混布到同一张卡上。经验是：任何跑AI的K8s集群，都要提前设计好GPU资源模型，到底是整卡模式还是切分模式，这决定了后面所有任务的调度效率。

4.2 观测指标错位：拿QPS监控LLM服务，等于盲开

传统Web服务的监控体系是围绕QPS、P99延迟、错误率、CPU负载建的，这套模板直接套到LLM服务上会吃大亏。原因前面提过：LLM请求的耗时和生成长度强相关，同一个请求，回答50个token可能只要1秒，回答500个token可能要7秒，P99延迟根本不能反映服务质量。真正要盯的，是排队请求数、显存水位、KV cache使用率、TTFT和TPOT的分布，以及重要的一点——prefill和decode阶段的耗时拆分。

prefill是一次性处理你输入的整段prompt的阶段，decode是逐token生成的阶段，两个阶段对算力的需求模式完全不同。prefill吃计算，decode吃显存带宽。如果监控里prefill耗时暴涨，多半是prompt太长或者批量拼接出了问题；如果decode变慢，大概率是显存带宽成为瓶颈。这些区分在普通监控体系里完全看不见。

工具方面，Prometheus加Grafana依然是底座，但上面要挂的是GPU指标、vLLM暴露的metrics端口、队列深度这类AI特有指标。请求级的链路追踪也很重要，Langfuse这类工具能记录每次请求的token消耗、首token延迟和完整链路，排查"某个回答为什么慢"时，没有它你会非常痛苦。

4.3 成本核算：别等账单出来才傻眼

做普通后端，服务成本大头是CPU和内存，定价相对简单。做AI服务，成本结构完全不同：大头往往是GPU时长和token消耗，而且模型一旦上线，每一轮对话都在持续花钱。我见过团队把模型服务跑了一个月，月账单出来都懵了——比预估高了三倍。原因很简单，当初只算了"一台机器多少钱"，没算"每个token多少钱"。

单位token成本怎么算？推荐一个很朴素的口径：单实例综合成本除以该实例有效输出token总量。综合成本要算上GPU实例的租赁或折旧费用、电费、存储和带宽成本。比如一台8卡A100服务器，云上按小时计价，不同云差异很大，一小时成本大约在总价的一百到数百元区间；如果自建，就按硬件总价除以三年折旧再加机房电费。假设这台机器往上有一次只能跑一个7B模型服务，压测稳定输出吞吐是每秒500 token，一个月有效运行时间是600小时，那么总token数是500 × 3600 × 600 = 10.8亿token，单token成本就是总成本除以这个数。

算出单位token成本后，很多决策都会变清晰：有些场景该上小模型就上小模型，回答质量问题可以通过RAG补齐；有些两步调用的业务，可以合并成一次生成来省token；高峰期扩两个实例够不够、低谷期要不要缩到零，全都能算。我甚至会在每个服务上线前写一个成本评估表，把预估token量、实例数、GPU时长的乘积关系列清楚，再决定要不要做人肉限流。

5. 第一章的实践路线图：六周闭环

前面讲了很多概念和计算，有基础和没基础的读者吸收程度肯定不一样。但AI-Infra这东西，看书看概念效果有限，必须动手跑通一条链路才算真的入门。下面是我给团队新人的六周实践路线，不是泛泛而谈，每一步都有明确交付物，供你参考。

5.1 前两周：让模型在本地GPU上跑起来

第一周先把环境搞定。目标不是跑大模型，而是建立"环境就绪"的完整检查清单。先运行nvidia-smi确认GPU型号、驱动版本和CUDA版本；然后用Docker跑一个GPU测试容器，确认容器能识别GPU：docker run --gpus all --rm nvidia/cuda:12.2.0-base-ubuntu22.04 nvidia-smi这段能通，才算环境OK。再装好vLLM，把上一节的7B模型启动命令跑通，用curl发一个最简单的问题。遇到问题优先查三件事：驱动版本够不够新、CUDA和PyTorch版本匹配不匹配、模型下载路径有没有权限。

第二周做显存实验。给服务定不同的--gpu-memory-utilization参数，从0.7到0.95各跑一遍，观察启动日志里KV cache大小的变化；再用压测工具发20并发，盯着nvidia-smi看显存水位变化。这一周会把"显存不是死的，是动态分配和释放的"这个概念彻底烙在脑子里。

5.2 第三、四周：把服务压出性能边界

第三周做压测，固定请求并发数从1、4、8、16、32、64递增，记录每个阶段的TTFT、TPOT、吞吐和显存水位，画出曲线。重点找拐点，也就是某个并发数之后TTFT突然恶化、报错率开始上升的那个位置。第四周围绕拐点做参数优化：调整并发上限、换iGPU内存比例、尝试max-num-seqs这类批处理配置，看能不能把拐点往后推。

这两周结束时，你应该能回答这几个问题：这台服务能扛多少并发、为什么扛不住、瓶颈在排队还是生成速度、加一张卡能换来多少吞吐提升。这些问题别人问不倒你，才算过了推理性能这一关。

5.3 第五周：用RAG把整条链路串起来

单模型服务跑通了，还差业务场景。RAG是目前最典型的AI业务形态，用来串联整条链路非常合适。你不需要从头做向量库，直接用Milvus或pgvector，配一个embedding模型，把一批文档切块灌进去，然后让7B模型基于检索结果生成回答。

这一周你会遇到大量真实问题：检索结果太长导致prompt超限、embedding批处理同时打进来和推理争显存、并发高时RAG和LLM之间的超时链路处理不合理等等。把这些问题的解决方案写成文档，就是你第一篇有分量的AI-Infra实践总结。

5.4 第六周：沉淀文档，把经验变成团队资产

最后一周，把前五周踩过的坑整理成一份"AI-Infra服务上线检查清单"，内容包括：环境检查命令、显存估算模板、vLLM推荐参数、压测方案、监控看板清单、单位token成本计算表。这个文档的读者是未来接手服务的同事，所以重点是"照着做就能跑通"。

到这里，一个人就算初步具备了AI-Infra的实战能力。回头再看AI-Infra，你会发现它不是某一个高深莫测的系统，而是一连串朴素问题的总和：模型放哪、跑多快、花多少钱、挂了怎么办。把这几个问题问到极致，就已经超过了大部分"只会调API"的工程师。

最后分享一个我的体会：入门AI-Infra最容易犯的错，是先去啃分布式训练框架，觉得那才是核心。实际上，绝大多数团队的痛点在推理和交付层——模型怎么稳定高效地服务业务，成本怎么算得清楚。先把这条线打通，再回头补训练基础设施，路会顺得多。第一章就到这里，下一章我会专门拆解推理引擎的内部机制和调优经验。