HyperFrames v0.7.98为失败渲染补上并行 drawElement 路由状态让崩溃与回退不再难以区分【免费下载链接】hyperframesWrite HTML. Render video. Built for agents.项目地址: https://gitcode.com/GitHub_Trending/hy/hyperframesHyperFrames 的 Producer 渲染引擎在长视频上默认启用并行 drawElement 捕获路由parallel drawElement router并通过自验证self-verify与固定 worker 回退保证正确性。v0.7.982026-08-07 发布是一次纯可观测性修复失败渲染现在会记录并行 drawElement 路由器当时是否处于激活状态。此前该状态几乎出现在每一次成功渲染中、却几乎不出现在任何失败渲染里导致一次崩溃或挂起hang在遥测上和这次渲染根本没走路由器长得一模一样。本文基于 releases/v0.7.98.md 的发布说明结合 renderOrchestrator.ts、observability.ts 与 render.ts 的源码讲清楚这个状态从哪里产生、在哪条路径上丢失、v0.7.98 如何把它补回失败路径以及随附的 CLI 断路器如何消费这一信号。v0.7.98 发布说明原文与修复内容发布说明的完整内容如下来源 releases/v0.7.98.mdFailed renders now record whether the parallel drawElement router was active. That state was on almost every successful render and almost no failed one, so a crash or hang looked the same as a render that never used the router. Nothing changes about how renders run.唯一的 Fixes 条目Producer:Record routing state on the failure path提交 a3d13e267完整变更对比见官方 compare 链接。要点拆解问题本质是遥测盲区不是渲染行为问题——Nothing changes about how renders run 说明本次发布不改变任何路由、回退或重试策略只补齐失败路径上缺失的字段。盲区造成的混淆路由器几乎出现在每一次成功渲染中意味着成功侧遥测里deParallelRouter基本总是有值而失败侧几乎没有这个字段。于是分析失败渲染时无法回答一个关键问题这个渲染失败时是否正处于并行 drawElement 路由之下答案缺失时崩溃、挂起、OOM 与路由器从未介入的普通渲染无法区分。并行 drawElement 路由器是什么状态的产生位置要理解这次修复为何重要先看清deParallelRouter这个状态在引擎里的产生时机。渲染编排器在 worker 数解析阶段决定路由核心逻辑在 renderOrchestrator.ts// Router takes priority over the single-worker inversion when both would fire — // its higher frame threshold means this only ever picks up long-tail comps // the inversions own benchmark didnt cover. if (deParallelRouterEligible workerCount 1) { deParallelRouter routed; // Fixed at 3, not calibration-derived: the benchmark validated exactly // this worker count (par3 beat par2 consistently...). const ROUTER_WORKER_COUNT 3; log.info( [Render] Fast capture: verified parallel drawElement streaming preferred over single-worker inversion (${totalFrames} frames ${deParallelMinFrames}; ... Set HF_DE_PARALLEL_ROUTERfalse or --workers N to override., ); workerCount ROUTER_WORKER_COUNT; deParallelStreamForced true; } else if (deInversionEligible workerCount 1) { deWorkerInversion inverted; ... workerCount 1; }从源码结构可以确认该路由器的关键属性默认开启、按条件触发当渲染满足deParallelRouterEligible帧数达到deParallelMinFrames阈值、走 drawElement 捕获、且非单 worker时路由器把 worker 数固定 pin 到 3ROUTER_WORKER_COUNT 3并跳过校准calibration——因为基准测试只验证过 3 这个具体值而不是大于 1 的任何值。与单 worker 反转inversion互斥路由器优先级更高两者同时满足时只触发路由器因为它面向的是反转基准没覆盖的长尾更长作品。用户开关日志里给出的覆盖手段是环境变量HF_DE_PARALLEL_ROUTERfalse或 CLI 的--workers N。结果取值routed触发且保持或reverted触发后自验证重试回滚到截图路径。触发之后立即写入活体捕获可观测性且源码注释明确给出了 v0.7.98 想解决的语义——见 renderOrchestrator.tsupdateCaptureObservability({ workerCount, deWorkerInversion, deParallelRouter, // Recorded here (not just in the success-path perfSummary) so a hard // failure while routed/inverted still tells us what worker count the // resolver would have used absent the experiment — the DE-router pin // to 3 workers regardless of calibration is the leading suspect for // any resource-pressure failure unique to this cohort. dePreInversionWorkers: ..., dePreRouterWorkers: deParallelRouter ? preRoutingWorkerCount : undefined, ... });也就是说路由器状态被记录在updateCaptureObservability写入的活体捕获可观测性对象RenderCaptureObservability里而不是只写在渲染结束才构建的成功路径perfSummary中。类型定义在 observability.ts/** DE parallel-router outcome: routed (fired, held) | reverted (fired, self-verify retry rolled back). */ deParallelRouter?: routed | reverted; /** * Low-cardinality GPU bucket (backend/vendor)... Lives on capture * observability (not just perfSummary) so a hard failure — crash / OOM / * timeout — still reports which GPU backend it hit: that is precisely the * cohort the win32 D3D11 rollout must attribute. */ deGpuRenderer?: string; /** Worker count the resolver would have used absent the router; undefined if it never fired. */ dePreRouterWorkers?: number;同一批字段还包括自验证回退原因deFallbackReason∈blank/psnr/oom/capture_error、回退帧号与 PSNR 分数、单 worker 反转状态deWorkerInversion等均集中在 observability.ts 的RenderCaptureObservability接口中。状态的两条消费链成功路径归一化与失败路径断路器路由器状态产生后有两条消费链v0.7.98 正是为了打通失败侧那条成功路径perfSummary 归一为 none渲染成功结束时编排器把deParallelRouter写入性能摘要renderOrchestrator.tsdrawElement: { ... parallelRouter: deParallelRouter, preRouterWorkers: deParallelRouter ? preRoutingWorkerCount : undefined, selfVerifyFallback: deSelfVerifyFallback, fallbackReason: deFallbackReason, ... }perfSummary.ts 在聚合时把它兜底为字符串none无论 drawElement/路由器是否介入保证成功路径上该字段永不为 undefined。CLI 在 render.ts 读取时做归一化function resolveDeParallelRouterOutcome(job: RenderJob): string | undefined { const outcome job.perfSummary?.drawElement?.parallelRouter ?? job.errorDetails?.observability?.capture.deParallelRouter; return outcome none ? undefined : outcome; }注意??链的右项job.errorDetails?.observability?.capture.deParallelRouter——这正是失败路径上的字段来源。注释解释了这个回退读取的必要性硬失败crash/OOM/timeout时perfSummary从未构建只能从就地变更的errorDetails.observability.capture里拿路由器结局。v0.7.98 的修复提交 a3d13e267确保这个失败路径字段在硬失败抛出前被写入使上面的回退读取真正可用。失败路径路由器结局如何触发断路器CLI 侧的maybeConsumeDeParallelRouterTrialrender.ts在渲染无论成功还是失败后都会运行失败分支调用点见 render.ts 的catch块} catch (error: unknown) { maybeConsumeDeParallelRouterTrial(deParallelRouterActive, job, options.quiet); ... handleRenderError(error, options, startTime, false, ..., job); }其判定逻辑render.ts// Trip on any recorded non-success, not only the literal string reverted. const fired outcome ! routed; if (fired) { config.deParallelRouterTrialFired true; deParallelRouterBreakerTrippedThisProcess true; applyDeParallelRouterBreaker(); } writeConfig(config);即路由器结局只要不是干净的routed包括reverted、停滞、超时等任何非成功信号就熔断该安装install的路由器写入~/.hyperframes/config.json的deParallelRouterTrialFired此后该安装的渲染在启动阶段由applyDeParallelRouterCircuitBreakerrender.ts把HF_DE_PARALLEL_ROUTER显式 latch 为false并打印Parallel drawElement capture stays off for this install (a previous render had to fall back). Re-enable with HF_DE_PARALLEL_ROUTERtrue.这条链路有一个直接依赖断路器要能区分路由器触发后回退和路由器从未介入必须能在失败渲染上读到deParallelRouter。在 v0.7.98 之前失败渲染的该字段几乎总是缺失undefinedresolveDeParallelRouterOutcome返回undefined断路器就无法消费一个本应触发它的失败信号——一次由 3 worker pin 引起的 OOM 崩溃不会让该安装永久关闭路由器。这正是发布说明里crash or hang looked the same as a render that never used the router的工程后果。值得强调断路器设计的两个克制点源码注释可证遥测开关只治理上报不治理行为hasDeParallelRouterBreakerTripped刻意不检查 telemetry 状态避免关闭分析的用户被惩罚性地使用更慢的渲染器render.ts。用户显式设置优先进程首次观察时 latchdeParallelRouterUserManaged用户无论设true还是false断路器都不覆盖其选择。回退重试与reverted的语义理解deParallelRouter的两种取值需要看失败时引擎如何反应。当路由器处于routed状态且捕获阶段出错时shouldRetryViaPinnedFallback 决定是否可以走固定 worker 回退if (args.isCancellation || args.isEncoderInterrupted) return false; if (args.isVerifyError) return true; if (args.isDeRendererStall true || args.isSequentialCaptureStall true) return true; return args.deWorkerInversion inverted || args.deParallelRouter routed;自验证错误blank frame / PSNR 跌破HF_DE_VERIFY_MIN_DB在任何路由下都重试路由器处于routed时的通用捕获失败宿主机争用超时、worker 崩溃、OOM也重试因为 pin 到 3 worker 本身就是路由器引入的资源压力风险面——重试会回到已验证的并行磁盘 / 单 worker 截图路径取消与编码器中断除外用户中止必须立即传播不得先空转一轮资源启停。具体重试计划由 resolveParallelRouterRetryPlan 生成OOM 场景降到单 worker否则沿用路由器触发前的 worker 数并把状态改写为reverted。所以reverted的语义是路由器触发过、但自验证/通用失败重试把它回滚了而不是渲染失败——渲染回退后仍可能成功。失败遥测中区分这两类情况靠的就是本次补齐的deParallelRouter与deFallbackReason组合。如何验证与观测这些行为仓库内可用的验证入口均为只读查看路由器状态记录与失败路径断言renderOrchestrator.test.ts 中成组的用例覆盖deParallelRouter: routed | reverted | undefined各情形下回退计划与断路器输入的组合包括路由器未介入时永远不触发的场景同文件 L2767。CLI 侧断路器测试render.test.ts 验证了完整的状态机——deParallelRouterTrialFired的写入与镜像、进程内 latchdeParallelRouterBreakerTrippedThisProcess在配置不可写时兜底、用户显式HF_DE_PARALLEL_ROUTER时断路器 no-op、job.errorDetails { observability: { capture: { deParallelRouter: routed } } }的硬失败不触发熔断而reverted触发render.test.ts以及deParallelRouterTrialRenderCount计数与上限回退。调试渲染时编排器在job.config.debug下会把perfSummary写入磁盘renderOrchestrator.ts其中drawElement.parallelRouter字段即路由器结局none表示路由器从未介入。排查建议遇到失败渲染时先确认遥测/errorDetails.observability.capture.deParallelRouter是否有值——v0.7.98 起该值要么真实反映路由状态要么明确表示未介入结合deFallbackReason、dePreRouterWorkers与deGpuRenderer即可区分路由器 pin 到 3 worker 导致的资源压力失败自验证回退后仍失败与路由器未参与的普通失败三类情况。小结v0.7.98 是一次典型的失败路径可观测性补丁不改渲染行为只把路由器激活状态从仅成功路径扩展到失败路径使崩溃与挂起能够归因到并行 drawElement 路由这个具体队列。源码层面的佐证链完整——状态产生于 renderOrchestrator.ts 的 worker 解析阶段类型与语义定义在 observability.ts成功路径经 perfSummary.ts 归一失败路径经errorDetails.observability.capture被 render.ts 的断路器消费行为由 renderOrchestrator.test.ts 与 render.test.ts 两侧测试锁定。对维护渲染队列排障的人来说这个字段让3 worker pin 是否嫌疑人从猜测变成一次查询。【免费下载链接】hyperframesWrite HTML. Render video. Built for agents.项目地址: https://gitcode.com/GitHub_Trending/hy/hyperframes创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 HyperFrames v0.7.98：为失败渲染补上并行 drawElement 路由状态，让崩溃与回退不再难以区分
HyperFrames v0.7.98为失败渲染补上并行 drawElement 路由状态让崩溃与回退不再难以区分【免费下载链接】hyperframesWrite HTML. Render video. Built for agents.项目地址: https://gitcode.com/GitHub_Trending/hy/hyperframesHyperFrames 的 Producer 渲染引擎在长视频上默认启用并行 drawElement 捕获路由parallel drawElement router并通过自验证self-verify与固定 worker 回退保证正确性。v0.7.982026-08-07 发布是一次纯可观测性修复失败渲染现在会记录并行 drawElement 路由器当时是否处于激活状态。此前该状态几乎出现在每一次成功渲染中、却几乎不出现在任何失败渲染里导致一次崩溃或挂起hang在遥测上和这次渲染根本没走路由器长得一模一样。本文基于 releases/v0.7.98.md 的发布说明结合 renderOrchestrator.ts、observability.ts 与 render.ts 的源码讲清楚这个状态从哪里产生、在哪条路径上丢失、v0.7.98 如何把它补回失败路径以及随附的 CLI 断路器如何消费这一信号。v0.7.98 发布说明原文与修复内容发布说明的完整内容如下来源 releases/v0.7.98.mdFailed renders now record whether the parallel drawElement router was active. That state was on almost every successful render and almost no failed one, so a crash or hang looked the same as a render that never used the router. Nothing changes about how renders run.唯一的 Fixes 条目Producer:Record routing state on the failure path提交 a3d13e267完整变更对比见官方 compare 链接。要点拆解问题本质是遥测盲区不是渲染行为问题——Nothing changes about how renders run 说明本次发布不改变任何路由、回退或重试策略只补齐失败路径上缺失的字段。盲区造成的混淆路由器几乎出现在每一次成功渲染中意味着成功侧遥测里deParallelRouter基本总是有值而失败侧几乎没有这个字段。于是分析失败渲染时无法回答一个关键问题这个渲染失败时是否正处于并行 drawElement 路由之下答案缺失时崩溃、挂起、OOM 与路由器从未介入的普通渲染无法区分。并行 drawElement 路由器是什么状态的产生位置要理解这次修复为何重要先看清deParallelRouter这个状态在引擎里的产生时机。渲染编排器在 worker 数解析阶段决定路由核心逻辑在 renderOrchestrator.ts// Router takes priority over the single-worker inversion when both would fire — // its higher frame threshold means this only ever picks up long-tail comps // the inversions own benchmark didnt cover. if (deParallelRouterEligible workerCount 1) { deParallelRouter routed; // Fixed at 3, not calibration-derived: the benchmark validated exactly // this worker count (par3 beat par2 consistently...). const ROUTER_WORKER_COUNT 3; log.info( [Render] Fast capture: verified parallel drawElement streaming preferred over single-worker inversion (${totalFrames} frames ${deParallelMinFrames}; ... Set HF_DE_PARALLEL_ROUTERfalse or --workers N to override., ); workerCount ROUTER_WORKER_COUNT; deParallelStreamForced true; } else if (deInversionEligible workerCount 1) { deWorkerInversion inverted; ... workerCount 1; }从源码结构可以确认该路由器的关键属性默认开启、按条件触发当渲染满足deParallelRouterEligible帧数达到deParallelMinFrames阈值、走 drawElement 捕获、且非单 worker时路由器把 worker 数固定 pin 到 3ROUTER_WORKER_COUNT 3并跳过校准calibration——因为基准测试只验证过 3 这个具体值而不是大于 1 的任何值。与单 worker 反转inversion互斥路由器优先级更高两者同时满足时只触发路由器因为它面向的是反转基准没覆盖的长尾更长作品。用户开关日志里给出的覆盖手段是环境变量HF_DE_PARALLEL_ROUTERfalse或 CLI 的--workers N。结果取值routed触发且保持或reverted触发后自验证重试回滚到截图路径。触发之后立即写入活体捕获可观测性且源码注释明确给出了 v0.7.98 想解决的语义——见 renderOrchestrator.tsupdateCaptureObservability({ workerCount, deWorkerInversion, deParallelRouter, // Recorded here (not just in the success-path perfSummary) so a hard // failure while routed/inverted still tells us what worker count the // resolver would have used absent the experiment — the DE-router pin // to 3 workers regardless of calibration is the leading suspect for // any resource-pressure failure unique to this cohort. dePreInversionWorkers: ..., dePreRouterWorkers: deParallelRouter ? preRoutingWorkerCount : undefined, ... });也就是说路由器状态被记录在updateCaptureObservability写入的活体捕获可观测性对象RenderCaptureObservability里而不是只写在渲染结束才构建的成功路径perfSummary中。类型定义在 observability.ts/** DE parallel-router outcome: routed (fired, held) | reverted (fired, self-verify retry rolled back). */ deParallelRouter?: routed | reverted; /** * Low-cardinality GPU bucket (backend/vendor)... Lives on capture * observability (not just perfSummary) so a hard failure — crash / OOM / * timeout — still reports which GPU backend it hit: that is precisely the * cohort the win32 D3D11 rollout must attribute. */ deGpuRenderer?: string; /** Worker count the resolver would have used absent the router; undefined if it never fired. */ dePreRouterWorkers?: number;同一批字段还包括自验证回退原因deFallbackReason∈blank/psnr/oom/capture_error、回退帧号与 PSNR 分数、单 worker 反转状态deWorkerInversion等均集中在 observability.ts 的RenderCaptureObservability接口中。状态的两条消费链成功路径归一化与失败路径断路器路由器状态产生后有两条消费链v0.7.98 正是为了打通失败侧那条成功路径perfSummary 归一为 none渲染成功结束时编排器把deParallelRouter写入性能摘要renderOrchestrator.tsdrawElement: { ... parallelRouter: deParallelRouter, preRouterWorkers: deParallelRouter ? preRoutingWorkerCount : undefined, selfVerifyFallback: deSelfVerifyFallback, fallbackReason: deFallbackReason, ... }perfSummary.ts 在聚合时把它兜底为字符串none无论 drawElement/路由器是否介入保证成功路径上该字段永不为 undefined。CLI 在 render.ts 读取时做归一化function resolveDeParallelRouterOutcome(job: RenderJob): string | undefined { const outcome job.perfSummary?.drawElement?.parallelRouter ?? job.errorDetails?.observability?.capture.deParallelRouter; return outcome none ? undefined : outcome; }注意??链的右项job.errorDetails?.observability?.capture.deParallelRouter——这正是失败路径上的字段来源。注释解释了这个回退读取的必要性硬失败crash/OOM/timeout时perfSummary从未构建只能从就地变更的errorDetails.observability.capture里拿路由器结局。v0.7.98 的修复提交 a3d13e267确保这个失败路径字段在硬失败抛出前被写入使上面的回退读取真正可用。失败路径路由器结局如何触发断路器CLI 侧的maybeConsumeDeParallelRouterTrialrender.ts在渲染无论成功还是失败后都会运行失败分支调用点见 render.ts 的catch块} catch (error: unknown) { maybeConsumeDeParallelRouterTrial(deParallelRouterActive, job, options.quiet); ... handleRenderError(error, options, startTime, false, ..., job); }其判定逻辑render.ts// Trip on any recorded non-success, not only the literal string reverted. const fired outcome ! routed; if (fired) { config.deParallelRouterTrialFired true; deParallelRouterBreakerTrippedThisProcess true; applyDeParallelRouterBreaker(); } writeConfig(config);即路由器结局只要不是干净的routed包括reverted、停滞、超时等任何非成功信号就熔断该安装install的路由器写入~/.hyperframes/config.json的deParallelRouterTrialFired此后该安装的渲染在启动阶段由applyDeParallelRouterCircuitBreakerrender.ts把HF_DE_PARALLEL_ROUTER显式 latch 为false并打印Parallel drawElement capture stays off for this install (a previous render had to fall back). Re-enable with HF_DE_PARALLEL_ROUTERtrue.这条链路有一个直接依赖断路器要能区分路由器触发后回退和路由器从未介入必须能在失败渲染上读到deParallelRouter。在 v0.7.98 之前失败渲染的该字段几乎总是缺失undefinedresolveDeParallelRouterOutcome返回undefined断路器就无法消费一个本应触发它的失败信号——一次由 3 worker pin 引起的 OOM 崩溃不会让该安装永久关闭路由器。这正是发布说明里crash or hang looked the same as a render that never used the router的工程后果。值得强调断路器设计的两个克制点源码注释可证遥测开关只治理上报不治理行为hasDeParallelRouterBreakerTripped刻意不检查 telemetry 状态避免关闭分析的用户被惩罚性地使用更慢的渲染器render.ts。用户显式设置优先进程首次观察时 latchdeParallelRouterUserManaged用户无论设true还是false断路器都不覆盖其选择。回退重试与reverted的语义理解deParallelRouter的两种取值需要看失败时引擎如何反应。当路由器处于routed状态且捕获阶段出错时shouldRetryViaPinnedFallback 决定是否可以走固定 worker 回退if (args.isCancellation || args.isEncoderInterrupted) return false; if (args.isVerifyError) return true; if (args.isDeRendererStall true || args.isSequentialCaptureStall true) return true; return args.deWorkerInversion inverted || args.deParallelRouter routed;自验证错误blank frame / PSNR 跌破HF_DE_VERIFY_MIN_DB在任何路由下都重试路由器处于routed时的通用捕获失败宿主机争用超时、worker 崩溃、OOM也重试因为 pin 到 3 worker 本身就是路由器引入的资源压力风险面——重试会回到已验证的并行磁盘 / 单 worker 截图路径取消与编码器中断除外用户中止必须立即传播不得先空转一轮资源启停。具体重试计划由 resolveParallelRouterRetryPlan 生成OOM 场景降到单 worker否则沿用路由器触发前的 worker 数并把状态改写为reverted。所以reverted的语义是路由器触发过、但自验证/通用失败重试把它回滚了而不是渲染失败——渲染回退后仍可能成功。失败遥测中区分这两类情况靠的就是本次补齐的deParallelRouter与deFallbackReason组合。如何验证与观测这些行为仓库内可用的验证入口均为只读查看路由器状态记录与失败路径断言renderOrchestrator.test.ts 中成组的用例覆盖deParallelRouter: routed | reverted | undefined各情形下回退计划与断路器输入的组合包括路由器未介入时永远不触发的场景同文件 L2767。CLI 侧断路器测试render.test.ts 验证了完整的状态机——deParallelRouterTrialFired的写入与镜像、进程内 latchdeParallelRouterBreakerTrippedThisProcess在配置不可写时兜底、用户显式HF_DE_PARALLEL_ROUTER时断路器 no-op、job.errorDetails { observability: { capture: { deParallelRouter: routed } } }的硬失败不触发熔断而reverted触发render.test.ts以及deParallelRouterTrialRenderCount计数与上限回退。调试渲染时编排器在job.config.debug下会把perfSummary写入磁盘renderOrchestrator.ts其中drawElement.parallelRouter字段即路由器结局none表示路由器从未介入。排查建议遇到失败渲染时先确认遥测/errorDetails.observability.capture.deParallelRouter是否有值——v0.7.98 起该值要么真实反映路由状态要么明确表示未介入结合deFallbackReason、dePreRouterWorkers与deGpuRenderer即可区分路由器 pin 到 3 worker 导致的资源压力失败自验证回退后仍失败与路由器未参与的普通失败三类情况。小结v0.7.98 是一次典型的失败路径可观测性补丁不改渲染行为只把路由器激活状态从仅成功路径扩展到失败路径使崩溃与挂起能够归因到并行 drawElement 路由这个具体队列。源码层面的佐证链完整——状态产生于 renderOrchestrator.ts 的 worker 解析阶段类型与语义定义在 observability.ts成功路径经 perfSummary.ts 归一失败路径经errorDetails.observability.capture被 render.ts 的断路器消费行为由 renderOrchestrator.test.ts 与 render.test.ts 两侧测试锁定。对维护渲染队列排障的人来说这个字段让3 worker pin 是否嫌疑人从猜测变成一次查询。【免费下载链接】hyperframesWrite HTML. Render video. Built for agents.项目地址: https://gitcode.com/GitHub_Trending/hy/hyperframes创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考