逐字稿文字預覽
昨天錄了一期關於Deepseek V4.1 Flush發布之後,如何在AMD、英伟達以及蘋果三個小主機之間進行選擇的視頻。 但是剛剛發布就被打了臉,因為Deepseek已經開放了這個V4.1 Flush的這個權重。 那麼它的尺寸已經相比於V4 Flush的話要大大提升。 首先它的總餐從這個V4的284B提升到了748B,就是7480億總餐。 這個是一個非常大的一個模型的,說實話把它叫做Flush都有點誇張了。 這個就再大一點它就破萬億了,就是旗艦模型的配置了。 然後這個模型的權重總體是510G,其中有306G是MOE以及它的主模型權重。 各個專家加起來是306G。然後還有204G是這個英官支持權重。 就這一塊是可以把它放到SSD中去的,如果說利用小核再來部署的話。 那麼由於這個模型本身的變化,首先AMD的小主機就可以被排除在外了。 它是跑不了V4.1 Flush的。 因為它最大的就是192G內存的AI Max 400。 那麼它就已經出局了。當然,AI Max 400像我們上期說的,它這個在本地跑一跑這個V4 Flush。 這還是能玩一玩的,但是它的體驗也不會好到哪去。 然後就是我們在說蘋果。蘋果它也發生了很大的變化。 就是昨天我跟大家說的黃金尺寸的這麼一個M5 Ultra 256G內存的這麼一個機型。 它就瞬間就不像了。因為它只能跑V4 Flush了。 雖然V4 Flush也補足了這個視覺模塊。也是個怎麼說呢?全能的這麼一個六邊形戰士。 就是它用來跑這個V4 Flush的話效果是不錯的。 但是它畢竟未來已經被鎖死了。它跑不了這個什麼V4.1 Flush了。 它以後就沒法升級了,沒法更新了。 當然了,你可以用它來跑這個什麼GLM5.3 Flush之類的300B左右的模型。 這樣也是可以的。這個DeepSig不搞了,GLM以後不代表就不搞了。是吧?但是它畢竟它不能跑最香的模型了。它的價值要大打折扣了。 那麼所以說,你如果是買M5Osh的话,就一步到位上這個512的這個機型。 它就是目前,低表上你能買到的這個內存最大的就個人的這種消費小主機了。 那它做工也好,還是說它的蘋果生態也好,還是說它普達模型的能力也好。 它都是能拿的,就非常的不錯。但是呢,價格就很貴了。就看你的腎夠不夠賣了。你有幾個腎。 當然了,有之前買的一些,比如說買了96G M5Ocha的,或者說買了什麼64G的這個M5MAX的這些小主機的朋友們。 你們就可以幸灾樂禍了。反正你買256G的,你也跑不了V4.1 Flush。是吧?以後DeepSig Flush家族就256G對身,你就跑不了了。 它只會越來越大,不會越來越小的。那麼大家在本地就想跑得舒爽,就只能跑這個什麼青文3.8 27B。 就青文家族的27B模型。未來可能有3.9、4.0、甚至5.0。 那這個模型,阿里巴巴肯定會持續升級的。因為它是本地部署的黃金尺寸的模型。 在這一塊,你無論是M5MAX64G還是M5Ocha96G,它都能跑。當然M5Ocha96G它的體驗肯定要更好一點。 甚至說你同樣是MAX的話,MAX沒有96G,MAX只有128G。128G肯定是要比64G的體驗要更好的。 但是64G的性價比就凸顯了。 因為它畢竟比這個128G版本的MAX要便宜50%。那你已經做出採購選擇的這些兄弟,這些朋友們,你們就可以慶祝了。 就沒有那麼多的遺憾,反正你們256G也跑不了。 所以說這個梁子對於這個開源社區的這個影響還是非常的大的。 但是我們也不得不說DeepSeq的開源確實是路線非常的堅定,意志非常的堅定,沒有藏著藏著藏著。 就連Ingram算法,Ingram架構,這麼它的核心機密,是吧? 它在悶了一段時間之後,還是把它全部開放了。 這真的是非常牛逼,加上它最近開源的DeepSeq Harness。 我可以說DeepSeq已經是毫無疑問的當下的開源AI的王者。 這短短的一個月,梁子就通過G-R03的操作奠定了開源王者的地位。 阿里巴巴可以說通過這個本地的切換小模型,還能跟梁子再標一標,但是已經基本上是出局了。 就說以後你說開源AI的基礎設施是誰?那就是DeepSeq。這個應該是沒有什麼爭論了。 當然我相信目前收益最大的還是老黃這個肩商。 首先說在這個企業市場,大家都知道它的這個什麼NVFPS加上FP吧? 就是DeepSeq、弗拉希家族的這個默認的這個標準模型權重。 就是這個DeepSeq目前雖然採購了大量的這個華為生存機群,包括950PR和950DT。 950DT據說一次已經買了16萬張。 那它以後肯定是要把這個華為當作主要的生態。 是吧?那麼英伟達無論如何,它作為世界標準,它跟華為是並列的。 DeepSeq不管是發布什麼模型權重,它肯定能在這個英伟達的這個群群上跑起來。 否則它就失去了作為全世界通用的開源AI基礎設施的意義。 那其他的像AMD、蘋果啊,這些你等這個DeepSeq官方把模型權重放出來之後,社區也好,還是你們企業去組織人也好,你們想辦法把它跑起來。 那就不是良子關心的事情了。 以前在這個V4Flash時代,那麼兩個盒子,就是兩個128級綠存的拼凑起256級綠存,那麼就可以跑這個V4Flash了。 現在呢,它由於這個MOE,這個包括說這個模型的這個核心權重,一共是306級。 那麼它可能說兩個就不夠了,就需要三個。 哎,加一個之後,就剛好這個DGX Spark本身就支持三個或者四個互聯。 應該說你不超過四個的情況下,它還是一個黃金的甜點置存,就它的互聯的效率不會打什麼折扣。 就總體ITM是不會差的。 然後三個盒子,你一共是384級的統一綠存。 那麼這個384級的這個統一綠存呢,我們來給它簡單分配一下。 就是說你系統本身,因為跑的都是Linux嘛,你占幾個G就夠了。 可能說再加上框架開銷,我們總體上給它扣除24個G吧。 然後你還剩下360個G,是吧。 那麼360個G,你減去這個什麼306G,你還剩下54個G。 這54個G的這個什麼性存,這個統一綠存就足夠你去跑長生雅文多開繪畫了。 因爲什麼?因為這個DBC它這次技術又有了重大的進步。 它這個官方公布的文檔是,對於這個什麼顯存的需求降低到了以前的什麼六分之一,對於什麼SSD的需求降低到以前的八分之一。 這個當然我不知道是已經優化過之後,需要這麼多資源。 還是說在現有的這個什麼三台小盒子的資源之下,它能夠深度的優化。 反正肯定是夠的,三個小盒子是夠的。 並且,你以前如果是買了一台DGX Spark,是吧。你買兩台就能跑這個V4弗拉奇。 買三台就能跑V4.1弗拉奇。 這是一個平滑過渡的這麼一個流程。 將來如果是有一天,你什麼4.2或者5.0的弗拉奇。 它的尺寸又增加了。那麼你再買一個小盒子。 四個盒子基本上就是,英偉達的這個小肌群的這個極限了。 再高它可能通信效率就不高了。 這麼看來的話,你要想在本地部署AI玩的比較舒爽。 那麼老黃的盒子可以說是當仁不讓了。 而且老黃的盒子是把所有的特性都給它做滿了的。 它不像蘋果,不像這個什麼AMD。 它是自己就是這個原生支持NVFP4,支持FP8推理。 這個是全內路的。 大家呢,我在評論區也看到了一些比較積極的消息。 我上網也查了一下,這些事情呢,有可能是謠言。 但是有更大的可能呢,是說會成為現實。 就是中國有不少企業也在準備出這個AI小盒子。 也傳說什麼華為小米這些企業都在準備搞。 哎,我覺得像阿里巴巴這些企業你都可以搞啊。 像什麼海武G是吧。 你們不要光想著去賣這個服務器去賣給這些企業客戶。 你們也把我們這些個人開發的中小團隊,是吧。 我們這些技術屌絲給這個照顧一下。 你們的小盒子如果真的能跑DipSig,威斯芙拉吉,跑起來的這個速度還不錯,效率還不錯。 是吧。再能偶爾玩一玩這個什麼ComphiUI。 那這個小盒子就非常有性價比,我們是不願意花錢買的。 你說你這個國產的這個硬件生態,你想要這個打開市場,是吧。 想要這個繁榮生態。 你這個時候不下手,那什麼時候下手。 都跟他們AMD和英特爾去學。 是吧。打生態的時候看不到他們。 老黃賺的錢呢,就後著臉皮擠進來,要分一杯跟。 你說你們不被老黃吊打,誰被老黃吊打。 是吧。 我們到現在被老黃這個肩上左一刀右一刀割的。 說白了就是因為你們其他的硬件廠商不爭氣。 你們但凡給老黃增加一點壓力,他都不敢把卡賣的這麼貴。 好吧,有點牢騷多了啊。 這個悠感阿發。 本期視頻就到這裡,有什麼新的消息啊。 包括說我在視頻中有哪些錯誤,大家可以這個激激的指出。 是吧。歡迎你到論壇,發帖跟我交流討論。 打臉也可以。 是不是。 但是一定要奔著討論事情,討論技術,來。 不要陰陽怪氣。 陰陽怪氣,我這個人對你就是上去就是一耳光,知道嗎。 是個山野村父,非常的野蠻,非常的暴力。 好吧,我們下期視頻再見。
本次執行流程與問題處理
下達指令
預期流程
- 下載與語音辨識
- 來源選擇與品質檢查
- 文字校正與句子單元
- 筆記與發布
- 公開網頁發布
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（來源選擇報告）
耗時：26.3 秒
關係：依序執行
結果：完成
2. 全文快速校讀
工具：videonote_rapid_transcript_review.py
處理：先速讀完整逐字稿，再修正高可信突兀詞句並列出待確認項目
產出：rapid_transcript_review_report.json（產出檔案）
耗時：40.7 秒
關係：依序執行
結果：完成
3. 建立句子單元
工具：videonote-build-sentence-units
處理：將逐字稿切成帶時間軸的句子單元
產出：sentence_units.json（句子單元）
耗時：0.8 秒
關係：依序執行
結果：完成
4. 句子密度平衡
工具：videonote_balance_sentence_units.py
處理：平衡句子長度與密度
產出：sentence_units.json（句子單元）
耗時：0.8 秒
關係：依序執行
結果：完成
5. 時間軸稽核
工具：videonote_timeline_audit.py
處理：檢查時間軸與音訊對齊
產出：timeline_audit_report.json（時間軸稽核）
耗時：0.8 秒
關係：依序執行
結果：完成
6. 品質檢查
工具：videonote_controlled_quality.py（檢查時間軸與品質）
處理：檢查語言、時間軸與可讀性品質
產出：controlled_quality_report.json（品質報告）、language_sanity_report.json（語言檢查）
耗時：0.9 秒
關係：依序執行
結果：完成
7. 播放時間軸回填
工具：videonote_rebase_display_timeline.py
處理：將網頁播放時間軸回填為校正字幕時間
產出：display_timeline_rebase_report.json（時間軸回填報告）
耗時：0.9 秒
關係：依序執行
結果：完成
8. 逐字稿交叉檢查
工具：videonote_cross_check_transcript.py
處理：交叉檢查逐字稿與來源字幕
產出：transcript_crosscheck_report.json（交叉檢查）
耗時：0.9 秒
關係：依序執行
結果：完成
9. 來源句整理
工具：videonote_prepare_source_entries.py
處理：整理來源句子供時間軸與頁面使用
產出：sentence_units.json（句子單元）
耗時：1.0 秒
關係：依序執行
結果：完成
10. 生成筆記摘要
工具：videonote-generate-note（生成筆記摘要）
處理：生成筆記摘要與重點
產出：note.md（筆記 Markdown）、note.html（筆記 HTML）
耗時：132.4 秒
關係：依序執行
結果：完成
11. 建立筆記頁面
工具：videonote-render-html（產生筆記 HTML）
處理：產生可閱讀的筆記 HTML 頁面
產出：note.html（筆記 HTML）
耗時：0.4 秒
關係：依序執行
結果：完成
12. 發布公開頁面
工具：videonote-publish（發布公開頁面）
處理：發布到公開網站與每日列表
產出：公開筆記網址、result.json（管線結果）
耗時：0.5 秒
關係：依序執行
結果：完成
手動來源字幕
- 尚未產生
自動來源字幕
Whisper 字幕
Qwen 字幕
- 尚未產生
Parakeet 字幕
- 尚未產生
MOSS 字幕
- 尚未產生
聲學時間證據（PyAnnote / WhisperX）
- 尚未產生
校正前後逐字稿
- 校正前 transcript.whisper.json 純文字 JSON
- 校正後 transcript.json 純文字 JSON
目前待解決問題與初步改善方向
- 逐字稿全文快速校讀未完成
已保留自動字幕/原始逐字稿並繼續生成筆記。；未完成的全文速讀項目可在精進模式回聽確認。；RAPID_REVIEW_STATUS=REVIEW_REQUIRED_INVALID_OUTPUT
- 逐字稿可先使用，但有待校正清單
segment=1 unnatural_sentence_boundary: 標點出現在句首或停在逗號位置，斷句可能不符合文法/口語；segment=105 unnatural_sentence_boundary: 標點出現在句首或停在逗號位置，斷句可能不符合文法/口語
- Qwen3-ASR 未完成，需確認 qwen_asr_lab 環境與音訊後重試精進模式。