本文核心观点：
基于大模型的 AI 原生应用将越来越多，容器和微服务为代表的云原生技术将加速渗透传统业务。 API 是 AI 原生应用的一等公民，并引入了更多流量，催生企业新的生命力和想象空间。 AI 原生应用对网关的需求超越了传统的路由和负载均衡功能，承载了更大的 AI 工程化使命。 AI Infra 的一致性架构至关重要，API 网关、消息队列、可观测是 AI Infra 的重要组成。
AI 给业务带来了哪些变化？
AI 给应用和架构带来了哪些变化？
我们正在探索的实践场景。
AI 到底给我们带来了哪些变化？
Aliware
第二个原因是算力限制和投入产出的考量。我不知道今天在场的多少家公司买了 GPU，在大模型上投入了多少费用，但是产出是否能带来足够的经济效益。好消息是各个云厂商大幅降低了大模型的训练和推理成本，很多公司的 ROI 就立马转正了。另外，AI Infra 在资源利用率、研发效率、业务稳定性上的成熟度远不如云原生的这套基础设施，也缺少开源、商业产品等带来的最佳实践。例如用 GPU 每次调用做一次搜索区间的成本更高，这些都对拐点的到来会产生影响。
第三个原因是合规性、价值观对齐、算法偏见和公平性等的约束。没有这些约束，大模型就会衍生出大量的社会问题、道德问题等。我们和做大模型落地的企业聊，好奇为什么你们在 AI 上落地了这么多场景，为啥外边看不到呢？原因就是要保证合规，放慢了应用上线的节奏。
GPU 和 CPU 正在相互融合，摩尔定律决定了 CPU 性能每两年提升1倍，但 GPU 的性能每两年能增加10倍。未来10年，GPU 性能能提升100倍，成本持续下降，如果每个手机都内置一个 GPU，在端上进行推理，那对 AI 的落地会是非常大的推进。在座的各位都见证了 CPU 给我们生活带来的变化，我相信演进速度更快的 GPU ，会给我们这个时代带来更大的变化。
AI 给应用和架构带来了哪些变化？
Aliware
有人会问，AI 时代，应用和应用架构发生了哪些变化，我们从下方这个图来看下演进过程。
第一是 API First，API 成为 AI 原生应用的一等公民。现在每家企业都做降本增效，降本很好衡量，就是用 IT 支出，减少计算设备、提升算力利用率，优化数据存储，但是效率提升要用数字来做显性化衡量就比较难。我们实施敏捷开发的时候，会引入 DevOps、低代码、AI 编程，提效是提效了，但是如何用标准化的方式来衡量呢？人均产出么？计算方式过于复杂，口径不一，影响因子太多。
API First 在国外其实已经非常火、市场接受度也很高，因为以往在线应用都是通过 Service 对外暴露提供服务能力，但是基于大模型的 AI 原生应用将会通过 API 对外提供服务能力，因此，企业的数字化资产管理和上下游生态，均会基于 API 标准来构建。但国内仍处于布道期，我们都是 Code First，前后端各自把代码写好，然后怼在一起，反复修改调试，协作效率不高，业务规模越大，技术债越重。API First 则是先定义好 API 规范，再 code，并能借助 AI 来自动生产代码、自动化单元测试，甚至包括攻防演练的代码、前端代码等，都能自动搞定。API 定义世界，AI 生成世界，API 会成为企业的核心资产，并作为衡量效率的标准化方式。
此外，大量的非 AIGC 应用例如物流系统、体育赛事、娱乐活动、天气信息等，作为 Agent 编排的被调用方，将加速把规范 API 设计提上日程，避免接口调用的兼容性问题，改变 Code First 的开发习惯、提升开发效率，融入 AIGC 大生态。
OpenAI 的 API 日调用量已经超过国内一线互联网公司的日活用户数，但是今天围绕 API First 的后端协同还未发生变化。大部分企业仍然是用信息聚拢的方式，来提供搜索结果。当 API 成为企业服务用户不可或缺的方式后，将会产生大量的 AI 原生应用，对各家的 API 进行智能编排，提供更加智能的服务。因此，Agent 编排将成为 AI Engineering 领域必不可缺的一环。
简单的场景只需要单 Agent，结合提示词优化和提示词模版就可以解决，但是例如 AI 工程师的场景，就需要多个 Agent 做编排和协同，以便于解决复杂问题。从 Agent 角色上看，需要 PD Agent、研发 Agent、测试 Agent 等组合，才能做好协调，最后得到整体结果的提升。再举一个生活中的例子，我们要做一个团建计划，现在的做法是小红书找旅游攻略，然后同飞猪去看火车票和机票，再找合适的酒店，还要去点评找饭店。以后可能只需要做好提示词工程，例如输入团建的时间、地点、人数，以及其他定制化需求（团建额度、表格对比输出...），就能直接给出团建方案了，甚至由 AI 以一问一答的方式来引导我们输入提示词，进一步降低自然语言对话的门槛。
Langchain 已经提供了面向 Python 开发者非常友好的 Agent 的编排能力，对于国内占比 65% 的 Java 开发者群体，我们将基于 Spring AI 帮助 Java 程序员快速掌握 AI 编程能力。
第二是消息解耦。我不知道大家做 AIGC 开发的时候，平均 RT 大概多少？有能做到延迟 3 秒以下的么？早期文生文的时候，没有机制去实时检索和整合训练集外的知识，RT 是比较低的。但是 RAG 技术出现后，除了在库内进行检索，还会基于大模型利用更加具体和即时的信息，来提升输出内容的准确性和实效性。信息传输过程中的报文是非常大的，推理对算力的消耗也非常大。例如通义在春节期间上线过一个全民舞王，视频生成的 RT 是非常高的，要等10几分钟。
另外，大模型推理链路中，会涉及图片、视频消息的传输，存在消息体大小限制过低的痛点。所以如何通过消息解耦来降低 RT，并支持更大的消息体，都是 AIGC 应用必然会应用到的技术。并且，面对大模型或大数据量，消息量显著增加，AI 开发者不仅需要通过架构演进降低消息队列成本、提升消息队列的数据处理能力，还需要完善消息队列运维体系的建设，确保系统的稳定性和可靠性。
第三是 AIOps。这里的 AIOps 是指 OPS for AI，而不是 AI for OPS。我们提炼三个应用场景。
模型优化：大模型普遍依赖数据、训练、部署、验证、调优等，需要做到对大模型生命周期的全方位了解以及问题发现，从而制定优化策略。
模型选择：选择合适的大模型并判断其实际效果，通过访问跟踪数据，可以轻松地将各种请求路由到不同的 LLM 模型并衡量其性能和成本。
模型应用：LLM 应用的生命周期还会和很多工具或者组件进行交互，包含 Prompt 调优、输入输出，模型调用、RAG、用户交互、效果评估、成本费用、故障排查等多方面。
以模型应用的故障排查的场景展开为例，目前大部分 LLM 应用都是单体架构，提供独立的交互入口，虽然应用架构相比微服务简单很多，但是入口应用到后端应用和模型，失败率较高，排查代价非常大，缺少成熟的可观测技术和实践。之前我拜访过一家大模型企业，他的报文非常大，日志经常打不起来。这里要是用 Java 那一套可观测体系肯定是搞不定的，因此我们正在开发 Go 和 Python 的 Agent 技术，去完善 LLM 应用的可观测生态。
AI 原生应用，对网关的需求已经超越了传统的路由和负载均衡功能，还需要为 AI 应用开发者提供便利，例如统一不同 LLM 提供商的 API 协议，并提供 API 编排、安全、稳定性和成本控制等扩展功能。因此 AI 时代，网关承载了更大的工程化使命，需要在网关侧做好 AI 场景的深度扩展和集成。
阿里云网关开源项目 Higress 升级为 AI 原生的 API 网关，提供了丰富的 AI 插件扩展和生态集成，让开发者一键构建 AI 应用。Higress 在支撑通义、云产品 PAI 和百炼的过程中，积累了大量 AI 应用工程话的能力，下面我们将详细介绍。
热更新场景
安全防护和敏感词过滤场景
Higress 网关的另一个优势是处理大报文时的内存消耗非常少。传统的 Nginx 网关处理大报文会有 OOM 内存溢出的问题，我遇到过一个客户，一开始用的就是 Nginx 网关，就出现了把内存踩爆的情况。其他的例如敏感词过滤、安全防护等，都会基于网关来实现，因此在 AI 原生应用架构下，网关承载了更多的业务需求。
流控场景
我们的企业客户有时候都是诚惶诚恐的。每年耗费几十几百万采购云计算资源，黑产可能只需要几百几千 QPS 就能搞垮你的系统，甚至迁移走你的数字资产。AI 时代，客户屯的 GPU 资源越来越多，黑客攻击轻轻松松就把 GPU 资源跑满，资产损失大幅提升。因此，在网关入口做整个的流量防护和安全防护，意义和必要性会变得更大。Token 级别的流控、IP级别的流控，以及面向全链路的观测体系，就显得非常关键了。但我们现在看到的是围绕 GPU 的配套体系，效率是非常低的。
负载均衡场景
不同的场景，对 GPU 的消耗量是不同的。有的场景只需要一张卡，文生视频就需要多个卡并行去处理。在 CPU 场景，我们通过容器的调度技术提升计算资源的利用率，GPU 场景还没见成熟的资源调度方案，因此负载均衡对 GPU 的利用率提升就很关键了。我们有一个客户，手里有几百张卡，有的卡负载很高、有的卡负载很低，导致大量的闲置资源，没法充分的压榨 GPU。然后我们基于长链接后端的最小负载进行优化，通过长链接的负载均衡技术，慢慢优化 GPU 的利用率。常规的文生文、文生图的场景都可以通过网关的负载均衡，再结合重试和容错功能，来提升利用率。
目前阿里的通义系列、云产品百炼和 PAI，外部用户 Sealos、Lepton.ai 都跑在了我们的 Higress 网关上。比如说 Sealos，他的开发者用户已经非常多了，一个用户一个模型，模型特别多的时候，网关的域名就非常的多，会影响推送性能。因此他们用 Higress 网关实现按需订阅、差量推送，来降低大批量域名对网关的消耗。
上面我们讲了网关的 4 个典型场景，接着我们来看下 AI Proxy。今天搞大模型的公司毕竟是少数，更多的企业是基于大模型做应用的落地，去对接多个大模型，例如通义GPT、通义、还有 Google 的羊驼等。但是不同模型的通信协议是不一致，身份体系也不同。
第一类需求，以 Sealos 为例，他优先调用的是 GPT，次选是通义，使用 Higress 网关就可以在 GPT 调用失败的时候实现容错，来调用通义。第二个需求，很多大型企业主账号接入了大模型，给每个员工开通一个使用的子账号，并可以对每个子账号开放或屏蔽模型类型进行自由选择，同时提供体验一致、高可用的服务，这个就是通过 Higress 网关的统一身份的能力来实现的。
很多公司基于 Langchain 的链式能力已经可以做些拖拖拽拽、低代码的事情，像包括阿里云的百炼，对于模型的训练、部署都是非常简单的。后续我们会把 AI 相关的更多工程化能力，通过 Spring AI 对接起来，方便广大 Java 开发者。
以上只是 AI 应用的应用架构视角，若从 AI Infra 的视角看，还有计算、存储、网络、操作系统等，这些构成了完整的 AI Infra，而 AI Infra 的一致性架构至关重要，这里暂不展开，网关、消息队列、可观测是 AI Infra 的重要组成。
我们正在探索的实践场景
Aliware
基于 AI 的实践场景很多，选择哪个先落地的商业判断很重要。一类是只解决 50% 的问题，但是可用性 100%。另一类是解决 80% 的问题，但是可用性只有 60%，这是不同的选择。
所以我们优先上线的场景是在 Spring Cloud Alibaba 的官网，和通义深度集成，构建了一个 AI 答疑工程师。使用 Spring Cloud Alibaba 过程中遇到的开发问题或难题，都可以向这个 AI 答疑工程师进行提问，我们现在每天有几百个 ID 在和 AI 答疑工程师进行交互，问题的解决率可以达到 90% 以上。然后，我们有一个后台能持续的去完善答案。有数据、有场景、能根据实际的反馈去完善答案，形成正循环。这就是一个真正管用的 AI 工具的基本三要素。
开发者 AI 答疑工程师，我们经历了 3 种选型。
提示词增强模式：早期我们用的是提示词增强模式。通义 1.0 的时候，模型能力还比较弱，使用提示词对答疑效果帮助非常大。但随着 2.0、2.5 的出现，最新已经是 3.0 了，我们发现提示词对结果的优化价值越来越弱化，因为模型能力在不断增强，上面每一层做的价值其实都在被弱化。
微调：理想情况是我们希望 AI 答疑工程师每天都能提升答疑能力，实现快速迭代，但是每一次微调的资源成本是比较高的。
RAG：先把所有的开源信息和语料，基于通义完成训练，然后把开发者输入的 Top 问题整理出来，压缩后再给大模型进行抽链，来获得更好的答疑效果。
这个架构图里，我们入口网关选择的 MSE 云原生网关，在入口建立安全、高可用的防线，解决一些敏感词过滤的问题，然后在应用管理这层是选择了 SAE，他是免运维的，后端接的是通义2.5的大模型。所以总的来看，构建应用的代码少了、构建应用需要的人力少了，整个开发运维效率都提升了，然后大模型的调用成本在不断下降，能力在不断演进，我的应用可以持续享受用户体验提升的红利。整个过程的感受是非常震撼的。因此，我认为从云原生架构到 AI 原生架构的演进，会持续加速。
未来计划
Aliware
我们会把 RAG 的能力近期对外开放，并陆续发布已经沉淀的 Java 版的 Langchain 能力，这对国内广大 Java 开发者是一大福音，很方便的基于 Java 大模型应用。欢迎访问sca.aliyun.com。
我们会逐步发布 Higress 的 API 自动设计能力、测试代码的自动生成能力和插件的自动生成能力。欢迎访问higress.io。
点击阅读原文，下载专场资料合集。
报名参会?