工作清單

Qwen's 27B Model Is Now An 11.8GB Download

逐字稿文字預覽

Quen's 27 billion parameter model reads images and text. And the lab behind most local model
compression just shrank it into a single 11.8 GB file. A model that size normally needs more memory
than any gaming computer has. This one is smaller than a video game install. Needless to say,
this is a seriously impressive demonstration of model compression. But the question must be asked,
can a 12 GBTE graphics card actually run Quen's 27 billion parameter model? To find out,
we have to look at the repository where we see that the download page doesn't actually offer
a single file, but a menu of four different sizes shipped two ways for a total of eight
model files. That 11.8 GB model from our title is the largest of the plane options, which the
lab recommends as its task lossless build. But sitting right beside those models is a ninth file,
a 0.93 GBTE vision projector called MM Proj. None of the eight main checkpoints actually contain
this vision projector, which means you have to get it separately if you want to use the model's
multimodal capabilities. On paper, the 11.8 GB of the GSQ RCO build and the 12 GB of your graphics
card sit right next to each other. But those two numbers are actually measured in entirely
different units. When a card is sold as having 12 GB of memory, the operating system actually
counts that space in binary gigabytes, which is what your hardware actually has to work with. On
the other side of the ledger, that recommended GSQ RCO build is listed on HuggingFace at 11.77 GB.
But when you inspect the actual weights of that GSQ RCO build, they only take up 10.96 GB of space
because the download page is using decimal GB. If you subtract 10.96 from your 12 GB of capacity,
you are left with 1.04 GB of free space, that means the actual headroom on your card is larger
than the 200 megabytes the headline number suggested. But that extra headroom is about
to vanish because the model's ability to read images is stored in a completely separate file
called mm praj, which weighs 931 million bytes or 0.87 GB. And in a release designed entirely around
model compression, this vision projector is the only file that wasn't compressed at all. Instead,
the lab left it at its original 16-bit format. And because one copy serves every single build
on the menu, this memory penalty is exactly the same whether you pick the largest budget
or the smallest. In llama.cpp, you load this projector using a separate command line flag,
which makes it easy to forget that it's even there. But once it loads, 0.8 87 GB of the 1.04 we
just found is instantly gone. This means the part of the model the title sells, the system that lets
it read images, is the one part the compression never touched, and it eats almost all of the
headroom your card has left. The quantization paper behind this build splits the field of
model compression into simple scalar methods like GPTQ and AWQ that everyone deploys and vector or
trellis methods like Q-tip and AQLM that score better. In the paper's own words, scalar methods
plateau in accuracy at 3 to four bits, while the more accurate vector family is notoriously
hard to implement and scale. So GSQ closes most of that accuracy gap while staying on a scalar grid,
ensuring the compressed model remains fully compatible with the existing scalar inference
kernels we already run on our cards. It turns out the same lab published GPTQ, which is one of the
standard methods GSQ measures itself against. On top of that, GSQ can be applied directly to an
existing GGUF release you already have, improving its accuracy and exporting it right back into the
exact same format. This file runs in your everyday apps like Llama.cpp, Olama, and LM Studio without
modifying any of them. And that's not luck. It happens because the lab deliberately chose the
family of methods that scores worse in order to stay inside a format the existing software already
reads. Compressing a single tensor doesn't build a whole file because you still have to
decide how much compression to apply to each part of the model to fit your hardware. To solve that,
Michael Hellig and Dan Allistar published a second paper titled Model Compression with Exact Budget
Constraints, framing the problem as assigning one of several options to each group under a
total cost budget. While penalty-based approaches only enforce a budget approximately and require
extensive hyperparameter tuning, this method meets it exactly without any constraintspecific tuning.
Relaxing the budget constraint describes a smooth curved surface called a remmanion manifold in
lojit space allowing a gradient method to walk along it without ever leaving it. The procedure
takes three steps. You quantize every tensor into every candidate format, search for the assignment
that meets your budget and stitch those winners into one ordinary file. And that means you can
spend your memory budget down to the last bite, which is exactly the problem you face when trying
to squeeze a 27 billion parameter model onto a 12 GB card. You don't even have to download the model
to see what that search algorithm decided because the lab published the entire decision list as a
plain text file. Inside the recommended build, the search algorithm ended up slicing 851 individual
tensors across 11 different storage formats. It left 96 tensors at full 16-bit precision
while dropping the rest into a staircase of smaller quantization formats. For instance,
the search assigned 144 tensors to the IQ3S format. And the measured average lands right
on the lab's 3.5 target, but non-uniform is not just a marketing word, and the search isn't afraid
to starve a single component if it means saving the rest of the network. In the published dump,
block 13's feed forward gate is squeezed down to a starved format called IQ1M, running on just 1 and
3/4 bits. That single tensor isn't surrounded by full precision. It sits inside a block whose other
matrices were all given 2, 3, and 4bit formats. It's simply the

來源：transcript.txt

本次執行流程與問題處理

  1. 下達指令

    指令：videonote https://www.youtube.com/watch?v=iia8G9HFVww --language en --bilingual --learning --adopt-source-subtitles

    來源：https://www.youtube.com/watch?v=iia8G9HFVww

    辨識語言：en ｜ 參數：--language en --bilingual --learning --adopt-source-subtitles

  2. 預期流程

    依指令產生的處理順序：

    1. 採用來源字幕（略過語音辨識）
    2. 來源選擇與品質檢查
    3. 文字校正與句子單元
    4. 雙語翻譯
    5. 雙語時間軸與學習單元
    6. 筆記與發布
    7. 公開網頁發布

  3. 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.8 秒

    關係：依序執行

    結果：完成

  4. 2. 全文快速校讀

    工具：videonote_rapid_transcript_review.py

    處理：先速讀完整逐字稿，再修正高可信突兀詞句並列出待確認項目

    產出：rapid_transcript_review_report.json（產出檔案）

    耗時：44.9 秒

    關係：依序執行

    結果：完成

  5. 3. 建立句子單元

    工具：videonote-build-sentence-units

    處理：將逐字稿切成帶時間軸的句子單元

    產出：sentence_units.json（句子單元）

    耗時：1.0 秒

    關係：依序執行

    結果：完成

  6. 4. 時間軸稽核

    工具：videonote_timeline_audit.py

    處理：檢查時間軸與音訊對齊

    產出：timeline_audit_report.json（時間軸稽核）

    耗時：1.0 秒

    關係：依序執行

    結果：完成

  7. 5. 品質檢查

    工具：videonote_controlled_quality.py（檢查時間軸與品質）

    處理：檢查語言、時間軸與可讀性品質

    產出：controlled_quality_report.json（品質報告）、language_sanity_report.json（語言檢查）

    耗時：0.1 秒

    關係：依序執行

    結果：完成

  8. 6. 播放時間軸回填

    工具：videonote_rebase_display_timeline.py

    處理：將網頁播放時間軸回填為校正字幕時間

    產出：display_timeline_rebase_report.json（時間軸回填報告）

    耗時：0.1 秒

    關係：依序執行

    結果：完成

  9. 7. 雙語翻譯

    工具：vnt-sentence（句子雙語翻譯）

    處理：將句子翻譯成繁體中文

    產出：sentence_bilingual_transcript.json（雙語逐字稿）

    耗時：110.6 秒

    關係：依序執行

    結果：完成

  10. 8. 雙語時間軸與學習單元

    工具：videonote_learning_timeline_v2.py（建立雙語時間軸與學習單元）

    處理：建立雙語時間軸與學習內容

    產出：sentence_bilingual_timeline.html（雙語時間軸頁）、learning.json（學習單元）、japanese_learning.json（日文學習單元）

    耗時：312.6 秒

    關係：依序執行

    結果：失敗

    問題：exit code 1

  11. 9. 生成筆記摘要

    工具：videonote-generate-note（生成筆記摘要）

    處理：生成筆記摘要與重點

    產出：note.md（筆記 Markdown）、note.html（筆記 HTML）

    耗時：216.6 秒

    關係：依序執行

    結果：完成

  12. 10. 建立筆記頁面

    工具：videonote-render-html（產生筆記 HTML）

    處理：產生可閱讀的筆記 HTML 頁面

    產出：note.html（筆記 HTML）

    耗時：0.7 秒

    關係：依序執行

    結果：完成

  13. 11. 發布公開頁面

    工具：videonote-publish（發布公開頁面）

    處理：發布到公開網站與每日列表

    產出：公開筆記網址、result.json（管線結果）

    耗時：0.8 秒

    關係：依序執行

    結果：完成

手動來源字幕

自動來源字幕

Whisper 字幕

Qwen 字幕

Parakeet 字幕

MOSS 字幕

聲學時間證據（PyAnnote / WhisperX）

校正前後逐字稿

目前待解決問題與初步改善方向

進一步精進字幕與筆記
使用 Workbench 上傳校正字幕、中文參考稿或回饋 SRT，重新產生雙語與學習單元。
開啟 Workbench