现在的 AIGC 应用最难的不是把模型跑起来而是跑起来之后怎么让用户愿意持续用下去。很多团队把大模型接口一接、前端页面一搭觉得产品就成了。结果推上线之后发现两个问题像两堵墙一样横在面前一个是算力账单每天都在跳一个月下来成本比预估高了好几倍另一个是用户一多推理延迟就压不住问一句话要等七八秒才出第一个字用户早就关掉页面走了。这个项目要解决的就是这两件事。我们基于腾讯云把一整套 AIGC 全栈技术从底层算力调度到上层互动体验做了完整打通覆盖模型推理加速、容器化部署、流式响应、成本治理、商业化落地的完整链路。整篇内容不是理论推演而是我们在真实业务里一步一步踩出来的实践记录包括为什么选这套架构、延迟优化到底在哪几个环节动手、商业化落地时哪些指标必须盯死。如果你的团队也正在做或准备做 AIGC 应用后面这些内容应该能帮你少走几条弯路。1. 项目背景与整体思路从“想明白”到“做出来”动手写代码之前先花几天把思路捋清楚。AIGC 应用和传统互联网应用最大的区别在于它的核心单位不再是一次请求响应而是一次生成过程。这个过程会消耗 GPU 算力、占用显存、产生排队并且在用户体验上存在首字延迟和吞吐量之间的天然矛盾。这些问题如果不在架构阶段想清楚后面会处处被动。1.1 为什么 AIGC 产品绕不开“算力”和“延迟”这两个关口和传统 API 不一样大模型推理本质上是一个“边算边出”的过程。用户发一句话进来模型要先把整段上下文做预填充计算然后再一个 token 一个 token 地生成回复。这个机制决定了两个事实第一算力是 AIGC 产品的刚性成本。不管用户问的是“今天天气怎么样”还是“帮我写一份三万字报告”模型都要完整走一遍推理过程消耗的 GPU 算力是实打实的。做过成本测算的朋友应该知道一个大模型的单次推理成本如果按 GPU 小时折算比传统 API 接口贵出几个数量级。如果产品又恰好是免费开放给 C 端用户的那成本压力会非常直接地反映在月底账单上。第二延迟直接决定产品生死。互动场景里用户对等待的耐受力非常低。业内一般认为首字返回时间最好控制在 500ms 到 2s 之间超过这个区间用户就会有“卡”的感觉。而模型生成整个回复的时间又会随内容长度线性增长一篇文章生成几十秒都是正常情况。如果不做流式输出优化用户面对的就是一个漫长无反馈的空白页面体验差到没法谈留存。所以我们在项目立项时定了两条硬指标单次交互成本要能压到毛利模型可承受的范围之内首字延迟和总生成时延必须达到可商用水准。所有技术选型都是围绕这两个指标展开的任何和这两条冲突的方案就算再“先进”也要让路。1.2 全栈技术选型不追新只追稳全栈方案在前几年听起来是个很重的东西但在 AIGC 场景里恰恰是“全栈”才能把链路里的每一环都捏合起来。我们选型时没有追最新发布的框架而是围绕腾讯云上已经验证过的产品组合来搭核心原则是稳定、可控、可运维。底层算力用的是 GPU 云服务器配合容器服务来做实例编排。模型推理框架主要用了 vLLM 作为在线服务的主框架它的 PagedAttention 显存管理和 continuous batching 机制对吞吐提升非常明显实测能把单卡并发从几路提升到几十路。对于一些对响应速度要求极高、对模型效果要求相对简单的场景我们也试了 TensorRT-LLM 做额外加速效果确实快但工程落地复杂度高一些所以主要用在高优先级场景里。接入层用 API 网关做统一入口走 WebSocket 协议做流式消息推送。存储这块比较传统结构化数据丢云数据库对话上下文和生成日志走对象存储。监控体系是最容易被忽略但又最重要的模块后面会专门讲我们怎么用指标体系和日志系统反向驱动架构优化的。这套组合看起来没有特别惊艳的组件但它在生产环境里足够稳。选型建议就一条如果你的团队没有专门的基础设施团队尽量用云厂商托管服务别自己从头搭推理集群。自建看似省钱实际上 GPU 运维、故障恢复、扩缩容调度这些坑会把你拖垮。2. 算力层GPU 资源调度与成本控制实操算力是整个 AIGC 项目里花销最大、也是弹性最差的一块。差在哪里GPU 服务器不像普通云主机它不是按分钟计费然后想开就开的很多高规格实例需要提前预留而且一开机就产生高额账单。我们在这个项目里花了很大精力做算力层的资源治理目标是让每一张卡的利用率都能被看见、被度量、被优化。2.1 GPU 资源池化与弹性伸缩配置最开始我们的资源规划很粗放评估了一下峰值并发按峰值买了固定数量的 GPU 实例。结果就是低谷期一堆卡空转高峰期又偶尔不够用。后来改成资源池化加弹性伸缩的方案才算是把成本结构理顺了。具体做法是把不同业务场景的推理任务拆成独立的服务组每个服务组挂在同一个容器集群里通过节点自动伸缩策略按指标扩容缩容。扩缩容的触发指标不能只看 CPU推理场景里最关键的是 GPU 利用率、显存占用和队列深度。当某个服务组的排队请求数超过阈值就自动扩容 GPU 节点当队列清了且低负载持续一段时间再缩容释放。这里有几点实操心得值得说一下。第一缩容策略一定要有冷却时间不能一看到队列空了立刻缩否则在请求波动频繁的场景里会出现“抖动”资源刚释放又触发扩容来回横跳不仅省不了钱反而容易引发服务不稳定。第二尽量把“可预测的波峰”和“不可预测的突刺”分开处理。比如工作日的早高峰是可预测的我们可以提前一个小时预置资源而如果热点事件带来流量突袭那就得靠应急扩容流程快速拉资源。第三一定要给不同业务设置资源分组和配额。不能所有任务都在一个大池子里抢资源。我们遇到过某条业务线的批量任务把共享池的 GPU 全部占满导致在线交互服务扩容时拿不到卡的问题。后来彻底改成在线推理和离线批处理两类资源池物理隔离才断了这种互相影响。2.2 降低推理成本的关键手段削峰填谷与模型分档算力成本不能只靠扩缩容来压更核心的是对模型推理本身做成本治理。我们主要用了两招削峰填谷和模型分档。先说削峰填谷。大模型交互场景有非常明显的波峰波谷用户白天活跃、凌晨稀疏。对于离线任务比如内容批量生成、数据标注预处理、模型评测这种不要求实时返回的任务我们做了一套任务队列系统把这些任务统一放到队列里在推理资源空闲的时段批量执行。到凌晨时段在线流量降到低谷离线的批量任务就把波谷时段的 GPU 填满整体利用率提升非常明显。实测下来这套队列调度机制把我们 GPU 资源的日均利用率提升了将近 30 个百分点。再说模型分档。AIGC 产品经常会有多种模型大小可选比如一个 7B 的小模型和一个 70B 的大模型。它们的成本差距可能是数倍甚至数十倍。我们从产品层面直接把用户请求按场景分档路由简单问题、意图明确的请求直接命中可灵巧处理的小模型复杂推理、长文本创作才走大模型。这样不仅用户响应更快成本也被有效稀释。还有一招是在不影响效果的前提下做量化。我们部分场景把模型从 FP16 量化到 INT8 和 INT4显存占用下降后同样的卡可以跑更大的 batch单卡吞吐随之提升。这里必须提醒一点量化不是无损的上线前要做好充分的评测集验证尤其对数学逻辑、代码生成这类对精度敏感的场景要额外谨慎。像涉及隐私数据、需要使用智谱或豆包这类第三方大模型 API 的场景也可以接入云上国内提供 API 的模型服务通过腾讯云 API 网关做统一鉴权与流量治理。这类第三方 API 的好处是不占用自建推理资源适合低频长尾需求用多少付多少。成本模型算下来这种“自建主力模型 第三方补充模型”的混合策略比全部自建要省近三分之一。3. 互动延迟优化从“能跑”到“秒回”延迟是 AIGC 互动类产品的生死线。在项目初期我们做了个最小原型用户发消息后端同步调用模型等模型生成完整个回复后再一次性返回前端。这个方案逻辑最简单但实测体验极其糟糕——一个 200 字左右的回答用户要等十几秒才能看到内容。后来我们把延迟优化的改造拆成了几个层面逐层推进每一层都有明确目标。3.1 延迟来源拆解与量化先看一次请求完整链路里延迟都消耗在哪些环节。在动手优化之前我们先把链路拆成了五段分别埋点计时网络传输、网关转发、排队等待、模型预填充、模型逐字生成。量化下来发现一个有意思的现象当并发量不高的时候最大的延迟开销在模型预填充和生成阶段当并发量上来之后排队时间的占比会急剧上升甚至超过推理本身。这里放一次会话的典型延迟分布供参考延迟环节影响因素典型耗时低负载典型耗时高负载网络往返用户地理位置、网络质量30-80ms30-80ms网关与鉴权网关转发性能、鉴权算法10-30ms20-80ms推理排队服务并发、请求队列深度20-100ms2-10s预填充阶段输入长度、模型大小200-1500ms500-3000ms生成阶段输出长度、batch 大小2-15s逐字叠加5-30s从这张表可以看出来高负载下最刺眼的不是模型本身变慢了而是排队时间被放大。这也是为什么单纯加卡不优化调度延迟问题依然解决不了——因为瓶颈有可能在任务分发和队列策略上。3.2 流式输出与预填充/解码分离延迟优化的第一个大动作是把同步调用改成流式输出。这看起来是个简单改动实际上对架构设计影响很大。传统的同步等待方案会让用户面对一个空白页面体验极差。改成流式输出后模型每生成一个 token就通过 WebSocket 推给前端用户能看到文字一个接一个地“打”出来。虽然总生成时间没有缩短但用户的心理等待感大幅下降而且能及时判断模型是不是跑偏了、需不需要中断。对于长文本生成类应用来说这个体验差别是决定性的。再往深一层我们把预填充和解码两个阶段做了解耦。预填充阶段要把用户的整段上下文做一次完整计算这个过程计算量大且无法流式返回解码阶段是逐字生成每个 token 的计算量相对小但依赖前一步结果。传统实现里这两个阶段在同一个进程内顺序执行当多个请求并发时单个请求的预填充会阻塞其他请求的解码。我们借鉴了行业内连续批处理的做法把预填充和解码拆分到不同的微批次中进行调度。长输入的请求进来后先和同一个 batch 里的短请求混跑减少单独一个长请求对整个 batch 的拖累。这个优化直观感受是并发高的时候短问题的响应速度不会因为长文档处理任务的乱入而明显劣化。如果你的服务用的是 vLLM 这类框架它自带的 continuous batching 已经做了类似的事情但你需要仔细阅读它的调度文档理解排队队列的大小对整体行为的影响。还有个小细节流式输出的首字时间。首字返回时间不完全等于预填充耗时它包含网络建连、鉴权、路由、预填充等多个环节。我们专门做了一轮优化用户建立 WebSocket 连接后先立即推送一个“正在思考”的系统提示同时后端立刻开始预填充计算这样用户端的感知延迟又低了一截。3.3 路由层与边缘加速方案延迟优化不能只盯着模型服务本身请求从用户手机到后端机房的网络路径也占了很大一块。我们的用户分布在全国各地如果所有请求都打到同一地域的 GPU 集群跨地域的网络往返会吃掉几百毫秒。后来在路由层做了两件事。第一把静态资源和前端页面接入 CDN 加速这部分不多说属于标准操作。第二在 API 网关配置了就近接入策略用户请求首先被路由到离他最近的边缘接入点再通过云骨干网转发到 GPU 集群所在的地域。实测下来这项优化对南方和西部偏远地区的用户体验提升非常明显整体网络延迟平均降低了 30% 以上。另外我们还做了配套的 WebSocket 长连接管理避免每次请求都重新握手减少了连接建立带来的开销。一个常被忽视的点是前端渲染方式。流式输出时如果前端框架对增量消息处理得不好会出现整个页面频繁重绘的问题体验反而更差。我们在前端用虚拟滚动和增量渲染优化了消息列表的更新策略把逐字刷新的性能开销控制在很低水平。这块虽然是前端问题但直接影响用户对延迟的感受建议后端团队在做优化时一并重视。4. 商业化落地从 Demo 到真实付费模型跑通了、延迟也压下来了下一步就是让这个产品真的能为业务带来价值。商业化落地过程中我踩了不少坑最深刻的一条体会是技术指标和商业指标之间不能画等号。模型效果好不等于用户会付费用户愿意用也不等于业务能盈利。只有真正把成本和体验做成可持续的闭环产品才能立足。4.1 场景选择与产品化设计先说说场景选择。AIGC 的应用范围很广但并不是每个场景都适合做商业化。比如纯聊天机器人这种场景用户已经习惯了免费想直接收费阻力非常大。我们跑下来之后觉得真正容易商业化的 AIGC 场景有三个特征有明确的生产力价值、结果可量化、用户有付费习惯。内容创作辅助、营销文案生成、知识库智能问答这类场景都符合这些特征。场景确定之后产品化设计上还有几个关键细节。第一是“可用性”和“易用性”的区别。一个 AIGC 工具如果只是生成一段还行的文字用户很难为它付费但如果在生成之后提供一键适配多个平台格式、自动配图、关键词分析这些周边能力用户就愿意掏钱因为省下来的时间是可感知的。第二是“免费额度”的设计。免费额度的价值在于给用户体验完整流程而不是让重度用户白嫖。把免费额度控制在“体验最好的一次生成”所需的量附近既不影响用户体验也能保护成本。第三是计费模型。初期我们试过包月套餐后来发现用户对“用多用少一个价”的模式容易产生心理抵触。后来改成“基础订阅 用量计费”的混合模式基础订阅覆盖稳定的普通用户用量计费针对高频重度用户这样兼顾了收入的确定性和增长的弹性。4.2 SLI/SLO 指标设计与运营保障商业化之后运维团队一定会问一个问题我们怎么判断系统是否“健康”如果没有明确指标就会出现“系统好像能跑但不知道什么时候会出问题”的状态。所以我们在商业化阶段做了一套完整的 SLI/SLO 体系。SLI 是我们实际测量到的指标从三类核心维度定义可用性、延迟、准确性。可用性方面我们定义“请求成功且返回完整结果”为一次有效调用SLI 就是有效调用占总请求的百分比。延迟方面分了首字延迟TTFT和完整生成时间TBT分别设定阈值。准确性方面目前主要靠用户端反馈和人工抽检来定义“回答是否可用”虽然自动化程度还不够高但作为底线保障已经够用。SLO 是承诺给用户和内部的目标值。我们上线初期定的是月可用性 99.5%、首字延迟 P95 小于 2.5 秒、完整生成时间 P95 小于 20 秒。这个目标不算特别激进但考虑到成本约束已经是一个需要认真对待的水平。坦白说SLO 定得太激进会显著提高成本。比如首字延迟 P95 如果能从 2.5 秒压到 1.5 秒可能意味着需要多备 30% 的 GPU 资源来应付峰值请求。所以 SLO 的制定一定要结合商业目标来定不是越低越好而是要找到“用户体验可接受 成本可覆盖”的平衡点。我们在上线后经过几轮调整才把 SLO 定在了一个相对舒服的位置。另外推荐一个做法每两周做一次 SLO 复盘从指标趋势反推架构瓶颈。比如某个版本上线后首字延迟升高了就要回溯是新模型推理变慢了还是并发调度策略出了问题。这种“指标驱动优化”的工作方式比拍脑袋做优化要可靠得多。4.3 运营数据驱动的成本归因与迭代商业化还有一个容易被忽略的环节成本归因。不同用户在不同场景下产生的推理成本差异非常大有的用户一次会话消耗的资源是普通用户的几十倍。如果成本模型不落到用户和场景粒度很容易出现“表面上订单很多一算账全亏”的情况。我们在业务日志里额外打点了两个字段请求对应的模型档位和预估消耗的 token 数。然后按用户维度做成本分摊和用户实际贡献的收入做对比。这一个动作做完很多之前没发现的浪费就暴露出来了。比如我们发现某类长文本生成场景消耗成本极高但对应的用户转化率并不理想于是专门调整了该场景的策略限制同时对成本结构健康的高价值场景加大投入。这种以数据为驱动的成本治理方式是 AIGC 业务持续健康运营的关键。5. 常见问题与排查技巧实录这个项目从头到尾走下来遇到的坑远比我预想的多。这里整理了一些典型问题和排查思路算是用真金白银换回来的经验。有些问题排查起来很折磨人但搞清楚根因之后大多都指向同一个本质链路上的耦合没有梳理干净。5.1 典型问题速查表问题现象可能原因排查思路与解法首字延迟偶发飙高到 10s推理服务排队积压或有慢请求阻塞 batch查看队列深度指标开启连续批处理对长输入请求单独分队列并发一高GPU 利用率上不去单请求 batch 太小或者服务副本数配置不够调整动态批处理参数增大最大 batch 数检查副本数是否匹配流量流式输出时前端页面卡顿前端渲染逻辑未做增量优化长列表频繁重绘使用虚拟列表定时合并 token 推送消息再渲染部分地域用户普遍反馈慢跨地域网络问题配置 CDNAPI 网关就近接入策略WebSocket 长连接复用缩容后服务出现闪断缩容策略太激进正在处理的请求被强杀设置缩容冷却时间和优雅下线等待在途请求完成再销毁实例显存溢出的报错频发请求长度不可控单请求占用显存过高限制输入长度设置最大生成长度开启 PagedAttention按长度做路由模型效果忽好忽坏多副本模型版本不一致或负载均衡策略导致不同副本压力不均固定模型版本镜像检查路由权重配置是否漂移第三方 API 调用偶尔超时上游模型服务不稳或没有配置合理的超时重试设置超时上限和重试策略对非幂等请求做幂等处理必要时做模型降级5.2 几个值得展开的踩坑记录第一个坑是关于 WebSocket 网关的超时配置。我们的网关默认有个空闲超时时间比较短。流式输出有时候因为模型生成时间较长单条消息间隔超过了超时阈值连接就被服务端切断了。用户看到的现象就是生成到一半突然中断且前端不会自动重连。排查了很久才定位到是网关层在“捣鬼”。后来把流式接口的 WebSocket 空闲超时专门调大同时前端加了心跳机制和断线重连逻辑才算彻底解决。第二个坑是不同模型版本灰度时的兼容问题。我们在做模型升级时没注意到新版模型的输出格式有一处细微变化结果下游的解析服务直接报错线上用户体验瞬间劣化。后来规定所有的模型输出必须走一层 schema 校验与转换新增字段必须向后兼容模型升级必须经过完整的回归测试才能灰度。这个问题本质上是“把模型当黑盒”惹的祸重构了输出部分之后后面再升级模型就顺畅多了。第三个坑容易踩在成本优化阶段。我们的量化模型上线后线上评测发现某个垂直领域的回答质量出现明显下降。回看是因为当时评测集只覆盖了通用场景没覆盖该垂直领域的特殊表达方式。量化本身没有错错在评测样本不够。后来我们对所有量化模型强制附加一个领域评测集质量下降超过阈值的直接回滚。写在最后的体验分享这个项目做下来我最大的感受是AIGC 应用的落地不是“模型选得好就行”也不是“GPU 买得多就行”而是算力、延迟、成本、体验之间一场持续的平衡游戏。每一个技术决策背后都要回到一个朴素的追问——用户是否因此体验更好生意是否因此更健康。刚开始做技术选型时我也曾经被各种新框架和炫酷方案吸引总想全部都用上。后来发现全栈能力不等于什么都要自研更不等于什么都要用最新的。稳定的技术栈、清晰的指标体系和反复打磨过的运维流程才是支撑一个 AIGC 产品走下去的真正底座。如果你正准备启动类似的项目我的建议是先花时间把目标指标定清楚再动手搭建把成本模型设计到架构里而不是等账单出来再去优化延迟问题从端到端全链路去排查而不是只盯着模型服务本身。这些朴素的道理执行到位比任何“黑科技”都更管用。
