AI 应用的前端性能优化：流式渲染、Token 节约与缓存策略

点击上方 前端Q关注公众号回复加群加入前端Q技术交流群上一篇我们用 RAG 给 AI 产品接上了知识库——现在 Agent 能查资料、能回答、能引用来源了。但上线后你会发现一个扎心的现实用户觉得太慢了。点击发送后等 5 秒才开始出字一个复杂问题烧掉几万 token月底账单看得心惊肉跳。更要命的是同样的问题用户问了 10 遍后端就老老实实调了 10 次 LLM——每次都花钱、每次都慢。传统前端性能优化讲的是首屏渲染、代码分割、CDN 缓存。AI 应用的性能优化有自己的一套逻辑——快不快看流式、省不省看 Token、值不值看缓存。流式渲染让用户感觉快AI 应用最影响体验的不是总耗时而是首字时间Time to First Token——用户点击发送后多久看到第一个字。非流式请求用户等 5~10 秒然后啪一下全出来。流式请求200ms 就开始出字一个一个蹦出来总时间可能一样长但用户感知完全不同。这跟前端的 SSR 流式渲染是一个道理——不等数据全齐了再渲染边到边渲染。▎基础用 AI SDK 实现流式Vercel AI SDK 把流式封装得非常简洁——后端用streamText前端用useChat开箱即用。后端 API Routetypescript// app/api/chat/route.tsimport { streamText } from ai;import { openai } from ai-sdk/openai;export async function POST(req: Request) {const { messages } await req.json();const result streamText({model: openai(gpt-4o),messages,});return result.toDataStreamResponse();}前端组件tsxuse client;import { useChat } from ai/react;export default function Chat() {const { messages, input, handleInputChange, handleSubmit, isLoading } useChat();return (div{messages.map((msg) (div key{msg.id}{msg.content}/div))}form onSubmit{handleSubmit}input value{input} onChange{handleInputChange} /button typesubmit disabled{isLoading}发送/button/form/div);}useChat内部做了这些发起 POST 请求到/api/chat拿到ReadableStream响应用TextDecoder逐 chunk 解析 SSE 事件实时更新messages状态触发 React 重渲染▎底层手动处理 SSE 流如果不用 AI SDK自己处理流式也不复杂。核心是ReadableStreamTextDecodertypescriptasync function streamChat(messages: Message[]) {const response await fetch(/api/chat, {method: POST,headers: { Content-Type: application/json },body: JSON.stringify({ messages }),});const reader response.body!.getReader();const decoder new TextDecoder();let buffer ;while (true) {const { done, value } await reader.read();if (done) break;buffer decoder.decode(value, { stream: true });const lines buffer.split(\n);buffer lines.pop() || ;for (const line of lines) {if (!line.startsWith(data: )) continue;const data line.slice(6);if (data [DONE]) return;const parsed JSON.parse(data);const token parsed.choices?.[0]?.delta?.content;if (token) {onToken(token); // 逐 token 回调更新 UI}}}}▎流式渲染的 3 个优化技巧技巧 1防抖更新减少重渲染。每个 token 都触发setState的话一秒可能更新 30~50 次。用requestAnimationFrame合并更新typescriptlet pendingText ;let rafId: number | null null;function onToken(token: string) {pendingText token;if (!rafId) {rafId requestAnimationFrame(() {setText((prev) prev pendingText);pendingText ;rafId null;});}}技巧 2Markdown 增量解析。AI 返回的内容通常是 Markdown 格式。如果每次都重新解析整个字符串性能很差。推荐用增量解析typescriptimport { marked } from marked;const renderedRef useRef();const rawRef useRef();function onToken(token: string) {rawRef.current token;// 只在段落结束时重新解析避免频繁 DOM 更新if (token.includes(\n) || token.includes(E6DB74)) {renderedRef.current marked.parse(rawRef.current);forceUpdate();}}技巧 3代码块延迟高亮。代码块在流式过程中是不完整的——等到 \\\ 闭合后再做语法高亮否则 Prism.js / highlight.js 会反复解析半成品代码typescriptfunction renderContent(content: string) {const codeBlockRegex /E6DB74(\w)?\n([\s\S]*?)/g;return content.replace(codeBlockRegex, (match, lang, code) {// 只有完整的代码块才高亮return highlightCode(code, lang);});// 未闭合的代码块保持原始文本}▎中断生成AbortController用户不想等了点「停止生成」——前端要能取消正在进行的流式请求tsxconst abortControllerRef useRefAbortController | null(null);async function handleSubmit() {abortControllerRef.current new AbortController();const response await fetch(/api/chat, {method: POST,body: JSON.stringify({ messages }),signal: abortControllerRef.current.signal,});// 处理流式响应...}function handleStop() {abortControllerRef.current?.abort();}AI SDK 的useChat内置了stop()方法更简洁tsxconst { messages, stop, isLoading } useChat();// 直接调用button onClick{stop} disabled{!isLoading}停止生成/buttonToken 节约花更少的钱办更多的事LLM 的计费方式是按 token 收费——输入 token 输出 token。一个中型 AI 应用日均几万次请求Token 成本很容易失控。▎策略 1Prompt 压缩System Prompt 是每次请求都要发的——它越长每次请求的基础成本越高。typescript// ❌ 冗余的 System Prompt约 500 tokenconst systemPrompt 你是一个非常专业的前端技术助手。你的目标是帮助用户解决各种前端开发中遇到的问题。你应该用通俗易懂的语言来解释技术概念同时提供可运行的代码示例。在回答问题时你需要考虑到用户可能是初级开发者所以要避免使用过于专业的术语。如果你不确定答案请诚实地告诉用户而不是编造一个可能错误的答案。你应该始终保持友好和耐心的态度...省略 300 字;// ✅ 精简的 System Prompt约 80 tokenconst systemPrompt 前端技术助手。通俗解释附可运行代码。不确定时如实说明。;效果一样但每次请求省了 400 token。假设日均 10 万次请求一天就省了 4000 万 token。▎策略 2对话历史滑动窗口多轮对话中完整历史越来越长。只保留最近 N 轮 早期对话的摘要typescriptfunction trimMessages(messages: Message[], maxTokens: number 4000) {let totalTokens 0;const trimmed: Message[] [];// 从最新消息往前保留for (let i messages.length - 1; i 0; i--) {const msgTokens estimateTokens(messages[i].content);if (totalTokens msgTokens maxTokens) break;trimmed.unshift(messages[i]);totalTokens msgTokens;}// 如果有被截断的历史加一条摘要if (trimmed.length messages.length) {const droppedMessages messages.slice(0, messages.length - trimmed.length);const summary await summarizeMessages(droppedMessages);trimmed.unshift({role: system,content: E6DB74之前的对话摘要${summary},});}return trimmed;}function estimateTokens(text: string): number {// 粗略估算中文 1 字 ≈ 2 token英文 1 词 ≈ 1.3 tokenreturn Math.ceil(text.length * 1.5);}▎策略 3模型路由——简单问题用便宜模型不是所有问题都需要 GPT-4o。今天星期几用 GPT-4o-mini 就够了。typescriptimport { openai } from ai-sdk/openai;import { generateText } from ai;async function routeToModel(query: string) {// 先用便宜模型判断复杂度const { text: complexity } await generateText({model: openai(gpt-4o-mini),prompt: 判断以下问题的复杂度回答 simple 或 complex\n${query},maxTokens: 10,});const model complexity.trim() simple? openai(gpt-4o-mini) // $0.15 / 1M input tokens: openai(gpt-4o); // $2.50 / 1M input tokensreturn model;}实际效果70% 的请求走 mini 模型成本直降 80%。▎策略 4控制输出长度用户问React 是什么不需要输出 2000 字的长文。typescriptconst result streamText({model: openai(gpt-4o),messages,maxTokens: 500, // 限制输出长度});结合结构化输出让 LLM 按固定格式回答避免废话typescriptimport { z } from zod;import { generateObject } from ai;const { object } await generateObject({model: openai(gpt-4o),schema: z.object({answer: z.string().describe(简洁的回答不超过 200 字),codeExample: z.string().optional().describe(代码示例如有必要),references: z.array(z.string()).optional().describe(参考资料链接),}),prompt: userQuestion,});▎成本对照表模型输入价格每百万 token输出价格每百万 token适合场景GPT-4o$2.50$10.00复杂推理、代码生成GPT-4o-mini$0.15$0.60简单问答、分类、路由Claude 3.5 Sonnet$3.00$15.00长文本、复杂分析Claude 3.5 Haiku$0.80$4.00快速响应、轻量任务经验法则先在 mini 上跑效果不够再切大模型。别一上来就用最贵的。缓存策略同样的问题不要重复花钱AI 应用的一个特点很多用户会问类似的问题。React hooks 怎么用和如何使用 React hooks本质是同一个问题——但没有缓存的话每次都要调 LLM。▎第一层精确匹配缓存最简单——完全相同的输入直接返回缓存结果typescriptimport { Redis } from ioredis;import { createHash } from crypto;const redis new Redis();function getCacheKey(messages: Message[]): string {const content JSON.stringify(messages);return ai:chat:${createHash(md5).update(content).digest(hex)};}async function cachedChat(messages: Message[]) {const key getCacheKey(messages);// 查缓存const cached await redis.get(key);if (cached) {console.log(Cache hit!);return JSON.parse(cached);}// 没命中调 LLMconst result await generateText({model: openai(gpt-4o),messages,});// 写缓存TTL 1 小时await redis.setex(key, 3600, JSON.stringify(result.text));return result.text;}局限必须完全一样才命中。React hooks 怎么用和react hooks 怎么用大小写不同就是两个 key。▎第二层语义缓存Semantic Cache用 Embedding 相似度匹配——React hooks 怎么用和如何使用 React hooks能命中同一条缓存。typescriptimport { OpenAIEmbeddings } from langchain/openai;import { MemoryVectorStore } from langchain/vectorstores/memory;const embeddings new OpenAIEmbeddings({modelName: text-embedding-3-small,});interface CacheEntry {question: string;answer: string;embedding: number[];}const cacheStore await MemoryVectorStore.fromTexts([], [], embeddings);const cacheMap new Mapstring, string();async function semanticCachedChat(question: string) {// 1. 语义检索找相似问题const results await cacheStore.similaritySearchWithScore(question, 1);if (results.length 0) {const [doc, score] results[0];// 相似度 0.92 认为是同一个问题if (score 0.92) {console.log(Semantic cache hit! (similarity: ${score.toFixed(3)}));return cacheMap.get(doc.pageContent);}}// 2. 没命中调 LLMconst { text: answer } await generateText({model: openai(gpt-4o),prompt: question,});// 3. 写入缓存await cacheStore.addDocuments([{ pageContent: question, metadata: {} },]);cacheMap.set(question, answer);return answer;}语义缓存的命中率远高于精确缓存——实际测试中语义缓存能把命中率从 15% 提升到 60%。▎第三层Embedding 缓存RAG 场景中每次用户提问都要把问题转成 Embedding 向量。这个 Embedding 调用虽然便宜但积少成多也是成本。typescriptconst embeddingCache new Mapstring, number[]();async function cachedEmbed(text: string): Promisenumber[] {const key text.trim().toLowerCase();if (embeddingCache.has(key)) {return embeddingCache.get(key)!;}const result await embeddings.embedQuery(text);embeddingCache.set(key, result);return result;}▎缓存失效策略策略做法适合场景TTL固定时间过期如 1 小时信息时效性不强LRU淘汰最久未使用的缓存空间有限知识库更新时清除文档变更后清缓存RAG 场景版本标记模型/Prompt 变了就失效迭代频繁UX 优化让 AI 应用像人一样技术优化之外UX 设计对 AI 应用的体验影响巨大。▎骨架屏 打字机效果用户点击发送后立即展示占位 UI避免空白等待tsxfunction AIMessage({ content, isStreaming }: { content: string; isStreaming: boolean }) {if (!content isStreaming) {return (div classNameflex items-center gap-2 text-gray-400span classNameanimate-pulse●/spanspan classNameanimate-pulse delay-100●/spanspan classNameanimate-pulse delay-200●/spanspan classNameml-2思考中.../span/div);}return (div classNameproseReactMarkdown{content}/ReactMarkdown{isStreaming span classNameanimate-blink▎/span}/div);}▎重试与反馈AI 的回答不一定对——给用户重新生成和反馈的能力tsxfunction MessageActions({ messageId, onRegenerate }: Props) {const [feedback, setFeedback] useStateup | down | null(null);return (div classNameflex gap-2 mt-2 text-gray-400buttononClick{onRegenerate}classNamehover:text-blue-500title重新生成/buttonbuttononClick{() {setFeedback(up);trackFeedback(messageId, positive);}}className{feedback up ? text-green-500 : hover:text-green-500}/buttonbuttononClick{() {setFeedback(down);trackFeedback(messageId, negative);}}className{feedback down ? text-red-500 : hover:text-red-500}/button/div);}▎Token 用量可视化让用户知道这次对话花了多少钱有助于控制使用tsxfunction TokenUsage({ usage }: { usage: { input: number; output: number } }) {const cost (usage.input * 2.5 usage.output * 10) / 1_000_000;return (div classNametext-xs text-gray-400 flex gap-4span输入: {usage.input.toLocaleString()} tokens/spanspan输出: {usage.output.toLocaleString()} tokens/spanspan≈ ${cost.toFixed(4)}/span/div);}AI SDK 返回的结果中包含usage字段typescriptconst result await generateText({model: openai(gpt-4o),messages,});console.log(result.usage);// { promptTokens: 150, completionTokens: 280, totalTokens: 430 }性能监控建立 AI 应用的指标体系传统前端用 LCP、FID、CLS 衡量性能。AI 应用需要一套新指标。▎核心指标指标含义达标线怎么测TTFTTime to First Token首字时间 1s从请求发出到第一个 token 到达TPSTokens Per Second生成速度 30输出 token 数 ÷ 生成时间总延迟从发送到完成的总时间 10s端到端计时缓存命中率命中缓存的请求比例 50%cache hit / total requests单次成本每次请求的 token 花费 $0.01(input output) × unit price错误率请求失败或超时的比例 1%error count / total▎前端埋点方案typescriptfunction trackAIMetrics(metrics: {ttft: number;totalLatency: number;inputTokens: number;outputTokens: number;model: string;cached: boolean;}) {// 上报到你的监控系统DataDog / Grafana / 自建analytics.track(ai_request, {...metrics,tps: metrics.outputTokens / (metrics.totalLatency / 1000),cost:(metrics.inputTokens * getInputPrice(metrics.model) metrics.outputTokens * getOutputPrice(metrics.model)) /1_000_000,});}// 在 useChat 的回调中埋点const { messages } useChat({onResponse(response) {startTime.current Date.now();},onFinish(message) {trackAIMetrics({ttft: firstTokenTime.current - startTime.current,totalLatency: Date.now() - startTime.current,inputTokens: message.usage?.promptTokens ?? 0,outputTokens: message.usage?.completionTokens ?? 0,model: gpt-4o,cached: response.headers.get(x-cache) HIT,});},});实战清单AI 应用上线前的性能检查把上面的内容整理成一个可执行的清单上线前逐条检查检查项具体做法优先级✅ 流式渲染用streamTextuseChat确保首字 1sP0✅ 中断能力实现「停止生成」按钮用 AbortControllerP0✅ 模型路由简单问题走 mini复杂问题走大模型P1✅ Prompt 精简System Prompt 200 tokenP1✅ 对话历史裁剪滑动窗口 摘要控制在 4k token 以内P1✅ 精确缓存Redis 缓存完全相同的请求P1✅ 语义缓存Embedding 相似度匹配相似问题P2✅ 输出长度控制maxTokens 结构化输出P2✅ 错误重试加重试逻辑 降级策略P1✅ 性能监控TTFT、TPS、成本、缓存命中率全量埋点P1✅ UX 反馈骨架屏、打字机效果、重新生成、反馈按钮P1避坑指南▎坑 1流式渲染导致 Markdown 闪烁每个 token 都重新解析 Markdown导致页面闪烁——尤其是代码块和表格。typescript// ❌ 每个 token 都重新渲染useEffect(() {setHtml(marked.parse(content));}, [content]);// ✅ 用 useDeferredValue 或节流const deferredContent useDeferredValue(content);const html useMemo(() marked.parse(deferredContent), [deferredContent]);▎坑 2缓存了错误的回答LLM 有时会给出不正确的答案——如果缓存了所有后续用户都会看到错误答案。解法▸缓存前做质量检查用 LLM-as-Judge 打分低于阈值不缓存▸TTL 不要太长1~4 小时▸提供「反馈」按钮用户标记错误后自动清除缓存▎坑 3模型路由判断本身就花 Token用 GPT-4o-mini 判断复杂度虽然便宜但也是一次额外调用。解法用规则优先模型兜底typescriptfunction quickRouting(query: string): simple | complex | unknown {// 规则判断短问题大概率简单if (query.length 20) return simple;// 包含代码关键词大概率复杂if (/写.*代码|实现.*功能|重构|优化/.test(query)) return complex;return unknown;}async function getModel(query: string) {const quick quickRouting(query);if (quick ! unknown) {return quick simple ? openai(gpt-4o-mini) : openai(gpt-4o);}// 规则搞不定再用模型判断return await routeWithLLM(query);}▎坑 4流式请求没做错误处理SSE 连接断了、服务端 500 了——前端一片空白用户不知道发生了什么。typescriptconst { messages, error, reload } useChat({onError(err) {toast.error(AI 服务暂时不可用请稍后重试);},});// 显示错误状态 重试按钮{error (div classNametext-red-500 flex items-center gap-2span出错了{error.message}/spanbutton onClick{reload} classNameunderline重试/button/div)}▎坑 5忽略了并发控制用户疯狂点击发送——前端同时发了 10 个请求后端 token 烧到冒烟。typescriptconst isLoadingRef useRef(false);async function handleSubmit() {if (isLoadingRef.current) return; // 防重复提交isLoadingRef.current true;try {await sendMessage();} finally {isLoadingRef.current false;}}AI SDK 的useChat已经内置了这个——isLoading为 true 时不会重复发送。总结AI 应用的前端性能优化核心就是三板斧流式渲染——让用户感觉快▸streamTextuseChat实现开箱即用的流式▸requestAnimationFrame合并更新减少重渲染▸Markdown 增量解析 代码块延迟高亮▸AbortController实现中断生成Token 节约——让老板省心▸Prompt 压缩System Prompt 精简到 200 token▸滑动窗口只保留最近 N 轮 历史摘要▸模型路由简单问题走 mini 模型成本降 80%▸输出控制maxTokens 结构化输出缓存策略——让重复问题零成本▸精确缓存Redis 存完全相同的请求▸语义缓存Embedding 相似度匹配命中率 60%▸Embedding 缓存避免重复向量化▸合理的 TTL 质量检查兜底这三板斧下来一个 AI 应用的体验和成本都能优化一个量级。到这里第三模块「AI Agent 工程化」的 10 篇文章就全部写完了——从第一个 Agent、到 ReAct 模式、到 Memory、到 LangGraph、到多 Agent 协作、到 RAG、再到今天的性能优化走完了 Agent 工程化的全链路。下一个模块我们进入原理与趋势篇——前端视角拆解 Agent 运行原理、Tool Calling 底层机制、Cursor 的代码补全是怎么做的以及 AI × 前端的下一站。推荐资源▸Vercel AI SDK 文档https://sdk.vercel.ai/docs▸OpenAI 计费说明https://openai.com/pricing▸GPTCache开源语义缓存https://github.com/zilliztech/GPTCache▸LangChain.js Cachinghttps://js.langchain.com/docs/integrations/llm_caching往期推荐Multi-Agent Teams让多个专家 Agent 像团队一样协作AI Agent 是怎么想一步做一步的拆解 ReAct 模式从零开始用 LangChain.js 构建你的第一个 Tool-Calling Agent最后点个在看支持我吧