逐字稿文字預覽
開放了千萬3.8RGB的模型權重。很多人看到RGB之後的第一個問題就是,這東西,我的Mac到底能不能跑呢? 有人看到量化以後只需要十幾GB的內存,覺得自己的24GB Mac應該也沒有什麼問題。 结果模型下载完以后 要么加载失败 要么刚开始生成 系统内存就直接爆掉 有人花了半天时间把模型跑起来 最后发现生成速度只有每秒八九个Token 打开MTP之后不仅没有加速 反而更慢了 所以今天这支影片 我会从零开始 带你在Mac上完整部署一次 千万3.8 RGB 我们会先搞清楚RGP到底代表什么 它和Cloud GPT这些B原模型 大概处于什么水平 然后算清楚模型运行时 到底会占用多少内存 接下来我会带你选择正确的MLX量化版本 使用Hugging Face的并行下载工具 把模型下载到本地 先跑出一个没有任何加速的基础速度 最后再安装DFlesh 2 在下载模型之前 我们首先得搞清楚一件事 前往3.827B里面的这个27B到底是什么意思 这里的B是Billing 也就是实义 27B代表这个语言的模型部分 大约拥有271个参数 你可以把参数理解成有模型训练完成以后保留下来的271个数字 模型每生成一个token都要读取这些数字进行计算 然后判断下一个token最有可能是什么 如果想象的更具体一点 你可以把它理解成一台拥有271个旋钮的巨大机器 训练模型的过程就是不断调整这271个旋钮 而我们现在进行的本地推理 就是把这些调整好的旋钮加载到内存里 然后用它们来生成答案 这里还有一个非常重要的概念 也就是说千问3.827B是一个Distance模型 也就是稠密模型 而不是MROE混合专家模型 有些模型名称可能写着总参数35B 但是后面还有一个A3B 所谓的A3B呢 这个A3B的意思就是 它虽然一共有350亿参数 但每次生成Token的时候 大约只有30亿参数会被激活 前往3.827B不一样 它没有A几B的后缀 它的语言模型拥有270亿参数 每生成一个Token 那么就代表着 基本要经过这270亿参数的计算 所以它的总参数大约是27B 激活参数呢 同样也是27B 这也是为什么同样叫做30B左右的模型 千万3.8 27B 可能比一些35B A3B的MOE模型大很多 当然 稠密模型也不是只有缺点 它的优势是所有能力都集中在同一套参数里 通常在输出稳定性 复杂任务和知识调用上会更加均衡 如果可以把本地运行的模型简单承评成三个类别 3B到8B通常属于轻量模型 这类模型速度很快 但复杂任务比较容易走偏 14B到30B可以看成本地大模型目前最实用的高质量区间 能力已经足以处理比较复杂的编程文章生成和工具调用 以及agent任务 70B以上的稠密模型能力通常会更加稳定 但需要的内存和内存带宽也会明显上升 对于大部分个人用户来说 部署成本其实是比较高的 所以千万3.8RGB基本属于个人电脑还能够比较现实的部署 同时能力有足够强的高端本地模型 那它跟市面上的B1模型相比怎么样呢 首先我们不能直接拿RGB去和Cloud和GPT的比较参数量 因为大部分B原模型不会公开完整参数量和激活参数 即使参数量一样 训练数据、模型架构、后训练和推理预算不同 最终能力也可能差很多 比较稳妥的说法是 千万3.8RGB已经进入了可以和B原旗舰模型 在部分任务上正面竞争的范围 但它还不能全面替代B原旗舰 以签问官方测试为例 可以看到 在Batch Pro里签问3.8 RTB是61.7 OPLA 4.6 MAX是53.4 Terminal Bench则是73对78.2 HLE是30.8对40 那么这组数据就可以说明 它在某些编程和工具调用任务上 可以接近甚至超过B元 但是复杂开放式推理 知识广度和长容稳定性 B元旗舰通常还是更强一些 而且这是签问官方公布的测试 它不是不同模型可能使用了不同的harness 所以这也包含官方自己的测试集 可以作为一部分定位参考 但不能因为某一个分数更高 就是说千万已经全面超越了Cloud 对我来说最准确的定位是 它不是B原旗舰的完整替代品 但已经是一款可以真正承担生产任务的高端本地模型 接下来我们来算一下它到底需要多少内存 很多人看到27B会直接认为它需要27G的内存 这个说法只在非常特定的条件下才大致成立 如果使用BF16一个参数呢 需要两个字节 270一个参数乘以两个字节的话 光语言模型原始权重就要大约54G 这还没有算计算系统 缓存和退理过程中的临时内存 所以64G Mac 虽然理论上可以放下BF16权重 但运行语量其实非常有限 量化的作用呢 就是使用更少的位数保存这些参数 8bit理论权重大约27G 4bit理论上大约13.5G 实际MLX版本还包含量化参数 词表和配置 8bit纯文字版约28.6G 带视觉能力约29.5G 4bit版本大约16G 那么从这些地方的这些数字 只代表模型权重 并不是模型启动后的总内存占用 每次运行时 内存里至少还要放进五类东西 第一类也就是最大的一类 就是模型群众 运行8bit版本光这一向就已经接近29G 而且启动后基本都要进入Mac统一内存 第二类是KVKISH和线性注意力技术 模型需要保存已经处理过的上下文 否则每生成一个Token都需要重新计算前文 KVKISH和上下文长度直接下文 前文原生支持约26万Token,但支持不代表你的Mac适合直接开满。 粗略计算 32K上下文 仅标准注意力 64K约4G 128K约8G 256K就要16G 此外还没包含线性注意力状态 如果平常只是聊天 或者处理普通代码任务 先从16K和32K开始 通常就已经足够了 第三类是MLX和META运行时 使用的计算空间 包括临时激活值和计算缓冲区 那么它不是固定数字 会随输入程度和并发变化 尤其是在第一次读取大段Prompt 也就是Prefill阶段 内存占用可能突然上升 第四类是视觉编码器 那么只做文字 写代码或运行Agent 可以选择TextOnly 需要读取图片或视频 才选择完整多模态版本 第五类是DFLASH2草稿模型 它不是普通开关 还需要一个配套的草稿模型 本身它大约21个参数 并额外占用缓存和缓冲区 所以最终的内存杖不是27B等于27G 而是模型权重加Cache 加运行缓冲加系统占用 再加DFLASH2草稿模型 如果想运行8bit版本 那么48G统一内存可以作为比较现实的起点 例如4G会更加舒服 32G不是绝对加载不了 但余量非常小 如果Mac只有24G或32G的话 我建议更加直接使用4bit版本是比较好的 模型文件大约16G 给系统Cache和D-Flash 2留下的空间会宽松很多 Mac运行本地模型常见的聊线 GGUF加Lama CPP一节MLX 这次选择MLX 因为它针对苹果电脑有比较特殊的一些优化 而且后面的D-Flash 2工具可以直接运行MLX权重 我这次选择千万3.8RGB的MLX 8bit版本 如果内存比较小 把8bit换成对应的4bit仓库即可 其他流程基本是一样的 模型可以直接去HarkinFace下载 那么下载的时候 不建议打开浏览器 一个文件一个文件点击 大模型通常拆成多个权重封片 浏览器下载非常容易中断 也可能漏掉配置文件 那么这里更推荐用HarkinFace官方的 HF命令航工具 使用新版的HUB 使用XNET后端 它可以支持并行下载 就造成你的Transfer 已经逐步被淘汰了 那么我们这里 首先安装最新版Hagenface CLI 接下来 开启高性能模式 然后把模型下载到指定目录 那么高性能模式会提高并发 尽可能利用网络和CPU资源 模型比较大 下载前记得磁盘至少还有几十T的空余空间 下载完成之后 我们先别着急安装D-Flash 2 先跑出没有加速的基础版本 建议给本地模型单独创建 Python虚拟环境 避免不同的项目依赖会互相污染 创建环境 激活环境 以及安装MXM和MX 第一次测试呢 不要开超长的上下纹 不要开Dflash 2 同时呢 也不要修改一大堆采样参数 只指定模型路径 固定Prompt 生成几百个Token 运行最基础的生成命令 运行完成之后呢 我们可以把模型加载时间 Prompt处理速度 守Token等待时间和生成Token速度 这四个数字记录下来 如果没有基础数据 后面看到每每20几个token也不知道到底快了多少 基础9变27是3倍 那么基础20变22可能就不值得增加内存和复杂度 确认基础模型稳定之后呢 我们就可以安装D-Flash 2 D-Flash 2本质上是一种推测解码技术 正常情况下 千万3.827B每生成一个token的话 都要让完整270亿参数计算一次 那么生成10个token 就要连续做10次完整的推理 Dflash 2 让一个大约20亿参数的草稿模型 一次性并行预测接下来的一组token 然后再让27B主模型一次检查这一整组答案 如果草稿模型猜的比较准 主模型一次计算就可以接受多个Token 原本连续走五六四的流程 现在可能只需要一次验证 草稿模型只负责猜 最终决定权依然在27B主模型手上 贪心解码下最终输出 可以与基础模型一致 随机采样则保留主模型原本的分布 在Mac上 比较直接的实现是MX的D Spark 那么这个虽然名字写着Dspark 但它同时支持Dspark,Dflash和Dflash2 在用的时候对于千万3.8,27B,Ultra模式会直接使用Dflash2 安装命令也非常简单 屏幕上的安装命令 安装完成以后不要凭感觉判断有没有变快 直接运行项目自带的Benchmark 使用三轮测试 第一次运行会自动下载匹配的DFlesh2草稿模型 并根据这台Mac的实际成本测试 合适的推理长度 M1 M3 M4 M5的最佳参数呢 它是不一定一样的 如果你想直接生成内容的话 建议用这个命令 可以使用MXD Spark Generate 默认AUTO模式会为千万3.8RCB匹配DFLASH2 再用完全相同的Prompt测试 对比基础速度 DFLASH2速度接受长度和内存占用 那么比下来之后 项目在特定的M4 Pro测试中 8bit的基础约8.4Token每秒 DFLASH2平均约30.5Token每秒 不同任务约2.8到4倍 但这不是你的Mac一定能达到的速度 因为呢 DFLASH2不是打开以后 它就一定变快 如果草稿接受率低的话 主模型会不断拒绝和重新生成 草稿计算反而成为额外的负担 对于只有几十个Token的短回答 模型刚加载完成和校准 任务就结束了 实际体感提升可能不是很明显 D-Flash 2还会增加内存占用 所以呢 如果8bit主 所以,如果8bit主模型以及頻繁swap,那麼再加載草稿模型,最終速度反而更慢。 所以要用自己最常執行的任務去測試一下。寫代碼就測真實代碼修改。 生成口播稿就连续输出一两千的token 运行agent就测试完整工具调用 最后一步是把模型启动成API MLX的Dspark可以兼容OpenAI 那么和Astorbit格式的本地服务 启动命令是MLXDsparkServe 默认是开在本级8080端口去提供接口的 客户端BaseURL设置成127.0.18080 设置好之后 只在自己电脑使用 可以不设置真正的API Key 需要局域网访问的时候 要调整监听地址 检查防火墙 但不要把无件权接口直接暴露到公网 到这里我们完成了整套部署流程 第一 R7B代表约270亿参数 而且它是全量激活的稠密模型 第二 RGB不等于只需RGB内存 把比特权重接近R9G运行 是要加CASE缓冲区系统和草稿模型 那么第三 它属于本地模型高端档 部分编程和Agent任务接近B原起见 但不是全面的替代 第四 不要一上来 就打开所有加速箱 先用MLX跑出基础速度 再用相同Prompt做A-B测试 决定是否长期使用D-Flash 2 如果真实任务从每秒9个Token 能够提高到2-30个的话 而且内存稳定 那么它就值得长期去打开 如果频繁Swap或者主要都是短问答的话 4bit基础模型可能更舒服一些 本地部署大模型的价值不是省API费用 当它变成Mac上的本地服务 它就可以接入代码Langraph 自动剪辑系统 知识库 以及agent工作流 真正好的本地布置方案 不是参数最大 也不是测试数字最高 而是在自己的设备上 质量足够好 速度能够接受 内存保持稳定 并且真的进入日常工作流 才能长期去使用 影片领誘到的模型地址安装命令和测试命令 我都会整理在下方 如果希望下一期测试4bit 6bit和8bit的品质差距的话 以及DFlex 2速度也可以留言给我 喜欢这支影片的话 记得帮我按赞订阅加分享哦 这是我持续创作的最大动力 我们下次再见
本次執行流程與問題處理
下達指令
預期流程
- 下載與語音辨識
- 來源選擇與品質檢查
- 文字校正與句子單元
- 筆記與發布
- 公開網頁發布
1. 下載與語音辨識
工具：videonote-transcribe-url（主辨識管線：下載、Whisper 辨識與選稿）
處理：下載音訊、以 Whisper 辨識並選出最佳逐字稿
產出：yt_dlp_meta.json（影片元資料）、audio_16k_mono.wav（16kHz 單聲道音訊）、transcript.whisper.json（Whisper 辨識結果）、transcript.json（正式逐字稿）、transcript_selection_report.json（來源選擇報告）
耗時：1479.8 秒
關係：依序執行
結果：完成
2. 全文快速校讀
工具：videonote_rapid_transcript_review.py
處理：先速讀完整逐字稿，再修正高可信突兀詞句並列出待確認項目
產出：rapid_transcript_review_report.json（產出檔案）
耗時：44.8 秒
關係：依序執行
結果：完成
3. 建立句子單元
工具：videonote-build-sentence-units
處理：將逐字稿切成帶時間軸的句子單元
產出：sentence_units.json（句子單元）
耗時：0.8 秒
關係：依序執行
結果：完成
4. 句子密度平衡
工具：videonote_balance_sentence_units.py
處理：平衡句子長度與密度
產出：sentence_units.json（句子單元）
耗時：0.9 秒
關係：依序執行
結果：完成
5. 時間軸稽核
工具：videonote_timeline_audit.py
處理：檢查時間軸與音訊對齊
產出：timeline_audit_report.json（時間軸稽核）
耗時：0.9 秒
關係：依序執行
結果：完成
6. 品質檢查
工具：videonote_controlled_quality.py（檢查時間軸與品質）
處理：檢查語言、時間軸與可讀性品質
產出：controlled_quality_report.json（品質報告）、language_sanity_report.json（語言檢查）
耗時：1.0 秒
關係：依序執行
結果：完成
7. 播放時間軸回填
工具：videonote_rebase_display_timeline.py
處理：將網頁播放時間軸回填為校正字幕時間
產出：display_timeline_rebase_report.json（時間軸回填報告）
耗時：1.0 秒
關係：依序執行
結果：完成
8. 逐字稿交叉檢查
工具：videonote_cross_check_transcript.py
處理：交叉檢查逐字稿與來源字幕
產出：transcript_crosscheck_report.json（交叉檢查）
耗時：1.0 秒
關係：依序執行
結果：完成
9. 來源句整理
工具：videonote_prepare_source_entries.py
處理：整理來源句子供時間軸與頁面使用
產出：sentence_units.json（句子單元）
耗時：0.0 秒
關係：依序執行
結果：完成
10. 生成筆記摘要
工具：videonote-generate-note（生成筆記摘要）
處理：生成筆記摘要與重點
產出：note.md（筆記 Markdown）、note.html（筆記 HTML）
耗時：128.7 秒
關係：依序執行
結果：完成
11. 建立筆記頁面
工具：videonote-render-html（產生筆記 HTML）
處理：產生可閱讀的筆記 HTML 頁面
產出：note.html（筆記 HTML）
耗時：0.8 秒
關係：依序執行
結果：完成
12. 發布公開頁面
工具：videonote-publish（發布公開頁面）
處理：發布到公開網站與每日列表
產出：公開筆記網址、result.json（管線結果）
耗時：0.8 秒
關係：依序執行
結果：完成
手動來源字幕
- 尚未產生
自動來源字幕
Whisper 字幕
Qwen 字幕
- 尚未產生
Parakeet 字幕
- 尚未產生
MOSS 字幕
- 尚未產生
聲學時間證據（PyAnnote / WhisperX）
- 尚未產生
校正前後逐字稿
- 校正前 transcript.whisper.json 純文字 JSON
- 校正後 transcript.json 純文字 JSON
目前待解決問題與初步改善方向
- 逐字稿全文快速校讀未完成
已保留自動字幕/原始逐字稿並繼續生成筆記。；未完成的全文速讀項目可在精進模式回聽確認。；RAPID_REVIEW_STATUS=REVIEW_REQUIRED_INVALID_OUTPUT
- Qwen3-ASR 未完成，需確認 qwen_asr_lab 環境與音訊後重試精進模式。