Posts

この記事は、私の作成した pxq というジョブ管理 CLI の紹介です。 この記事を読んでほしい人 クラウド GPU を使いたいけどイマイチ使えてない人 お家に GPU は買えないけど、Kaggle でゴリゴリ GPU 使いたい人 RunPod やクラウド GPU の仕組みに詳しくない人 多くの Kaggler が抱えている課題 Kaggle でクラウド GPU って便利そうだけど… 使い方がよくわからん できるだけ安く GPU を使い倒したい 実験のたびにポチポチ設定するのが面倒 複数の実験を並列に回したい そんな悩みを解決するのが、私が開発した pxq です。 pxq を使うのはどうでしょう？ pxq は、クラウド GPU を「もっと簡単に便利に」使うためのツールです。 GitHub リポジトリ: https://github.com/takeru1205/pxq PyPI プロジェクト: https://pypi.org/project/pxq pxq でできること シンプルな CLI でジョブを管理: pxq add "コマンド" だけで GPU ジョブを実行 自動 Pod 管理: ジョブ完了後、自動的に Pod を停止して課金を抑制（managed モード） Web ダッシュボード: 進捗をリアルタイムで監視 Network Volume 活用: 一度ダウンロードしたデータを複数 Pod で使い回せる SSH 接続: 実行中の Pod に簡単 SSH デバッグ RunPod とは？初心者向け解説 pxq を使う前に、RunPod の基本を知っておきましょう。...

お仕事でリアルタイムのMLエンドポイントを立てる事がなく、知見があまりない。 単純に、各フレームワークでの実行速度が気になったから雑に比較してみた。 実装したコードはこちらのGitHubリポジトリ 雑なまとめ Pythonを使う環境ならFastAPIを使えば問題ない。欲を言えば、onnxにモデルを変換しておくのが理想。 モデルをonnxに変換できる かつ Rustを利用できる環境 なら、Rustでエンドポイントを立てるとより高速な推論が期待できる。 比較する条件 フレームワーク Python FastAPI Flask Rust(axum, tokio) ort(onnx runtime) tract(onnx runtime) ※ RustのコードはClaudeCodeに書いてもらいました モデル PyTorch(2層のNN) LightGBM PyTorch ONNX(2層のNN) LightGBM ONNX タスク Titanicの生存予測(2値分類) 学習コードは notebooks/ にある。 特徴量 Pclass(Int) Sex(String) Age(Int) SibSp(Int) Parch(Int) Fare(Float) 前処理 Sex → Label Encoding Age → Fill Null(median) Age → Standard Scaler Fare → Standard Scaler 結果 各フレームワークで実装したエンドポイントに1000回のリクエストを送信して、計測した結果を集計した。 すべて、同じマシン上で実行・リクエストを行っている。 Framework 平均推論時間 (ms) FastAPI 約 1.75 ms Flask 約 2....

最近、自分にあった集中の方法を考えている。 これまで、デュアルディスプレイで作業をする際に、サブモニターでYouTubeや音楽を流しながら作業することが多かった。でも、引っ越しのときにモニターが一枚だけになった際、YouTubeを再生していない状態の方が、なんとなく集中できる気がした。 ビジュアルシンカーの脳を読んで、自分は言語優位ではなく、視覚優位だと感じた。 みんな本読むとき頭の中でもうひとりの私に音読してもらわないの？登場人物によって声変えたりしない？ 文字を視覚でとらえただけで頭に入ってくる？？？ また、上のポストを見て、「まさに自分だ」と思い、言語優位ではなく視覚優位と聴覚優位のグラデーションの中に自分がいると改めて感じた。 これが関係あるかはわからないが、歌詞のある曲とない曲では、圧倒的に歌詞のない曲の方が感覚的に集中できる。 歌詞のある曲を聴くと、耳に入ってくる音を言語として認識しようとしてしまい、その処理に脳が無駄に負荷をかけている気がする。 世界一流エンジニアの思考法を読んで、ADHDとまではいかないと思うが自分もマルチタスクが苦手で、できるだけ並列のタスクを減らしたいと強く思った。そのため、歌詞のある曲を聴くのは自分には合っていないという結論になった。 また、視覚優位であるがゆえに、視界の中で動くものがとても気になる。 だから、サブディスプレイでYouTubeなど動きのあるコンテンツを流すのは、今思えばありえない行動だったと思う。 これらを踏まえると、自分にとって一番良いのは「ディスプレイを一つにして音を流さない」ことだと考えた。 しかし現実には、業務上ディスプレイは複数欲しいし、完全な無音が理想だとしても、外の音が急に割り込んでくるのは苦手だ。 さらに、最初から無音だとどうにもやる気が出ない。音が流れていると集中はしづらいが、逆に何かに取り組もうという気持ちが湧かない。 困った。

自宅サーバーを立てた 勉強(遊ぶ)ためになんとなく自宅にサーバーを立てたくなった結果、気づいたら色々ポチっていた。 スペック CPU: AMD Ryzen9 7945HX(16Core/32Thread)(Amazonリンク) RAM: DDR5-5200 SODIMM 96GB(48GBx2)(Amazonリンク) GPU: NVIDIA RTX3060 12GBAmazonリンク クーラー: Corsair NAUTILUS 240 RSAmazonリンク ストレージ: NVMe 2TBAmazonリンク 電源: 玄人志向 80PLUS Bronze 650WAmazonリンク ケース: LianLi A3-mATX BlackAmazonリンク 組む時に考えていたこと PROXMOXを使ってVMを建てたいから、コア数(スレッド数)を多くしたい Ryzen CPUを使ったことがないから使ってみたい VRAMのコスパはAMDの方が良いけど、まだまだCUDAがデファクトスタンダードだから選択しづらい メインPCがあるからGPUにはそんなにお金をかけない。 ピカピカゲーミングで眩しくない サーバーで立っているもの サーバーはざっくり以下のイメージで構成されている。 現時点で、microk8sとDifyのVMが立っている。 リソースの配分はこんな感じ。 リソース microk8s Dify 余り vCPU 24 4 4 RAM 80 12 4 ストレージ 1TB 512GB 400GB その他 GPU - - microk8s microk8sでは、常時以下のものを動かしている mlflow tracking server MCPサーバー streamlitアプリ これらとは別に、必要な時に動かすものは以下のもの...

はじめに 配信プラットフォームでよく見かける「IRL配信(外配信)」。街中や山の上など、様々な場所で配信するコンテンツですが、モバイル回線の不安定さが大きな課題となっています。この課題を解決するのが「IRLToolkit」というサービスです。 今回は、このIRLToolkitの主要機能を備えた自作バージョンを開発したお話です。 IRLToolkitとは IRLToolkitは、不安定なモバイル回線でも安定した配信を実現するためのサービスです。特徴は以下の通りです： 配信デバイスからの映像を一旦中継サーバーで受け取り、そこから配信プラットフォームへ送信 ネットワークが途切れても配信が継続できる ダッシュボードから配信のコントロールが可能 自作版の実装内容 主要機能 配信機能 SRTプロトコルでの映像・音声受信 RTMPプロトコルでの配信プラットフォームへの送信 ネットワーク不安定時の代替映像表示 ダッシュボード機能 リアルタイムスクリーンショット表示 配信状態の監視(配信状態、マイク状態) 基本的な配信コントロール(開始/停止、ミュート) ビットレートのリアルタイムプロット リモート設定機能 OBS Studioのリモート操作機能 右側がダッシュボード機能、左側がリモートデスクトップです。 技術スタック コンテナ化：Docker 配信システム 映像受信：SRT (srt-live-transmit) 配信エンジン：OBS Studio 制御インターフェース：OBS Websocket UI実装：Streamlit リモート操作：xpra システム構成 単一のDockerコンテナ内で全機能が動作する構成を採用しました： 映像フロー 配信デバイス → srt-live-transmit → OBS Studio → 配信プラットフォーム 制御フロー Streamlitダッシュボード ↔ OBS Websocket ↔ OBS Studio 本来は、srt-live-transmitを利用せずともOBS Studioで直接srtで伝送された映像を受信できます。 しかし、今回は受信ビットレートをダッシュボードにプロットするという要件があるため、一度srt-live-transmitを経由し、受信した統計情報を名前付きパイプに吐き出させています。 名前付きパイプをStreamlitアプリから読み取る事でリアルタイムに受信したビットレートを確認できるようにしています。 コスト比較 商用のIRLToolkitは月額$129(約19,000円)かかりますが、自作版では： 自宅ホスティング：実質無料 AWS ECS利用時：約150円/時間（Tokyo リージョン、vCPU:16、RAM:32GB構成） (ネットワーク料金を無視すれば)5日(126時間)以内の利用であれば、自作版の方が安く利用できます。 今後の展望 IRLToolkitには搭載されていて、今回のアプリケーションでは実装できなかったものとして、SRTLA(SRT Link Aggregation)への対応があります。これは複数のモバイル回線を束ねて安定性を向上させる技術ですが、利用した環境の問題で実装する事ができませんでした。 今後対応したいと考えています。 参考リンク IRLToolkit BELABOX Free Relay Hosting for your SRT, SRTLA or RTMP IRL stream Haivision/srt Xpra-org/xpra OBS Studio Streamlit