企业官网建设流程全解析

1. AI-Infra到底在解决什么问题

先说个我自己的体会。三年前我第一次接触大模型部署的时候，整个人是懵的——模型文件几十个G，显存一上就爆，推理速度慢到让人怀疑人生。那时候我还在做传统的后端服务，以为把模型塞进GPU跑起来就算完事，结果真上了生产环境才发现，AI Infra这一层的水比想象中深得多。

AI-Infra，全称是AI Infrastructure，翻译过来就是AI基础设施。它不是某一个具体的工具，也不是某一套固定的架构，而是介于底层硬件和上层AI应用之间的一整层工程体系。你可以把它理解成一条高速公路：模型是车，业务是目的地，AI-Infra就是那条把车从起点送到终点的路。路修得好不好，直接决定车跑得快不快、堵不堵、稳不稳。

这一层具体包含什么？我在实际工作中把它拆成四个大块：算力资源的管理与调度、模型推理服务的部署与优化、数据与特征管道的构建、以及整个链路的可观测与稳定性保障。每一个大块往下拆，又会延伸出一堆细节。比如算力调度要管GPU的分配、显存的隔离、任务的排队策略；推理服务要管模型加载、批处理策略、缓存机制、动态路由；数据管道要做清洗、加速、版本管理；稳定性要做监控、告警、容灾、降级。

为什么这一层这么重要？因为算法工程师的产出，最终要通过这一层才能真正变成用户能用、能赚钱的产品。我见过很多团队，模型在验证集上效果很好，一上生产就变得又慢又不稳，用户骂声一片。问题往往不在模型本身，而在Infra。同样的模型，有人能扛住每秒几千的请求，有人几百就挂了，差别全在这一层。

所以，第一章我打算从一线工程师的视角，把AI-Infra的版图理一遍，重点讲清楚三个问题：这一层到底有什么、每个模块解决什么问题、作为工程师我们应该从哪里切入。不追求面面俱到的教科书式铺陈，只讲我在真实项目里用过、踩过、优化过的东西。

2. 推理服务：AI-Infra的兵家必争之地

2.1 为什么推理服务是核心战场

如果说AI-Infra是一个系统，推理服务就是它的心脏。训练再强大，模型最终要落地，靠的就是推理。过去两年我参与过的项目，无论是什么业务场景——文本生成、智能问答、内容审核——最终无一例外都要落到推理服务上。

推理服务之所以是核心，原因有两点。

第一，它是离用户最近的一环，直接决定用户体验。模型推理快一秒，用户感知的响应速度就快一秒。在对话类场景里，用户对“流式输出”的期待是每个token都要尽量快地蹦出来，任何延迟都会被放大成“卡顿”“不好用”的印象。

第二，它是成本开销的大头。训练GPU再贵，那是阶段性的；推理GPU是7x24小时在烧钱。我经手过一个文本生成服务的优化项目，最初每天跑在8张A系列显卡上，GPU利用率不到30%。优化了推理服务之后，同样的流量只用4张卡，成本直接砍了一半。这一半，就是Infra工程师的价值。

推理服务要做的事，通俗点说就是：把模型从存储介质加载到显存里，接住上游发来的请求，组织成模型能吃的输入格式，调用GPU做计算，再把结果翻译成上层业务能用的响应。看起来简单，实际里处处是坑。模型加载慢怎么办？并发高了显存不够怎么办？长文本输入的算力开销怎么降？这些问题，每一项都足够写一篇单独的博客。

2.2 从同步到流式：架构演进的关键一步

我最早做的推理服务，是典型的同步请求-响应模式。客户端发一个请求过来，服务端等模型算完，一次性返回完整的回答。这种模式在短文本、低并发的场景下勉强能用，但一遇到大模型生成场景，问题就暴露了。

大模型的生成是逐token的，一个完整的回答可能要几秒钟才能算完。如果让用户干等几秒再看到全部内容，体验会非常差。更实际的问题是，很多网关和负载均衡器都有超时时间，通常设置在三到五秒，同步模式下长回答很容易被网关掐断。

后来我引入了流式返回，用Server-Sent Events（SSE）或者WebSocket，把模型每算出一个token，就立刻推给前端。用户看到的是文字一个个蹦出来，打字机一样的效果，体感延迟降到了几百毫秒，哪怕总耗时要五秒，用户也不会觉得“没反应”。

这个改动看起来简单，实际上牵动了一整条链路：网关要做适配，不能默认缓冲响应体；客户端要支持事件流解析；服务端要处理客户端断开时的生成终止。我遇到过不止一次，客户端提前断开，但GPU还在傻傻地生成，白白浪费算力的场景。后来我学乖了，凡是做流式推理，一定在业务代码里监听客户端断开事件，一旦断开就主动取消生成任务，同时释放显存和计算资源。

2.3 部署形态选型：原生服务还是专用框架

做推理服务的另一个经典选择题，是用通用框架自己封装，还是直接上专用的推理服务框架。我两种路线都走过，各有各的适用场景。

初期项目，模型少、并发低、迭代快，我推荐直接用通用框架封装。原因很简单：团队对通用框架熟悉，出了问题能查源码、能加日志、能快速改。对一个刚起步的项目来说，可控性比性能更重要。我那时候的做法是把模型加载、预处理、推理、后处理包成一个异步服务，请求进来先排队，再分发给GPU worker，返回时统一做协议转换。这套架构撑到每天几十万次调用都没问题。

等到并发量上来了，模型变多了，问题就逐渐显现。通用框架在调度效率、显存复用、批处理优化上都不是强项，性能瓶颈很明显。这时候就该换专用推理服务框架了。市面上的主流方案我都试过，核心优势集中在几个方面：支持连续批处理、自带kv cache管理、能动态分配显存、内置了模型并行策略。换上去之后，吞吐量往往能翻一到两倍。

我给个朴素的建议：不要一上来就追新框架，老老实实把通用方案的瓶颈吃透，再平滑迁移。迁移的时候重点做两件事——用同样的输入集做压测对比，确认新框架的收益；留好降级开关，新框架出问题能一键切回旧方案。

3. GPU资源管理：把每一张卡用到刀刃上

3.1 GPU利用率为什么普遍偏低

做AI-Infra的人，天天要对着一张GPU利用率报表过日子。我见过太多团队，买了昂贵的GPU，利用率却长期在20%到40%徘徊。这不是个别现象，而是普遍难题。为什么会这样？我总结下来有三个常见原因。

第一，显存与算力的不匹配。大模型推理最显著的特点是显存占用高，但计算未必打满。一个7B参数的模型，光权重就要占十几个G的显存，加载到单卡上之后，留给KV Cache的空间就不多了。如果并发开得少，GPU的计算单元闲着；如果并发开得多，显存又爆了。

第二，任务形态的碎片化。线上请求的时长差异很大——有人问一句话就结束，有人连续问一大段。如果调度策略不讲究，长请求和短请求混在一起，很容易让GPU资源被少数长请求霸占，其他短请求排队等到地老天荒。

第三，模型实例的资源隔离太粗。很多团队习惯一个模型独占一张卡，即使这张卡只用了20%，也不允许其他模型共用。这种做法的好处是隔离性好、互不干扰，坏处就是利用率的巨大浪费。

解决GPU利用率问题，不能只靠某一个技巧，要一套组合拳。我建议从三个层面入手：模型层面的显存优化、调度层面的请求动态路由、资源层面的混部与共享。

3.2 显存优化：从静态分配到动态池化

大模型推理的显存瓶颈，很大一部分来自KV Cache。这是什么概念呢？模型在生成每个新token的时候，都要依赖之前所有token的注意力信息。如果每次重新计算，代价大到无法接受，所以业界的主流做法是把历史token的Key和Value缓存下来。这个缓存非常吃显存——序列越长，并发越高，KV Cache占的内存越大。

最早期的实现，是按照最大可能序列长度预分配显存。比如设定每个请求最多2048个token，那就按2048来预留KV Cache。这种静态分配方式有两个问题：一是浪费，请求平均长度只有几百token，却按2048预留；二是灵活性差，一旦请求超过预设长度，要么截断，要么报错。

后来业界普遍转向了PagedAttention这一类思路，说白了就是把KV Cache切成固定大小的块，用的时候动态分配，不用了立刻回收，类似操作系统里的虚拟内存分页管理。这个机制上线之后，我观察到的显存利用率提升了30%到50%，同一条GPU能同时服务的请求数也明显增加。

除了KV Cache，模型权重本身的显存优化也值得做。有量化技术可以把权重从FP16压缩到INT8甚至INT4，显存占用直接减半甚至减到四分之一，速度通常还能变快。代价是精度略有损失。我的经验是，先用量化版本做一轮效果评测，如果业务指标下降在可接受范围内，果断上量化，性价比很高。

3.3 多模型混部与弹性伸缩

单模型独占GPU的模式，在小规模场景下很省心。规模一大，就得考虑混部——让多个模型共享同一批GPU资源。

混部的核心是隔离与调度的平衡。我目前在用的方案，是把GPU卡按组划分，每个组跑一个模型集合，组内通过显存隔离和算力权重来限制相互影响。这样既有一定的隔离性，又能提高总体利用率。

具体到调度策略，我倾向于队列优先级的思路：给不同的业务模型分配不同的优先级，高优先级的任务插队执行，低优先级的任务在空闲时跑。为了保证公平性，还需要配合配额机制，防止高优先级任务饿死低优先级任务。

弹性伸缩这块，我一开始做得比较保守，只在每天流量高峰前半小时扩容、低峰期缩容。后来发现不够，线上的流量波动比想象的剧烈。踩过几次坑之后，我换成了基于指标的自动伸缩：跟踪GPU利用率、请求排队长度、平均响应时间这几项核心指标，根据阈值自动增减推理实例。这里要特别提醒，自动伸缩的触发阈值设置很讲究，定的太低会导致频繁抖动，性价比反而差。我一般会让扩容阈值保持适度保守，宁可稍微多留一点冗余，不要频繁扩缩容。

4. 请求调度与批处理策略：把吞吐量拉满的秘密

4.1 静态批处理与连续批处理的区别

推理服务的吞吐量，很大程度上取决于批处理策略。早期我看到很多团队的实现，是把请求攒够一批再一起送进模型，等这一批全部算完才送下一批。这种静态批处理方式，逻辑简单，但在线服务的流量到达不可能是均匀的，经常出现凑不满一批的情况，只能干等，延迟飙升。

后续业界引入了连续批处理机制，思路是微观层面的动态调整：模型每算完一个请求，立刻从等待队列里拉一个新的请求补上，不需要等整批都结束。这个机制可以理解为公交车的流水发车——不再等满一车人再走，而是车上哪个乘客到站了，就有新乘客补位，车始终在开。

这个改动带来的收益非常大。我做过一个对比测试，同样的模型、同样的GPU、同样的请求集，静态批处理的吞吐量大约是每秒40个请求，换成连续批处理之后直接涨到每秒90个，延迟还有所下降。原因是GPU的计算孔隙被填满了，每一毫秒都在做有效计算。

4.2 动态batching的工程实现细节

连续批处理听上去美好，但实现层面有不少讲究。我说几个我踩过的坑。

第一，批大小的动态控制。并发请求多的时候，批可以开大一点，把吞吐顶上去；并发请求少的时候，批就要收小一点，免得把延迟拉高。我做了一套简单的自适应逻辑：根据最近几秒的平均请求排队长度，动态调整最大批大小。排队长度高了就加大批，排队长度低了就减。实测下来，KN95性能稳定，没有出现过大的抖动。

第二，序列长度对齐问题。GPU的计算对输入的长度比较敏感，同一个批次里的请求长度如果差太多，短的请求会被长的请求拖慢。我现在的做法是在组批时加一个约束，让同批请求的长度分布尽量均匀。长请求和短请求会分到不同的批次里，这样计算资源能利用得更充分。

第三，优先级与公平性。线上服务里，有些请求是用户实时交互的，有些是后台异步任务。实时请求的延迟要求高，但后台任务的量又很大。如果不加区分，后台任务很容易挤占实时请求的资源。我的方案是把请求分成两个队列，实时队列优先级高，后台队列优先级低，GPU优先处理实时队列的任务，只有在实时队列空闲时才处理后台任务。这套方案上线后，实时请求的P99延迟从原先的3秒降到了800毫秒左右。

4.3 前缀缓存与语义缓存

大模型推理还有一个特殊的优化点——前缀缓存。对话场景下，用户经常会在同一轮会话里来回追问，系统要把之前的对话历史全部塞进输入里。如果用户只是追问一个新问题，前面的历史完全没变，那模型计算时，前面对话历史的KV Cache其实是可以复用的。

我做过一次实测，一个五轮对话的请求，如果系统能够复用前几轮的KV Cache，首token的生成延迟能从1.5秒降到0.3秒。原理很直白，不需要重新计算的部分越多，响应越快。

但这个优化有前提，就是框架要支持对KV Cache做精确的哈希匹配。请求中的历史部分完全一致才能命中。实际业务里，对话历史经常带有动态字段，比如时间戳、随机ID，导致哈希永远不匹配。解决办法是在业务层做归一化，把动态字段剔除，只把稳定的那部分内容拿去算哈希。

另一种思路是语义缓存，缓存的是模型生成的完整响应，而不是KV Cache。适合那些高频重复的问题——比如法律咨询里的常见条款、客服场景里的常见答案。如果用户的问题和某个历史问题语义相似，直接返回缓存的回答，连模型都不用跑。这个做法的成本最低、效果最直接，但要注意语义判定的准确性，判不好会答非所问。

5. 可观测性与稳定性：让问题在爆发之前现形

5.1 不止是看监控面板那么简单

每个做Infra的工程师，都有一块写满指标的监控面板。但我发现，很多团队的监控面板只是摆设——指标列了一大堆，真正能指导定位问题的没几个。

我的观点是，可观测性不是指标越多越好，而是指标要能帮你在故障发生前就发现问题、在故障发生后快速定位根因。所以我在设计监控体系时，把指标分成三个层次：资源层、性能层、业务层。

资源层关注的是GPU利用率、显存占用、显存碎片率、显存带宽、温度功耗这些硬件指标。性能层关注的是请求延迟、吞吐量、排队长度、批大小分布等系统运行指标。业务层关注的则是上游更关心的东西，比如请求成功率、结果完整率、平均生成长度。这三层指标不能割裂，要能关联着看。比如用户反馈变慢了，我先看性能层的延迟曲线，再往下钻到资源层看是不是显存不足导致GC频繁。

5.2 日志链路：一次请求的完整追踪

大模型推理的链路很长——客户端到网关，网关到推理服务，推理服务到模型，每一个环节都可能出问题。如果没有一套完整的链路追踪体系，出了问题只能到处猜。

我现在的做法是给每一个请求分配一个唯一的trace ID，一直传到模型层面。每一层的中间状态、耗时、错误信息都带上这个ID。问题排查的时候，拿着trace ID一查，整个链路一目了然：哪个环节慢了、哪个环节报错了、哪一层重试了几次，全都能看到。

这里有个细节容易被忽视：推理服务自己生成的token，也要记录到日志里。线上出问题的时候，用户说“回答到一半断了”，你查日志能看到断在哪个token、当时的概率值是多少、有没有触发停止条件。这种细粒度日志，对分析问题帮助特别大。

日志量大了之后，还要考虑采样策略。我采用的是全量记录请求元信息、按比例采样记录token明细的做法。元信息全量留存，占比不大，但能解决大部分问题；token明细按1%采样，够做量化分析，又不会让存储开销失控。

5.3 高可用设计与故障预案

有时候无论监控做得再好，故障还是会来。所以我的习惯是提前把最坏的情况想好，写好预案，等故障真正来的时候，直接照着执行总比临时拍脑袋强。

推理服务的高可用设计，我总结了五个重点。

第一，多副本部署。同一个模型至少部署两个副本节点，分布在不同的物理机上。单节点故障时，另一个副本能平滑承接流量。

第二，优雅上下线。模型更新或者机器维护时，不能直接杀进程。要先从负载均衡摘掉流量，等正在处理的请求跑完，再执行关闭。否则用户会看到大片超时。

第三，过载保护。当请求量超过系统的处理上限时，要主动降级，而不是硬撑。我的做法是设置一个最大排队长度，超过之后直接返回“系统繁忙”的响应，宁可丢弃一部分请求，也不让整个服务雪崩。

第四，模型版本兼容。上线新模型之前，先做一段时间的灰度。新旧模型同时在线，按比例分流，观察一段时间没问题再全量切换。

第五，快速回滚。发布系统里必须留好一键回滚的按钮。回滚要恢复的是“代码版本+模型版本+配置版本”三者一致的状态。我遇到过代码回滚了、模型没跟着回滚的情况，行为完全不可预期，折腾了很久才缓过来。

6. 从零搭建一个推理服务的实战记录

6.1 需求场景与架构选型

有了前面的理论铺垫，我用一个实战案例把整个流程串起来。这个案例是我之前做过的模拟项目X——需要把某个在线问答模型做成一个生产级的推理服务，支撑每日百万次请求，单次请求的P95延迟目标在1.5秒以内。

需求拆解下来，约束条件有四个：模型大小在10G级别，需要单卡部署；并发峰值约每秒50个请求；延迟要求严格；团队运维能力中等，不能搞太复杂的架构。

基于这些约束，我做了如下的选型。推理框架用支持连续批处理和KV Cache优化的成熟方案；模型量化到INT8，把显存占用降下来，给并发留余地；部署形态选了多副本的Kubernetes方案，配合负载均衡和自动伸缩；监控体系直接基于框架自带的指标能力，加上业务层的自定义埋点。

架构上我是这样设计的：入口是负载均衡层；中间是推理服务集群，每个Pod里跑一个模型实例；下面是模型存储和配置文件中心。整体拓扑不复杂，但每个环节都有明确的职责。

6.2 配置参数与调优过程

部署过程中，我重点调整了三个关键参数。

第一个是最大批大小。最初按框架默认值来，压测发现P95延迟超标，问题出在批开的太大，长请求把短请求拖住了。我把最大批大小从64降到32，同等并发下延迟降了40%。

第二个是KV Cache的分配比例。框架把显存分为权重区和缓存区，缓存区的比例决定了最多能同时服务多少请求。我一开始设了50%，结果并发请求多的时候还是爆显存。调成60%之后，实测显存利用率从70%提升到约85%，并发能力跟着上去了。注意要留有余量，调太高会导致其他显存开销没有空间。

第三个是自动伸缩的阈值。我观察了一周的流量曲线，发现长期平均GPU利用率大约在40%，峰值能到80%。我把扩容触发阈值设为70%，缩容阈值设为30%，冷却时间设为5分钟。这样既不会频繁抖动，也能在流量上来时快速反应。

6.3 压测结果与上线心得

整个优化完成后，我做了两轮压测。第一轮按照生产流量1.5倍的规模跑，系统稳定无错误，P95延迟1.2秒；第二轮把流量拉到生产预期的3倍，出现了少量超时和排队，但系统没有崩溃，过载保护机制正常触发。这个结果我认为是符合预期的——保障系统在正常流量下从容，在突发流量下不崩、不影响可用性。

整个实战过程我总结了几条心得。

第一，不要一上来就追求极致性能。先把架构跑通、监控上线、预案写好，把系统做成一个稳定可靠的底座，再逐步优化参数。第二，参数调优一定要有对比数据支撑，不能拍脑袋。我每改一个参数，都会跑同一组压测用例，用数据说话。第三，一定要在发布前把灰度、回滚、监控整个流程走一遍，哪怕多花半天时间，也比线上出事再抢救要划算得多。

7. 给一线工程师的几点建议

篇幅到这里，我觉得应该收个尾了。作为一线的Infra工程师，我这几年的体会是，这一行最需要的不是某种高深莫测的技术，而是扎实的工程习惯和系统思考的能力。AI-Infra的魅力就在于，它的每一个模块都可以深入钻研，但最终要回归到为业务创造价值——延迟降了多少、成本省了多少、稳定性提升了多少，这些才是核心指标。

如果你正在或打算进入这个方向，最后分享几条实实在在的建议。

第一，先动手把一个小模型完整部署起来，端到端跑通请求链路，再考虑优化性能。纸上谈兵没有用，真实的问题往往在实际运行中才会暴露出来。

第二，建立自己的调优工具箱。压测工具、监控面板、日志查询接口、trace追踪系统，这些工具要提前备好、随时可用。等到出问题再临时找工具，节奏会非常被动。

第三，每次优化都要沉淀成文档和指标对比数据。AI-Infra方向变化很快，今天能用的方案，半年后可能就有更好的替代品。你能带走的最有价值的资产，是方法论，不是某个具体的配置。

第四，保持对新技术的好奇心，但不要盲目追新。判断一个新框架值不值得用，标准很简单：它能不能在现有约束下，帮你解决实际遇到的瓶颈。能，就试；不能，再等等也不迟。

AI-Infra这条路很长，第一章只是起步。往后还有更多的议题等着展开——推理服务的深入调优、算力集群的规划建设、数据管道与特征服务的架构演进，每一个都值得单独梳理。先把这一章的内容吃透，再接着往下走。