企业官网建设流程全解析

现在的 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 延迟来源拆解与量化

先看一次请求完整链路里延迟都消耗在哪些环节。

在动手优化之前，我们先把链路拆成了五段，分别埋点计时：网络传输、网关转发、排队等待、模型预填充、模型逐字生成。量化下来发现一个有意思的现象：当并发量不高的时候，最大的延迟开销在模型预填充和生成阶段；当并发量上来之后，排队时间的占比会急剧上升，甚至超过推理本身。

这里放一次会话的典型延迟分布供参考：

从这张表可以看出来，高负载下最刺眼的不是模型本身变慢了，而是排队时间被放大。这也是为什么单纯加卡不优化调度，延迟问题依然解决不了——因为瓶颈有可能在任务分发和队列策略上。

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 典型问题速查表

5.2 几个值得展开的踩坑记录

第一个坑是关于 WebSocket 网关的超时配置。我们的网关默认有个空闲超时时间，比较短。流式输出有时候因为模型生成时间较长，单条消息间隔超过了超时阈值，连接就被服务端切断了。用户看到的现象就是生成到一半突然中断，且前端不会自动重连。排查了很久才定位到是网关层在“捣鬼”。后来把流式接口的 WebSocket 空闲超时专门调大，同时前端加了心跳机制和断线重连逻辑，才算彻底解决。

第二个坑是不同模型版本灰度时的兼容问题。我们在做模型升级时，没注意到新版模型的输出格式有一处细微变化，结果下游的解析服务直接报错，线上用户体验瞬间劣化。后来规定所有的模型输出必须走一层 schema 校验与转换，新增字段必须向后兼容，模型升级必须经过完整的回归测试才能灰度。这个问题本质上是“把模型当黑盒”惹的祸，重构了输出部分之后，后面再升级模型就顺畅多了。

第三个坑容易踩在成本优化阶段。我们的量化模型上线后，线上评测发现某个垂直领域的回答质量出现明显下降。回看是因为当时评测集只覆盖了通用场景，没覆盖该垂直领域的特殊表达方式。量化本身没有错，错在评测样本不够。后来我们对所有量化模型强制附加一个领域评测集，质量下降超过阈值的直接回滚。

写在最后的体验分享

这个项目做下来，我最大的感受是：AIGC 应用的落地不是“模型选得好就行”，也不是“GPU 买得多就行”，而是算力、延迟、成本、体验之间一场持续的平衡游戏。每一个技术决策背后，都要回到一个朴素的追问——用户是否因此体验更好，生意是否因此更健康。

刚开始做技术选型时，我也曾经被各种新框架和炫酷方案吸引，总想全部都用上。后来发现，全栈能力不等于什么都要自研，更不等于什么都要用最新的。稳定的技术栈、清晰的指标体系和反复打磨过的运维流程，才是支撑一个 AIGC 产品走下去的真正底座。

如果你正准备启动类似的项目，我的建议是：先花时间把目标指标定清楚，再动手搭建；把成本模型设计到架构里，而不是等账单出来再去优化；延迟问题从端到端全链路去排查，而不是只盯着模型服务本身。这些朴素的道理，执行到位比任何“黑科技”都更管用。