企业官网建设流程全解析

前阵子有个做智能客服产品的朋友找我吐槽，他们的AIGC功能在Demo阶段惊艳全场，一放到生产环境就被打回原形：用户一多就卡成PPT，GPU账单却呈指数级增长，整体成本比原来的传统客服系统贵了十几倍。这种现象我在不同类型项目里见过太多次了。它从来不是模型本身的问题，而是算力和互动延迟这两个工程问题没解决。这篇文章就围绕这两件事展开，讲讲从技术选型、架构设计到商业化落地，AIGC项目到底应该怎么搭才扛得住生产环境的考验。

1. AIGC项目真正烧钱和劝退用户的，从来不是模型本身

1.1 算力账单拆解：你为哪些看不见的资源付了钱

先说一个很多团队算错账的地方。大模型项目的成本大头不在“买模型”，而在“跑模型”。模型本身要么开源，要么按API调用付费，这笔账很清楚；真正让人看不明白的是GPU账单。尤其是自建推理集群以后，你会发现卡买了、集群搭了、服务也上线了，但GPU利用率长期在10%~30%徘徊，绝大部分时间都在为“峰值兜底”付钱。

这里面有几种典型的资源浪费。

一是显存膨胀。模型参数只是显存占用的下限，真正吃掉显存的是KV Cache。对话场景里每个并发请求都要缓存历史token的Key和Value，上下文越长、并发越高，KV Cache增长越快。很多团队只按模型参数量估算显存，结果并发一上来直接OOM。二是模型加载后的空闲等待。推理服务和Web服务不一样，模型加载到显存后即使没有任何请求，这块卡也不能干别的，出租率一旦波动，固定成本就压在那里。三是训练和推理混用资源导致的碎片化。拿训练集群的机器临时跑推理，排队时间不可控，GPU利用率也上不去。

我建议每个AIGC项目在立项时就把“单次推理成本”算清楚：一次完整对话平均多少输入tokens、输出多少tokens、单卡能支撑多少并发、目标DAU对应的峰值QPS是多少。然后把GPU包年包月、按量计费和竞价实例按一定比例配起来。只要单次成本模型没跑通，后面商业化越成功亏得越多，这个道理很多团队是上线三个月后看账单才明白的。

1.2 “卡顿”是怎么来的：感知延迟的三段式拆解

用户说你的AI产品“卡”，到底卡在哪里？绝大多数时候不是模型变笨了，而是从用户输入到看到回复的整条链路里，某个环节拖了后腿。

用户感知的延迟可以拆成三段。第一段是网络与接入层，用户请求从客户端到服务端，正常几十毫秒到几百毫秒，跨地域会更高。第二段是排队与预处理，请求到达后要经过鉴权、限流、RAG检索、Prompt拼接，然后进入推理队列等待GPU调度。第三段是模型推理本身，又分两块：首字延迟（TTFT）和后续token生成速度（TPOT）。对话场景下，模型每生成一个token大约需要几十毫秒到一两百毫秒，一整段回答如果按500字算，非流式返回可能让用户干等十几秒。

这里有个反直觉的点：同样的平均延迟，流式输出和非流式输出的用户体验完全不同。非流式要让用户盯一个转圈图标十几秒，流式输出用户看第一个字可能只需要一两秒，后面字是陆续“打”出来的。所以我一直跟团队强调，在线对话类AIGC应用必须做流式返回，这不是锦上添花，是生死线。TTFT做到1秒以内，token生成节奏稳定，用户就会觉得“这AI反应很快”；反过来，即使总延迟一样，只要TTFT超过3秒，投诉率立刻上来了。

1.3 训练与推理的诉求相反，别再一套集群打天下

训练集群和推理集群虽然都叫GPU集群，但本质诉求完全不同。训练要的是高吞吐、高利用率、大规模并行，任务跑起来就是几个小时甚至几天，对单次请求延迟不敏感，挂了可以断点续训。推理要的是低延迟、高并发、弹性伸缩，请求是离散的，高峰期和低峰期差异巨大，还需要频繁更新模型版本。

我见过不少团队图省事，训练和推理共用一套集群。结果是训练任务一跑，推理请求排队排到超时；推理高峰来了，又把训练任务卡死。训练和推理在资源调度、网络拓扑、存储策略上应该彻底分离。训练集群可以追求极致利用率和性能，推理集群则要把重点放在弹性伸缩、模型常驻、多版本灰度上。腾讯云上做推理我一般推荐用容器化方案，把GPU节点池和调度策略管控起来，而不是直接在某台GPU云服务器上手工启动服务，后面扩缩容会非常痛苦。

2. 算力侧的第一场硬仗：如何把GPU用出性价比

2.1 先算账再选卡：一张表看懂显存、并发和卡数

很多人选GPU卡型的时候只看“显存越大越好”，这是典型的拍脑袋。正确的做法是先按业务并发和上下文长度反推显存需求，再决定卡型和数量。我整理了一个估算方法，基本够用：

模型参数占用的显存 = 参数量 × 每个参数字节数。FP16/BF16是2字节，INT8是1字节，INT4大约0.5字节。比如7B模型用BF16部署，参数就要占约14GB；用INT4量化后大约4GB。

KV Cache的计算稍微复杂一点：KV Cache大小 = 2 × 层数 × KV头数 × 头维度 × 序列长度 × 字节数。以7B模型、32层、8个KV头、每个头128维为例，每token每层要占 2×8×128×2=8KB，32层就是256KB/token，处理4096上下文长度时，单请求KV Cache大约1GB。如果同时来64个并发请求，光KV Cache就是64GB。现在你就明白了为什么长上下文、高并发场景显存消耗那么惊人。

我给一个简化估算表，大家选卡时可以直接套：

选卡时不用死磕“一张卡跑最大的模型”，而要算“单卡能支撑多少并发、多少QPS”。业务并发不高但单请求上下文很长，瓶颈就在KV Cache；业务并发很高但通常问题很短，瓶颈就在卡的总吞吐。把这些量算清楚，再去看腾讯云上GPU云服务器的卡型，思路就清晰多了。

2.2 弹性伸缩不等于省一半钱，GPU的伸缩坑比CPU多得多

CPU应用的弹性伸缩已经非常成熟了，流量上来就加Pod，流量下去就缩掉，几乎不怎么需要操心。GPU应用的伸缩完全不是一回事，这里有几个典型的坑。

第一个坑是冷启动慢。如果伸缩组里没有提前准备好节点，新实例要经历申请、初始化、拉镜像、加载模型几个阶段。模型加载尤其慢，几十GB的模型从COS或CFS读进显存可能要几分钟。流量高峰来了触发扩容，等新实例Ready，高峰期已经过去了。所以GPU弹性伸缩必须配合“预热池”，预留一部分空闲但带好模型缓存的实例，随时准备接管流量。

第二个坑是指标用错。很多人照着CPU服务的习惯，用Pod CPU使用率做HPA指标，这对GPU集群完全无效。即使GPU算力已经打满，CPU可能才用不到30%。应该用GPU利用率和自定义的业务指标，比如推理队列深度、TTFT分位数，或者吞吐量指标来做伸缩。更合理的做法是结合时间预测，比如早晚高峰提前扩、低峰定时缩，而不是完全被动响应。

第三个坑是竞价实例的不确定性。我见过有人为了省钱把推理集群全部放在竞价实例上，结果上游一回收资源，整批推理服务同时被终止，用户端瞬间全部超时。稳妥的做法是核心流量用包年包月或按量实例保底，非核心的批量任务放到竞价实例，同时不能依赖任何单点实例的长期存活状态。

2.3 推理加速三板斧：量化、连续批处理、投机解码

同样的模型和卡型，推理框架和优化策略选对了，吞吐量差一个数量级都不夸张。我平时在腾讯云上搭推理服务，默认会考虑这三板斧。

第一是量化。INT8、INT4量化可以把显存占用直接砍半甚至砍到1/4，相应的单卡并发能力可以翻倍以上。量化有精度损失，但7B以下模型在通用对话、知识问答这类场景里，用GPTQ或AWQ微调后的INT4方案，质量损失肉眼几乎不可感知。特别是面向C端的大规模服务，量化基本是必选项。

第二是连续批处理。传统批处理方式要等人凑齐一批才开始推理，延迟大、吞吐低；连续批处理（Continuous Batching）和PagedAttention这类机制，可以在一个模型实例内部动态调度不同请求的生成进度，让新请求插空执行，GPU始终不被浪费。开源框架vLLM、TensorRT-LLM都支持，部署推理服务时优先选这类方案。起服务时大概这样的思路：

python -m vllm.entrypoints.openai.api_server \ --model /models/7b-chat \ --quantization awq \ --max-model-len 4096 \ --gpu-memory-utilization 0.9 \ --tensor-parallel-size 1

第三是投机解码。用一个很小的草稿模型先预测多个token，再交给大模型一次验证，理论上可以把生成速度提升1.5~3倍，尤其适合低并发、长回复的场景。如果你的业务很多是2000字长文生成，这个优化值得投入。

还有一点建议：推理加速优化不是上线后有空再做的，应该在技术选型阶段就决定好推理框架和精度方案，否则后面换框架等于整套服务重写。我在实际项目里见过因为前期只部署了原版HuggingFace Transformers，上线后吞吐不够，被迫换vLLM，结果多花了三四周做兼容性改造。

3. 互动延迟攻坚：让用户感觉“AI是在秒回你”

3.1 首字延迟TTFT去哪儿了：从HTTP到达开始一路追查

用户发出消息到看到第一个字，这段时间就是TTFT。它由很多环节叠加而成，想优化TTFT，得先搞清楚时间都花在哪了。

以常见链路为例：客户端请求先经过DNS解析、公网传输，到达接入层后要过鉴权、限流、日志采集，然后业务服务可能要检索向量数据库、拼接Prompt，最后才进入推理网关排队，GPU完成prefill计算返回第一个token。这中间任何一个环节都可能变成瓶颈。

我排查TTFT偏高的经验是，先做分段压测，把每段的耗时拆出来。最简单的方式是用curl看时间分解：

curl -w "dns:%{time_namelookup}s connect:%{time_connect}s ttfb:%{time_starttransfer}s total:%{time_total}s\n" \ -X POST https://api.example.com/v1/chat \ -H "Content-Type: application/json" \ -d '{"prompt": "你好"}'

如果DNS和连接时间就花了几百毫秒，优先考虑接入地域是否离用户太远，或者是否走了不必要的代理层。如果ttfb和total几乎一样，说明在服务端卡了，这时候要看RAG检索耗时、Prompt拼接逻辑和推理网关的排队时长。很多人以为TTFT高就是模型推理慢，结果查了一圈发现是向量数据库被慢查询拖死了，或者服务端用了不支持流式的网关，把整段响应缓冲到最后才发给客户端。这种问题换模型根本解决不了。

3.2 别把模型推理当成唯一瓶颈：流式、调度与就近接入

TTFT只是“第一个字”，真正的用户体验还要看整段输出的节奏。这就是我反复强调的流式交互。如果用HTTP短连接做流式，网关和代理层必须支持SSE或WebSocket透传，不能把响应体缓冲起来。有些代理服务器默认会积攒数据再一次性转发，流式效果直接没了，用户看到的就是“卡顿”和“一次蹦一大段”。

在线AIGC服务还需要设计好“排队与过载保护”策略。当GPU实例全部忙不过来时，与其让用户无限等待，不如快速返回一个“当前服务繁忙请稍后再试”，或者把请求放入有界队列并明确告诉用户预计等待时间。这背后其实是对“互动延迟”的一种主动管理：用户感知的不是绝对延迟，而是“不确定性”。如果系统能明确告诉他要等4秒，他会愿意等；如果一直转圈不知道要等多久，他就会关掉页面。

就近接入也非常重要。如果服务器部署在北京，用户在香港，单次公网RTT就多出几十毫秒，流式场景下每个token都受到影响。腾讯云上的GPU实例和负载均衡都支持多地域部署，我通常建议根据目标用户分布选择一两个核心region，配合负载均衡做就近调度。网络层面的几十毫秒优化，在流式交互场景里往往比模型层的优化感知更明显。

3.3 延迟观测清单：上线前先回答这几个问题

AIGC服务上线前，一定要先确认你能回答下面几个问题，否则出了问题都不知道去哪里看。

第一，TTFT的p50和p95是多少？有没有监控和告警？第二，生成阶段token的平均间隔时间TPOT是多少？每秒钟能稳定输出多少个token？第三，推理网关的排队深度是多少？高峰期有多少请求在等待？第四，GPU的KV Cache利用率高不高？是算力瓶颈还是显存瓶颈？第五，完整链路能不能做分布式追踪，从接入层到RAG到推理，出问题时几分钟内定位到具体环节？

这里提一下可观测性工具链，一般用Prometheus采集指标，Grafana看大盘，再接入OpenTelemetry做链路追踪。推理服务的指标要额外关注token级别的数据，比如每秒生成token数、prefill耗时、decode耗时、请求取消率。这些指标光看平均值没用，要看分位数。平均TTFT只有500ms的服务，可能p95已经到5秒了，因为少数慢请求会把平均值拉“好看”，但真实用户一直在骂。我自己的习惯是重点盯p95和p99，低于平均水平线以下再谈优化。

4. 商业化落地不是“把模型接上”就行：全栈方案怎么搭

4.1 从POC到生产，中间隔着稳定性、成本与合规

很多团队做AIGC产品，POC阶段跑得飞快，两三个星期就能拿出惊艳的Demo，但一到生产环境就各种翻车。核心原因是POC只验证了“模型能不能做这件事”，没验证“系统能不能稳定、低成本、合规地做这件事”。

稳定性上，大模型推理天然带有不确定性，同一个问题可能这次回得好，下次就胡言乱语。生产系统必须设计降级和兜底策略。比如模型服务超时或异常时返回缓存答案、切换到小模型、或者直接转人工；对模型输出做长度限制、格式校验、敏感词过滤。千万别让模型错误直接把整个业务流程打断。

成本上，要建立一套从“单次请求成本”到“毛利”的核算体系。一个对话用户每天用10次，单次成本1分钱，每个用户每天成本就1毛钱，如果产品收入模式打不平这笔账，用户量越大越危险。商业化产品最好在架构设计时就埋好计量点，把每个租户、每个功能、每个模型版本的token消耗都记录下来，按月分摊复盘，否则成本失控时你根本找不到源头。

合规与安全这块，B端客户尤其在意。很多企业客户要求数据不出私有化环境，模型也不能随便把内部数据拿去训练。这决定了架构上要支持私有化部署、数据加密、权限隔离。就算用云上的模型平台，也要确认数据是否只用于API调用、日志是否脱敏、内容安全是否接入。腾讯云上的内容安全、密钥管理这类基础组件，看起来不起眼，但商业化方案里缺了它们，政企客户那一关是真的过不去。

4.2 三种典型AIGC场景，工程侧重点完全不同

AIGC落地场景很多，但工程上不能套同一个模板。我拿最常见的三类场景来拆解。

第一类是智能客服和知识问答。核心是RAG（检索增强生成），工程重点在知识库切分、向量检索召回率、引用溯源和幻觉控制。延迟要求高，但生成长度通常较短。算力上7B~14B的模型加量化就够，难点在业务层面怎么把知识库维护好、怎么处理检索不到的问题。

第二类是内容创作工具，比如营销文案、短视频脚本、图片生成。这类场景特点是单次请求计算量大、耗时长，用户不一定需要实时返回，更看重批量生成效率和成本控制。工程上适合用异步任务队列，先把生成任务放到消息队列里，再由后端批量消费，结果生成完通过回调或站内信通知用户。这样既能削峰填谷，也能错峰利用GPU实例，把成本控制住。

第三类是数字人和实时互动应用。这类场景对延迟的要求最苛刻，用户对话要实时响应，音频、视频和文本流式输出要同步，任何一段链路卡顿都会直接毁掉体验。工程重点从单纯的模型推理扩展到了音视频传输链路、边缘节点接入和流媒体处理，技术栈横跨推理、RTC和传统的媒体服务。

三类场景的特点可以放在一起对比：

4.3 全栈选型蓝图：从GPU实例到知识库的完整链路

一个能跑通商业化的AIGC系统，绝对不是“找个开源模型部署一下”就完事了。从底层到上层，每一层都有明确的选型逻辑。

最底层是算力资源。中小团队不需要自建机房，直接在腾讯云上选GPU云服务器或者HAI这类高性能应用服务，快节奏验证时先用托管服务把模型跑起来，避免从0开始配驱动、装框架。规模化后再迁到TKE容器平台，做GPU节点池、弹性伸缩和资源调度。

再往上是模型平台层。如果是自训或微调，可以用TI平台管理数据标注、训练任务和模型版本；如果主要用开源模型推理，就自己搭建推理服务，把量化、连续批处理、投机解码这些优化做进去。模型层一定要做版本管理和灰度发布，上线新模型前先在内部环境验证效果，再逐步切流量，这是AIGC上线事故的最大避雷点。

接着是数据与知识层。RAG应用需要向量数据库来存知识切片和做相似度检索，还需要处理文档解析、切片、清洗这些环节。这一层最容易被低估，实际上知识库的质量直接决定回答质量，很多“换个大模型效果会更好”的认知是错的，问题往往出在知识库没建好。

最上层是应用与接入层，包括API网关、业务服务、流式推送、内容安全、监控告警。这一层决定了系统的对外体验，也决定了能不能好用、可运维。全栈落地时，每一层的选型都要和业务目标绑定，而不是单纯追新。

5. 我从AIGC上线实战中踩过的坑，提前帮你避开

5.1 冷启动失控：模型加载几百秒，扩容扩了个寂寞

有一次线上流量突增，伸缩组自动触发扩容，新实例陆续Ready，但用户侧的报错率不降反升。查了半天，发现新实例虽然被Kubernetes标记为Ready，但推理服务还在加载模型文件，根本没真正对外开放流量。流量调度器已经把请求分过去了，结果请求全在等待模型加载，纷纷超时。

后面的修复方案是双管齐下。一是准备“预热池”，提前把模型缓存在实例本地磁盘或CVM镜像里，新实例启动直接从本地读模型，而不是每次从对象存储下载几十GB文件；二是把就绪探针改成真实的模型加载完成检查，比如向推理服务发送一个小的health请求，确认能正常返回后再放流量。还有一个习惯是每次发版前先做一次冷启动演练，确认新实例从创建到真正可服务的时间，再决定预热池要留多少缓冲实例。

5.2 成本失控常常藏在看不见的token里

很多团队看成本只看GPU实例费用，但真正让账单失控的往往是“看不见的token”。

最常见的几个坑：第一个是用户中断生成后，上游请求没取消，后端还在继续跑完一整段生成，白白浪费token。第二个是异常重试机制设计得不好，一个超时请求被自动重试五次，每次都从零开始重新生成，等于一次用户请求消耗了六倍算力。第三个是日志和调试代码里打印了完整Prompt和Response，生产环境每天产生的日志数据量巨大，而且有多少字段和数据被写入了日志系统就产生了多少存储成本。第四个是测试环境和压测任务没有自动回收机制，测试脚本每隔几分钟打一批请求，人下班了任务还在跑，GPU资源闲置过夜但费用照扣。

建议所有AIGC项目从一开始就做全链路token计量，按租户、按功能模块、按模型版本建立成本分摊表。每个月做一次“成本归因分析”，找出那些消耗占比异常高的调用来源，往往能发现意想不到的浪费。

5.3 混合架构是常态：大模型负责聪明，小脚本负责可靠

一个很容易被忽略的认知是：生产环境的AIGC系统，不应该所有请求都走大模型。大模型虽然聪明，但单次调用成本高、延迟长，还有概率输出不可控内容。真正上线的系统，应该把简单任务和复杂任务分流。

比如智能客服场景，先用规则引擎或意图识别小模型判断用户问题类型，常见问题直接走知识库精确匹配，只有复杂问题和需要综合推理的请求才交给大模型。这样整体成本可能直接下降一半甚至更多，平均延迟也会明显下降。公众号或短视频文案场景也是类似，固定模板的简单内容用普通程序生成，创意性内容才调用大模型。

这个思路听起来朴素，但做起来需要架构上的刻意设计。在接入层就要预留“分流”的开关和策略位，而不是把所有请求一股脑转发给模型服务。模型不是越强越好，而是用得越精准越好。大模型负责系统里最聪明的那部分，小脚本和规则负责靠得住的那部分，两边配合，系统才能在成本、延迟和效果之间取得平衡。

最后说一点个人体会，我见过太多项目把精力全放在“换更好的模型”上，结果模型每次升级都带来新的兼容成本和稳定性风险。与其反复折腾那一层，不如老老实实把算力规划、延迟链路、成本计量和分流策略做扎实。这些看起来不性感的工程工作，才是AIGC项目真正能商业化的底座。