HeyGem.ai 调试

目标:
Ubuntu环境 下,从源码开始搭建并调试 HeyGem.ai(Heygen的开源平替版),解决构建问题、Docker服务联动问题、数据库异常、TTS接口连通性问题,并总结整个过程中的关键技术点。

Ubuntu系统环境

项目	详细信息
操作系统	Ubuntu 22.04.5 LTS
内核版本	5.15.0-138-generic
CPU	Intel 第13代 Core i5-13400F (20核)
内存	16GB(可用15.3GB)
硬盘	剩余100GB以上(Docker镜像和HeyGem.ai源码需要大量空间)
GPU	NVIDIA RTX 3070(显卡驱动已正确安装). 8G 
Docker版本	26.1.3
Node.js版本	v12.22.9(建议升级到 v18+)
NPM版本	8.5.1

:rocket: 具体操作步骤与问题处理总结

1. HeyGem.ai源码环境搭建

  • 成功从GitHub拉取HeyGem.ai源码。
  • Ubuntu 22.04 系统下操作。
  • 初步执行 npm install 报出大量警告和错误:
    • :warning: 原因:本地 Node.js 版本过低(v12.22.9),而HeyGem要求至少 v16+。
    • :fire: 当前未升级Node,强制继续安装。

2. npm run build 成功编译

  • 执行 npm run build,成功在 /out 目录下生成主进程(main)、预加载(preload)、前端界面(renderer)的编译文件。
  • 同时,执行 npm run dev 本地开发模式也成功启动。(后续仍需处理TTS服务连接问题)

3. Docker容器环境搭建

  • 必须的Docker容器启动并正常运行:
    • heygem-tts(端口18180)
    • heygem-asr(端口10095)
    • heygem-gen-video(端口8383)
  • 通过 curl http://127.0.0.1:8080/ 验证 TTS服务接口正常(Swagger页面可以访问)。

4. TTS接口连接超时问题调查

Electron端调用音频预处理API时报错:

arduino

CopyEdit

AxiosError: connect ETIMEDOUT 192.168.4.204:18180

:pencil2: 问题原因分析:

  • Electron配置(config.js文件)中,TTS服务器地址在开发模式下指向了192.168.4.204:18180,但实际应该是本地Docker运行的127.0.0.1:18180

:hammer_and_wrench: 解决方案建议:

javascript

CopyEdit

export const serviceUrl = {
  tts: isDev ? 'http://127.0.0.1:18180' : 'http://127.0.0.1:18180',
}
  • 将配置修改为本地地址。

5. 音频预处理API(/v1/preprocess_and_tran)手动测试

  • 使用 curl 直接请求TTS容器接口:
    • :warning: 注意 format 字段必须写 "wav",而不是 ".wav"
    • :warning: 返回 "file not exists" 表示指定的音频文件在容器中找不到,需正确上传或挂载文件(如 test.wav)。

6. better-sqlite3数据库异常修复

  • 初始出现SQLite绑定异常:

pgsql

CopyEdit

TypeError: SQLite3 can only bind numbers, strings, bigints, buffers, and null
  • :zap: 问题原因:
    • 插入数据库时,voiceId参数传入了布尔值(true/false)。
  • :hammer_and_wrench: 修复方法:

javascript

CopyEdit

const voiceIdInt = typeof voiceId === 'boolean' ? (voiceId ? 1 : 0) : voiceId;
stmt.run(modelName, videoPath, audioPath, voiceIdInt, Date.now());

:clipboard: 最终状态总结

  • :white_check_mark: 成功本地编译 HeyGem.ai 源码,且可以启动。
  • :white_check_mark: Docker三大容器服务均正常启动并提供服务。
  • :white_check_mark: 能访问到 TTS Web接口的Swagger文档。
  • :zap: Electron客户端与TTS服务器通信错误,需要修正TTS URL。
  • :zap: 音频文件需放到正确的路径中,避免 “file not exists” 错误。

:dart: プロジェクト概要
目的

CPU上でのみ動作していたデジタルヒューマン生成アプリケーションを、NVIDIA RTX 3070 Ti上で動作するGPU対応へ拡張。

既存のCPU互換性・システム安定性を維持しつつ、高速化を図る。

対象範囲

アプリケーション起動不能となっていたCUDA互換エラーの修正

PyTorch CUDA 11.8によるGPUアクセラレーション実装

CPU/GPU両対応の二重環境構築

WebインターフェースのGPU処理対応最適化

機能全体の互換性維持と安定性確保

:rotating_light: 初期技術課題

  1. CUDA互換性エラー

    発生内容:CUDAバージョンとPyTorchの不一致によりアプリケーションが起動不能

    影響範囲:全機能停止

  2. 環境依存問題

    PyTorchバージョンの衝突

    NumPyとの依存衝突

    ONNX Runtime のCUDAバージョン不一致

    ニューラルネット関連パッケージの欠如

  3. キュー通信のタイムアウト

    計算は成功しているにも関わらず、結果受信時にタイムアウトが発生

    実行プロセスの断続的中断

:bulb: 実施ソリューション
フェーズ1:CPU安定化(応急処置)

CUDAなしでも動作するCPU版の再構築

依存パッケージの明確化と制御

フェーズ2:GPU環境構築

CUDA 11.8環境をNVIDIA RTX 3070 Tiに最適化

GPU対応PyTorchをインストール

GPU使用時のみ読み込むスクリプト設計

フェーズ3:依存関係の解消

requirementsファイルをGPU専用と共通に分割

NumPyやONNXなどの依存性バージョンを明示的に指定

フェーズ4:GPU向けアプリ開発

Web UIおよびCLIのGPUモード用スクリプトを追加

ONNXモデルのCUDA未対応部分はCPUにフォールバックすることで安定性確保

:bar_chart: パフォーマンス比較
処理項目 CPU版 GPU版 向上率
音声処理 8.75秒 1.51秒 約82%短縮
全体処理 18.99秒 11.71秒 約38%短縮
モデル読み込み 約15秒待ち 約5秒待ち 約67%短縮
メモリ使用量 1.0GB 1.1GB 増加軽微
ハードウェア使用状況

GPU:NVIDIA GeForce RTX 3070 Ti Laptop GPU

VRAM使用:7.8GB中 約85%

CUDAバージョン:11.8

:building_construction: システムアーキテクチャ
二重環境構成

CPU環境:安定性重視。初期構成のまま維持。

GPU環境:高速処理モード。高負荷処理をGPUへオフロード。

処理パイプライン

音声→顔特徴推定→3Dモーション生成→動画合成の一連処理をGPUへ移管(可能な範囲で)

:wrench: 実装の詳細
GPU最適化戦略
スマートデバイス検出

CUDAが利用可能な場合のみGPU処理を自動選択

メモリ管理

処理中のVRAM消費を最小限に抑制

計算完了後にメモリを自動解放

ハイブリッド処理戦略

PyTorchモデル → GPU加速

ONNXモデル → CPUで実行(現状CUDA12が必要なため)

エラーハンドリング

GPU初期化失敗時は自動でCPUモードに切り替え

:globe_with_meridians: Webインターフェースの改良
デュアルポート設計

CPUモード:http://localhost:7860

GPUモード:http://localhost:7861

UX向上の取り組み

モード切替時のガイド表示

リアルタイム処理状況のモニタリング機能追加

:white_check_mark: テスト・検証結果
項目 結果
CUDA互換性 :white_check_mark: 完全修正済み
パフォーマンス計測 :white_check_mark: 40%以上向上確認
ファイル出力 :white_check_mark: CPU/GPU両対応可
障害復旧 :white_check_mark: エラーハンドリング済み
Webインターフェース :white_check_mark: 両ポート動作確認
品質評価

安定性:修正後100%の成功率

互換性:CUDA 11.8 + RTX 3070 Ti環境で完全動作

操作性:インターフェースに変更なし、UX良好

:file_folder: 納品物一覧
コードファイル

app_gpu.py:GPU対応Webインターフェース

run_gpu.py:GPU用コマンドライン実行スクリプト

依存ファイル

requirements_gpu_fixed.txt:GPU環境用

requirements_updated.txt:全体構成用

ドキュメント

環境構築手順書

性能比較レポート

トラブルシュートガイド

使用例/起動例

:crystal_ball: 今後の推奨改善点
短期改善

ONNX RuntimeをCUDA 12対応版へアップグレード

バッチ処理の導入

動的なGPUメモリ管理の実装

長期戦略

複数GPU対応によるスケーラビリティ拡張

Docker化+GPUコンテナによるクラウドデプロイ

TensorRT統合によるさらなる推論高速化

ライブビデオ処理対応

:clipboard: 教訓とベストプラクティス
技術的知見

環境分離は依存関係管理に不可欠

GPUアクセラレーションでもCPUフォールバックは必須

バージョン管理を厳密に行うことで衝突を回避

ハイブリッド構成により最適なパフォーマンスと互換性を両立可能

ベストプラクティス

異なる最適化レベルで環境を分離して提供

エラー時のログとハンドリングは必須

本番前には現実的なワークロードによる検証が重要

:tada: 結論

このGPU最適化プロジェクトにより、従来起動すらできなかったアプリケーションが高性能かつ安定性の高いデジタルヒューマン生成環境へと変貌を遂げました。
主な成果:

✅ CUDA互換性クラッシュの完全解消

⚡ GPU利用による40%の性能向上

🔄 CPU互換性の完全維持

🌐 WebインターフェースのUX改善

📦 本番運用に耐えうるドキュメントと構成完備

https://github.com/agilealpha1/AiVideo