最近半年，我们团队在搭一套全栈的AI工具链。

从底层的模型部署，到中间的API服务，再到上层的Web应用和移动端，整条链路都涉及AI能力。听起来很高大上，但实际做起来，踩了无数的坑，很多问题都让我熬夜排查到凌晨。

这篇文章，我想分享一下搭建全栈AI工具链过程中遇到的典型问题，以及我们是怎么解决的。希望能帮到正在做类似事情的朋友，让你们少走一些弯路。

坑一：模型部署后，推理速度慢得无法接受

第一个坑，是模型部署的性能问题。

我们用的是一个开源的7B大模型，在开发环境用CPU跑的时候，虽然慢，但还能接受。部署到线上的GPU服务器上，本以为会快很多，结果推理速度还是很慢，生成一句话要十几秒，用户根本没法用。

排查过程：

第一步，我们先看GPU的利用率。用nvidia-smi查看，发现GPU利用率只有20%左右，大部分时间GPU在空闲。这说明不是GPU算力不够，而是没有充分利用。

第二步，我们看了一下推理的batch size。发现每次只处理一个请求，没有做批处理。大模型推理是计算密集型的，单个请求的计算量小，GPU的并行计算能力用不上。

第三步，我们检查了推理框架。一开始用的是最基础的transformers库，直接用model.generate()来生成。这个方法简单，但性能很差，没有做任何优化。

解决方案：

我们把推理框架换成了vLLM。vLLM支持连续批处理（Continuous Batching）和PagedAttention，能同时处理多个请求，GPU利用率一下子提到了80%以上，推理速度提升了好几倍。

同时，我们对模型做了INT4量化，减少了显存占用，让单张卡能同时处理更多请求。量化之后，推理速度又提升了一些，精度损失在可接受范围内。

经验：大模型部署，不要用最基础的transformers直接跑，一定要用专门的推理框架（vLLM、TensorRT-LLM、TGI等）。这些框架做了大量优化，性能差距是数量级的。

坑二：长文本输入时，显存直接爆了

第二个坑，是长文本处理的显存问题。

我们的一个功能是长文档问答，用户上传一个几万字的文档，然后提问。一开始，我们把整个文档都塞到prompt里，结果直接OOM（显存不足），服务崩溃。

排查过程：

我们算了一下，几万字的文档，转换成token之后有好几万token。7B模型处理这么长的序列，KV缓存需要的显存是巨大的。我们用的A10显卡，24GB显存，根本不够。

而且，就算显存够，处理这么长的序列，推理速度也会很慢，因为自注意力的计算复杂度是序列长度的平方。

解决方案：

我们采用了RAG（检索增强生成）的方案。具体做法是：

第一步，把长文档切分成小块（chunk），每块几百到一千字。

第二步，把每个小块用embedding模型转换成向量，存到向量数据库里。

第三步，用户提问的时候，先把问题转换成向量，从向量数据库里检索出最相关的几个小块。

第四步，只把检索到的相关小块放到prompt里，让大模型基于这些信息回答。

这样，prompt的长度就控制在了几千token，显存和速度都没问题。而且，因为只保留了相关的内容，回答的准确率反而提高了，因为大模型不会被无关信息干扰。

经验：长文本处理，不要直接把所有内容塞给大模型。用RAG的方式，先检索再生成，是目前最成熟、最经济的方案。

坑三：AI生成的内容，有时候会胡说八道

第三个坑，是大模型的幻觉问题。

我们的AI助手功能，上线之后发现，有时候大模型会一本正经地胡说八道。比如，用户问一个产品的参数，大模型会编造一个不存在的参数；用户问一个技术问题，大模型会给出一个错误的答案。

这在To B的场景下是致命的，因为用户会把AI的回答当成权威信息，如果出错了，会影响我们产品的信誉。

排查和解决方案：

我们从几个方面入手解决这个问题：

第一，优化Prompt。在Prompt里明确告诉模型："如果不知道答案，就说不知道，不要编造。只根据提供的资料回答，不要使用资料以外的信息。"这个简单的指令，能减少一部分幻觉。

第二，引入RAG。前面说的RAG方案，不仅能解决长文本问题，还能减少幻觉。因为模型是基于我们提供的资料回答的，而不是靠自己的"记忆"，编造的可能性大大降低。

第三，增加事实核查环节。对于重要的回答，我们加了一个事实核查的步骤。用另一个模型或者规则，检查回答中的关键信息（比如数据、时间、人名）是否和资料一致。如果发现不一致，就重新生成或者标记为待人工审核。

第四，设置人工审核。对于高风险的场景（比如医疗、法律、金融），AI的回答必须经过人工审核才能发布。不能让AI直接面对用户。

第五，收集用户反馈。在回答下面加一个"有用/没用"的按钮，以及"举报错误"的入口。用户反馈的错误回答，我们定期整理，用来优化Prompt和知识库。

经验：大模型的幻觉是无法完全消除的，但可以通过RAG、Prompt优化、事实核查、人工审核等手段，把幻觉控制在可接受的范围内。关键是，不要在高风险场景下完全依赖AI。

坑四：流式输出，前端处理不好就乱序

第四个坑，是流式输出的前端处理。

为了提升用户体验，我们的AI回答用了流式输出，就是一个字一个字地显示出来，像打字机一样。但上线之后，发现有时候文字会乱序，或者重复，或者丢失。

排查过程：

我们用的是SSE（Server-Sent Events）来做流式传输。后端用FastAPI，前端用React。一开始，前端是直接把收到的片段拼接到状态里。但发现，在网络不好的时候，SSE的事件可能会乱序到达，或者同一个事件被接收多次。

另外，我们发现，有些代理服务器或者CDN会缓冲SSE的数据，导致前端不是实时收到，而是一下子收到一大段。

解决方案：

第一，前端处理的时候，给每个片段加序号。后端在每个SSE事件里带上一个递增的序号，前端根据序号来拼接，确保顺序正确。如果收到乱序的事件，先缓存起来，等前面的到了再显示。

第二，处理重复事件。前端记录已经处理过的事件ID，重复的直接忽略。

第三，配置服务器和CDN，关闭缓冲。在Nginx和CDN的配置里，设置X-Accel-Buffering: no，以及Cache-Control: no-cache，确保SSE数据不被缓冲，实时传输。

第四，加心跳机制。后端定期发送心跳事件，前端如果长时间没收到任何事件，就判断连接断开了，自动重连。

经验：流式输出看起来简单，但实际做起来有很多细节。SSE的乱序、重复、缓冲、断连，都要处理好。做好测试，尤其是弱网环境下的测试。

坑五：多模态上传，大文件总是超时

第五个坑，是文件上传的问题。

我们的功能支持用户上传图片、PDF、音频等文件，让AI处理。但上线之后发现，大一点的文件（比如超过10MB的PDF或者高清图片），上传经常超时，或者上传到一半失败。

排查过程：

一开始，我们是把文件直接传到后端API，后端再转发给AI服务。但大文件传输慢，而且经过多次转发，容易超时。我们的API网关默认超时是30秒，大文件上传根本不够。

另外，我们发现，有些用户的网络不好，上传速度慢，更容易超时。还有，文件上传过程中如果网络中断，之前传的就白传了，要从头再来。

解决方案：

第一，改用直传方案。文件不经过我们的后端，直接从前端传到对象存储（比如阿里云OSS、AWS S3）。后端只负责生成一个临时的上传凭证，前端拿到凭证之后直接上传。这样，文件传输不经过我们的服务器，速度更快，也不会占用我们的带宽。

第二，支持分片上传。对于大文件，前端把文件切成小块，一块一块地上传。上传过程中如果中断了，下次可以从断点继续，不用从头来。对象存储一般都支持分片上传，用对应的SDK就行。

第三，调整超时设置。API网关、后端服务、Nginx的超时时间，都根据需要调大。同时，设置合理的文件大小上限，避免超大文件拖垮服务。

第四，加上传进度条。前端显示上传进度，让用户知道上传还在进行，不会以为卡死了而刷新页面。

经验：文件上传，尤其是大文件上传，是Web应用里的一个经典难题。用对象存储直传+分片上传，是目前比较成熟的方案。不要让文件经过你的后端服务器，那样既慢又浪费资源。

坑六：AI服务的成本，比预期高了好几倍

第六个坑，是成本问题。

项目立项的时候，我们估算了一下AI服务的成本，觉得可以接受。但上线之后，发现实际成本是估算的好几倍，每个月的API费用和GPU费用高得吓人。

排查过程：

我们分析了成本的构成，发现几个问题：

第一，很多请求的prompt太长了。用户输入了大量的内容，加上我们的系统提示和历史对话，一次请求要消耗很多token。token消耗大，成本就高。

第二，没有做缓存。相同或者相似的请求，每次都重新调用AI，重复花钱。比如，很多用户问的是相同的常见问题，这些完全可以缓存答案。

第三，模型选型不合理。不管什么请求，都用最贵的大模型。但很多简单的请求（比如分类、提取关键词），用小模型就够了。

第四，没有限流。有些用户或者某些接口，调用量特别大，消耗了大量资源。没有有效的限流，导致成本失控。

解决方案：

第一，优化Prompt。精简系统提示，减少不必要的内容。对用户的输入做预处理，去掉无关的内容。控制历史对话的长度，只保留最近的几轮。

第二，加缓存。对于相同的问题，缓存AI的回答。缓存的时间根据场景来定，常见问题可以缓存久一点。用Redis做缓存，命中率高的话，能省很多钱。

第三，模型分级。简单的任务用小模型（比如GPT-4o mini、开源的小模型），复杂的任务才用大模型。可以做一个路由，根据任务的复杂度自动选择模型。

第四，加限流和配额。对每个用户、每个接口设置调用频率限制和总量配额。超过限制的，要么拒绝，要么降级（用更便宜的模型或者缓存）。

第五，监控和告警。对AI调用的成本做实时监控，设置预算告警。如果某个月的成本超过预算，及时收到通知，排查原因。

经验：AI服务的成本很容易失控，因为每次调用都要钱，而且调用量不可控。从一开始就要有成本意识，做好优化和监控。不要等账单出来了才发现超了。

坑七：并发一高，AI服务就雪崩

第七个坑，是高并发下的稳定性问题。

我们的产品做了一次推广活动，用户量一下子涨了好几倍。结果，AI服务直接崩了，所有用户都用不了。

排查过程：

我们看了一下监控，发现AI服务的GPU利用率直接跑到了100%，请求队列越积越长，每个请求都要等好几分钟。而且，因为请求堆积，内存也不够用了，服务开始OOM崩溃。

根本原因是，我们的AI服务没有做好容量规划和流量控制。平时流量小的时候没问题，一遇到流量高峰，就扛不住了。

解决方案：

第一，做容量规划。根据预估的最大并发量，准备足够的GPU资源。可以用云服务的弹性伸缩，流量大的时候自动加机器，流量小的时候自动减机器。不过GPU的弹性伸缩比较慢，因为要加载模型，所以要提前扩容。

第二，加限流和排队。在API网关层加限流，超过服务能力的请求，直接返回"系统繁忙，请稍后再试"，而不是让请求堆积把服务拖垮。对于可以等待的请求，放到队列里，慢慢处理。

第三，降级策略。在系统压力大的时候，自动降级。比如，关闭一些非核心的AI功能，或者用更便宜、更快的小模型，或者返回缓存的答案。保证核心功能可用。

第四，熔断机制。如果AI服务连续出错，或者响应时间太长，就熔断一段时间，直接返回错误或者降级结果，不要继续把请求发过去，让服务有时间恢复。

第五，压测。上线之前，对AI服务做压力测试，找到系统的瓶颈和最大承载量。根据压测结果，优化架构和配置。

经验：AI服务的并发能力有限，因为GPU很贵，不可能无限扩容。一定要做好流量控制和降级策略，保证在高并发下核心功能可用，而不是整个服务雪崩。

坑八：AI功能的用户体验，怎么做都觉得别扭

第八个坑，是用户体验问题。

AI功能做出来之后，我们自己用着总觉得别扭。用户反馈也说，不知道怎么用，或者用起来不顺手。

排查过程：

我们观察了用户的使用行为，发现几个问题：

第一，用户不知道AI能做什么。界面上只有一个输入框，用户不知道该输入什么，能得到什么。

第二，等待时间长，用户焦虑。AI生成回答需要几秒钟，用户在等待的时候不知道发生了什么，以为卡死了。

第三，回答不符合预期。用户想要的是简单直接的答案，但AI经常给一大段文字，或者答非所问。

第四，出错了不知道怎么办。AI回答出错了，或者服务不可用，用户不知道该怎么反馈，怎么重试。

解决方案：

第一，做好引导。在输入框下面加一些示例问题，或者常用功能的快捷按钮，让用户知道可以问什么、怎么用。新用户进来的时候，做一个简单的引导教程。

第二，流式输出+加载动画。用流式输出，让用户看到AI正在一个字一个字地生成，而不是干等。加一个加载动画和提示语，比如"正在思考中..."，让用户知道系统在工作。

第三，优化回答格式。根据不同的场景，设计不同的回答格式。比如，简单问题就给简短的答案，复杂问题给结构化的回答（分点、加标题）。让用户能快速找到想要的信息。

第四，做好错误处理和反馈。出错的时候，给用户清晰的错误提示和解决办法（比如"网络异常，请检查网络后重试"）。加一个反馈按钮，让用户可以举报错误回答，或者给回答打分。

第五，持续迭代。根据用户的使用数据和反馈，持续优化产品。AI产品的用户体验，不是一次就能做好的，需要不断地试错和改进。

经验：AI产品的用户体验，和传统产品不一样。因为AI的输出是不确定的，等待时间长，容易出错。在设计的时候，要充分考虑这些特点，做好引导、反馈、错误处理，让用户用得明白、用得安心。

一些总结

踩了这么多坑，我总结了几条经验：

第一，不要低估AI工程的复杂度。AI功能不是调一个API那么简单，从模型部署到性能优化，从成本控制到用户体验，每一个环节都有很多坑。要给项目留足时间和资源，不要想得太简单。

第二，用成熟的工具和框架。不要什么都自己造轮子。模型部署用vLLM，向量数据库用Milvus或Qdrant，前端框架用React+成熟的组件库。站在巨人的肩膀上，能少踩很多坑。

第三，从小处着手，快速迭代。不要一开始就做一个大而全的AI系统。先做一个最小可用的功能，上线验证，根据用户反馈和实际问题，逐步优化和扩展。

第四，重视监控和可观测性。AI系统的行为复杂，出了问题很难排查。一定要做好日志、监控、链路追踪，让问题可追溯、可定位。

第五，成本意识贯穿始终。AI服务是真金白银在烧钱。从设计阶段就要考虑成本，在开发过程中持续优化，上线后严格监控。不要等账单出来了才心疼。

第六，用户体验是关键。技术再好，用户用着不舒服，也是白搭。多站在用户的角度思考，把AI的不确定性和等待时间，用产品设计的方式化解掉。

写在最后

全栈AI工具链的搭建，是一个充满挑战的过程。每一个环节都可能出问题，每一个问题都可能让你熬夜排查。

但回过头来看，这些踩过的坑，都是宝贵的经验。每解决一个问题，对AI工程的理解就深一层。而且，看到自己做的AI功能被用户使用、给用户带来价值，那种成就感是无法替代的。

AI技术还在快速发展，新的工具、新的框架、新的模式不断出现。今天的最佳实践，明天可能就过时了。保持学习，保持实践，才能在这个快速变化的领域里不掉队。

希望我的踩坑经历能帮到大家。如果你也在做AI相关的开发，遇到过什么坑，欢迎在评论区分享，一起交流。