LibreChat 推理流性能基准用 react-scan 验证单个不拆分长思维块渲染仍然有界【免费下载链接】LibreChatEnhanced ChatGPT Clone: Features Agents, MCP, Skills, DeepSeek, Anthropic, AWS, OpenAI, Responses API, Azure, Groq, o1, GPT-5, Mistral, OpenRouter, Vertex AI, Gemini, Artifacts, AI model switching, message search, Code Interpreter, langchain, DALL-E-3, OpenAPI Actions, Functions, Secure Multi-User Auth, Presets, open-source for self-hosting. Active项目地址: https://gitcode.com/GitHub_Trending/li/LibreChat本文以 reasoning-stream 性能基准 为主体完整讲解 LibreChat 如何验证移除遗留的内容块拆分SplitStreamHandler/blockThresholdPR #10533 中删除后通过真实 mock-model agents 管道流式渲染一个不拆分的超长think块加长 Markdown 文本时渲染开销依然有界这一命题。读完后你将掌握该基准的运行方式、确定性 payload 的构造方法、react-scan 注入式度量的实现细节以及各项渲染阈值帧上界、长任务预算、打字延迟背后的设计依据与前端源码级佐证。1. 背景为什么需要这个基准LibreChat 曾有一版遗留的流式内容拆分逻辑SplitStreamHandler配套 4500 字符的blockThreshold当一条流式内容超过阈值时将其拆成多个内容 part 以降低单块渲染压力。PR #10533 移除了这套拆分逻辑之后需要一个持续性的性能证据来回答不拆分长推理块单个 Thoughts 折叠框渲染性能是否真的撑得住这个基准的答案来自实测而非推断。它通过注入 react-scan度量库非仓库依赖从磁盘路径注入到页面对流式渲染过程做逐组件的 render 计数与计时。README 明确列出了它度量的六个方面一个约 18k 字符的think块加约 6k 字符的 Markdown 回复逐 token 流式渲染期间各组件的 render 次数与 render 耗时整个推理段落在管道中最终落入唯一一个think part单个 Thoughts 切换按钮管道任何位置都不得再次拆分rAF 合并coalescing效果思维盒的重渲染次数远低于流式 chunk 数Markdown 块级记忆化MarkdownBlock的 render 总量约等于 O(tokens blocks)而非 O(tokens × blocks)主线程健康度长任务long task总耗时相对流式墙钟时间有界长转录完成后的打字延迟转录组件不得随每次击键重渲染。仓库中SplitStreamHandler与blockThreshold已无任何残留实现仅在 payload.ts 与 README 中作为历史参照被引用——基准 payload 的推理段刻意远超旧的 4500 字符阈值正是为了复现旧拆分逻辑当年要保护的那个极端场景。2. 基准文件结构与运行方式基准由三个文件构成外加两个共享设施文件职责e2e/benchmarks-reasoning/README.md度量目标说明与运行指令e2e/benchmarks-reasoning/reasoning-stream.perf.spec.ts唯一的 Playwright 测试包含全部断言e2e/benchmarks-reasoning/payload.ts确定性长文 payload 构造器e2e/perf/scan.ts各 render-perf 基准共享的 react-scan 注入与快照设施e2e/playwright.config.reasoning-perf.ts专用 Playwright 配置2.1 运行命令README 原文继承react-scan 不是仓库依赖需要自行提供 bundle 路径。README 强调已记录的基线与阈值是用react-scan 0.5.7测得——度量开销与onRender语义都随版本变化因此必须保持版本锁定npm i --no-save react-scan0.5.7 npx playwright test --confige2e/playwright.config.reasoning-perf.ts或者通过环境变量REACT_SCAN_PATH指向一个现成的react-scan0.5.7/dist/auto.global.js文件。另外与其他 mock e2e 配置一样要求客户端已构建存在client/dist。这个从磁盘注入、不进依赖的策略在 scan.ts 中落地resolveReactScanPath()优先取REACT_SCAN_PATH且校验文件存在否则回退到require.resolve(react-scan/dist/auto.global.js)即npm i --no-save装进node_modules的那份。2.2 Playwright 配置的关键设定playwright.config.reasoning-perf.ts 基于 mock 配置派生有几个决定成败的细节注入回复 payloadprocess.env.MOCK_LLM_REPLY buildReasoningPayload()把整个思维块 Markdown 长文作为 mock 模型的一次性回复锁定 chunk 延迟为 1msMOCK_LLM_CHUNK_DELAY_MS 1。注释明确说明这是pinned, not defaulted——render 次数阈值是针对该投递速率标定的更慢的流会放松按帧推导的上界因此不允许默认值介入走 vite dev server端口 3090/api代理到 3080 的 mock 后端dev 构建保留组件名react-scan 依赖组件名做逐组件统计——生产环境压缩器oxc会剥掉displayName赋值统计将全部落入anonymoustestDir收窄到benchmarks-reasoningretries: 0性能测试重试无意义timeout: 10 分钟。2.3 确定性 payload 的构造payload.ts 用固定句式循环拼出两段内容保证每次运行的 chunk 数、块数完全一致阈值比较才有意义思维段buildThinkSection()以THINK_TARGET_CHARS 18000为目标长度循环追加Step i: 固定分析句每 6 步插入一个空行段落正文段buildTextSection()以TEXT_TARGET_CHARS 6000为目标循环生成## Section N标题、双倍句段落、两条列表项每 3 个 section 追加一个 TypeScript 代码块每 4 个 section 追加一个含120000/135500/151200数值的表格结尾追加END_MARKER END-OF-BENCH-STREAM最终形态buildReasoningPayload()think{思维段}/think\n\n{正文段}——payload 永远以推理开头这一特性后面被用作度量锚点chunk 计数countModelChunks()用正则/(?\s)|(?\s)/按空白边界切分注释说明这是镜像 mock FakeChatModel 默认空白切分策略即测试侧统计的 chunk 数与 mock 模型实际投递的 delta 数一致。3. 测试流程逐段解析reasoning-stream.perf.spec.ts 只有一个测试超时 6 分钟流程可分为流式阶段与打字阶段两个测量区间。3.1 度量锚点与初始化installReactScan(page, ThinkingContent)注入 react-scan 与统计脚本并把锚点组件设为ThinkingContent。由于 payload 永远以推理开头ThinkingContent的首次 render 就是首条 assistant 内容上屏的时刻——度量区间从这里开始把 composer 渲染与空闲请求设置排除在分母之外少量发送前的 composer 渲染仍留在总计里只会让上界更严格通过addInitScript预先种下localStorage.setItem(showThinking, true)让思维盒在流式期间处于展开状态。这是用户开启 Show Thinking 后更重的布局路径——度量区间覆盖的是思维盒内段落的实时布局而非仅折叠头部首次进入页面走 vite dev server模块图需要转换因此page.goto给了 180 秒超时随后选择 mock 端点resetPerf在发送消息之前执行1ms 的 chunk 延迟下最早的 delta 可能在响应头解析之后、后续 evaluate 之前就已经渲染若发送后再 reset 会把它们抹掉。时钟锚定到首次ThinkingContentrender正是为了让这段早期渲染计入流式区间。3.2 等待流式完成先等END_MARKER文本可见4 分钟超时再等 Stop generating 按钮消失30 秒超时。注释解释marker 只证明最后一个文本 delta 上屏而生成收尾usage chunk、终态事件、保存时的重渲染本身是度量流的一部分必须先等它结束。3.3 完整性断言不只是能渲染单 think part 断言统计名为Thoughts/Thinking的按钮必须恰好为 1 个——多于 1 个意味着管道某处重新拆分了推理。并且一个非空 toggle还不够思维组rolegroup内第一个p的文本必须严格等于thinkSection.trim()。因为盒子用whitespace-pre-wrap渲染段落内空行是用户可见内容而 UI 对推理文本只做了行内标签剥离与首尾裁剪所以裁剪源文本首尾后可做精确比较。这一点与前端实现吻合Reasoning.tsx 中的reasoningText只做^think\s*与\s*$/的正则剥离加trim()与测试注释描述的仅有的两种变换一一对应。Markdown 正文完整性断言END_MARKER只能证明后缀渲染了结构正确也不够测试逐条验证了正文本身——每个 section 的标题Section N共sectionCount个、双倍句段落每 section 恰好 1 次、两条列表项均可见listitem总数恰为sectionCount × 2表格数 floor(sectionCount / 4)且120000、135500、151200三个单元格值各出现tableCount次代码块数 floor(sectionCount / 3)其中export function estimate与return Math.round(total * rate);两行代码各出现codeBlockCount次。这些断言保证了被度量的渲染工作量覆盖了完整 payload而不是某个被截断的短回复。3.4 流式阶段的阈值断言snapshotPerf(page)取出PerfSnapshot各组件 render 计数/耗时、long task 时长列表、锚点起算的elapsedMs随后断言断言取值设计依据源码注释ThinkingContentrender 次数 10下界防止度量脚本或组件名静默失效导致计数归零、上界形同虚设ThinkingContentrender 次数 ceil(streamMs/1000 × 90)帧上界rAF 合并下缓存 flush 每动画帧至多一次render 数随帧数而非 chunk 数增长60fps 加 50% 余量取 90。无合并时 render 数跟随 chunk约 5k 个 / 约 13 秒实测基线 122 次已远超此界ThinkingContentrender 次数 thinkChunks / 4速率无关伴随界慢流下帧上界会膨胀但每 chunk 渲染一次的行为在此界下仍会失败MarkdownBlockrender 次数 10 且 帧上界、textChunks / 4块级记忆化每个 token 不得重渲染所有块实测基线 153 次远低于 blocks × tokens约 10 万量级单条 long task 250ms主线程健康流式期间不允许出现单次超过 250ms 的卡顿long task 总量 streamMs × 10%主线程健康实测基线为单条 51–96ms 的任务累计 render 时间 streamMs × 25%主线程健康持续的 50ms 以下工作不会浮现为 long task需另行封顶实测基线约 4–7%3.5 打字阶段断言流式结束后resetPerf点击消息输入框以 25ms 间隔逐键输入 40 个字符typing latency probe after long transcript再取快照转录侧组件——MarkdownBlock、MarkdownBlocks、Markdown、ThinkingContent、TextPart、Part、MessageContent——在打字期间的 render 次数每个 ≤ 2消息内容组件保持安静只有 composer 在更新但组件安静不证明击键手感快输入处理器或布局的滞后不会体现在具名组件上因此对流式后的打字区间自身也设限——最坏 long task 150ms实测基线无 long task、long task 总量 300ms绝对预算注释说明这是为了防止反复的亚阈值卡顿同时躲过最坏值检查并抬高elapsedMs故不用比率、累计 render 时间 typing.elapsedMs × 25%实测基线约 3%。最后两份快照streaming-renders.json/typing-renders.json通过attachSnapshot作为 JSON 附件挂到测试报告附带streamMs、thinkChunks、textChunks元数据便于跨机器对比。4. 共享度量设施 scan.ts 的实现细节e2e/perf/scan.ts 是所有 render-perf 基准包括本基准共用的注入层理解它能解释上面每个数字的来源页面侧全局window.__PERF__由buildTallySetup(anchorComponent)生成的内联脚本建立包含PerformanceObserver监听longtaskbuffered: true持续收集长任务时长drain()在快照时把缓冲记录取出reset()则先 drain 再清空react-scan 配置enabled: true、log/showToolbar: false、trackUnnecessaryRenders: false、dangerouslyForceRunInProduction: true在已构建页面上强制启用核心是onRender(fiber, renders)回调——记录首次 render 时间、首次锚点组件 render 时间并按组件名累加count与time组件名解析nameOf(fiber)沿 fiber 向上最多 4 层优先取displayName这正是配置注释强调 dev 构建保留displayName的原因react-scan 异步就位问题configure()失败时每 50ms 重试直到window.reactScan可用——因为注入脚本先于应用代码执行。Node 侧 APIinstallReactScan(page, anchorComponent)用addInitScript依次注入 react-scan bundle 与统计脚本保证在任何应用代码前生效snapshotPerf(page)evaluate页面内drain()后返回{ renders, longTasks, elapsedMs }elapsedMs的取法是firstAnchorRenderAt ?? firstRenderAt ?? startedAt——任何 render 之前的空闲设置时间永远不会撑大区间这与 3.1 中锚点即首次 ThinkingContent render的设计闭环totals(snapshot)汇总 render 总数与总耗时topComponents(snapshot, limit)按 count 排序输出 Top N测试用它打印 Top 15 与打字区间 Top 10longTaskStats(snapshot)给出{ total, worst }attachSnapshot(testInfo, name, snapshot, extra)把元数据与快照合并为 JSON 附件。PerfSnapshot的类型定义scan.ts本身就把锚点语义写进了文档注释是理解各阈值分母口径的最直接依据。5. 前端源码佐证为什么不拆分是安全的基准之所以敢用单块 18k 字符思维 6k 字符 Markdown压测前提是前端渲染路径本身已有足够强的局部更新机制。结合源码可以看到两层保障5.1 思维盒memo 懒挂载折叠体Thinking.tsx 中的ThinkingContent是memo组件并显式声明displayName ThinkingContent第 402 行——react-scan 的逐组件统计正依赖这个名称其内容只是whitespace-pre-wrap的p流式期间 children 字符串变化才会触发重渲染现代路径的 Reasoning.tsx 用useLazyCollapseBody(isExpanded)控制折叠体是否挂载reasoningText由useMemo从reasoning派生——同一 think part 的推理文本随 token 增长时只有文本字符串本身变化头部按钮行ThinkingButton等兄弟子树不受影响。测试种入showThinkingtrue正是强制走展开布局这条更重的路径使度量覆盖盒内段落布局单 Thoughts toggle 断言与ContentTypes.THINK的语义对应每个 THINK part 有独立 toggle见 Reasoning.tsx 头部注释因此 toggle 数 think part 数等于 1 即证明全管道无二次拆分。5.2 Markdown块级 memo 让 render 复杂度降一级MarkdownBlocks.tsx 是实现O(tokens blocks)的关键MarkdownBlocks用useMemo调splitMarkdownIntoBlocks(content)把消息切成顶层块并用前缀和为每块记录codeBaseIndex/artifactBaseIndex/mermaidBaseIndex保持文档序的代码/Artifact 索引连续每个块由独立MarkdownBlock渲染其memo比较函数第 78–83 行只比较content、三个 base 索引与animate——已完成的块在后续 token 中源切片不变既跳过重解析也跳过重渲染只有末尾仍在增长的块重新解析。这就是基准中MarkdownBlockrender 总数停留在 153 次量级而非 10 万级的机制来源每块自带ArtifactProvider/CodeBlockProvider与独立的 fade 插件闭包仅追踪本块字符偏移进一步把流式动画的失效范围限制在单块内。5.3 rAF 合并基准把render 数随帧数而非 chunk 数作为核心命题1ms 延迟下约 5k 个 chunk而阈值上界直接按 90 帧/秒 × 墙钟时间推导。从源码结构看客户端消息内容路径存在requestAnimationFrame缓存刷新的使用如 ActivityPhaseGroup.tsx 中的 rAF 链与测试注释cache flushes happen at most once per animation frame的描述一致基准正是用帧上界把这个行为固化成可回归的断言。6. 如何正确解读与扩展这个基准基线是版本敏感的react-scan 的度量开销与onRender语义随版本移动升级 react-scan 必须重测并更新 README 记录的基线MOCK_LLM_CHUNK_DELAY_MS1同理被刻意锁定改投递速率即需重新标定帧上界必须走 dev server生产构建剥掉displayName后逐组件统计失去锚点只有anonymous计数——这不是配置失误而是硬性前提playwright.config.reasoning-perf.ts 头注释下界断言是防失效设计 10类下界不衡量性能而是防止统计脚本/组件名静默丢失让上界检查空转——这是该基准区别于普通期望小于某数性能测试的严谨之处扩展新场景时正确姿势是新增 payload 构造器 复用 scan.ts 的注入设施并像本基准一样同时给出完整性断言内容真的完整到达 有界性断言render/长任务/打字延迟两层验证运行前确认client/dist已构建、mock 后端3080可被 dev server 的/api代理代理参数由 client/vite.config.ts 的HOSTBACKEND_PORT控制配置中已按 E2E base URL 显式注入。7. 小结这套 reasoning-stream 基准的价值在于把移除拆分逻辑后的渲染有界性从经验判断变成了可回归、可复现、带完整性保障的自动化证据确定性 payload 固定了输入分布react-scan 注入层给出了逐组件的 render 计数与 long task 分布帧上界 速率无关伴随界 绝对预算三类阈值互相补位而 Thinking.tsx、Reasoning.tsx 与 MarkdownBlocks.tsx 中的 memo、懒挂载与块级记忆化则是这些阈值能够长期保持绿色的底层原因。当你修改消息渲染路径、流式合并逻辑或 Markdown 解析管线时直接运行npx playwright test --confige2e/playwright.config.reasoning-perf.ts配合锁定的 react-scan 0.5.7即可验证渲染性能是否回归。【免费下载链接】LibreChatEnhanced ChatGPT Clone: Features Agents, MCP, Skills, DeepSeek, Anthropic, AWS, OpenAI, Responses API, Azure, Groq, o1, GPT-5, Mistral, OpenRouter, Vertex AI, Gemini, Artifacts, AI model switching, message search, Code Interpreter, langchain, DALL-E-3, OpenAPI Actions, Functions, Secure Multi-User Auth, Presets, open-source for self-hosting. Active项目地址: https://gitcode.com/GitHub_Trending/li/LibreChat创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 LibreChat 推理流性能基准：用 react-scan 验证“单个不拆分“长思维块渲染仍然有界
LibreChat 推理流性能基准用 react-scan 验证单个不拆分长思维块渲染仍然有界【免费下载链接】LibreChatEnhanced ChatGPT Clone: Features Agents, MCP, Skills, DeepSeek, Anthropic, AWS, OpenAI, Responses API, Azure, Groq, o1, GPT-5, Mistral, OpenRouter, Vertex AI, Gemini, Artifacts, AI model switching, message search, Code Interpreter, langchain, DALL-E-3, OpenAPI Actions, Functions, Secure Multi-User Auth, Presets, open-source for self-hosting. Active项目地址: https://gitcode.com/GitHub_Trending/li/LibreChat本文以 reasoning-stream 性能基准 为主体完整讲解 LibreChat 如何验证移除遗留的内容块拆分SplitStreamHandler/blockThresholdPR #10533 中删除后通过真实 mock-model agents 管道流式渲染一个不拆分的超长think块加长 Markdown 文本时渲染开销依然有界这一命题。读完后你将掌握该基准的运行方式、确定性 payload 的构造方法、react-scan 注入式度量的实现细节以及各项渲染阈值帧上界、长任务预算、打字延迟背后的设计依据与前端源码级佐证。1. 背景为什么需要这个基准LibreChat 曾有一版遗留的流式内容拆分逻辑SplitStreamHandler配套 4500 字符的blockThreshold当一条流式内容超过阈值时将其拆成多个内容 part 以降低单块渲染压力。PR #10533 移除了这套拆分逻辑之后需要一个持续性的性能证据来回答不拆分长推理块单个 Thoughts 折叠框渲染性能是否真的撑得住这个基准的答案来自实测而非推断。它通过注入 react-scan度量库非仓库依赖从磁盘路径注入到页面对流式渲染过程做逐组件的 render 计数与计时。README 明确列出了它度量的六个方面一个约 18k 字符的think块加约 6k 字符的 Markdown 回复逐 token 流式渲染期间各组件的 render 次数与 render 耗时整个推理段落在管道中最终落入唯一一个think part单个 Thoughts 切换按钮管道任何位置都不得再次拆分rAF 合并coalescing效果思维盒的重渲染次数远低于流式 chunk 数Markdown 块级记忆化MarkdownBlock的 render 总量约等于 O(tokens blocks)而非 O(tokens × blocks)主线程健康度长任务long task总耗时相对流式墙钟时间有界长转录完成后的打字延迟转录组件不得随每次击键重渲染。仓库中SplitStreamHandler与blockThreshold已无任何残留实现仅在 payload.ts 与 README 中作为历史参照被引用——基准 payload 的推理段刻意远超旧的 4500 字符阈值正是为了复现旧拆分逻辑当年要保护的那个极端场景。2. 基准文件结构与运行方式基准由三个文件构成外加两个共享设施文件职责e2e/benchmarks-reasoning/README.md度量目标说明与运行指令e2e/benchmarks-reasoning/reasoning-stream.perf.spec.ts唯一的 Playwright 测试包含全部断言e2e/benchmarks-reasoning/payload.ts确定性长文 payload 构造器e2e/perf/scan.ts各 render-perf 基准共享的 react-scan 注入与快照设施e2e/playwright.config.reasoning-perf.ts专用 Playwright 配置2.1 运行命令README 原文继承react-scan 不是仓库依赖需要自行提供 bundle 路径。README 强调已记录的基线与阈值是用react-scan 0.5.7测得——度量开销与onRender语义都随版本变化因此必须保持版本锁定npm i --no-save react-scan0.5.7 npx playwright test --confige2e/playwright.config.reasoning-perf.ts或者通过环境变量REACT_SCAN_PATH指向一个现成的react-scan0.5.7/dist/auto.global.js文件。另外与其他 mock e2e 配置一样要求客户端已构建存在client/dist。这个从磁盘注入、不进依赖的策略在 scan.ts 中落地resolveReactScanPath()优先取REACT_SCAN_PATH且校验文件存在否则回退到require.resolve(react-scan/dist/auto.global.js)即npm i --no-save装进node_modules的那份。2.2 Playwright 配置的关键设定playwright.config.reasoning-perf.ts 基于 mock 配置派生有几个决定成败的细节注入回复 payloadprocess.env.MOCK_LLM_REPLY buildReasoningPayload()把整个思维块 Markdown 长文作为 mock 模型的一次性回复锁定 chunk 延迟为 1msMOCK_LLM_CHUNK_DELAY_MS 1。注释明确说明这是pinned, not defaulted——render 次数阈值是针对该投递速率标定的更慢的流会放松按帧推导的上界因此不允许默认值介入走 vite dev server端口 3090/api代理到 3080 的 mock 后端dev 构建保留组件名react-scan 依赖组件名做逐组件统计——生产环境压缩器oxc会剥掉displayName赋值统计将全部落入anonymoustestDir收窄到benchmarks-reasoningretries: 0性能测试重试无意义timeout: 10 分钟。2.3 确定性 payload 的构造payload.ts 用固定句式循环拼出两段内容保证每次运行的 chunk 数、块数完全一致阈值比较才有意义思维段buildThinkSection()以THINK_TARGET_CHARS 18000为目标长度循环追加Step i: 固定分析句每 6 步插入一个空行段落正文段buildTextSection()以TEXT_TARGET_CHARS 6000为目标循环生成## Section N标题、双倍句段落、两条列表项每 3 个 section 追加一个 TypeScript 代码块每 4 个 section 追加一个含120000/135500/151200数值的表格结尾追加END_MARKER END-OF-BENCH-STREAM最终形态buildReasoningPayload()think{思维段}/think\n\n{正文段}——payload 永远以推理开头这一特性后面被用作度量锚点chunk 计数countModelChunks()用正则/(?\s)|(?\s)/按空白边界切分注释说明这是镜像 mock FakeChatModel 默认空白切分策略即测试侧统计的 chunk 数与 mock 模型实际投递的 delta 数一致。3. 测试流程逐段解析reasoning-stream.perf.spec.ts 只有一个测试超时 6 分钟流程可分为流式阶段与打字阶段两个测量区间。3.1 度量锚点与初始化installReactScan(page, ThinkingContent)注入 react-scan 与统计脚本并把锚点组件设为ThinkingContent。由于 payload 永远以推理开头ThinkingContent的首次 render 就是首条 assistant 内容上屏的时刻——度量区间从这里开始把 composer 渲染与空闲请求设置排除在分母之外少量发送前的 composer 渲染仍留在总计里只会让上界更严格通过addInitScript预先种下localStorage.setItem(showThinking, true)让思维盒在流式期间处于展开状态。这是用户开启 Show Thinking 后更重的布局路径——度量区间覆盖的是思维盒内段落的实时布局而非仅折叠头部首次进入页面走 vite dev server模块图需要转换因此page.goto给了 180 秒超时随后选择 mock 端点resetPerf在发送消息之前执行1ms 的 chunk 延迟下最早的 delta 可能在响应头解析之后、后续 evaluate 之前就已经渲染若发送后再 reset 会把它们抹掉。时钟锚定到首次ThinkingContentrender正是为了让这段早期渲染计入流式区间。3.2 等待流式完成先等END_MARKER文本可见4 分钟超时再等 Stop generating 按钮消失30 秒超时。注释解释marker 只证明最后一个文本 delta 上屏而生成收尾usage chunk、终态事件、保存时的重渲染本身是度量流的一部分必须先等它结束。3.3 完整性断言不只是能渲染单 think part 断言统计名为Thoughts/Thinking的按钮必须恰好为 1 个——多于 1 个意味着管道某处重新拆分了推理。并且一个非空 toggle还不够思维组rolegroup内第一个p的文本必须严格等于thinkSection.trim()。因为盒子用whitespace-pre-wrap渲染段落内空行是用户可见内容而 UI 对推理文本只做了行内标签剥离与首尾裁剪所以裁剪源文本首尾后可做精确比较。这一点与前端实现吻合Reasoning.tsx 中的reasoningText只做^think\s*与\s*$/的正则剥离加trim()与测试注释描述的仅有的两种变换一一对应。Markdown 正文完整性断言END_MARKER只能证明后缀渲染了结构正确也不够测试逐条验证了正文本身——每个 section 的标题Section N共sectionCount个、双倍句段落每 section 恰好 1 次、两条列表项均可见listitem总数恰为sectionCount × 2表格数 floor(sectionCount / 4)且120000、135500、151200三个单元格值各出现tableCount次代码块数 floor(sectionCount / 3)其中export function estimate与return Math.round(total * rate);两行代码各出现codeBlockCount次。这些断言保证了被度量的渲染工作量覆盖了完整 payload而不是某个被截断的短回复。3.4 流式阶段的阈值断言snapshotPerf(page)取出PerfSnapshot各组件 render 计数/耗时、long task 时长列表、锚点起算的elapsedMs随后断言断言取值设计依据源码注释ThinkingContentrender 次数 10下界防止度量脚本或组件名静默失效导致计数归零、上界形同虚设ThinkingContentrender 次数 ceil(streamMs/1000 × 90)帧上界rAF 合并下缓存 flush 每动画帧至多一次render 数随帧数而非 chunk 数增长60fps 加 50% 余量取 90。无合并时 render 数跟随 chunk约 5k 个 / 约 13 秒实测基线 122 次已远超此界ThinkingContentrender 次数 thinkChunks / 4速率无关伴随界慢流下帧上界会膨胀但每 chunk 渲染一次的行为在此界下仍会失败MarkdownBlockrender 次数 10 且 帧上界、textChunks / 4块级记忆化每个 token 不得重渲染所有块实测基线 153 次远低于 blocks × tokens约 10 万量级单条 long task 250ms主线程健康流式期间不允许出现单次超过 250ms 的卡顿long task 总量 streamMs × 10%主线程健康实测基线为单条 51–96ms 的任务累计 render 时间 streamMs × 25%主线程健康持续的 50ms 以下工作不会浮现为 long task需另行封顶实测基线约 4–7%3.5 打字阶段断言流式结束后resetPerf点击消息输入框以 25ms 间隔逐键输入 40 个字符typing latency probe after long transcript再取快照转录侧组件——MarkdownBlock、MarkdownBlocks、Markdown、ThinkingContent、TextPart、Part、MessageContent——在打字期间的 render 次数每个 ≤ 2消息内容组件保持安静只有 composer 在更新但组件安静不证明击键手感快输入处理器或布局的滞后不会体现在具名组件上因此对流式后的打字区间自身也设限——最坏 long task 150ms实测基线无 long task、long task 总量 300ms绝对预算注释说明这是为了防止反复的亚阈值卡顿同时躲过最坏值检查并抬高elapsedMs故不用比率、累计 render 时间 typing.elapsedMs × 25%实测基线约 3%。最后两份快照streaming-renders.json/typing-renders.json通过attachSnapshot作为 JSON 附件挂到测试报告附带streamMs、thinkChunks、textChunks元数据便于跨机器对比。4. 共享度量设施 scan.ts 的实现细节e2e/perf/scan.ts 是所有 render-perf 基准包括本基准共用的注入层理解它能解释上面每个数字的来源页面侧全局window.__PERF__由buildTallySetup(anchorComponent)生成的内联脚本建立包含PerformanceObserver监听longtaskbuffered: true持续收集长任务时长drain()在快照时把缓冲记录取出reset()则先 drain 再清空react-scan 配置enabled: true、log/showToolbar: false、trackUnnecessaryRenders: false、dangerouslyForceRunInProduction: true在已构建页面上强制启用核心是onRender(fiber, renders)回调——记录首次 render 时间、首次锚点组件 render 时间并按组件名累加count与time组件名解析nameOf(fiber)沿 fiber 向上最多 4 层优先取displayName这正是配置注释强调 dev 构建保留displayName的原因react-scan 异步就位问题configure()失败时每 50ms 重试直到window.reactScan可用——因为注入脚本先于应用代码执行。Node 侧 APIinstallReactScan(page, anchorComponent)用addInitScript依次注入 react-scan bundle 与统计脚本保证在任何应用代码前生效snapshotPerf(page)evaluate页面内drain()后返回{ renders, longTasks, elapsedMs }elapsedMs的取法是firstAnchorRenderAt ?? firstRenderAt ?? startedAt——任何 render 之前的空闲设置时间永远不会撑大区间这与 3.1 中锚点即首次 ThinkingContent render的设计闭环totals(snapshot)汇总 render 总数与总耗时topComponents(snapshot, limit)按 count 排序输出 Top N测试用它打印 Top 15 与打字区间 Top 10longTaskStats(snapshot)给出{ total, worst }attachSnapshot(testInfo, name, snapshot, extra)把元数据与快照合并为 JSON 附件。PerfSnapshot的类型定义scan.ts本身就把锚点语义写进了文档注释是理解各阈值分母口径的最直接依据。5. 前端源码佐证为什么不拆分是安全的基准之所以敢用单块 18k 字符思维 6k 字符 Markdown压测前提是前端渲染路径本身已有足够强的局部更新机制。结合源码可以看到两层保障5.1 思维盒memo 懒挂载折叠体Thinking.tsx 中的ThinkingContent是memo组件并显式声明displayName ThinkingContent第 402 行——react-scan 的逐组件统计正依赖这个名称其内容只是whitespace-pre-wrap的p流式期间 children 字符串变化才会触发重渲染现代路径的 Reasoning.tsx 用useLazyCollapseBody(isExpanded)控制折叠体是否挂载reasoningText由useMemo从reasoning派生——同一 think part 的推理文本随 token 增长时只有文本字符串本身变化头部按钮行ThinkingButton等兄弟子树不受影响。测试种入showThinkingtrue正是强制走展开布局这条更重的路径使度量覆盖盒内段落布局单 Thoughts toggle 断言与ContentTypes.THINK的语义对应每个 THINK part 有独立 toggle见 Reasoning.tsx 头部注释因此 toggle 数 think part 数等于 1 即证明全管道无二次拆分。5.2 Markdown块级 memo 让 render 复杂度降一级MarkdownBlocks.tsx 是实现O(tokens blocks)的关键MarkdownBlocks用useMemo调splitMarkdownIntoBlocks(content)把消息切成顶层块并用前缀和为每块记录codeBaseIndex/artifactBaseIndex/mermaidBaseIndex保持文档序的代码/Artifact 索引连续每个块由独立MarkdownBlock渲染其memo比较函数第 78–83 行只比较content、三个 base 索引与animate——已完成的块在后续 token 中源切片不变既跳过重解析也跳过重渲染只有末尾仍在增长的块重新解析。这就是基准中MarkdownBlockrender 总数停留在 153 次量级而非 10 万级的机制来源每块自带ArtifactProvider/CodeBlockProvider与独立的 fade 插件闭包仅追踪本块字符偏移进一步把流式动画的失效范围限制在单块内。5.3 rAF 合并基准把render 数随帧数而非 chunk 数作为核心命题1ms 延迟下约 5k 个 chunk而阈值上界直接按 90 帧/秒 × 墙钟时间推导。从源码结构看客户端消息内容路径存在requestAnimationFrame缓存刷新的使用如 ActivityPhaseGroup.tsx 中的 rAF 链与测试注释cache flushes happen at most once per animation frame的描述一致基准正是用帧上界把这个行为固化成可回归的断言。6. 如何正确解读与扩展这个基准基线是版本敏感的react-scan 的度量开销与onRender语义随版本移动升级 react-scan 必须重测并更新 README 记录的基线MOCK_LLM_CHUNK_DELAY_MS1同理被刻意锁定改投递速率即需重新标定帧上界必须走 dev server生产构建剥掉displayName后逐组件统计失去锚点只有anonymous计数——这不是配置失误而是硬性前提playwright.config.reasoning-perf.ts 头注释下界断言是防失效设计 10类下界不衡量性能而是防止统计脚本/组件名静默丢失让上界检查空转——这是该基准区别于普通期望小于某数性能测试的严谨之处扩展新场景时正确姿势是新增 payload 构造器 复用 scan.ts 的注入设施并像本基准一样同时给出完整性断言内容真的完整到达 有界性断言render/长任务/打字延迟两层验证运行前确认client/dist已构建、mock 后端3080可被 dev server 的/api代理代理参数由 client/vite.config.ts 的HOSTBACKEND_PORT控制配置中已按 E2E base URL 显式注入。7. 小结这套 reasoning-stream 基准的价值在于把移除拆分逻辑后的渲染有界性从经验判断变成了可回归、可复现、带完整性保障的自动化证据确定性 payload 固定了输入分布react-scan 注入层给出了逐组件的 render 计数与 long task 分布帧上界 速率无关伴随界 绝对预算三类阈值互相补位而 Thinking.tsx、Reasoning.tsx 与 MarkdownBlocks.tsx 中的 memo、懒挂载与块级记忆化则是这些阈值能够长期保持绿色的底层原因。当你修改消息渲染路径、流式合并逻辑或 Markdown 解析管线时直接运行npx playwright test --confige2e/playwright.config.reasoning-perf.ts配合锁定的 react-scan 0.5.7即可验证渲染性能是否回归。【免费下载链接】LibreChatEnhanced ChatGPT Clone: Features Agents, MCP, Skills, DeepSeek, Anthropic, AWS, OpenAI, Responses API, Azure, Groq, o1, GPT-5, Mistral, OpenRouter, Vertex AI, Gemini, Artifacts, AI model switching, message search, Code Interpreter, langchain, DALL-E-3, OpenAPI Actions, Functions, Secure Multi-User Auth, Presets, open-source for self-hosting. Active项目地址: https://gitcode.com/GitHub_Trending/li/LibreChat创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考