InferNews

Hojo TTS Light 輕量語音合成，4000 萬參數就做到 15 種聲線

Share to X

Hojo-TTS-Light 僅約 0.08B 參數，以 ONNX 格式在 CPU 即時合成 24 kHz 語音，並預載 15 種聲線，免依賴 PyTorch。

Og image

想把文字轉語音（TTS）嵌入邊緣裝置或本地腳本，最大阻力往往來自 PyTorch 依賴肥大、GPU 門檻高。Hojo-TTS-Light 直接以 ONNX Runtime 執行，連 PyTorch 都不用安裝，對只有 CPU 或資源受限的環境相當友善。模型檔約 4000 萬參數（0.08B），輸出 24 kHz 音訊，並內建 15 種預設說話人聲線，開發者只需切換 embedding 即可換聲，省下自行收集語料或微調的工序。

隨倉提供的 infer.py 與 onnx_model.py 展示完整推理流程，搭配 requirements.txt 即可用幾行程式碼完成合成。對需要快速在本地或伺服器側加入語音回饋的項目而言，這種「開箱即播」的設計，比傳統 TTS pipeline 更貼近部署需求。

不過，15 種聲線屬於 preset 性質，若要新增自訂說話人，就需要額外準備參考音訊與對應 embedding，無法像大型 TTS 模型那樣靠一句話克隆。整體取向偏向「輕量、即用」，而非追求擬真度或表現力。

重點摘要：

  • 參數量約 0.08B，屬輕量級 TTS 模型
  • 採用 ONNX 格式，免安裝 PyTorch 即可在 CPU 環境執行
  • 預載 15 種 speaker-conditioned 聲線，可即時切換
  • 隨附 infer.py、onnx_model.py、requirements.txt，方便快速整合
  • 發佈平台為 Hugging Face，授權與權重可至該頁查閱

適合需要把語音合成嵌進邊緣裝置、CLI 工具或本地自動化流程的開發者；對追求高擬真或自訂聲線克隆的場景，則需要再評估擴充成本。

項目主頁

Categories: 開源, 文字轉語音, Agentic, Embedding, 模型, Audio, 語音, Skill 技能

Hojo-ASR-Multi-V1：廣東話語音識別引擎

Share to X

基於 Qwen3-4B-Instruct-2507 微調而成的多語言語音辨識模型，覆蓋歐亞九種語言，嘈雜環境與口語修正都有對應訓練。

Og image

如果你聽過一段嘈雜環境裡帶口音嘅外語對話，想即時轉成文字，Hojo-ASR-Multi-V1 就係針對呢類場景設計嘅。它並非由零訓練嘅語音模型，而係喺 Qwen/Qwen3-4B-Instruct-2507 之上做微調，把語音編碼器接駁到大語言模型嘅解碼端，形成 Encoder-Adapter-LLM 嘅典型結構，再加入多幀聲學融合模組去保留細粒度嘅聲音特徵。訓練過程分階段進行並結合強化學習，所以喺噪音、非標準發音、講錯即改口呢類真實情境下都唔會輕易崩潰。

多語言覆蓋係佢最突出嘅賣點。官方公布支援德、法、西、葡、意、日、阿拉伯、韓、俄等九種主要語言，並加入咗普通話、英語、廣東話同四川話等方言支援。從公開評測結果睇，佢喺多個 CoVoST、MLS 同 FLEURS 基準上都錄得相當低嘅 WER，例如意大利 FLEURS 2.30、法語 MLS 2.95、德語 CoVoST 3.85，整體表現平穩。

喺使用層面，開發者可以透過 PyPI 上嘅 hojo-asr 套件快速部署，亦支援 Hugging Face Transformers 後端。HOJO_ASR.load_model 介面可以直接接收 wav 檔案路徑、scp 清單或原始音訊 bytes，配合 CUDA 設備做批次推論。授權用 Apache-2.0，並提供商業整合支援，方便團隊接入產品線。

由於佢建基於 Qwen3-4B 體量，運行門檻比傳統大型 ASR 親民得多，但仍然需要 GPU 推論以維持批次速度。

重點摘要：

  • 基礎模型：以 Qwen/Qwen3-4B-Instruct-2507 為骨幹，採用 Encoder-Adapter-LLM 架構
  • 語言覆蓋：歐亞九國主要語言，加普通話、英語、廣東話、四川話
  • 訓練方式：多階段模組化訓練結合強化學習，針對噪音同口語修正優化
  • 評測表現：CoVoST、MLS、FLEURS 多語言 WER 普遍處於 2–5 區間
  • 部署方式：pip install hojo-asr 後用 HOJO_ASR.load_model 載入，支援檔案路徑、scp 或 bytes 輸入

需要留意嘅係，頁面並未提供 GGUF 量化檔案或本地推論引擎資訊，目前主要以 transformers 後端配合 GPU 運行；如果你想喺純 CPU 或邊緣裝置上使用，就要留意後續會唔會補上量化版本。

項目主頁

Categories: 開源, 模型, Qwen, Audio, 庫, 語音, Dataset 數據集, 廣東話

Fizgig：免重訓練逐塊修 LoRA，仲可以當遊戲咁變體

Share to X

你試過 train 好個 LoRA 先發現風格走晒樣、身份感 overbaked 嗎？Fizgig 畀你逐個 block 拉 slider 救返，仲可以一鍵部署上 RunPod，免安裝。

Fizgig LoRA Studio — watch the full video tutorial

對成日同 LoRA 打交道嘅創作者來講，最痛苦嘅唔係訓練，而係訓練完之後先發現結果唔啱用。Fizgig 就係針對呢個痛點而嚟：佢係一個圍繞 Flux 2 Klein 9B、Krea 2 同 MiniMax H3 嘅 LoRA 工作台，聲稱可以喺 16 GB 顯示卡起跳，由普通 LoRA 一直玩到全模型微調都搞得掂。

佢最實用嘅功能叫做「LoRA surgery」：當你發現某個 LoRA 身份感太重、風格被壓扁，可以逐個 block 拉 slider 去修正，唔使重新訓練，直接輸出新嘅 .safetensors。對應到 MiniMax H3 影片 LoRA，仲可以逐 block 預覽每段對動作、面孔同聲音嘅影響，22 格短片連音效並排播俾你揀。

Minimax H3 - Edit your LoRAs directly with Video Previews

如果你鍾意試新變體，Fizgig 提供類似遊戲化嘅 mutation 流程：應用程式提出變化，你揀鍾意嘅，LoRA 就透過選擇演化落去。配合 LoRA Royale，你可以一次過睇晒成個訓練 run 每個 epoch 嘅效果，或者用 crossfade 喺唔同版本之間游走。LoRA Royale 仲可以直接輸出 MP4 或 GIF 格式嘅循環動畫，方便分享成果。

佢支援標準 LoRA、LoKR 甚至全模型微調，完成嘅 fine-tune 會變成普通 checkpoint，而 Checkpoint to LoRA 功能可以將任何 fine-tune 蒸餾返做可分享嘅 LoRA，揀你鍾意嘅 rank。對於冇 GPU 嘅人，官方提供 RunPod 一鍵部署連結，唔使本地安裝就得用到 24 GB 卡嘅 int8 設定。

重點摘要：

  • 逐 block 修復 LoRA：slider 直接調，唔使重訓練，解決 overbaked identity 同風格崩塌
  • 遊戲化變體探索：app 提議 mutation，用戶揀最愛，LoRA 經選擇演化
  • LoRA Royale 視覺化：一次過 render 晒每個 epoch，crossfade 揀最好嗰個，仲可以輸出分享用動畫
  • Block profiling：清楚顯示每個 block 揹住身份、風格定係細節，調之前先知邊度落手
  • 多模型支援：Flux 2 Klein 9B、Krea 2、MiniMax H3 三線齊，由照片、影片到聲音都覆蓋

GitHub

Categories: 開源, ComfyUI, AI productions, Video, MiniMax

VDN-H3 開源：14 秒 MiniMax 影片生成只花 11 秒

Share to X

OpenVDN 團隊將 softmax 與線性注意力混合架構(hybrid attention)套用到 MiniMax H3 影片生成模型，在 8 張 B200 上以 8 步去噪產出 14.4 秒 768p 影片，速度比播放還快。

Repository image for OpenVDN/vdn-minimax-h3

影片生成最貴的部分往往不是參數量，而是長序列上的 softmax attention。VDN-H3 針對這個痛點，把 MiniMax H3 骨幹拆成兩條互補分支：滑窗 softmax 負責鄰近幀之間的精細對齊，線性注意力則接手長距離語境與主體一致性，並用 4 向邊界錨點補強全域結構。最終在 8 張 NVIDIA B200 上，用 8 步去噪就能在 11.23 秒內生成 14.4 秒 768p 片段，生成速度比播放還快。

與同類做法的差異在於「近乎無損」這個定位。純線性注意力雖然快，但長序列下容易丟失主體身份、場景佈局與時序依賴；VDN-H3 透過混合架構把這部分成本交回給局部 softmax，線性分支只負責長程記憶，因此視覺品質與原版 H3 幾乎難以區分，也比 MiniMax FastH3 有更好的指令跟隨能力。對需要高吞吐量同時不犧牲一致性的團隊，這個取捨相當實用。

部署面需要 PyTorch 2.13、CUDA 12.9 與 FlashAttention 4（含 nvidia-cutlass-dsl 預釋版依賴），另外還要安裝一份修補過的 Diffusers；骨幹權重不需更動，兩條 LoRA adapter 可在推理時合併進去，等同 plug-and-play 替換。程式碼、訓練流程與優化後的推理 stack 一併開源，研究者與影片生成產品團隊都能直接複用。

重點摘要

  • 8 步去噪、8 張 B200，11.23 秒生成 14.4 秒 768p 影片，生成快過播放。
  • 混合 attention：滑窗 softmax 保留局部細節，線性分支負責長距離語境。
  • 視覺品質與原版 MiniMax H3 近乎無損，比 FastH3 指令跟隨更佳。
  • LoRA adapter 可合併進骨幹推理，不需更動原始權重。
  • 權重、推理 stack 與訓練程式碼同步開源。

項目主頁 · GitHub · 模型· ComfyUI 節點

Categories: 開源, AI productions, 視覺模型, 多模態模型, 視頻模型, NVIDIA, Video, Python, MiniMax

MiniMax-H3-Motion-Director 全能導演台節點

Share to X

ComfyUI 自訂節點 Motion Director 將 T2V、I2V、V2V 等多段生成整合到同一介面，支援分鏡重跑、跨鏡頭連貫與即時預覽，讓多片段 AI 影片製作不再被節點海淹沒。

MiniMax H3 Motion Director — Mixed Mode

用 ComfyUI 砌 AI 影片嘅朋友，多數都經歷過呢個困局：想做一個有五個鏡頭嘅項目，要由零開始接 T2V、I2V、V2V 各種 workflow，每段調好參數再串埋，節點一多就連自己都搞唔清邊段行緊、邊段要重做。Motion Director 想處理嘅就係呢個問題——佢係一個 ComfyUI 自訂節點，把多段影片生成收納到同一個 Director 介面，等你可以逐段揀唔同生成方法（T2V / I2V / FL2V / R2V / V2V / RV2V），又唔使為咗切換而重新拉整個圖。

佢同一般 ComfyUI 工作流最大嘅分別，係圍繞「項目」做設計。Director 介面入面有 Segment、Multi Segment、Final Result 三層檢視，亦有 Director Live Preview 即時顯示邊段行緊、邊段做完。跨段連貫靠 Motion Context、Context Frames、Latent Scale Lock 同生成音訊接續，仲可以將上一段已解碼嘅幀直接當下一段嘅 I2V／FL2V 輸入，避免每次都重新生成首幀。素材方面提供 Common References 同持久化 Material Library，圖、音、影片、提示詞都可以重複用。

另一個貼地嘅設計係 Selective Run——只要揀要重做嘅片段就得，唔使成條 pipeline 重跑，配合 MIXED 模式用，可以幾段文生、幾段圖生、幾段源影片剪輯混埋做項目。Director 本身係 OUTPUT_NODE，最尾嗰格就可以輸出畫面、音訊同 FPS 畀下游 ComfyUI 節點繼續接。後製方面內置 Global Refine、放大、可揀 NVIDIA RTX VSR / Deblur 同 Face Refine，不過 VSR／Deblur 要相容 NVIDIA VFX runtime，Face Refine 要 UI 揀好對應 detector／SAM 路徑。

適合要處理多鏡頭、有分鏡表、要保持視覺同音訊一致嘅創作者，例如廣告原型、MV 概念、敘事短片預覽，或者要把源影片做局部 V2V／RV2V 修補嘅後期流程。生成方面支援內建 sampling 或外部 ComfyUI SAMPLER + SIGMAS，方便想自己控制 noise schedule 嘅人。版本去到 v1.2.0，採用 GPL-3.0；硬件門檻就睇你揀嘅功能——基本生成跟返 ComfyUI 一般配置，想用 VSR／Deblur 或大尺寸放大就要 NVIDIA 顯卡同對應 runtime。

重點摘要：

  • 多段整合 Director 介面：T2V／I2V／FL2V／R2V／V2V／RV2V 同一畫面揀，逐段切換唔使重拉 workflow
  • Selective Run + Mixed Mode：只重跑指定片段，唔使成條 pipeline 由頭嚟
  • 跨鏡頭連貫：Motion Context、Context Frames、Latent Scale Lock 同音訊接續，仲可以重用上一段解碼幀
  • 內建 Live Preview 與三層檢視：Director 介面直接睇 Segment／Multi Segment／Final Result
  • 後製選項齊全：Global Refine、放大、可選 RTX VSR／Deblur 與 Face Refine，對硬件有特定要求

GitHub

Categories: 開源, ComfyUI, AI productions, NVIDIA, Video, 框架, 庫, MiniMax

Qwen-Audio Realtime API 上線：以 WebSocket 即時串接語音對話

Share to X

阿里巴巴雲 Model Studio 推出 Qwen-Audio Realtime API，用 WebSocket 串流處理語音輸入與輸出，支援 VAD 偵測與雙向文字回傳，適合即時語音助理開發。

Og image

想在應用程式裡加入即時語音對話，但又不想自己串接一堆音訊前處理、ASR、TTS 的流程？阿里巴巴雲 Model Studio 這次直接把 Qwen-Audio 做成可即時呼叫的 Realtime API，開發者只要透過 WebSocket 連線，就能處理語音輸入、文字輸入，並即時收到串流音訊與文字回應。

這個 API 的設計重點在於「一條連線做完整件事」。客戶端與伺服器以 JSON 事件雙向溝通，支援語音活動偵測（VAD），讓系統知道用戶何時開始與結束說話，省去自行判斷靜音的麻煩。對話中的每一則訊息會以 conversation item 形式保存，整個 session（即一條 WebSocket 連線）則負責維護設定與上下文狀態。

服務端點分為中國（北京）與新加坡兩個區域，皆已改用 workspace-specific 專屬網域，官方表示穩定度與推論表現都比原本的共用網域更好。連線時需使用 wss:// 協定，並在 request header 帶上 Authorization: Bearer <your_api_key>，API key 會在 WebSocket 握手階段驗證，若無效會直接回 HTTP 401/403。

若你的項目是語音助理、即時翻譯、客服 robot 或電話自動化，會感受到整合成本明顯降低——不用分別串 ASR、LLM、TTS，只要管理好 WebSocket 的事件流即可。舊網域雖然仍可用，但官方強烈建議遷移至新網域以取得更佳體驗。

重點摘要

  • 即時雙向串流：WebSocket 連線同時處理音訊輸入與串流輸出，搭配 VAD 自動偵測語音起止。
  • JSON 事件溝通：所有互動以結構化事件傳遞，方便除錯與日誌記錄。
  • 雙區域專屬網域：中國（北京）與新加坡皆提供 workspace-specific 端點，穩定度與推論表現提升。
  • 簡化整合流程：免去自行串接 ASR、LLM、TTS 的負擔，適合快速建構語音應用。
  • 原有網域仍可用：但官方建議盡快遷移以享受新網域的效能改善。

項目主頁

Categories: 阿里巴巴, 文字轉語音, Qwen, API, Audio, Robotic, 語音, 中國

ComfyUI-CGlide：MiniMax H3 短片創作者的自訂節點

Share to X

這是一套給 ComfyUI 用的 MiniMax H3 影片生成自訂節點，把提示詞拼裝、即時預覽、寫檔與續接四步壓成四個節點，特別適合用 H3 拍短片的人。

Repository image for CGlide/ComfyUI-CGlide

想做 H3 短片但不想在 ComfyUI 裡堆十幾個 loaders 同 text box 嘅人，可以留意 CGlide 嘅呢套自訂節點。佢將成個 H3 影片生成流程拆成四個節點：拼裝 prompt 同 conditioning、邊取樣邊預覽當下鏡頭、寫出影片檔，以及將續寫片段接返去原本嘅 clip。H3 Studio 更加將九張圖、三段影片、三段聲音同 prompt 全部塞入一個面板，但保留原本嘅 sampler 同步數，唔會插手推 sampling。

安裝好簡單，喺 ComfyUI Manager 搵 CGlide 或者 git clone 入 custom_nodes就得，不過官方提醒 ComfyUI 一定要更新，因為低 VRAM 嘅 w4a8 路徑要 0.31.0 或以上，否則會出黑畫面有聲冇畫，唔彈 error。模型要從 Comfy-Org 嘅 MiniMax H3 repo 拎，reference-to-video 或 first-last-frame checkpoint 入 diffusion_models，text encoder 入 text_encoders，影片同音訊 VAE 就擺去 vae。VRAM 唔夠嘅話可以用 Kijai 嘅 w4a8 版同 int8_convrot video VAE，大約 11.8 GB 就推到，原 workflow 唔使改。

H3 Studio: prompts, projects and clip extension for MiniMax H3

呢套節點嘅 chain 機制用 source_video 同 guide_frames 兩個輸出做接駁，比較啱做有連貫性嘅敘事短片，作者就用呢套工具完成咗 THE RECITATION。PyAV、torchaudio 同 ffmpeg 屬於依賴項目，PyAV 多數已經裝好，ffmpeg 放上 PATH 就夠，Glide Video 內部會 shell out 畀佢用。

對習慣 ComfyUI 節點工作流、又想用 H3 拍短片或敘事片段嘅創作者嚟講，呢套節點減少咗重複接線嘅時間，亦令低顯存方案更易落地。

重點摘要：
– 四節點設計：拼 prompt、即時預覽、寫檔、續接，分工清晰。
– H3 Studio 整合面板：九圖三影片三音訊同 prompt 集中管理，但唔干預 sampling。
– 低 VRAM 路徑：w4a8 加 int8_convrot VAE 約 11.8 GB，但要 ComfyUI 0.31.0 以上。
– chain 輸出：source_video 同 guide_frames 支援敘事鏡頭接駁。
– 作者實戰驗證：用同一套工具完成短片 THE RECITATION。

GitHub

Categories: 開源, ComfyUI, AI productions, 模型, 多模態模型, Video, Audio, 提示詞, 工具, Content Creator, Clone, MiniMax

Atlas 世界模型一次處理文字、圖片、影片與 3D

Share to X

World Labs 推出 Atlas，聲稱是目前首個原生同時處理文字、圖像、影片與 3D 的「omni」世界模型，能從一張相機路徑推算未見過的視角，並重建真實場景。

Og image

World Labs 公開了新一代世界模型 Atlas。它的特別之處在於從訓練階段就同時處理四種輸入——文字、圖像、影片、3D——並把它們整合到同一個空間脈絡裡，再以多模態自迴歸擴散 Transformer 推算下一個畫面。這意味著 Atlas 不只是「看得更多」，而是嘗試理解世界怎樣呈現、怎樣變化，並把想像中的場景渲染出來。

從使用場景來看，Atlas 主要涵蓋四類工作：相機控制生成、空間重建、空間時間模擬，以及純文字生圖與 360 度全景。其中相機控制生成支援 1 至 6 張輸入圖片，可輸出最高 1440p、最長約 1 分鐘的影片，並以像素級精度的相機幾何作為輸入，而不只是粗略的文字描述。

重建方面，Atlas 只需要 1 張到幾十張相片，就能還原真實場景並產出新視角的影像幀與明確的 3D 輸出。團隊指出，這項表現優於專門做 3D 重建的同類模型。空間時間模擬則可從影片重新取景，生成電影級視覺效果，並支援 Real-to-Sim 流程，供機器人規劃動作。

以下幾點值得留意：

  • 原生多模態：文字、圖片、影片、3D 一開始就共享同一空間脈絡，並非後期拼接。
  • 像素級相機控制：把精確相機幾何列為原生輸入，能逐格構圖、逐段運鏡。
  • 超越專用模型：3D 重建表現優於專門訓練的模型。
  • 支援 Real-to-Sim：能把真實影片轉成可模擬的世界，供機器人規劃。
  • 規模持續擴展：團隊表示表現會隨訓練算力提升，並預期這個趨勢會延續下去。

World Labs 表示，Atlas 將驅動他們自家 Marble 的未來版本及其他產品，現已開放早期使用的申請。

項目主頁

Categories: AI productions, 多模態模型, 世界模型, 模型訓練, API, Video, Image, 影像模型, Robotic, 3D

SimLoss 用單次生成多階段圖像描述

Share to X

由 UMass Amherst 與 Adobe Research 團隊開發，SimLoss 想解決圖像描述太籠統的老問題。它把細節監督搬到 embedding space，換來更快推理與更高描述精細度。

Repository image for srynsh/SimLoss-Image-Captioning

UMass Amherst 與 Adobe Research 團隊，瞄準的是圖像描述常常只講到大意、漏掉材質、數量、紋理同位置關係的問題。SimLoss 屬於影像 captioning 模型訓練方法，核心不是再加一條冗長後處理流程，而是令 Vision-Language Model 在單次生成前，先把隱藏狀態對齊影像 embedding，直接補回細節監督。

它的技術關鍵，在於用 reference-free 的 embedding-space objective 取代人手撰寫細粒度 captions，亦唔需要先跑多階段系統去製造 pseudo-captions。SimLoss 列出兩條路線：SimLoss FFT 會透過本地可用的 Qwen3-VL-Embedding-2B 反向傳播；SimLoss GRPO 則把 Gemini Embedding 2 當成 black-box reward。兩者都建基於 Qwen2.5-VL-7B-Instruct captioning policy，但前者偏向直接做表徵對齊，後者更接近以獎勵訊號微調。

同類方法常見做法，是生成、拆解、驗證、重寫逐步修補描述內容；SimLoss 揀的是保留 single-pass inference，換取更低延遲，再用對比式學習補回細節。代價是它仍然依賴外部 embedding 模型品質，而且項目展示的是研究基準與訓練框架，不是即裝即用的成品服務。

IIW-400 測試中，SimLoss FFT 配合 Qwen2.5-VL-7B backbone，把 precision 由未調整 backbone 的 0.788 提升到 0.849，F1 與多階段 CapMAS 接近到難以區分，同時推理速度約快 20 倍；SimLoss GRPO 則拿到最強 recall。呢個取捨幾實際：想要更準確地講出畫面細節，又唔想接受多步驗證延遲的團隊，會比一般 captioning fine-tune 更感受到差別。

  • 同一儲存庫放入 SimLoss、CapMAS、PAPO、DCScore RL 等基線，方便直接比較
  • 單次生成保留低延遲，同時補足 attributes、counts、textures、materials、spatial relations
  • 提供方法分目錄、資料與 checkpoint 說明，但大型資料與模型檔案未隨儲存庫附上

研究、內容理解、影像搜尋標註，甚至要為電商圖片或視覺資產建立更細緻描述的團隊，都會較容易受益。安裝與執行入口在儲存庫內有 setup 與各方法，但目前公開資訊主要指向研究復現流程；想完整重跑訓練或延遲基準，仍要另外處理資料集、checkpoint 同對應運行環境。

項目主頁 · GitHub

Categories: 開源, Embedding, 視覺模型, 多模態模型, Qwen, Gemini, Image

FastH3 Live：單張消費級 GPU 跑出無限 AI 直播

Share to X

FastH3 Live 將 MiniMax-H3 蒸餾成 4 步模型，配合重定時與 ComfyUI 串流伺服器，用一張 RTX 5090 就能長開 448×448 18fps 嘅無限影片加音訊直播。

Hero image preview

喺消費級硬件上長開一段無止境嘅 AI 影片頻道，一直係文字轉視頻工作流嘅痛點——雲端成本高、本地生成速度慢，仲要面對提示詞同角色一致性嘅限制。FastH3 Live 就係圍繞呢個矛盾設計：佢將 MiniMax-H3 經過 4 步 DMD2 蒸餾成 FastH3，配合一套本地串流伺服器，令生成同播放可以同步進行，前一段影片播放期間，模型已經喺度產出下一段。

整個項目以 ComfyUI 作為運行環境，並喺單張 RTX 5090（32GB、Windows 11）上完成測試。v1.1.0 版本將解析度提升至 448×448、幀率達到 18fps，相比 v1.0.0 嘅 512×288 12fps 有明顯進步。音訊部分亦同步串流，用戶只要用 VLC 指向本地 URL，就可以一直接收新嘅短片，支援多位觀眾同時連線同斷線重連。

對於內容創作者、ComfyUI 用戶或者想試文字轉視頻嘅人來說，呢套工具最直接嘅吸引力係「無限直播」呢個使用場景。項目內附 321 個場景提示詞、503 個已驗證可用嘅角色清單，使用時可以快速組合出唔同長度嘅段落，唔需要每次由零開始寫 prompt。

需要注意嘅限制亦都幾清楚：相關權重屬於 MiniMax-H3 社群授權，適用範圍排除歐盟、英國、韓國同美國，下載前需要確認所在地。

項目主頁 · 數據集

Categories: 開源, ComfyUI, Agentic, 視頻模型, Video, Dataset 數據集, MiniMax
Page 5 of 36
1 … 3 4 5 6 7 … 36