MOSS-Transcribe-Diarize + SGLang-Omni 推理方案:显存与解码参数详解
**类型:Explanation(理解导向)**。本文解释
temperature、mem-fraction-static、max_new_tokens三个参数为何影响转写质量、显存占用与可支持音频时长,帮助你在遇到重复退化、OOM 或输出截断时做出正确的调参决策。本文只讨论上述三个参数;
top_p、top_k等其他采样参数不在讨论范围内。
**类型:Explanation(理解导向)**。本文解释
temperature、mem-fraction-static、max_new_tokens三个参数为何影响转写质量、显存占用与可支持音频时长,帮助你在遇到重复退化、OOM 或输出截断时做出正确的调参决策。本文只讨论上述三个参数;
top_p、top_k等其他采样参数不在讨论范围内。
在上一篇《Ray 应用场景一例》中,我介绍了如何使用 Ray 内置的 node:IP 资源,把任务绑定到指定节点。那篇文章要解决的核心问题是:当任务依赖节点本地文件或节点本地环境时,如何确保后续步骤落到正确的机器上执行。
但在当前项目里,这还不够。
这个项目的执行链路大致如下:
如果继续沿用第一篇文章里的思路,节点绑定本身依然是成立的,但会进一步暴露出两个新问题:
所以,本文并不是要推翻上一篇文章里的方案,而是在那个思路之上继续往前走一步:在“节点绑定”已经成立的前提下,引入节点级 Actor Pool 做模型预热,并通过 NodeAffinitySchedulingStrategy 实现更稳定的节点级资源调度。
需要先说明一点:本文中的 Pipeline 设计来自一个具体项目实现,不是 Ray 的固定范式。文中提到的某些约束,例如 step_d 固定在 Head 节点执行、step_c 不做节点绑定,都是当前项目的工程选择,而不是 Actor Pool 方案本身的必然要求。
可以把两篇文章的关系简单理解为:
| 方案 | 主要解决的问题 | 模型预热 | 调度灵活性 | 实现复杂度 |
|---|---|---|---|---|
| node:IP 资源绑定 | 任务如何落到正确节点 | ⚠️ 可做但通常会退回任务级初始化 | ⭐⭐ | 简单 |
| 节点级 Actor Pool + NodeAffinity | 节点绑定基础上的模型复用与节点内调度 | ✅ 预加载复用 | ⭐⭐⭐⭐ | 中等 |
在使用 Oh My Zsh 的经典主题 ys 时,如果你安装了 Anaconda 或 Miniconda,默认情况下 Conda 会强行在 Prompt 最前方插入一行 (base)。这不仅破坏了主题原本的双行美感,还让终端显得异常臃肿。
本文将分享如何通过微调 .zshrc,将 Conda 环境名无缝嵌入到用户名与主机名之后,并保持 ys 原汁原味的配色方案。
默认情况下,终端可能是这样的:
1 | (base) |
三行显示不仅浪费空间,且视觉上非常割裂。我们期望的目标是将其压缩回两行,并让环境名成为“身份标识”的一部分:
1 | # alby@tubumu (base) in ~/dev on git:main x [08:00:00] |
直接将以下逻辑添加至你的 ~/.zshrc 文件末尾(确保在 ZSH_THEME=”ys” 之后):
1 | # ---------------------------------------------------------------- |
1 | #!/bin/bash |
本脚本由
ChatGPT辅助生成。
从网络下载视频数据,再进行本地 AI 分析,接着调用 LLM(ChatGPT、DeepSeek、Gemini、Qwen等) API,最后生成文档。
整个任务链涵盖了 IO 密集型、GPU 密集型、CPU+IO 混合型运算。
本文讲述了如何使用分布式计算框架 Ray 来满足需求。
| 方案 | 并发性 | 资源效率 | 备注 |
|---|---|---|---|
| 独立 placement group 每组绑定同一节点 | ❌ | ⭐⭐ | 安全、可控但排队严重(strategy=”PACK”) |
| Actor 保持节点定位 + 并发执行 | ✅ | ⭐⭐⭐ | 状态管理方便,适合流式任务或推理类任务 |
| 共享节点资源调度 + 同节点约束资源标签 | ✅ | ⭐⭐⭐⭐ | 灵活调度,但实现稍复杂 |
用常规编程语言绘制图表的工具非常多且功能强大,比如 matplotlib 就几乎能绘制所有类型的二维图表,甚至可以做一定程度的三维绘图。
但是,如果要使用 ChatGPT、DeepSeek、Qwen3 等 LLM 来一次性正确地生成绘制代码,声明式图表语言(Declarative Diagram Languages)可能是更好的选择。
再加上需从“对 Pandoc 友好”、“配置难度”等方面考虑,相较而言最合适的是 Mermaid。
| 语言/工具 | Pandoc 支持度 | Markdown 支持度 | 配置难度 | 适合场景 | 备注 |
|---|---|---|---|---|---|
| Mermaid | 通过过滤器(mermaid-filter)或 CLI | 高,许多 Markdown 编辑器原生支持 | 中,需安装 Node.js 和 mermaid-cli | 流程图、时序图、类图、甘特图 | 语法简洁,多图表类型,现代且广泛应用 |
| Graphviz DOT | 原生支持代码块 + pandoc-graphviz 过滤器 | 中,需插件或预先渲染图片嵌入 | 低,安装 graphviz 即可 | 复杂流程图、网络图、层次结构图 | 自动布局优良,图结构复杂时首选 |
| PlantUML | 通过 pandoc-plantuml 过滤器调用 Java | 中,部分 Markdown 编辑器支持插件 | 较高,需 Java 环境及 PlantUML | UML 建模(类图、时序图、用例图等) | 专业 UML 设计工具,适合软件设计文档 |
| WebSequenceDiagrams | 无原生支持,需手动生成图像插入 | 低,需插入生成的图片链接 | 低,在线使用即可 | 简单时序图,快速在线生成 | 依赖网络,适合临时绘图 |
| Ditaa | 通过 pandoc-ditaa 过滤器支持 | 低,需转换为图片插入 | 低,Java 环境,轻量 | ASCII 艺术风格简单流程图、小示意图 | 轻量快速,风格独特,适合纯文本环境 |
