逐字稿文字預覽
相信大家對於九月這批 新的 Mac mini 跟 Mac Studio, 到底要買哪一台,買什麼規格 都有很大的疑問 我也一樣 我打開購買頁排了一個下午 越排越不確定 因為官網把記憶體 GPU 核心數 跟記憶體頻寬 分成三個地方寫 你看得到每一個數字 但看不到它們是連在一起的 我先給你其中一個結論 你等一下就知道我在說什麼 如果你跑代理的時候 每一輪都要讀進很長的內容 卻只回你一小段 時間就可能主要花在處理輸 入的運算上,不是花在吐字 這一段主要看算力 所以模型裝得下、吐字很快 都不代表你按下 送出之後不用等 這支影片就是要幫助你 選一台適合自己的規格 先把買之前必須 知道的那幾個規格,各 自卡住你什麼,講清楚 然後你拿自己 的使用情境去對 你就抓得到最適 合你的那個規格 購買 mac 之前 有兩件事情一定要先理解 第一個叫什麼。 預填充 它會把你輸入的整段 提示詞一次全部算完 這一段算完之後 它會把每一層算出 來的中間結果存下來 就是所謂的 KV cache 第二個是解碼 它開始一個字一個字回你 每次吐一個字 它都要把整份 KV cache 從頭掃一次 這兩件事卡在 完全不同的地方 預填充是一次算一大片 主要靠算力 解碼是一個字一個字來 每次都要把資料整份搬過 靠的是記憶體頻寬 那麼. . 預填充為什麼會慢呢? 因為你輸入越長 它要算的量不是等比例增加 是跟長度的平方走 你貼一段程式碼進去 那一段要先被讀完 你才會看到第一個字 這裡有一個大家最 容易搞錯的地方 多輪對話的時候 前面所有的歷史 會不會每一輪都重新算一次 答案是不一定 如果前面那一段一個 字都沒變,KV cache 可以直接沿用 mac只算你這 一輪新加的東西 那什麼時候會失效 有三種情況 一種就是全部重算 第一種是什麼 你開了一個新的子代理 那是一個全新的對話 前面的快取一個字都用不到 第二種呢 工具回傳的結果被插進中間 插入點後面的全部失效 第三種呢 你把程式關掉再打開 本地跑的時候 通常不會把快取留到下一次 這個差別有多大 有人拿同一台mac 同一個模型量過 快取全中的時候,等兩點九秒 快取沒中要全部重算 等八十二秒 同一台mac,同一個模型 差二十八倍 差別只在前面 那段有沒有動過 所以你如果覺得同一台mac 有時候很快有時候很慢 那不是你的錯覺 還有一個例子更直接 有人測同一段長提示詞 量到兩點九七秒 覺得很快 然後他自己發現那是快取 命中,關掉重測,變成十七秒 先說一件事 Mac 跟一般電腦差在哪 差在它的記憶體是統一的 CPU 跟 GPU 共用同一池 所以規格表上那個記憶體 數字,就是模型可以用的量 這是 Mac 跑大 模型真正的優勢 在 Mac Studio 上 你只要把記憶體選 超過三十六 GB 系統就會自動把你的 GPU 換成貴一階的那顆 頻寬從四百六十跳到六 百一十四,價格多六百美元 這不是加價選配,是你沒得選 規格跟價格我整理成一張表 放在畫面上,你暫停看就好 我不念 這一段如果幫你省掉在購買頁上 來回猜的時間,順手按個讚 讓這支片被更多正 在選機器的人看到 那把前面那兩件事套回 Mac,會是什麼情況 預填充吃算力 而算力一直是 Apple 這幾代的弱點 M1 到 M4 這幾代 只要你輸入的東西一多 光是讀完就要等。 要多久 有數字 有人拿 M3 Ultra 加 五百一十二 GB 記憶體用了 六個月,寫下他的實際體感 簡單對話幾秒鐘就回 這一段你不會有感覺 請它改一篇七千字的文章 等三十秒 掛一個系統提示一萬 六千字的 coding agent ,等九十秒 九十秒。 在那九十秒裡 畫面上什麼都沒有 那台是 M3 Ultra 記憶體頻寬已經是 當時最高的一批 頻寬那麼高為什麼 沒有救到這一段 因為這一段卡的不是頻寬 那 M5 呢 Apple 去年十一月發過 一份研究,拿 M5 對比 M4 等第一個字出現的時間 快了三點三到四倍 這是很大的改進 而且方向對 他們加強的正好是算力 那這個改進是哪裡來的 M5 這一代在每一個 GPU 核心裡面,加了一 個專門算矩陣的單元 叫做神經加速器 Apple 自己的說法是 產生第一個字這 件事被算力綁住 而它完全吃得到神 經加速器的好處 換句話說 你多花的錢買到的算力 全部用在你按下送 出之後那段等待上 有多明顯 有人拿同一台 M5 同一個模型,只切這個開關 讀取的速度從每秒 兩百四十七跳到六 百三十六,兩點五七倍 吐字的速度從二十九點六 到三十一,只有一點零五倍 你注意一下這 兩個數字的差距 同一台機器同一個模型 只換一個開關,一邊跳兩倍半 另一邊幾乎不動 這就是那兩件事 真的分開的證據 那買之前要注意 什麼。 有兩件 第一,這個東西不是只有某一台有 M5,M5 Pro,M5 Max,M5 Ultra 連 M6 都有 所以它不是選型的差別 你買哪一台都吃得到 第二,有這個硬體是 不是就自動用得到。 不是 要 macOS 二十六點二以上 而且軟體要支援才會啟用 但要注意這是 Apple 拿自己比自己 它沒有回答跟 NVIDIA 差多少 那個差距目前只 有上一代的數字 同一個模型同一段輸入 M3 Ultra 要五點 五七秒,NVIDIA 那台小機器一點四七秒 差三點八倍 那 Mac Studio 上面那顆最大的 M5 Ultra 呢 它九月二十二 號才第一次出貨 在那之前 這顆晶片沒有人拿到過 能追上多少 要等出貨之後 才有人測得出來 那另外一半呢 解碼跟頻寬 解碼是一個字一個字產生 每產生一個字 mac都要把整份模型 權重從記憶體讀進晶片一次 所以它被什麼綁住 記憶體頻寬 頻寬翻倍 吐字速度就接近翻倍 所以跑分表上最常看到的那 個數字,每秒幾個 token 在 Mac 上為什麼會很好看 就是這個原因 M5 這一代吐字也有進步 官方的數字是快百 分之十九到二十七 比起預填充那個三到四倍小 很多,但你看跑分表的時候 感覺是很直接的 問題在這裡 你日常真正在做的事 決定你有沒有感覺 你平常是哪一種 如果你只是聊天 問一句答一句 輸入很短輸出很長 那頻寬就是你的體感 數字好看你就真的爽 但 如果你在做 agentic coding ,或者同時開好幾個 代理,情況完全反過來 那種工作是什麼形狀 讀進去一大坨,吐出來一小撮 實測下來 每一輪送進去二十萬 token ,只吐出不到一千個字 這種形狀下 你的時間幾乎全部 花在預填充,不在吐字 頻寬再高也救不了 這樣的體驗將會非常差 你大概率會想要退貨的 那多開幾個代理會怎麼樣 你每開一個子代理 就是一次全新的預填充 開四個就是四次 所以同一台mac 你拿它聊天會覺得很快 拿它跑代理會覺得很慢 兩個感覺都是真的 因為你在用的是 兩個不同的規格 如果你買 Mac 是為 了在本地跑語言模型,有 一類模型特別適合你 叫做 MoE 它的全名是 Mixture of Experts,混合專家 一般的模型裡面 負責運算的那一層只有一組 你每產生一個字 這一組全部都要動一次 MoE 把那一層拆成很多組 常見的是幾十組到幾百組 然後它多了一 個很小的分派器 每產生一個字 分派器決定這次要叫醒 哪幾組,通常只叫兩三組 沒被叫到的那幾百組 這個字完全不參與運算 那沒被叫到的那些呢 它們還是佔著記憶體 沒被叫到不等於不用放進來 那你怎麼看出一個 模型是不是 MoE。 看名字 你會看到兩個數字 像是三十 B,A 三 B 這種寫法 前面那個是總共多大 決定你裝不裝得下 A 後面那個是每次啟用多少 決定你跑起來多快 那這件事為什麼剛 好對 Mac 有用 回想一下前面講的 Mac 的強項是什麼 記憶體大 因為它是統一記憶體 整池都能給模型用 Mac 的弱項是算力比較差 讀你貼進去那一 大段的時候會等 頻寬也不是最頂的 吐字速度有天花板 MoE 要的剛 好是 Mac 有的 它吃記憶體 而記憶體是 Mac 最不缺的東西 MoE 省的剛 好是 Mac 缺的 每次只算兩三組 算力需求變小 要搬的權重也少很多 所以同一台 Mac 跑一個一千一百七 十億參數的 MoE 可以比跑一個七百 億的一般模型還快 這也是為什麼你會看到 有人拿 Mac 跑那些名 字聽起來很誇張的大模型 而且真的跑得動 你在 Mac 上挑模型的時候 名字裡有沒有那個 A 是你第一個要看的東西 有一件事不要算過頭 你不能拿啟用的那 一小塊直接去除頻寬 然後說速度會變幾倍 中間還有挑選專家的成本 那個不是零 說到這裡 規格對應到什麼已經清楚了 那就分成三種人來看 第一種,你的 AI 全部都用雲端的 ChatGPT,Claude,Gemini ,你不打算在自己 mac上跑模型 那這些頻寬跟核心數的差別 對你幾乎沒有意義 十六 GB,二十四 GB 或者三十二 GB 都夠用 那要花多少 八百九十九到一千兩 百九十九美元這一段 M6 的 Mac mini 就可以了 真的要偶爾在本地跑一下 三十二 GB 可以放 Qwen 那個三十 B,A 三 B 總共三百零五億 每次啟用三十三億 四位元之後十八點六 GB 第二種呢 你要剪影片 同時想在本地 跑一些語言模型 這一種的甜蜜點在哪 我認為是 Mac Studio 六十四 GB,三千七百九十九美元 六十四 GB 剛 好讓三百二十億 參數這一級跑得很舒服 七百億也塞得進去 六十四 GB 在 Studio 上必然是四 十核那顆,頻寬六百一十四 你為了容量付的錢 順便買到了最高的頻寬 這一級你能跑哪些 選擇一下子變多 三十幾 B 的 MoE 跑起來都很輕鬆 如果你買到一百二十八 GB 那 gpt-oss-120b 是最好的例子 一千一百七十億總參數 六十二點八 GB 但每次只啟用五十一億 第三種呢 你對本地大模型有很強的 需求,你要跑那種真正大的 那六十四 GB 夠不夠。 不夠 你要看的是二百五十六 GB 甚至五百一十二 GB 的統一記憶體 那個級距只有 Mac Studio 的 M5 Ultra 有 二百五十六 GB 是一 萬零七百九十九美元 為什麼要那麼多 因為真正大的那幾個 開源模型是這個量級 DeepSeek 那個 兩千八百四 十億,四位元要一百五十五 GB 更極端的 Kimi K3 四位 元要一點五一 TB 開源不等於你跑得動 你身邊如果有人也在這幾台之 間猶豫,把這一段轉給他 這三個級距是他要 先搞清楚的東西 五百一十二 GB 那個 版本現在還下不了單 官方說十月下旬才會上市 這一段的價格是跳躍的 不是線性的 從六十四跳到二百五十六 記憶體四倍,價格接近三倍 所以你要先確定你真的 需要跑那麼大的模型 這筆錢才花得下去 前面講的全部是文字模型 那生圖跟生影片呢 這兩件事在 Mac 上是弱的 而且弱的地方不一樣 先講影片 因為想在本地跑 AI 的人 很多是衝著這個來的 而算力,正是前面講的 Apple 這幾代的弱點 而且不只是算力 還有生態 Mac 這邊沒有 TensorRT 那種等級的推論優化 ,PyTorch 的編譯加 速跟 Mac 的後端不相容 ComfyUI 在 Mac 上是能跑的,走的是 PyTorch 的 Metal 後端 但有些運算沒實作 會掉回 CPU 跑 在 CUDA 上是裝好就動 M5 的算力是有改善 同一個 app 生同一段五 秒影片,筆電的 M5 Max 四十核兩分鐘,M3 Ultra 八十核要三分二十六秒 但 ComfyUI 不是 直接吃到這個算力,中間隔 著 PyTorch 的 Metal 後端,M5 新加的 矩陣單元它才剛開始支援 算力本來就是 Mac 的弱項 跟 NVIDIA 比 這一代還是輸 如果這台 Mac 你 本來就要買,它同時是你 的日常機,你的剪接機 你寫程式的機器 那半夜掛著跑 基本上只有電費的錢 但是生成的影片速度非常慢 並且還要考量到不是每一 段影片都是可以用的片段 真正能用的秒數,要再打個折 所以如果你的主要目的是 影片生成,那會建議 還是考慮 NVIDIA 最後有一個做法 你不一定用得到它 但我個人認為這解 決方案非常有趣! 有一個團隊 把一台 NVIDIA 的 DGX SPARK和一台 Mac Studio 接在一起 讓算力強的那台負責讀完 整段,讓頻寬高的那台負責吐字 他們自己測的數字是這樣 同一個模型同一段輸入 Mac 那台讀完花五點 五七秒,吐字零點八五秒 NVIDIA 那台 讀完一點四七秒 吐字二點八七秒 你看這四個數字 兩台各自贏一半 兩台各贏一半 接起來取兩邊快的那一段 總共兩點三二秒 快兩點八倍 這剛好證明了前面那 兩件事真的是分開的 沒有一台機器兩邊都贏 不過這是那個團 隊自己測的數字 而且現階段這個解決方案 一定還有很大的改善空間 即便如此 我還是相信未來會有更多 類似這樣的更好解決方案 讓大家可以自己根據需 求組合對應的硬體規格 最後再收一次 記憶體決定你裝不裝得下 頻寬決定吐字多快 按下任 務送出之後要等多久 你卡在哪一件 你要找的不是最強的那一台 是你自己卡在哪一件事 然後規格表上對應的那一行 生圖的話 我上面已經幫你們算過了 專門買一台不划算 順便用很划算 跑文字模型的話 裝得下是第一關 頻寬是第二關 相信這樣你自 己就挑得出來了 這批機器九月二十二號出貨 到時候會有第一批 真正的實測數字出來 我會回來把這支影片裡所 有還沒有數字的地方填滿 你如果不想錯過那一集 訂閱一下 另外,你現在卡在哪兩個規格之間 或者已經下訂了哪一台 留言告訴我你的用途 我看看能不能幫你判斷 我是路可,讓我們一起踹踹看
本次執行流程與問題處理
下達指令
預期流程
- 採用來源字幕（略過語音辨識）
- 來源選擇與品質檢查
- 文字校正與句子單元
- 筆記與發布
- 公開網頁發布
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（來源選擇報告）
耗時：3.3 秒
關係：依序執行
結果：完成
2. 全文快速校讀
工具：videonote_rapid_transcript_review.py
處理：先速讀完整逐字稿，再修正高可信突兀詞句並列出待確認項目
產出：rapid_transcript_review_report.json（產出檔案）
耗時：41.1 秒
關係：依序執行
結果：完成
3. 建立句子單元
工具：videonote-build-sentence-units
處理：將逐字稿切成帶時間軸的句子單元
產出：sentence_units.json（句子單元）
耗時：0.1 秒
關係：依序執行
結果：完成
4. 時間軸稽核
工具：videonote_timeline_audit.py
處理：檢查時間軸與音訊對齊
產出：timeline_audit_report.json（時間軸稽核）
耗時：0.2 秒
關係：依序執行
結果：完成
5. 品質檢查
工具：videonote_controlled_quality.py（檢查時間軸與品質）
處理：檢查語言、時間軸與可讀性品質
產出：controlled_quality_report.json（品質報告）、language_sanity_report.json（語言檢查）
耗時：0.2 秒
關係：依序執行
結果：完成
6. 播放時間軸回填
工具：videonote_rebase_display_timeline.py
處理：將網頁播放時間軸回填為校正字幕時間
產出：display_timeline_rebase_report.json（時間軸回填報告）
耗時：0.2 秒
關係：依序執行
結果：完成
7. 來源句整理
工具：videonote_prepare_source_entries.py
處理：整理來源句子供時間軸與頁面使用
產出：sentence_units.json（句子單元）
耗時：0.3 秒
關係：依序執行
結果：完成
8. 生成筆記摘要
工具：videonote-generate-note（生成筆記摘要）
處理：生成筆記摘要與重點
產出：note.md（筆記 Markdown）、note.html（筆記 HTML）
耗時：145.4 秒
關係：依序執行
結果：完成
9. 建立筆記頁面
工具：videonote-render-html（產生筆記 HTML）
處理：產生可閱讀的筆記 HTML 頁面
產出：note.html（筆記 HTML）
耗時：0.5 秒
關係：依序執行
結果：完成
10. 發布公開頁面
工具：videonote-publish（發布公開頁面）
處理：發布到公開網站與每日列表
產出：公開筆記網址、result.json（管線結果）
耗時：0.6 秒
關係：依序執行
結果：完成
手動來源字幕
自動來源字幕
Whisper 字幕
- 尚未產生
Qwen 字幕
- 尚未產生
Parakeet 字幕
- 尚未產生
MOSS 字幕
- 尚未產生
聲學時間證據（PyAnnote / WhisperX）
- 尚未產生
校正前後逐字稿
目前待解決問題與初步改善方向
- ⚠️ 全文快速校讀：已套用暫定修正，請確認
segment=75 已先套用暫定修正：一中就是全部重算 → 一種就是全部重算；segment=382 已先套用暫定修正：理由是六十四 GB 剛 → 六十四 GB 剛；segment=386 已先套用暫定修正：而且六十四 GB 在 → 六十四 GB 在；segment=416 已先套用暫定修正：V4 Flash,兩千八百四 → 兩千八百四
- Qwen3-ASR 未完成，需確認 qwen_asr_lab 環境與音訊後重試精進模式。
- 音訊下載不穩定，需更新 cookies / PO token 後重試精進模式。