1. 大模型落地为什么总卡在“算力”和“延迟”这两道坎上
做过AIGC项目的人都有一个共同感受：模型效果本身已经不是最头疼的事了，真正让人夜不能寐的是两件事——算力成本压不住，互动延迟下不来。我参与过几个从零到一的AIGC应用搭建，从最早的文生图工具到后来的RAG知识库问答系统，几乎每一个项目在Demo阶段都跑得挺漂亮，一旦进入真实业务场景，问题就集中爆发了。
举个很典型的例子。我们之前做一个面向电商场景的智能客服，底层用的是一个70B参数级别的大模型，知识库走RAG架构，向量检索用Milvus。测试环境里单轮问答响应时间大概2到3秒，团队觉得还能接受。但上线之后，高峰期并发一上来，P99延迟直接飙到15秒以上，用户等两三秒没回复就关掉窗口了。与此同时，GPU利用率却只有30%出头，大量算力在排队和调度中被白白浪费。这就是典型的“算力没少花，体验没做好”。
这个问题的本质在于：大模型应用的性能瓶颈从来不在单一环节，而是贯穿在模型推理、向量检索、内容渲染、网络传输这条完整链路上。任何一个环节拖后腿，端到端的互动体验就会崩塌。腾讯云在这方面的全栈技术布局，恰好是围绕这条链路逐段优化的思路，而不是只盯着某一个点做文章。
这篇文章适合谁看？如果你正在做AIGC相关的项目——不管是文生图、文生视频、智能问答还是多模态交互——并且已经过了“跑通Demo”的阶段，开始面对真实的并发压力、成本压力和用户体验压力，那接下来的内容应该能帮你少走一些弯路。我会从整体架构设计讲到具体的技术选型和参数调优，尽量把每个决策背后的“为什么”说清楚。
2. 全栈视角下的AIGC架构到底该怎么搭
2.1 为什么“单点优化”救不了AIGC应用
很多人做性能优化习惯从最显眼的环节入手，比如觉得模型推理慢就换更小的模型，觉得检索慢就换向量数据库。这种思路在传统Web应用里可能管用，但在AIGC场景下往往事倍功半。
原因很简单：AIGC应用的延迟是串联的，不是并联的。用户发一条请求，要经过网关鉴权、Prompt组装、向量检索、上下文拼接、模型推理、后处理、内容渲染，最后才返回给用户。假设每个环节的平均延迟是500毫秒，七个环节串起来就是3.5秒。你把模型推理从500毫秒优化到300毫秒，端到端只减少了200毫秒，用户几乎感知不到。但如果你能把其中三个环节做成并行执行，或者把两个环节合并，端到端可能直接砍掉1秒以上。
所以全栈优化的核心逻辑不是“每个环节都做到最快”，而是识别关键路径、消除串行瓶颈、合理分配算力资源。腾讯云在这方面的做法是把整个链路拆成四层：基础设施层（GPU算力调度）、模型服务层（推理加速与编排）、数据层（向量数据库与缓存）、应用层（渲染与交互）。每一层都有独立的优化手段，但层与层之间的协同才是真正的难点。
2.2 四层架构的职责划分与协同逻辑
先把这个四层架构说清楚，后面讲具体实操的时候才不会迷路。
基础设施层负责GPU资源的池化管理和弹性调度。这里的关键词是“池化”——不是给每个模型固定分配几张卡，而是把所有GPU资源做成一个共享池，按需分配。这样做的好处是，当推理任务和微调任务同时存在时，可以动态调配资源，避免一边闲着一边排队。
模型服务层是核心中的核心，负责模型的加载、推理、批处理、量化加速。这一层要解决的问题是：如何在保证输出质量的前提下，让单张GPU卡服务更多的并发请求。常用的手段包括连续批处理（Continuous Batching）、PagedAttention、量化推理（INT8/INT4）等。
数据层主要处理向量检索和缓存。RAG架构下，向量数据库的检索速度直接影响首Token延迟。同时，高频问题的答案缓存可以绕过模型推理，直接把延迟从秒级降到毫秒级。
应用层则是用户直接感知的部分，包括流式输出、内容渲染、多模态交互。云渲染在这里扮演的角色是：当AIGC生成的内容需要实时预览或高质量呈现时，通过云端GPU渲染能力把结果推送到用户终端，而不是让用户本地设备去扛渲染压力。
这四层之间的协同关系可以用一个简单原则概括：数据层尽量前置，模型层尽量并行，基础设施层尽量弹性，应用层尽量流式。后面我会逐层展开讲具体的实现细节。
2.3 选型背后的取舍：为什么是这套组合
在向量数据库的选择上，我们最终用的是Milvus。原因有几个：一是它对大规模向量数据的索引支持比较成熟，IVF_FLAT和HNSW两种索引模式可以覆盖不同场景；二是它的分布式架构允许水平扩展，当知识库从十万级文档增长到千万级时，不需要重构整个检索层；三是社区活跃，遇到问题能找到参考方案。
模型推理框架方面，vLLM是目前比较主流的选择。它的PagedAttention机制对KV Cache的管理效率很高，在并发场景下的吞吐量比朴素实现能高出好几倍。如果你用的是Ollama做本地部署，开发阶段很方便，但生产环境还是建议上vLLM或者类似的推理服务框架。
云渲染这块，d5云渲染是一个常被提到的方案，适合需要高质量实时预览的场景。它的操作逻辑不复杂：把渲染任务提交到云端GPU节点，渲染完成后把结果流式推回终端。对于AIGC视频生成这类场景，云渲染几乎是刚需，因为本地设备很难在合理时间内完成高质量渲染。
3. 模型推理加速：从“能跑”到“跑得快”的关键操作
3.1 连续批处理与PagedAttention的配合逻辑
先解释一下为什么这两个技术要放在一起讲。传统的静态批处理是这样的：凑够一批请求，一起送进GPU，等这批全部推理完，再处理下一批。问题在于，同一批里有的请求生成10个Token就结束了，有的要生成500个Token，短的必须等长的，GPU利用率自然上不去。
连续批处理（Continuous Batching）的思路是：不等整批完成，只要有请求结束，立刻把新的请求塞进去。这样GPU几乎不会空闲。但这样做带来一个新问题——KV Cache的管理变得非常复杂。每个请求的KV Cache大小不同，生命周期不同，如果按传统方式预分配显存，浪费会非常严重。
PagedAttention就是来解决这个问题的。它把KV Cache切成固定大小的块（Block），像操作系统管理内存页一样按需分配。这样一来，显存利用率能提升到90%以上，同时支持更大的批处理规模。
实际操作中，vLLM默认就开启了这两个机制。你需要关注的核心参数是--max-num-seqs（最大并发序列数）和--gpu-memory-utilization（显存利用率上限）。前者控制同时处理多少个请求，后者控制vLLM能用多少比例的显存。我的经验是，gpu-memory-utilization设到0.90到0.92之间比较稳妥，留一点余量给系统和其他进程。
3.2 量化推理的收益与代价
量化是另一个立竿见影的加速手段。简单说，就是把模型权重从FP16降到INT8甚至INT4，减少显存占用和计算量。INT8量化通常能带来1.5到2倍的推理加速，显存占用减半；INT4量化更激进，但输出质量可能会有可感知的下降。
这里有一个容易踩的坑：不是所有模型都适合量化。有些模型在量化后会出现明显的“智力下降”，表现为回答变得笼统、逻辑不连贯、或者频繁出现重复。我的做法是，量化后一定要跑一轮评估集，对比量化前后的输出质量。如果下降在可接受范围内（比如准确率下降不到2个百分点），那就值得上量化；如果下降明显，宁可多花点算力也别牺牲体验。
另外，量化方式也有讲究。GPTQ和AWQ是两种常见的后训练量化方法，AWQ通常对激活值的保护更好，输出质量更稳定。vLLM对这两种格式都支持，加载时指定--quantization awq或--quantization gptq即可。
3.3 实操：vLLM部署大模型的完整参数配置
下面是一个我实际用过的vLLM启动命令，部署的是一个13B级别的模型，场景是RAG问答，并发要求在50左右：
python -m vllm.entrypoints.openai.api_server \ --model /path/to/your/model \ --tensor-parallel-size 2 \ --max-num-seqs 64 \ --gpu-memory-utilization 0.90 \ --max-model-len 8192 \ --quantization awq \ --enable-prefix-caching \ --port 8000逐条解释一下关键参数的选择理由。tensor-parallel-size 2表示用两张GPU做张量并行，适合13B到70B级别的模型。max-num-seqs 64是最大并发序列数，设太小会限制吞吐，设太大可能导致显存不足，需要根据实际显存和请求长度来调。max-model-len 8192是最大上下文长度，RAG场景下通常够用，如果你的知识库文档很长，可以适当调大，但注意这会增加KV Cache的显存占用。enable-prefix-caching开启前缀缓存，对于系统Prompt固定的场景，能显著减少重复计算。
注意：
gpu-memory-utilization不要设到0.95以上，否则容易触发OOM。另外，如果你的模型不是量化版本，去掉--quantization参数即可。
启动之后，用OpenAI兼容的接口就能直接调用，现有的LangChain或FastGPT之类的框架可以无缝对接。腾讯云部署FastGPT的流程也类似，核心是把模型服务的地址配到FastGPT的环境变量里。
4. 向量数据库与RAG链路的性能调优
4.1 Milvus索引选择：IVF_FLAT还是HNSW
向量数据库的检索速度直接决定了RAG的“首Token延迟”。Milvus支持多种索引类型，最常用的是IVF_FLAT和HNSW。两者的核心区别在于：
| 对比维度 | IVF_FLAT | HNSW |
|---|---|---|
| 检索速度 | 中等 | 快 |
| 召回率 | 高（nprobe调大时） | 高 |
| 内存占用 | 较低 | 较高 |
| 构建速度 | 快 | 慢 |
| 适用场景 | 千万级以下，内存有限 | 亿级以下，追求低延迟 |
我的建议是：如果你的向量规模在百万级以内，对延迟敏感，直接上HNSW，把M参数设在16到32之间，efConstruction设在200到400之间。如果规模到了千万级，内存吃紧，那就用IVF_FLAT，把nlist设在4096左右，查询时nprobe设在32到64之间。
这里有一个实操心得：Milvus的索引参数不是设完就一劳永逸的。随着数据量增长，最优参数会变化。我一般会每隔一段时间跑一次基准测试，对比不同参数下的召回率和延迟，动态调整。
4.2 RAG链路中缓存层的设计要点
向量检索再快，也比不上直接命中缓存。在RAG架构里，缓存层能挡掉相当一部分重复请求。具体怎么做？
第一层是语义缓存。把用户的问题先做向量化，然后在缓存库里检索相似问题。如果相似度超过阈值（比如0.95），直接返回缓存答案，跳过整个RAG流程。这一层能把高频问题的响应时间从秒级降到毫秒级。
第二层是检索结果缓存。如果语义缓存没命中，但向量检索的结果和之前某次请求高度重合，可以复用那次的检索结果，只重新跑模型推理。这一层省掉的是向量检索的时间。
第三层是Prompt缓存。vLLM的prefix caching本质上就是这一层，对于系统Prompt固定的场景，KV Cache可以复用，减少重复计算。
这三层缓存叠加起来，在真实业务场景下通常能挡掉40%到60%的请求，效果非常明显。
4.3 向量化模型的选择与维度权衡
向量化模型的选择经常被忽视，但它对检索质量的影响很大。常见的方案有BGE系列、M3E、以及各种多语言模型。选择时主要看三个维度：语言支持、向量维度、推理速度。
向量维度不是越高越好。768维和1024维在检索效果上的差异，很多时候并不明显，但1024维的存储和计算成本要高出不少。我的经验是，中文场景下768维基本够用，除非你的知识库特别专业、术语特别多，才需要考虑更高维度。
另外，向量化模型最好和生成模型分开部署。向量化模型通常比较小（几百MB到几GB），可以用CPU推理或者小GPU，不需要占用大模型的GPU资源。这样资源分配更合理，成本也更低。
5. 云渲染与多模态交互的延迟优化
5.1 云渲染在AIGC场景中的角色
AIGC不只是文本生成。文生图、文生视频、3D内容生成这些场景，对渲染能力的要求很高。本地设备做渲染，要么速度慢，要么质量差，很难两全。云渲染的思路是把渲染任务放到云端GPU集群，利用云端算力快速完成渲染，再把结果推送到终端。
d5云渲染的操作流程大致是这样的：在本地完成场景搭建和参数配置，把任务提交到云端，云端分配GPU节点执行渲染，渲染完成后自动回传结果。对于需要实时预览的场景，还可以开启流式渲染模式，边渲染边推送，用户不用等全部完成就能看到效果。
这里的关键优化点是渲染任务的调度策略。如果所有任务都排一个队列，先提交的先渲染，那一个复杂任务就可能堵住后面一堆简单任务。更好的做法是按任务复杂度分级，简单任务走快速通道，复杂任务走批量通道，同时利用空闲节点做预渲染。
5.2 流式输出与前端交互的配合
文本生成的流式输出已经比较成熟了，SSE（Server-Sent Events）或者WebSocket都能实现。但多模态场景下的流式输出更复杂——图片是分块生成的，视频是逐帧渲染的，怎么让用户感知到“正在进行”而不是“卡住了”？
我的做法是分阶段反馈。比如文生图场景，先返回一个低分辨率的预览图，让用户知道构图和风格大致对了，然后再逐步返回高清版本。视频生成场景，先返回关键帧，再返回完整视频。这样用户的心理等待时间会大幅缩短。
前端这边，进度条和骨架屏要用好。不要只显示一个转圈圈的loading，那会让用户觉得系统卡死了。显示具体的进度百分比，或者显示当前正在执行的步骤（“正在检索知识库”“正在生成回答”“正在渲染图像”），用户体验会好很多。
5.3 多模态大模型的部署注意事项
多模态大模型（比如支持图文输入的模型）的部署比纯文本模型复杂得多。主要复杂在两个方面：一是显存占用更大，因为要同时处理图像编码器和文本解码器；二是输入预处理更耗时，图像需要做resize、归一化、编码等操作。
部署时的建议是：图像编码和文本推理尽量分开。图像编码可以用单独的GPU或者CPU来做，编码结果缓存起来，避免每次请求都重新编码。另外，多模态模型的批处理策略也需要调整，因为图像输入的大小不固定，不能简单地按Token数来组批。
6. 常见问题与排查技巧实录
6.1 推理服务OOM的排查思路
OOM是大模型部署中最常见的问题。排查时按以下顺序检查：
模型本身是否超出显存：先算一下模型权重的显存占用。FP16下，每10亿参数约占用2GB显存。一个13B模型大约需要26GB，加上KV Cache和中间激活值，实际需要35GB以上。如果单卡显存不够，就要考虑张量并行或者量化。
KV Cache是否过大：KV Cache的显存占用和
max-model-len、max-num-seqs、模型层数、注意力头数都有关。如果OOM发生在高并发时，优先调小max-num-seqs或者max-model-len。是否有显存泄漏：如果服务运行一段时间后OOM，而不是启动就OOM，那可能是显存泄漏。检查是否有未释放的中间变量，或者vLLM版本是否有已知的显存管理问题。
6.2 向量检索召回率低的调整方法
召回率低表现为：明明知识库里有答案，但检索不出来。调整方法按优先级排列：
- 检查向量化模型是否适合当前语言和领域。中文场景用中文优化的模型，专业领域考虑微调向量化模型。
- 调整索引参数。HNSW调大
ef，IVF_FLAT调大nprobe。 - 检查文档切分策略。切得太碎会丢失上下文，切得太大会引入噪声。一般建议每段300到500字，重叠50到100字。
- 考虑混合检索。向量检索结合关键词检索（BM25），能互补短板。
6.3 常见问题速查表
| 问题现象 | 可能原因 | 排查方向 | 解决手段 |
|---|---|---|---|
| 首Token延迟高 | 向量检索慢 | 检查索引类型和参数 | 换HNSW或调大nprobe |
| 吞吐量上不去 | 批处理效率低 | 检查max-num-seqs | 调大并发数或启用量化 |
| 输出质量下降 | 量化过度 | 对比量化前后评估集 | 换AWQ或降低量化等级 |
| 服务间歇性OOM | 显存碎片 | 检查显存利用率 | 降低gpu-memory-utilization |
| 多模态输入报错 | 图像尺寸不统一 | 检查预处理逻辑 | 统一resize到固定尺寸 |
6.4 几个踩过的坑和实操心得
第一个坑：盲目追求大模型。一开始总觉得参数越大效果越好，上了70B模型，结果推理成本是13B的五六倍，效果提升却不到10%。后来换成13B加RAG，效果反而更好，因为知识库补足了模型的知识盲区。所以选模型要看场景，不是越大越好。
第二个坑：忽视冷启动问题。模型服务刚启动时，第一次推理特别慢，因为要加载权重、初始化CUDA上下文。解决办法是启动后先跑几个预热请求，把常用路径的KV Cache和计算图都初始化好。
第三个坑：向量数据库和模型服务网络延迟。如果Milvus和vLLM部署在不同节点，网络延迟可能成为瓶颈。建议把它们放在同一可用区，内网互通，延迟能控制在1毫秒以内。
第四个坑：忘记设置超时和降级。模型推理偶尔会卡住，如果没有超时机制，请求会一直挂着。一定要设置合理的超时时间（比如30秒），超时后走降级逻辑，返回缓存答案或者提示用户稍后重试。
7. 成本控制与弹性伸缩的实战策略
7.1 GPU资源池化的具体做法
GPU资源池化的核心是“共享”和“弹性”。共享是指多个模型服务共用一组GPU节点，通过调度器动态分配；弹性是指根据负载自动扩缩容，高峰期加卡，低谷期减卡。
腾讯云的GPU调度方案支持这种池化模式。具体操作上，可以把推理服务、微调任务、渲染任务都注册到同一个资源池，设置不同的优先级。推理服务优先级最高，保证在线请求的响应；微调任务优先级低，利用空闲资源跑；渲染任务可以设置截止时间，在截止时间前完成即可。
这样做的好处是GPU利用率能从30%提升到60%以上，成本直接减半。
7.2 按量付费与预留实例的组合策略
成本控制不是一味省钱，而是把钱花在刀刃上。我的策略是：基线负载用预留实例，峰值负载用按量付费。
具体来说，先统计过去一段时间的GPU使用情况，找出基线负载（比如每天最低需要4张卡）。这部分用预留实例，单价更低。峰值时段（比如促销活动期间）临时加按量付费的卡，活动结束就释放。这样既保证了稳定性，又不会为闲置资源买单。
7.3 监控指标与告警设置
没有监控的优化都是盲人摸象。必须监控的核心指标包括：GPU利用率、显存占用、请求队列长度、首Token延迟、端到端延迟、错误率。这些指标要设置合理的告警阈值，比如GPU利用率持续5分钟低于20%说明资源浪费，持续5分钟高于90%说明需要扩容。
我一般会在Grafana上做一个看板，把这些指标都放上去，一眼就能看出系统状态。告警走企业微信或者邮件，确保第一时间能响应。
8. 从项目实践看AIGC商业化的关键决策
8.1 什么场景适合上AIGC，什么场景不适合
不是所有场景都适合上AIGC。我的判断标准是：容错率高、交互频率适中、知识更新快的场景优先上。比如智能客服、内容辅助生成、知识库问答，这些场景用户对偶尔的错误有一定容忍度，而且AIGC能显著提升效率。
反过来，对准确性要求极高、容错率极低的场景，比如金融交易、医疗诊断，AIGC目前还不适合做最终决策，只能做辅助。另外，交互频率极高的场景（比如每秒几千次请求），AIGC的成本可能扛不住，需要仔细算账。
8.2 从POC到生产的几个关键里程碑
POC阶段跑通不难，难的是从POC走到生产。我总结的几个关键里程碑是：
第一，性能达标。P99延迟控制在可接受范围内，通常文本问答在3秒以内，图像生成在10秒以内。
第二，成本可控。单次请求的成本要算清楚，包括GPU、存储、网络、人力。如果单次成本高于业务价值，那这个场景就不成立。
第三，质量稳定。输出质量不能忽好忽坏，要有评估机制和兜底策略。
第四，运维就绪。监控、告警、日志、降级、扩容，这些都要准备好，否则上线就是灾难。
8.3 团队能力建设的一点体会
AIGC项目对团队能力的要求和传统开发很不一样。传统开发重逻辑，AIGC项目重实验和调优。我的体会是，团队里需要有一个人专门负责“调参”和“评估”，不断尝试不同的模型、参数、Prompt策略，找到最优组合。这个人不一定是算法工程师，但一定要有耐心和数据敏感度。
另外，不要指望一次就把所有事情做对。AIGC项目的迭代速度很快，模型在更新，工具在更新，最佳实践也在更新。保持学习，保持实验，比一次性追求完美更重要。
最后分享一个我在实际项目中验证过的小技巧：在RAG链路的Prompt里，明确告诉模型“如果知识库中没有相关信息，请直接说不知道，不要编造”。这一句话能大幅降低幻觉率，比很多复杂的后处理手段都管用。
