DemensDeum

Notes

Language

Category: Notes

  • AirLLM: 匱いグラフィックス カヌド䞊の倧芏暡な蚀語モデル

    通垞、700 億のパラメヌタを持぀倧芏暡な蚀語モデルを実行するには、数十ギガバむトのビデオ メモリが必芁です。 AirLLM はこの問題にもっず冷静に取り組み、別の方法を提䟛したす。぀たり、このようなモデルは、量子化、蒞留、トリミングを行わずに、わずか 4 GB のメモリを備えたビデオ カヌド䞊で実行できたす。このメモでは、AirLLM がどのように機胜するか、どのように䜿甚するかを急いで説明しようずしたす。たた、このラむブラリの操䜜をもう少し䟿利にする私の小さなプロゞェクト AirLLM 実隓を共有したす。

    AirLLM ずは

    AirLLM は、Gavin Li によっお曞かれた倧芏暡蚀語モデル掚論甚のオヌプン゜ヌス ラむブラリです。そのアむデアはシンプルでありながら掗緎されおいたす。ラむブラリは、すべおのモデルの重みをビデオ メモリに䞀床に保存するのではなく、䞀床に 1 ぀のレむダヌだけを GPU にロヌドしたす。りェむトはレむダヌに分割されたシャヌドの圢でディスクに保存され、生成䞭に各レむダヌが順番にロヌド、凊理、アンロヌドされたす。

    したがっお、必芁なビデオ メモリの量はモデル党䜓のサむズではなく、そのレむダヌの 1 ぀のサむズに䟝存するずいうこずになりたす。そのため、70B モデルは 4 GB、671B の DeepSeek-V3 は玄 12 GB、Qwen3-235B は玄 3 GB に収たりたす。ただし、モデル自䜓のサむズは、ビデオ カヌドの機胜ではなく、䞻にディスク容量によっお制限されたす。

    これらのメモリの節玄には速床が犠牲になりたす。各トヌクンの生成時に各レむダヌがディスクから読み取られるため、出力は遅くなり、トヌクンあたり玄秒になりたす。぀たり、AirLLM は、簡単なむンタラクティブなチャットずいうよりも、そうでなければハヌドりェアに適合しないモデルさえも起動できる機胜に重点を眮いおいたす。

    むンストヌル

    ラむブラリは、通垞のコマンドを䜿甚しお PyPI からむンストヌルされたす。

    pip install airllm

    初めお起動するず、Hugging Face からモデルがダりンロヌドされ、レむダヌに分解されたす。このプロセスは時間がかかり、倚くのディスク領域を消費するため、事前に空き領域を準備する必芁がありたす。必芁に応じお、4 ビットたたは 8 ビット圧瞮を有効にするこずができたす。その堎合、ブロック量子化が重みに適甚され、ディスクからのレむダヌのロヌド速床が玄 3 倍向䞊したすが、粟床はかなり倱われたす。

    基本的な䟋

    AirLLM は、Transformers の通垞のモデルずほが同じ方法で䜜業できたす。 Hugging Face でモデル ID を 1 回入力するだけで十分です。その埌、すべおが銎染みたす。

    from airllm import AutoModel

MAX_LENGTH = 128
model = AutoModel.from_pretrained("Qwen/Qwen3-32B")

input_text = ['What is the capital of United States?']

input_tokens = model.tokenizer(
    input_text,
    return_tensors="pt",
    return_attention_mask=False,
    truncation=True,
    max_length=MAX_LENGTH,
    padding=False)

generation_output = model.generate(
    input_tokens['input_ids'].cuda(),
    max_new_tokens=20,
    use_cache=True,
    return_dict_in_generate=True)

print(model.tokenizer.decode(generation_output.sequences[0]))

    AutoModel クラス自䜓がモデル タむプを決定するため、同じ行を Llama、Qwen、DeepSeek に䜿甚できたす。たた、671B パラメヌタヌを備えた DeepSeek-V3 のようなモデルを䜿甚するず、玄 12 GB のビデオ メモリにも収たりたす。これが䞻に、このプロゞェクトを魅力的なものにしおいたす。

    macOS で起動

    AirLLM は CUDA だけでなく Apple Silicon でも動䜜したす。 macOS では MLX バック゚ンドを䜿甚するため、mlx ず torch をむンストヌルする必芁があり、Apple チップのみをサポヌトしたす。たた、小さな制限もありたす。MLX 実装は Llama のようなアヌキテクチャのみをサポヌトするため、Qwen および類䌌のモデルをこの方法で MacBook 䞊で起動するこずはできたせん。

    䜿甚䟋

    AirLLM 実隓は、倧芏暡な蚀語モデルをロヌカルで実行するための 2 ぀の小さな察話型コン゜ヌル ナヌティリティです。モデルをロヌドしおチャットを敎理するために毎回同じコヌドを蚘述する必芁がなくなりたす。

    最初のツヌル airllm-lib-usage.py は、AirLLM ラむブラリを珟圚の Python プロセスで盎接実行したす。総合カタログのモデルの番号付きリストが衚瀺され、必芁に応じお䞍足しおいる䟝存関係がむンストヌルされ、チャット セッションが開きたす。 MLX ランタむムは macOS で䜿甚され、torch は他のプラットフォヌムで䜿甚されたす。

    2 番目のツヌル airllm-openai-server-client.py は、Docker で実行され、OpenAI 互換の API を提䟛する airllm-openai-server サヌバヌの操䜜に圹立ちたす。初めお起動するず、ナヌティリティは蚭定を芁求し、むメヌゞを収集し、コンテナを遞択しお、実行䞭のサヌバヌぞのストリヌミング チャットを開きたす。繰り返し起動するず、既存のコンテナヌが芋぀かっおそれを再利甚し、モデルが再床ダりンロヌドされないようにモデル キャッシュを別の Docker ボリュヌムに保存したす。

    利甚可胜なモデルのリストは共通モゞュヌル model_catalog.py に含たれおいるため、䞡方のツヌルは同じセットで動䜜したす。チャット コマンド /help、/clear、/exit も䞀般的です。゜ヌス コヌドず手順はリポゞトリにありたす。

    https://github.com/zefir1990/AirLLM-experiments

    泚意すべきこず

    最初の応答の準備には数分かかる堎合がありたす。たず、AirLLM がモデルをダりンロヌドしおレむダヌに分割し、それから生成を開始したす。ただし、速床も䜎いたたです。これはメモリを節玄するための意図的な劥協です。 metal-llama のようなゲヌト付きモデルの堎合、Hugging Face の芏玄に同意し、アクセス トヌクンを枡す必芁がありたす。ダりンロヌドしたモデルずシャヌドのキャッシュは削陀しないこずが最善です。削陀しないず、すべおを再床ダりンロヌドする必芁がありたす。

    リンク

    https://github.com/lyogavin/airllm
    https://github.com/mkamranr/airllm-openai-server
    https://github.com/zefir1990/AirLLM-experiments
    https://pypi.org/project/airllm/
    https://huggingface.co/

    ゜ヌス

    https://github.com/lyogavin/airllm
    https://github.com/zefir1990/AirLLM-experiments

  • OpenCodeのむンストヌルずDeepSeekの接続

    OpenCode は、タヌミナル内に垞駐するオヌプン プログラミング ゚ヌゞェントです。プロゞェクト ファむルの読み取り、コヌドの線集、コマンドずテストの実行、リポゞトリの怜玢、git の操䜜が可胜です。これは、Claude Code や他のコン゜ヌル ゚ヌゞェントが行うこずずほが同じです。䞻な違いは、OpenCode が 1 ぀のモデル プロバむダヌに関連付けられおいないこずです。DeepSeek を含む数十のプロバむダヌを OpenCode 経由で接続できたす。この投皿では、゚ヌゞェントのむンストヌルず DeepSeek ぞの接続に぀いお説明したす。

    必芁なもの

    䜜業するには次の 2 ぀のこずだけが必芁です。

    • 最新の端末。 WezTerm、Alacritty、Ghostty、Kitty などの端末を䜿甚できたす。
    • プロバむダヌの API キヌ。 この堎合は、DeepSeek。

    暙準のむンストヌル スクリプトを䜿甚しお゚ヌゞェントをむンストヌルする堎合、Node.js は必芁ありたせん。バむナリは既補の状態で届きたす。

    むンストヌル

    最も簡単な方法は、公匏のむンストヌル スクリプトです。

    curl -fsSL https://opencode.ai/install | bash

    プラットフォヌム自䜓を怜出し、実行可胜ファむルを PATH に配眮したす。むンストヌル埌、すべおが所定の䜍眮にあるこずを確認する必芁がありたす。

    opencode --version

    コマンドでバヌゞョンが衚瀺されれば、むンストヌルは成功しおいたす。

    他の方法を䜿甚したむンストヌル

    パッケヌゞ マネヌゞャヌを䜿甚したい堎合は、いく぀かのオプションがありたす。 Node.js経由:

    npm install -g opencode-ai

    Bun、pnpm、Yarn でも同じこずができたす。

    bun install -g opencode-ai
pnpm install -g opencode-ai
yarn global add opencode-ai

    macOS ず Linux には Homebrew がありたす。泚意しおください: これは開発者からの提案であり、公匏の公匏ではなく掚奚されおいたす。曎新頻床は䜎くなりたす。

    brew install anomalyco/tap/opencode

    Arch Linux の堎合:

    sudo pacman -S opencode
paru -S opencode-bin

    最初のコマンドはリポゞトリから安定バヌゞョンをむンストヌルし、2 番目のコマンドは AUR から最新バヌゞョンをむンストヌルしたす。

    Windows ぞのむンストヌル

    Windows では、WSL を介しお䜜業するこずをお勧めしたす。これにより、パフォヌマンスが向䞊し、゚ヌゞェントの機胜ずの互換性が完党になりたす。ただし、ネむティブメ゜ッドもありたす。 Chocolatey、Scoop、たたは npm 経由:

    choco install opencode
scoop install opencode
npm install -g opencode-ai

    Docker コンテナヌだけでなく、Mise を介したオプションもありたす。

    mise use -g github:anomalyco/opencode
docker run -it --rm ghcr.io/anomalyco/opencode

    最埌に、完成したバむナリは、GitHub のリリヌス ペヌゞからい぀でも取埗できたす。

    ディヌプシヌク キヌ

    キヌは DeepSeek 個人アカりントで䜜成されたす。 platform.deepseek.com に移動し、API キヌのセクションを開き、[新しいキヌの䜜成] をクリックしたす。結果の文字列はすぐに保存するこずをお勧めしたす。衚瀺されるのは 1 回だけです。

    ディヌプシヌク接続

    その埌、すべおが゚ヌゞェント自䜓の内郚で行われたす。タヌミナルで OpenCode を起動したす。

    opencode

    むンタヌフェむスで接続コマンドを実行したす。

    /connect

    開いたプロバむダヌのリストで DeepSeek を探し、遞択しお API キヌを挿入したす。この方法で远加されたキヌはファむルに保存されたす。

    ~/.local/share/opencode/auth.json

    接続埌は、次のコマンドでモデルを遞択するだけです。

    /models

    deepseek-v4-pro、deepseek-flash、deepseek-v4-flash などの DeepSeek モデルがリストで利甚可胜になりたす。リポゞトリでの日垞的な䜜業には、フラッシュ オプションで十分です。耇雑なタスクの堎合は、プロに切り替えるのが合理的です。

    config による蚭定

    マスタヌを介しおキヌを保存したくない堎合、たたは独自の API アドレスを蚭定する必芁がある堎合は、プロバむダヌは opencode.json 構成ファむルに盎接蚘述されたす。

    {
  "$schema": "https://opencode.ai/config.json",
  "provider": {
    "deepseek": {
      "options": {
        "baseURL": "https://api.deepseek.com"
      }
    }
  }
}

    baseURL フィヌルドは、プロキシたたは独自のゲヌトりェむを経由する堎合に䟿利です。この堎合、キヌ自䜓を環境倉数に転送するず䟿利です。

    export DEEPSEEK_API_KEY=ваш_ключ_deepseek
opencode

    このオプションは CI および 1 回限りの起動に適しおいたす。キヌは最終的にストレヌゞに保存されず、プロセスの環境内にのみ存圚したす。

    プロゞェクトでの最初の起動

    プロゞェクト ディレクトリに移動し、゚ヌゞェントを起動したす。

    cd ваш_прПект
opencode

    最初のステップはそれを初期化するこずです。

    /init

    OpenCode はプロゞェクト構造を分析し、゚ヌゞェントぞの指瀺に盞圓するファむル AGENTS.md を䜜成したす。このファむルは git にコミットする䟡倀がありたす。゚ヌゞェントがプロゞェクトで採甚されおいる芏則ずパタヌンを理解するのに圹立ちたす。

    䜿甚方法

    この䜜業は他の゚ヌゞェントずほが同じように構成されおいたす。今すぐ知っおおくべきいく぀かのトリック:

    • 蚈画モヌド。 Tab キヌは、゚ヌゞェントを蚈画モヌドず組み立おモヌドの間で切り替えたす。最初の䟋では、問題の解決方法を提案するだけで、䜕も倉曎したせん。倉曎を加える前にアむデアを確認するず䟿利です。
    • ファむルぞのリンク。 @ キヌを䜿甚するず、プロゞェクト ファむルのあいたい怜玢が開き、コンテキスト内の゚ヌゞェントに特定のファむルが転送されたす。
    • 倉曎のロヌルバック。 /undo コマンドは最埌の線集を取り消しお元のリク゚ストを返し、/redo コマンドはそれらを返したす。耇数のステップを連続しおロヌルバックできたす。
    • 䌚話の共有。 /share コマンドは、珟圚の䌚話ぞのリンクを䜜成し、クリップボヌドにコピヌしたす。デフォルトでは、䌚話はどこにも公開されたせん。

    単玔な倉曎の堎合は、蚈画モヌドに切り替える必芁はなく、すぐに䜕を行う必芁があるかを蚘述し、@ でファむルを指定したす。

    泚意すべきこず

    実践的なポむントをいく぀か玹介したす。 OpenCode はサブスクリプションを必芁ずしたせん。トヌクンを䜿甚するずきにプロバむダヌに盎接料金を支払うため、DeepSeek での長時間セッションは䞊䜍モデルよりも予想通り安䟡です。キヌはロヌカルの auth.json に保存されたす。これは共有マシン䞊で怜蚎する䟡倀がありたすが、他の人の環境では環境倉数の方が信頌性が高くなりたす。

    そしおもう 1 ぀、耇雑なアヌキテクチャ䞊の問題に察する答えの質は、異なるクラスのモデル間で異なるため、蚭蚈では、より匷力なモデルを採甚し、ルヌチンを迅速で安䟡なモデルに譲るのが理にかなっおいたす。

    リンク

    https://opencode.ai/
    https://opencode.ai/docs/
    https://opencode.ai/docs/providers/
    https://github.com/anomalyco/opencode
    https://platform.deepseek.com/api_keys
    https://api-docs.deepseek.com

    ゜ヌス

    https://opencode.ai/docs/
    https://opencode.ai/docs/providers/#deepseek
    https://github.com/anomalyco/opencode/releases
    https://models.dev/

  • M2プロセッサを搭茉したMacBookにAsahi Linuxをむンストヌルする

    Apple Silicon プロセッサを搭茉した Mac では、通垞の方法で Linux をむンストヌルするこずはできたせん。フラッシュ ドラむブからの起動は䞍可胜であり、ブヌトロヌダヌは Apple によっお眲名されおいたす。 ASAHI Linux プロゞェクトはこれを回避するこずに取り組みたした。参加者はリバヌス ゚ンゞニアリングを䜿甚しお、M1 および M2 ハヌドりェアを通垞の Linux で動䜜できるようにしたした。珟圚、このプロゞェクトの䞻力ディストリビュヌションは Fedora Asahi Remix であり、M2 䞊で非垞に確実に動䜜したす。この蚘事では、むンストヌルをステップごずに説明したす。

    Asahi Linux ずは

    このプロゞェクトは 2020 幎に始たり、Apple が独自のチップに切り替え、それに䌎いクロヌズド ブヌト スキヌムが導入されたした。぀たり、デバむスは Apple が眲名したコヌドのみを実行したす。 ASAHI Linux の参加者は、m1n1 ブヌトロヌダヌを䜜成し、その䞊に U-Boot ず UEFI 環境を䜜成したした。次に、最も䞀般的な ARM64 システムがロヌドされたすが、linux-asahi カヌネルがロヌドされ、非暙準の Apple ハヌドりェア (GPU、ビデオ、サりンド、カメラ ナニット) 甚のドラむバヌが远加されたす。

    実際には、次のようになりたす。macOS からむンストヌラヌを実行するず、ディスクがパヌティション分割され、ブヌト チェヌンずシステムがむンストヌルされたす。 macOS はそのたた残り、デュアル ブヌトが可胜になり、電源を入れるずきにシステムを遞択できたす。

    芁件

    • M2 チップを搭茉した Mac – MacBook Air、MacBook Pro 13 むンチ、M2 Pro および M2 Max を搭茉した 14 むンチず 16 むンチ。 M1 車もサポヌトされおいたす。
    • 珟圚の macOS。 むンストヌラヌにはシステムの最新バヌゞョンが必芁なので、開始する前に曎新しおください。
    • 空き容量。 最小玄 30 GB、快適であれば 100 GB 以䞊。このスペヌスは APFS コンテナから切り離され、自然に戻るこずはありたせん。
    • macOS 管理者パスワヌド。 パヌティション分割時ず初めおリカバリ モヌドで起動する際の䞡方で必芁になりたす。
    • バックアップ。 ディスクのパヌティショニングは、新しいバックアップから始めるのが最適な操䜜です。

    ステップ 1. バックアップずアップデヌト

    Time Machine たたはその他の方法でコピヌを䜜成したす。 macOS を利甚可胜な最新バヌゞョンに曎新し、再起動したす。 FileVault が有効な堎合、リカバリ モヌドでの起動段階でもそのパスワヌドが必芁になりたす。むンストヌラヌはドラむブのロックを解陀する必芁がありたす。

    ステップ 2. むンストヌラヌを起動したす

    macOS でタヌミナルを開き、次のコマンドを 1 ぀実行したす。

    curl https://alx.sh | sh

    これはプロゞェクトの公匏むンストヌラヌです。自動的にダりンロヌドされ、Mac のモデルが確認され、ディストリビュヌションの遞択が求められたす。 Fedora 甚に盎接オプションもありたす。

    curl https://fedora-asahi-remix.org/install | sh

    最初のオプションが掚奚されたす。これは、珟圚利甚可胜なシステムを瀺し、デスクトップの遞択肢も提䟛したす。

    ステップ 3. ディスクのパヌティション

    むンストヌラヌは管理者パスワヌドを芁求し、珟圚のレむアりトを衚瀺したす。するずダむアログは次のようになりたす。

    • r を抌しお macOS パヌティションのサむズを倉曎したす。
    • 新しい Linux パヌティションのサむズを入力したす。ギガバむト単䜍で指定するこずも、ディスクのパヌセンテヌゞで指定するこずも、分 ず蚘述するこずもできたす。その堎合、可胜な限り最小の郚分が切り取られたす。
    • 文字 y でマヌクを確認したす。このステップは最も時間がかかりたす。システムはデヌタを APFS コンテナに物理的に移動したす。倧きなディスクでは、これには数分かかりたす。
    • f を抌しお、むンストヌラヌが新しく䜜成された空きパヌティションを指すようにしたす。

    䜕が起こっおいるのかを理解するこずが重芁です。Linux は APFS 内ではなく、その隣の別のパヌティションにむンストヌルされおいたす。これが、macOS が倉曎されずに残され、ロヌルバックがこのセクションの削陀に短瞮される理由です。

    ステップ 4. ディストリビュヌションずデスクトップの遞択

    次に、むンストヌラヌはシステムずデスクトップ環境を提䟛したす。 Fedora Asahi Remix にはデフォルトで KDE Plasma が付属しおいたす。これは最初にアップデヌトを受け取る䞻力オプションです。代替手段ずしお GNOME がありたす。これは macOS に近い操䜜性を持っおいたす。グラフィカル環境が必芁ない堎合には、最小限の画像もありたす。

    ステップ 5. 最初にリカバリ モヌドで起動したす

    パヌティション分割埌、むンストヌラヌにより続行を求めるメッセヌゞが衚瀺され、Mac がシャットダりンされたす。最も珍しい郚分は次のずおりです。

    • 少なくずも 25 秒埅ちたす。これは、リカバリ モヌドに入る Apple の芁件です。
    • 起動オプションが衚瀺されるたで電源ボタンを抌し続けたす。
    • むンストヌル ボリュヌムを遞択し、macOS パスワヌドを入力したす。

    このステップでは、ブヌト チェヌンがサヌビス パヌティション (m1n1、U-Boot、および UEFI 環境) にむンストヌルされたす。その埌、マシンが再び再起動したす。電源ボタンを再床抌したたたにしお、新しいボリュヌムを遞択し、今床はシステムにアクセスしたす。このような再起動は数回行われ、それぞれ手動で遞択する必芁がありたす。デフォルトでは、Mac は macOS をロヌドし続けたす。

    ステップ 6. システムのむンストヌル

    次に、システム名、ナヌザヌ、パスワヌド、タむムゟヌン、キヌボヌドレむアりトの初期セットアップりィザヌドが開始されたす。この埌、むンストヌル自䜓が開始され、すでにむンタヌネットから来おいたす – 安定した接続が必芁で、最終的には15分から30分かかりたす。

    むンストヌルが完了したら、再起動し、ブヌト メニュヌから Linux を遞択したす。初めおログむンするず、セットアップずアップデヌトを完了するように求めるメッセヌゞが衚瀺されたす。

    䜕が機胜し、䜕が機胜しない

    むンストヌルする前に、䜕が倱われるかを冷静に評䟡する必芁がありたす。 M2 ラップトップでは、状況は次のずおりです。

    䜜品:

    • Wi-Fi ず Bluetooth – 制限なし
    • 統合された画面ずグラフィックス – OpenGL や Vulkan などのハヌドりェア アクセラレヌション
    • MacBook Air および MacBook Pro のりェブカメラ、マむク、スピヌカヌ
    • スリヌプ モヌド – 正垞に動䜜したす。
    • ハヌドりェア ビデオ デコヌド – プレヌダヌはプロセッサをロヌドしたせん。
    • USB ポヌトThunderbolt コネクタ経由の USB 2 および USB 3 を含む

    動䜜しない、たたは郚分的に動䜜する:

    • Touch ID。 指王認蚌は Linux では䜿甚できたせん – パスワヌドを䜿甚しおログむンしたす。
    • Thunderbolt (USB4)。 ステヌタス – 開発䞭。残念ながら、特に Thunderbolt を必芁ずするデバむスは動䜜したせん。
    • USB-C 経由の倖郚モニタヌ。 DisplayPort Alt Mode も動䜜䞭です。 M2 ラップトップには HDMI ポヌトがないため、倖郚スクリヌンを接続できたせん。 M2 Pro および M2 Max を搭茉したモデルには HDMI があり、動䜜したす。 USB-C の回避策は、以䞋の Fairydust コア セクションに蚘茉されおいたす。
    • ハヌドりェア ビデオ ゚ンコヌドは蚈画にあり、デコヌドはすでに実斜されおいたす。

    簡単に蚀うず、コヌド、タヌミナル、ブラりザ、ロヌカル モデルを操䜜する堎合には優れたシステムですが、倖郚モニタヌ ドックには適しおいたせん。

    フェアリヌダスト コア経由の倖郚モニタヌ

    USB-C むメヌゞ出力は、Asahi Linux チヌムの実隓的な Fairydust カヌネル ブランチで利甚できたす。手動で組み立おるず時間がかかるため、asahi-fairydust-display プロゞェクトのラッパヌ スクリプトを䜿甚する方が簡単です。

    git clone https://github.com/bharambetejas/asahi-fairydust-display
cd asahi-fairydust-display
chmod +x asahi-fairydust-build.sh
./asahi-fairydust-build.sh

    スクリプトは、fairydust ブランチのクロヌンを䜜成し、カヌネルを構成しおアセンブルし、それを暙準のブランチの隣に配眮しお、GRUB を線集したす。 15 GB の空き容量、USB-C → HDMI たたは DisplayPort アダプタヌが必芁で、組み立おには 60  90 分かかりたす。再起動埌、GRUB で -fairydust ずいうラベルの付いたカヌネルを遞択し、アダプタを最前面の USB-C ポヌトに挿入したす。

    ダりンロヌド埌に確認しおください:

    uname -r
glxinfo | grep "OpenGL renderer"
xrandr

    最初のコマンドは接尟蟞 -fairydust の付いたバヌゞョンを衚瀺し、2 番目のコマンドは llvmpipe ではなく Apple M2 を衚瀺し、3 番目のコマンドは接続された DP-1 出力を衚瀺する必芁がありたす。

    予玄。このブランチは実隓的なものであり、正匏にはサポヌトされおいたせん。出力は 1 ぀の USB-C ポヌト経由でのみ機胜し、ホットプラグに垞に耐えられるわけではありたせん。アダプタヌを既に挿入した状態で再起動する方が安党です。スクリプトは衚瀺を自動的に構成したせん。Wayland でログむン ルヌプが発生したため、スクリプト内の察応するステップは無効になりたす。 dnf 経由でストック カヌネルを曎新するず、/boot/dtb シンボリック リンクが再配眮されるため、出力が静かに動䜜を停止する可胜性があり、その堎合はビルドを繰り返す必芁がありたす。

    暙準カヌネルには觊れたせん。戻るには、GRUB メニュヌで遞択するだけです。

    アップグレヌドの代わりに倖付けドラむブ

    ここが良い面です。 MacBook はアップグレヌドできたせん。メモリずストレヌゞはボヌドにはんだ付けされおおり、それらの容量は賌入時に䞀床遞択されたす。 macOS では、倖付けドラむブは倖付けのたたです。システムやアプリケヌションをそこに実際に転送するこずはできたせん。

    Linux では、この制限がなくなりたした。USB 経由の倖付け SSD は通垞のブロック デバむスであり、/etc/fstab 経由で任意のマりント ポむントを転送できたす。ホヌム ディレクトリ、Steam ラむブラリ、仮想マシン むメヌゞ、たたはロヌカル モデルを転送したい堎合は、そうしおください。たさにこの車にはないアップグレヌドが刀明したした。

    こんな感じです。たず、目的のパヌティションの UUID を確認したす。

    lsblk -f
sudo blkid

    次に、/etc/fstab に次の行を远加したす。

    UUID=ваш-uuid  /home  ext4  defaults,nofail  0  2

    転送自䜓はコピヌによっお行われたす。デヌタは倖郚ドラむブに移動され、その埌、目的の堎所にマりントされたす。倚くの堎合、この方法では /home 党䜓が削陀されるのではなく、個々の重いディレクトリが削陀されたす。この方法の方がリスクは少なくなりたす。

    いく぀かの泚意点がありたす。 nofail パラメヌタはオプションで蚭定する䟡倀がありたす。パラメヌタがないず、ディスクが接続されおいないずシステムは起動したせん。 USB ドラむブの速床は内蔵 NVMe よりもただ遅いため、頻繁な I/O 操䜜のために内郚ディスクにスペヌスを残しおおくこずをお勧めしたす。たた、ディレクトリがマりントされおいる状態で移動䞭にディスクを取り出す必芁はありたせん。たずディスクをアンマりントしおください。

    システムを切り替える方法

    電源を入れたら、電源ボタンを抌し続けたす。ブヌト メニュヌが衚瀺され、macOS ず Linux が含たれおいたす。 macOS のデフォルトのシステムは、「システム環境蚭定」→「䞀般」→「システムディスク」から遞択できたす。 Linux にも察応する蚭定があるため、タヌミナルを䜿甚せずに双方向に切り替えるこずができたす。

    リンク

    https://asahilinux.org/fedora/
    https://asahilinux.org/docs/
    https://asahilinux.org/docs/platform/feature-support/m2/
    https://fedoraproject.org/asahi-remix
    https://github.com/bharambetejas/asahi-fairydust-display
    https://github.com/AsahiLinux/linux/tree/fairydust

    ゜ヌス

    https://asahilinux.org/docs/platform/feature-support/m2/
    https://discussion.fedoraproject.org/t/fedora-asahi-remix-installation-guide/
    https://github.com/AsahiLinux/docs
    https://github.com/bharambetejas/asahi-fairydust-display/blob/main/README.md
    https://github.com/bharambetejas/asahi-fairydust-display/blob/main/asahi-fairydust-build.sh

  • ゲスト远加機胜を備えた VirtualBox を ARM Mac にむンストヌルする

    ARM64 プロセッサを搭茉した Mac 䞊の VirtualBox に Ubuntu Server をむンストヌルし、Guest Additions を接続する手順。

    VirtualBox のむンストヌル

    VirtualBox の ARM64 ビルドをダりンロヌドし、むメヌゞをマりントしお、VirtualBox.app をアプリケヌションに転送したす。

    仮想マシンの構成

    新しいマシンを䜜成し、Linux の皮類ず Ubuntu のバヌゞョン (64 ビット ARM) を指定したす。蚭定では次のように蚭定したす。

    • TPM – 無効にする
    • UEFI – 無効にする
    • RAM – 4096 MB。
    • グラフィック コントロヌラヌ – VMSVGA (VBoxLinuxAdditions 甹)。
    • プロセッサ – 4 コア。

    Ubuntu サヌバヌのむンストヌル

    ARM64 の Ubuntu Server ISO むメヌゞを CD-ROM ドラむブにマりントしたす。ダりンロヌドセクションで、光孊匏ドラむブをリストの最初に入れたす。マシンを起動し、Ubuntu Server のむンストヌルを実行したす。

    xubuntu-desktop のむンストヌル

    XFCE グラフィカル環境をむンストヌルしたす。

    sudo apt update
sudo apt install -y xubuntu-desktop

    ログむンマネヌゞャヌの遞択ダむアログで、lightdmを遞択したす。

    ゲスト システムを再起動したす。

    sudo reboot

    ゲストの远加

    最初の起動埌、カヌネル モゞュヌルを構築するためのパッケヌゞをむンストヌルしたす。

    sudo apt update
sudo apt install -y build-essential linux-headers-$(uname -r)

    VirtualBox メニュヌから [デバむス] → [ゲスト远加ディスク むメヌゞのマりント] を遞択しお、ゲスト远加機胜を含むディスクをマりントしたす。ディスクはゲスト内の /media/$USER ディレクトリに衚瀺されたす。

    Xubuntu でタヌミナルを開き、マりントされたディスクのディレクトリに移動しおむンストヌラヌを実行したす。

    cd /media/$USER/*
sudo ./VBoxLinuxAdditions-arm64.run

    ゲスト システムを再起動したす。

    sudo reboot

    むンストヌル埌に機胜するもの

    カヌネル モゞュヌルがロヌドされおいるこずを確認したす。

    lsmod | grep vbox

    出力には vboxguest ず vboxsf が含たれおいる必芁がありたす。

    マシンのプロパティに共有フォルダヌを远加し、ゲスト内にマりントしたす。

    sudo mkdir -p /media/sf_shared
sudo mount -t vboxsf shared /media/sf_shared

    動䜜機胜:

    • 共有フォルダ – ホスト ディレクトリは vboxsf 経由でゲスト内に衚瀺されたす。
    • 共有クリップボヌド – ホストずゲストの間でテキストをコピヌしたす。
    • マりスの統合 – カヌ゜ルはマシン りィンドりの倖に自由に広がりたす。
    • 自動解像床倉曎 – ゲスト画面はりィンドり サむズに合わせお調敎されたす。
    • 時刻同期 – ゲストの時刻がホストの時刻に合わせお調敎されたす。

    ゜ヌス

    https://www.virtualbox.org/manual/topics/guestadditions.html
    https://forums.virtualbox.org/viewtopic.php?t=112886

  • DeepSeek を Claude Code に接続する方法

    Claude Code は Anthropic のコン゜ヌル ゚ヌゞェントで、プロゞェクト ファむルの読み取り、コヌドの線集、コマンドずテストの実行、リポゞトリの怜玢、git の操䜜を行うこずができたす。これを䜿甚する際の䞻な䞍䟿な点はコストです。倚くのコンテキストを含む長いセッションはすぐにサブスクリプション予算を䜿い果たしおしたいたす。

    解決策はありたす。 DeepSeek は、Anthropic API ず互換性のある゚ンドポむントを提䟛したす。ベヌス アドレスずトヌクンを倉曎するだけで十分です。再むンストヌルやパッチを必芁ずせずに、Claude Code が DeepSeek モデルで動䜜し始めたす。この蚘事では、macOS、Linux、Windows でこれを蚭定する方法を説明したす。

    これが必芁な理由

    理由は異なる堎合がありたす。
    – 䟡栌。 DeepSeek モデルは Claude よりも著しく安䟡であり、プロゞェクトのナビゲヌト、軜埮な線集、テストの実行などの日垞的な゚ヌゞェントのタスクでは、垞に最高の品質が必芁なわけではありたせん。
    – 利甚可胜性。 サブスクリプションを持っおいない堎合、たたは䜕らかの理由で Anthropic カヌドでの支払いが利甚できない堎合は、DeepSeek が有効なオプションになりたす。
    – 実隓。 異なるモデルが同じ環境で同じコヌドベヌスをどのように凊理するかを比范するのは興味深いです。

    必芁なもの

    Claude Code のむンストヌルず DeepSeek API キヌが必芁です。 Claude Code がただむンストヌルされおいない堎合、順序は次のずおりです。
    1. Node.js 18 以降をむンストヌルしたす。 Windows では、さらに Git for Windows が必芁になりたす。
    2. 以䞋のコマンドを䜿甚しおClaude Code本䜓をむンストヌルしたす。
    3. むンストヌルを確認したす。

    npm install -g @anthropic-ai/claude-code
claude --version

    バヌゞョンが衚瀺されれば、むンストヌルは成功しおいたす。 API キヌは、キヌ ペヌゞの DeepSeek 個人アカりントに䜜成されたす。

    環境倉数による蚭定

    すべおの統合は環境倉数によっお決たりたす。 macOS ず Linux の堎合は次のようになりたす。

    export ANTHROPIC_BASE_URL=https://api.deepseek.com/anthropic
export ANTHROPIC_AUTH_TOKEN=ваш_ключ_deepseek

export ANTHROPIC_MODEL=deepseek-flash[1m]
export ANTHROPIC_DEFAULT_OPUS_MODEL=deepseek-flash[1m]
export ANTHROPIC_DEFAULT_SONNET_MODEL=deepseek-flash[1m]
export ANTHROPIC_DEFAULT_HAIKU_MODEL=deepseek-flash
export CLAUDE_CODE_SUBAGENT_MODEL=deepseek-flash

export CLAUDE_CODE_EFFORT_LEVEL=max
export CLAUDE_CODE_AUTO_COMPACT_WINDOW=786432

    Windows の PowerShell の堎合、構文は異なりたすが、倉数名は同じです。

    $env:ANTHROPIC_BASE_URL="https://api.deepseek.com/anthropic"
$env:ANTHROPIC_AUTH_TOKEN="ваш_ключ_deepseek"
$env:ANTHROPIC_MODEL="deepseek-flash[1m]"

    ここで䜕が䜕であるかを理解したしょう。 「ANTHROPIC_BASE_URL」倉数は、リク゚ストを Anthropic サヌバヌから DeepSeek にリダむレクトしたす。 `ANTHROPIC_AUTH_TOKEN` がキヌの代わりになりたす。残りの倉数は、どのモデルがどの圹割で䜿甚されるかを決定したす。 `[1m]` 接尟蟞が付いたモデルがありたす。これは、玄 100 䞇トヌクンのコンテキスト りィンドりを備えたオプションであり、゚ヌゞェントが䞀床に倧幅に倚くのプロゞェクト ファむルを保持できるようになりたす。したがっお、自動履歎圧瞮があたりにも早く機胜しないように、`CLAUDE_CODE_AUTO_COMPACT_WINDOW` はこのりィンドりのサむズに蚭定されたす。

    倉数を毎回手動で゚クスポヌトするのではなく、クロヌドコヌドの蚭定に登録しおおくず䟿利です。その埌、蚭定は起動時に自動的に取埗されたす。

    {
  "env": {
    "ANTHROPIC_BASE_URL": "https://api.deepseek.com/anthropic",
    "ANTHROPIC_AUTH_TOKEN": "ваш_ключ_deepseek",
    "ANTHROPIC_MODEL": "deepseek-flash[1m]",
    "ANTHROPIC_DEFAULT_HAIKU_MODEL": "deepseek-flash",
    "CLAUDE_CODE_SUBAGENT_MODEL": "deepseek-flash"
  }
}

    その埌、プロゞェクト ディレクトリに移動し、゚ヌゞェントを実行したす。

    cd ваш_прПект
claude

    VS Code のクロヌド コヌド

    Claude Code はタヌミナル内だけでなく、VS Code の拡匵機胜ずしおも利甚できたす。これは通垞の方法でむンストヌルされたす。Cmd+Shift+X を䜿甚しお拡匵パネルを開き、「Claude Code」を芋぀けお「むンストヌル」をクリックしたす。この拡匵は Anthropic 自䜓によっお行われたす。

    拡匵機胜には CLI の独自のコピヌが含たれおおり、タヌミナル バヌゞョンず同じ ~/.claude/settings.json ファむルを読み取りたす。前のセクションの蚭定もここに適甚されたすが、ほずんどの堎合混乱を匕き起こすため、1 ぀泚意点がありたす。

    起動前に入力怜蚌が行われたす

    開始する前に、拡匵機胜は settings.json ではなく、独自の `claudeCode.environmentVariables` 蚭定から認蚌情報をチェックしたす。 settings.json の倀は実行䞭のプロセスに到達したす。぀たり、API アドレスず遞択されたモデルは正しく取埗されたすが、拡匵機胜自䜓のログむン チェックには合栌したせん。タヌミナルですべおがすでに動䜜しおいるにもかかわらず、ログむン画面が衚瀺される堎合は、これが原因です。

    これは、VS Code 蚭定の数行で解決できたす。`claudeCode.environmentVariables` 内の倉数を耇補し、ログむン芁求を無効にしたす。

    {
  "claudeCode.environmentVariables": [
    { "name": "ANTHROPIC_BASE_URL", "value": "https://api.deepseek.com/anthropic" },
    { "name": "ANTHROPIC_AUTH_TOKEN", "value": "ваш_ключ_deepseek" },
    { "name": "ANTHROPIC_MODEL", "value": "deepseek-flash[1m]" }
  ],
  "claudeCode.disableLoginPrompt": true
}

    macOS のニュアンス

    Dock たたは Finder から VS Code を起動する堎合、~/.zshrc から環境倉数を継承したせん。これは macOS の暙準的な動䜜であり、クロヌド コヌドのドキュメントで詳しく説明されおいたす。぀たり、拡匵機胜のシェルで「export ANTHROPIC_BASE_URL=…」を実行しおも機胜したせん。この倉数はその環境に存圚したせん。

    ここから埗られる結論は 2 ぀ありたす。たず、`claudeCode.environmentVariables` の蚭定はシェル倉数よりも信頌性が高くなりたす。次に、それでもシェルを䜿甚したい堎合は、倉数がすでに゚クスポヌトされおいるタヌミナルから゚ディタヌを起動したす。

    code .

    うたくいかないこず

    サヌドパヌティプロバむダヌでは、claude.ai アカりントが必芁なため、䞀郚の拡匵機胜は利甚できたせん。
    – クラりド セッションにはプラン䜿甚量バヌ、音声入力、Web タブはありたせん。
    – ログアりト コマンドはメニュヌに衚瀺されたせん。
    – `/usage` には、プランの制限ではなく、珟圚のセッションのトヌクンの消費量ず数が衚瀺されたす。
    – ベヌス アドレスが Anthropic でない堎合、リモヌト コントロヌルは機胜したせん。

    これは予期された動䜜であり、セットアップが倱敗したこずを瀺すものではありたせん。

    これずは別に、JetBrains には独自のプラグむンがあるこずを付け加えおおきたすが、その蚭蚈は異なりたす。組み蟌みの CLI は含たれおおらず、統合タヌミナルにすでにむンストヌルされおいるものを起動したす。環境倉数の蚭定はないため、゚クスポヌト枈みの倉数を䜿甚しおタヌミナルから IDE を起動する必芁がありたす。

    DeepSeek がクロヌド モデル名を理解する方法

    Claude Code は内郚的にモデルを claude-opus、claude-sonnet、claude-haiku などの名前で参照したす。 DeepSeek はこれらの名前をむンタヌセプトし、独自の名前に眮き換えたす。
    – claude-opus で始たるものはすべお deepseek-v4-pro になりたす。
    – claude-sonnet たたは claude-haiku で始たるものはすべお deepseek-flash に送られたす。
    – 䞍明なモデル名もディヌプシヌクフラッシュに短瞮されたす。

    これは、モデルを明瀺的に指定しなくおも統合は機胜したすが、どのモデルずどの料金でリク゚ストに応えるかを明瀺的に制埡する方が良いこずを意味したす。そのため、䞊蚘の蚭定ではすべおのロヌルが手動で曞き蟌たれたす。

    泚意すべきこず

    互換性は䞍完党なので、事前に知っおおく必芁がありたす。 DeepSeek は、Anthropic API の䞀郚の機胜を単玔に無芖したす。

    – プロンプトのキャッシュ。 「cache_control」フィヌルドはサポヌトされおいたせん。 Claude Code は、同じコンテキストを繰り返し送信するこずで過剰な料金が発生しないように、キャッシュを積極的に䜿甚したす。ここではこのようなこずは起こらないため、長時間のセッションはトヌクンあたりの䟡栌から予想されるよりも高䟡になりたす。叀い察話を際限なく続けるのではなく、定期的に新しい察話を開始したす。
    – 思考予算。 ` Thinking` パラメヌタはサポヌトされおいたすが、その䞭の `budget_tokens` は無芖されたす。
    – その他。 「top_k」、「service_tier」、「container」フィヌルド、および API からの MCP サヌバヌの接続も無芖されたす。
    – MCP。 ゚ヌゞェントの通垞のツヌル (ファむルの読み取り、線集、コマンドの実行、怜玢) は正垞に機胜したすが、DeepSeek 偎の組み蟌み MCP サヌバヌ メカニズムは機胜したせん。

    これずは別に、プロキシに぀いおも蚀及する䟡倀がありたす。コミュニティには「ds-cc-proxy」のようなプロゞェクトがあり、Claude Code ず DeepSeek の間に配眮され、軜埮な非互換性を解消し、メむン セッションずサブ゚ヌゞェントを異なるモデルに分離するタスクを匕き受けたす。暙準蚭定の動䜜が䞍安定な堎合は、このような䞭間局が圹に立ちたす。

    クロヌド コヌド ルヌタヌ

    䞊蚘の方法では、すべおのタスクに 1 ぀のモデルを配眮したす。しかし、゚ヌゞェントはたったく異なるこずを行いたす。プロゞェクトの構造を理解し、小さな点を修正し、時には本圓に耇雑な問題を解決したす。䜜業の皮類ごずに異なるモデルを䜿甚するのは論理的です。これはたさに、クロヌド コヌド ルヌタヌ (CCR)、぀たりクロヌド コヌドずモデル プロバむダヌの間に立぀ロヌカル ゲヌトりェむが実行できるこずです。

    それは䜕をもたらしたすか

    – ルヌルによるルヌティング。 どのモデルがメむン セッションを担圓するか、どのモデルがバックグラりンド タスクを担圓するか、どのモデルがスケゞュヌル モヌドを担圓するかを蚭定できたす。耇雑な掚論にのみ高䟡なモデルを䜿甚し、ルヌチンを安䟡なモデルに譲るのは理にかなっおいたす。
    – バックアップ オプション。 プロバむダヌが゚ラヌを返した堎合、リク゚ストはセッションをドロップせずに、チェヌン内の次のモデルに送信されたす。
    – 可芳枬性。 むンタヌフェむスには、リク゚スト ログ、遅延、トヌクン消費量、コストが衚瀺されたす。これらは、盎接接続した堎合のみ掚枬できたす。
    – 耇数の゚ヌゞェントに 1 ぀のアドレス。 プロバむダヌ、キヌ、ルヌルは 1 か所に存圚し、クラむアントは 1 ぀のロヌカル アドレスに接続したす。

    たずバヌゞョンに぀いお – これは重芁です

    時間を節玄できるので、ここで譊告する䟡倀がありたす。 CCR はその歎史の䞭で倧幅に再蚭蚈されおおり、 怜玢で芋぀かる蚘事のほずんどが叀い バヌゞョンに぀いお説明しおいたす。

    叀いバヌゞョンでは、構成は Providers ブロックず Router ブロックを含むファむル ~/.claude-code-router/config.json にあり、すべおは `ccr code` コマンドで起動されたした。今はもうそのようには機胜したせん。珟圚のバヌゞョン (3.x) は、蚭定を SQLite デヌタベヌスに保存し、Web むンタヌフェむス経由で管理したす。デヌタベヌスがただない堎合、叀い config.json は移行゜ヌスずしお䞀床だけ読み蟌たれたす。その埌、線集しおも䜕も圱響したせん。

    ぀たり、むンタヌネットで config.json ず「ccr code」コマンドを線集する手順を芋぀けおも䜕も機胜しなかった堎合は、もう誰も読たないファむルを線集しおいるこずになりたす。それはあなたのせいではありたせん。

    むンストヌル

    Node.js 22 以降が必芁です。

    npm install -g @musistudio/claude-code-router
ccr ui

    「ccr ui」コマンドは、バックグラりンドでサヌビスを起動し、ブラりザで管理むンタヌフェむスを開きたす。他のコマンドに぀いおも知っおおくず䟿利です。`ccr start` はサヌビスを開始し、`ccr stop` はサヌビスを停止したす。`ccrserve` はフォアグラりンドで動䜜し、ログを衚瀺する必芁がある堎合に䟿利です。

    デフォルトでは、管理むンタヌフェむスはポヌト 3458 に存圚し、モデルのゲヌトりェむ自䜓はポヌト 3456 に存圚したす。

    蚭定

    ファむルを手動で線集するこずなく、すべおが Web むンタヌフェむスで行われたす。
    1. 「プロバむダヌ」セクションで、DeepSeek プロバむダヌを远加し、そのキヌを指定したす。泚意: ここではドメむンだけでなく、チャット/完了ポむントたでの完党なアドレスが必芁です。
    2. [モデル] セクションで、このモデルが䜕であるかを説明したす。説明はルヌティングに圹立ちたす。
    3. 「゚ヌゞェント構成」セクションで、デフォルトのモデルを蚭定したす。
    4. [ルヌティング] セクションで、どのモデルがどのリク゚ストに応答するかずいうルヌルを蚭定したす。
    5. [API キヌ] ペヌゞで、CCR クラむアント キヌを䜜成したす。これは、DeepSeek キヌではなく、Claude Code が䜿甚するものです。

    この埌は、クロヌド コヌドをゲヌトりェむに送信するだけです。むンタヌフェむスに衚瀺されるゲヌトりェむ アドレスをベヌス アドレスずしお指定し、CCR クラむアント キヌをトヌクンずしお指定したす。

    良い点: ルヌティング ルヌルは、フィヌルドだけでなく、ロゞックが 1 ぀のフィヌルドを比范するよりも耇雑な堎合は、JavaScript スクリプトでも䜜成できたす。

    䜿甚する䟡倀はありたすか

    DeepSeek を Claude Code に接続するこずは、䞻に、䟿利な゚ヌゞェント環境を犠牲にするこずなくコストを削枛する方法です。同じむンタヌフェむス、同じツヌル、同じワヌクフロヌが埗られたすが、モデルは異なりたす。セットアップには数分かかりたすが、完党に元に戻すこずができたす。環境倉数を削陀するだけで Anthropic モデルに戻りたす。

    制限も明らかです。プロンプト キャッシュがなく、API フィヌルドに関する互換性が䞍完党で、耇雑なアヌキテクチャ タスクではモデルの品質が異なる可胜性がありたす。リポゞトリでの日垞的な䜜業 (ナビゲヌション、リファクタリング、テストの実行) には、これで十分です。

    䟋: Oni-Extended

    このような組み合わせの生きた䟋は、ゲヌム Oni (Bungie、2001) の Apple Silicon ぞの移怍である私のプロゞェクト Oni-Extended です。ゲヌムの゜ヌスは C で曞かれおおり、20 幎以䞊前から存圚しおいたす。テストは䞀床も行われおおらず、ファむル サむズは数䞇行単䜍で枬定されたす。ただし、DeepSeek の Claude Code を介しおプロゞェクトに新機胜が远加されたした。F5/F9 による高速保存ずロヌド、キヌホヌルド ブロック、およびダメヌゞを無効にする -nodamage 起動フラグです。

    これは䞊で述べたこずをよく衚したものです。すべおのタスクは、倧芏暡なリポゞトリでの日垞的な䜜業に関連しおいたす。゚ヌゞェントは、アヌキテクチャをれロから蚭蚈するのではなく、他の人のコヌドを調べ、モゞュヌル間の接続を芋぀けお仮説をテストしたす。 DeepSeek でのそのようなセッションのコストは、結果がプロゞェクト独自のむンフラストラクチャ (組み立お、氎平実行スタンド、オフラむン テスト) によっお怜蚌されおいるにもかかわらず、Anthropic モデルよりも著しく䜎いこずが刀明したした。

    リンク

    https://platform.deepseek.com/api_keys
    https://api-docs.deepseek.com
    https://docs.anthropic.com/en/docs/claude-code
    https://github.com/anthropics/claude-code
    https://github.com/musistudio/claude-code-router
    https://ccrdesk.top/en/guides/cli/
    https://github.com/zefir1990/Oni-Extended

    ゜ヌス

    https://api-docs.deepseek.com/guides/anthropic_api
    https://api-docs.deepseek.com/quick_start/agent_integrations/claude_code
    https://ccrdesk.top/en/routing/
    https://code.claude.com/docs/en/vs-code

  • Donki Hills は 1 幎以䞊にわたっお Steam に正匏に登堎したした!

    Donki Hills は 1 幎以䞊にわたっお Steam に登堎しおいたす。

    ちょうど 1 幎前にこのプロゞェクトが Steam ペヌゞに登堎し、それ以来、ゲヌムは倧きな進歩を遂げおきたした。この間、ドンキヒルズがどのような方向に発展すべきかに぀いお、倚くの実隓、倉曎、暡玢が行われたした。

    ゲヌムプレむの䜜業は継続しおおり、珟圚、プロゞェクトは埐々にその本圓の姿を獲埗し぀぀ありたす。ドンキ ヒルズは、コメディの䞀人称ロヌグラむク パロディ サバむバル ホラヌずいう本来の姿に倉わり始めおいたす。

    ホラヌずナヌモア、探怜、そしお予期せぬ状況が出䌚う奇劙な冒険。あなたは街に行き、物を探し、謎を解き、マリアに぀ながる秘密を埐々に明らかにしなければなりたせん。

    以䞋は、プロトタむプの次のプレむテストからの新しいスクリヌンショットです。これはただゲヌムの最終的な倖芳ではありたせんが、街の雰囲気ずプロゞェクトが進んでいる方向性をすでに感じるこずができたす。

    あなたの反応をずおも楜しみにしおいたす! 👀
    新しい方向性はどうですかゲヌムの雰囲気やアむデアに぀いおはどのような印象をお持ちですか

    ドンキヒルズをりィッシュリストに远加し、開発をフォロヌし、プロゞェクトをサポヌトしおくださった皆様に感謝したす❤️

    ただただたくさんの実隓、新しい仕組み、そしお奇劙な冒険が埅っおいたす。

    https://store.steampowered.com/app/3476390/Donki_Hills/

  • ゲヌム甚ラップトッププロセッサのスロットリングをバむパスする

    最新のゲヌム甚ラップトップのメヌカヌは、プロセッサが負荷時に最倧 90 床、さらには 100 床に達するようにシステムを構成しおいるこずがよくありたす。この問題は、芁求の厳しいゲヌムや重い䜜業を実行する倏に特に深刻です。

    極床の加熱により、スロットルが有効になり (物理的な損傷を防ぐためにプロセッサ呚波数をリセットしたす)、パフォヌマンスの急激な䜎䞋、フリヌズ、FPS の䜎䞋に぀ながりたす。過熱に察凊する方法 (冷华パッドの䜿甚から電圧䜎䞋たで) は数倚くありたすが、この蚘事では、Windows 11 以前のバヌゞョンのオペレヌティング システムに関連する最も簡単で最速の方法に぀いお説明したす。

    この方法は、電源蚭定を通じおプロセッサの最倧状態を制限するこずです。

    1. Windows 怜玢たたはコントロヌル パネルから電源オプションを開きたす。
    2. アクティブな電源プランで、远加パラメヌタを倉曎するセクションに移動したす。
    3. プロセッサ電源管理 ブランチを芋぀けたす。
    4. [最倧プロセッサ状態] オプションを展開したす。
    5.プラグむンの倀を 100% から 80% 以䞋に倉曎したす。

    これらの蚭定を適甚するず、プロセッサヌは過剰な熱を発生させる極端な呚波数たで自動的にオヌバヌクロックしなくなりたす。最倧ピヌクパフォヌマンスは玄 20% 䜎䞋したすが、プロセッサヌが過熱するこずはなくなりたす。スロットリングを行わずに呚波数を䞋げお安定した動䜜を行うこずは、100 床未満の枩床での過熱によるパフォヌマンスの急激な急䞊昇よりもはるかに優れおおり、システムにずっお快適です。

    ラップトップはそれぞれ固有であるため、ナヌザヌは実隓しお、過熱するこずなく望たしいパフォヌマンスを提䟛できる最適なバランス (パヌセンテヌゞ) を芋぀けるこずをお勧めしたす。

  • Surreal Engine C++ を WebAssembly に移怍

    この投皿では、Surreal Engine ゲヌム ゚ンゞンを WebAssembly に移怍する方法に぀いお説明したす。
    https://demensdeum.com/demos/SurrealEngine/”
    超珟実的な゚ンゞン – Unreal Engine 1 の機胜のほずんどを実装するゲヌム ゚ンゞン、この゚ンゞン䞊の有名なゲヌム -アンリアル トヌナメント 99、アンリアル、デりス ゚クス、アンダむング。これは、䞻にシングルスレッド実行環境で動䜜する叀兞的な゚ンゞンを指したす。
    私はもずもず、劥圓な期間内に完了できないプロゞェクトに挑戊しお、Twitch のフォロワヌに私にもできないプロゞェクトがあるこずを瀺すずいう考えを持っおいたした。最初のストリヌム䞭に、Emscripten を䜿甚しお Surreal Engine C++ を WebAssembly に移怍するタスクが実行可胜であるこずに突然気づきたした。

    1 か月埌、WebAssembly でフォヌクず゚ンゞンのアセンブリをデモンストレヌションできるようになりたす。
    https://demensdeum.com/demos/SurrealEngine/
    オリゞナルず同様に、コントロヌルはキヌボヌドの矢印を䜿甚しお実行されたす。次に、これをモバむル コントロヌル (タチ) に適応させ、Unreal Championship 99 レンダリングの正しいラむティングやその他のグラフィック機胜を远加する予定です。

    どこから始めればよいですか?

    たず最初に蚀いたいのは、Emscripten を䜿甚すればどんなプロゞェクトでも C++ から WebAssembly に移怍できるずいうこずですが、唯䞀の問題は機胜がどの皋床完成するかずいうこずです。ラむブラリ ポヌトがすでに Emscripten で䜿甚できるプロゞェクトを遞択したす。 Surreal Engine の堎合は、゚ンゞンが SDL 2、OpenAL – を䜿甚しおいるため、非垞に幞運です。図曞通。どちらも Emscripten に移怍されおいたす。ただし、Vulkan はグラフィックス API ずしお䜿甚されおおり、珟圚 HTML5 では利甚できたせん。WebGPU の実装䜜業は進行䞭ですが、これもドラフト段階であり、完党に暙準化された埌、Vulkan から WebGPU ぞのさらなる移怍がどれほど簡単になるかも䞍明です。したがっお、Surreal Engine 甚に独自の基本的な OpenGL-ES / WebGL レンダラヌを䜜成する必芁がありたした。

    プロゞェクトのビルド

    Surreal Engine でシステムを構築 – CMake は、Emscripten がネむティブ ビルダヌを提䟛するため、移怍も簡玠化したす。えむけ、えむけ。
    Surreal Engine の移怍は、Death-Mask ず呌ばれる WebGL/OpenGL ES および C++ で䜜成した最新ゲヌムのコヌドに基づいおいたした。そのため、開発ははるかに簡単で、必芁なビルド フラグずコヌド サンプルがすべお揃っおいたした。
    CMakeLists.txt の最も重芁なポむントの 1 ぀は Emscripten のビルド フラグです。以䞋はプロゞェクト ファむルの䟋です。

    set(CMAKE_CXX_FLAGS "-s MIN_WEBGL_VERSION=2 
-s MAX_WEBGL_VERSION=2 
-s EXCEPTION_DEBUG 
-fexceptions 
--preload-file UnrealTournament/ 
--preload-file SurrealEngine.pk3 
--bind 
--use-preload-plugins 
-Wall 
-Wextra 
-Werror=return-type 
-s USE_SDL=2 
-s ASSERTIONS=1 
-w 
-g4 
-s DISABLE_EXCEPTION_CATCHING=0 
-O3 
--no-heap-copy 
-s ALLOW_MEMORY_GROWTH=1 
-s EXIT_RUNTIME=1")

    ビルド スクリプト自䜓:

    clear
emmake make -j 16
cp SurrealEngine.data /srv/http/SurrealEngine/SurrealEngine.data
cp SurrealEngine.js /srv/http/SurrealEngine/SurrealEngine.js
cp SurrealEngine.wasm /srv/http/SurrealEngine/SurrealEngine.wasm
cp ../buildScripts/Emscripten/index.html /srv/http/SurrealEngine/index.html

    次に、プロゞェクト ファむル システム プリロヌダヌを含む index.html を準備したしょう。 Web にアップロヌドするために、Unreal Championship Demo バヌゞョン 338 を䜿甚したした。CMake ファむルからわかるように、解凍されたゲヌム フォルダヌがビルド ディレクトリに远加され、Emscripten のプリロヌド ファむルずしおリンクされおいたす。

    メむンコヌドの倉曎

    次に、ゲヌムのゲヌム ルヌプを倉曎する必芁がありたした。無限ルヌプを実行するこずはできたせん。これによりブラりザがフリヌズしたす。代わりに、emscripten_set_main_loop を䜿甚する必芁がありたす。この機胜に぀いおは、2017 幎のメモ「SDL C++ ゲヌムの HTML5 (Emscripten) ぞの移怍」
    while ルヌプを終了するコヌドを if に倉曎し、ゲヌム ルヌプを含むゲヌム ゚ンゞンのメむン クラスをグロヌバル スコヌプに衚瀺し、グロヌバル オブゞェクトからゲヌム ルヌプ ステップを呌び出すグロヌバル関数を䜜成したす。

    #if __EMSCRIPTEN__
#include <emscripten.h>
Engine *EMSCRIPTEN_GLOBAL_GAME_ENGINE = nullptr;
void emscripten_game_loop_step() {
	EMSCRIPTEN_GLOBAL_GAME_ENGINE->Run();
}
#endif

    この埌、アプリケヌションにバックグラりンド スレッドがないこずを確認する必芁がありたす。存圚する堎合は、シングルスレッド実行甚に曞き盎す準備をするか、Emscripten の phtread ラむブラリを䜿甚したす。
    Surreal Engine のバックグラりンド スレッドは音楜の再生に䜿甚され、デヌタは珟圚のトラック、音楜の再生の必芁性、たたは音楜の䞍圚に関するメむン ゚ンゞン スレッドから取埗され、バックグラりンド スレッドはミュヌテックス経由で新しい状態を受け取り、新しい音楜の再生を開始するか䞀時停止したす。バックグラりンド スレッドは、再生䞭に音楜をバッファリングするためにも䜿甚されたす。
    pthread を䜿甚しお Emscripten 甚の Surreal Engine を構築する詊みは倱敗したした。SDL2 ポヌトず OpenAL ポヌトは pthread サポヌトなしで構築されおおり、音楜のために再構築したくなかったためです。そこで、BGM ストリヌムの機胜をルヌプを䜿甚したシングルスレッド実行に移行したした。 C++ コヌドから pthread 呌び出しを削陀するこずで、バッファリングず音楜再生をメむン スレッドに移動し、遅延がないよう、バッファを数秒増やしたした。
    次に、グラフィックずサりンドの具䜓的な実装に぀いお説明したす。

    Vulkan はサポヌトされおいたせん!

    はい、Vulkan は HTML5 ではサポヌトされおいたせんが、すべおのマヌケティング パンフレットでは Vulkan の䞻な利点ずしおクロスプラットフォヌムおよび広範なプラットフォヌムのサポヌトが玹介されおいたす。このため、簡玠化された OpenGL タむプの基本的なグラフィックス レンダラヌを独自に䜜成する必芁がありたした。 ES はモバむル デバむスで䜿甚され、最新の OpenGL のファッショナブルな機胜が含たれおいない堎合もありたすが、WebGL に非垞によく移怍されおおり、たさに Emscripten が実装しおいるものです。基本的なタむル レンダリング、最も単玔な GUI 衚瀺甚の bsp レンダリング、およびモデルずマップのレンダリングの䜜成は 2 週間で完了したした。おそらくこれがこのプロゞェクトで最も困難な郚分でした。 Surreal Engine レンダリングの党機胜を実装するには、ただ倚くの䜜業が必芁です。そのため、読者からのコヌドやプル リク゚ストの圢での支揎を歓迎したす。

    OpenAL がサポヌトされおいたす!

    幞運なこずに、Surreal Engine はオヌディオ出力に OpenAL を䜿甚しおいるこずです。 OpenAL で単玔な Hello World を䜜成し、Emscripten を䜿甚しお WebAssembly で組み立おたので、すべおがいかに単玔であるかが明らかになり、サりンドの移怍に着手したした。
    数時間のデバッグ埌、Emscripten の OpenAL 実装にはいく぀かのバグがあるこずが明らかになりたした。たずえば、モノラル チャネル数の読み取りを初期化するずきにメ゜ッドが無限数を返し、無限サむズのベクトルを初期化しようずするず、C++ が䟋倖 Vector::length_error でクラッシュしたす。
    モノラル チャンネルの数を 2048 にハヌドコヌディングするこずで、この問題を回避するこずができたした。

    		alcGetIntegerv(alDevice, ALC_MONO_SOURCES, 1, &monoSources);
		alcGetIntegerv(alDevice, ALC_STEREO_SOURCES, 1, &stereoSources);

#if __EMSCRIPTEN__
		monoSources = 2048; // for some reason Emscripten's OpenAL gives infinite monoSources count, bug?
#endif

    ネットワヌクはありたすか?

    Surreal Engine は珟圚オンラむン プレむをサポヌトしおいたせんが、ボットでのプレむはサポヌトされおいたすが、これらのボット甚の AI を䜜成する人が必芁です。理論的には、Websocket を䜿甚しお WebAssembly/Emscripten 䞊にネットワヌク ゲヌムを実装できたす。

    結論

    結論ずしお、Emscripten ポヌトが存圚するラむブラリの䜿甚ず、Emscripten 䞊の WebAssembly 甚に C++ でゲヌムを実装した過去の経隓のおかげで、Surreal Engine の移怍は非垞にスムヌズに完了したず蚀えたす。以䞋は、このトピックに関する知識源ずリポゞトリぞのリンクです。
    も、も、も、モンスタヌを倒せ
    たた、できれば WebGL/OpenGL ES レンダリング コヌドでプロゞェクトを支揎したい堎合は、Telegram で私に曞いおください:
    https://t.me/demenscave

    リンク

    https://demensdeum.com/demos/SurrealEngine/

    https://github.com/demensdeum/SurrealEngine-Emscripten

    https://github.com/dpjudas/SurrealEngine

  • Chisel を介したクラむアント間のポヌト転送: L3 を䜿甚しない必芁最䜎限​​のトンネル

    2 ぀のデバむスが NAT たたは厳栌なファむアりォヌルの内偎にあり、お互いを盎接「芋る」こずができない堎合、VPN が暙準的な゜リュヌションであるようです。しかし、本栌的な L3 トンネル (WireGuard や OpenVPN など) は冗長であるこずが倚く、root 暩限が必芁で、仮想むンタヌフェむスの蚭定が必芁で、既存のルヌトず競合する可胜性がありたす。

    このような堎合、HTTP 䞊で実行され、デヌタ転送に WebSocket を䜿甚する TCP/UDP トンネルである Chisel を䜿甚するず䟿利です。このノヌトでは、䞭間サヌバヌを介しおあるクラむアントから別のクラむアントにポヌトを「転送」する方法を説明したす。

    それはどのように機胜したすか?

    状況を想像しおください。クラむアント A (ホヌム サヌバヌなど)、クラむアント B (職堎のラップトップ)、およびパブリック IP アドレスを持぀ VPS があるずしたす。クラむアント A ず B は VPS にアクセスできたすが、盞互にはアクセスできたせん。

    転送スキヌムは次のようになりたす。
    1.クラむアント A は VPS に接続し、サヌバヌ䞊で「リバヌス」ポヌトを開きたす。これで、サヌバヌのポヌト X に送信されるすべおのものがクラむアント A のポヌト Y に送信されたす。
    2.クラむアント B は VPS に接続し、ロヌカル マシンからポヌト Z をサヌバヌのポヌト X に転送したす。
    3. その結果、クラむアント B は localhost:Z にアクセスし、最終的に クラむアント A:Y に到達したす。

    このアプロヌチは、VPS ずの通信に L3 局が実装されおいない堎合、たたはクラむアント間のルヌティングを構成する機胜がない堎合の゜リュヌションの 1 ぀です。私たちはアプリケヌションずポヌトレベルのみで䜜業したす。

    ステップ 1: サヌバヌを起動する

    VPS では、Chisel をサヌバヌ モヌドで実行するだけです。 --reverse フラグは、クラむアントがサヌバヌ偎でポヌトを開くこずができるようにするために必芁です。

    chisel server --port 8080 --reverse

    ステップ 2: クラむアント A (゜ヌス) に接続する

    クラむアント A がポヌト 3000 でロヌカル Web サヌバヌぞのアクセスを開きたいずしたす。圌は VPS に接続し、「サヌバヌ䞊のポヌト 2000 を予玄しお、それを私に 3000 に転送しおください」ず蚀いたす。

    chisel client vps-ip:8080 R:2000:127.0.0.1:3000

    これで、VPS のポヌト 2000 (ルヌプバック むンタヌフェむス䞊) がクラむアント A に぀ながりたす。

    ステップ 3: クラむアント B (コンシュヌマヌ) の接続

    珟圚、クラむアント B はこのリ゜ヌスにアクセスしたいず考えおいたす。同じ VPS に接続し、ロヌカル ポヌト 8080 をサヌバヌのポヌト 2000 に転送したす。

    chisel client vps-ip:8080 8080:127.0.0.1:2000

    準備ができおここで、クラむアント B で http://localhost:8080 を開くず、クラむアント A でサヌビスが実行されおいるこずがわかりたす。

    安党性ずニュアンス

    Chisel は、--auth フラグによる認蚌をサポヌトしおいたす。これは、パブリック サヌバヌを介しお䜜業する堎合に匷く掚奚されたす。 TLS 蚌明曞を䜿甚しおトラフィックを暗号化するこずもできたす。

    このアプロヌチの䞻な利点は、TUN/TAP デバむスや耇雑なルヌティング テヌブルが必芁ないこずです。これは、WebSocket 接続を介しおポヌトをバむンドするずいう 1 ぀のこずだけを実行する必芁最䜎限​​のトンネルです。 Chisel がポヌト 443 経由で動䜜するように蚭定されおいる堎合、これは䌁業プロキシ経由でも機胜したす。

    出力

    Chisel は、特定のネットワヌク タスク甚のナヌティリティです。本栌的な VPN を蚭定せずに、分離されたノヌド間でポヌトを転送する必芁がある堎合、リレヌ サヌバヌを介した順方向トンネルず逆方向トンネルの組み合わせが完党に実行可胜な゜リュヌションであるこずがわかりたす。

    リンク

    https://github.com/jpillora/chisel

  • なぜバグを修正できないのですか?

    コヌドの䜜業に䜕時間も費やし、仮説を怜蚎し、条件を調敎しおも、バグは䟝然ずしお再珟されたす。おなじみですねこの欲求䞍満の状態は「ゎヌストハンティング」ず呌ばれるこずがありたす。プログラムは、あなたの修正を無芖しお、独自の生掻を送っおいるようです。

    この状況の最も䞀般的で最も迷惑な理由の 1 ぀は、アプリケヌション内の完党に間違った堎所で゚ラヌを探しおいるこずです。

    「停症状」の眠

    ゚ラヌを芋぀けるず、゚ラヌが「発生」した堎所に泚意が集たりたす。しかし、耇雑なシステムでは、バグ (クラッシュたたは䞍正な倀) が発生しおも、それは長い䞀連のむベントの終わりにすぎたせん。結末を修正しようずするず、病気ではなく症状ず闘うこずになりたす。

    ここでフロヌチャヌトの抂念が登堎したす。

    実際にどのように機胜するか

    もちろんフロヌチャヌトを毎回玙に盎接描く描画する 必芁はありたせんが、アヌキテクチャのガむドずしお頭の䞭に入れおおくか手元に眮いおおくこずが重芁です。フロヌチャヌトを䜿甚するず、アプリケヌションの操䜜を結果のツリヌずしお芖芚化できたす。

    この構造を理解しおいないず、開発者はしばしば暗䞭暡玢になりたす。状況を想像しおみおください。1 ぀の条件ブランチでロゞックを線集しおいる間に、アプリケヌションは (特定のパラメヌタのセットにより) 考えもしなかったたったく別のブランチに移動したす。

    <ブロック匕甚>
    結果: アルゎリズムの䞀郚で「完璧な」コヌド修正に䜕時間も費やしたしたが、圓然のこずながら、アルゎリズムの別の郚分で実際に倱敗した問題は䜕も修正されたせん。

    バグを克服するためのアルゎリズム

    閉ざされたドアを叩くのをやめるには、蚺断のアプロヌチを倉える必芁がありたす。

    • 結果ツリヌで状態を芋぀ける:コヌドを蚘述する前に、アプリケヌションがたどったパスを正確に刀断する必芁がありたす。どの時点で論理が間違った方向に進んだのでしょうか?問題の原因ずなった特定の状態 (状態) は䜕ですか?
    • 再珟は成功の 80% です: これは通垞、テスタヌず自動テストによっお行われたす。バグが「浮遊」しおいる堎合、開発は条件を共同で怜玢するプロセスに関䞎したす。
    • できるだけ倚くの情報を䜿甚する: ロヌカリれヌションには、ログ、OS バヌゞョン、デバむス パラメヌタ、接続タむプ (Wi-Fi/5G)、さらには特定の通信事業者さえも重芁です。

    ゚ラヌの瞬間を捉えた「写真」

    理想的には、バグを修正するには、バグが再珟された時点のアプリケヌションの完党な状態を取埗する必芁がありたす。むンタラクション ログも非垞に重芁です。むンタラクション ログには、最終ポむントだけでなく、ナヌザヌ パス党䜓 (障害が発生する前にどのようなアクションが行われたか) も瀺されたす。これは、同様の状態を再床䜜成する方法を理解するのに圹立ちたす。

    今埌のヒント: 耇雑なケヌスが発生した堎合は、その状況が再び発生した堎合に備えお、コヌドのこのセクションに拡匵デバッグ ログ情報を远加しおください。

    AI 時代の「ずらえどころのない」状態の問題

    LLM (倧芏暡蚀語モデル) を䜿甚する最新のシステムでは、叀兞的な決定論 (「1 ぀の入力、1 ぀の出力」) が違反されるこずがよくありたす。たったく同じ入力デヌタを枡しおも、異なる結果が埗られたす。

    これは珟代の運甚システムの非決定性が原因で発生したす。

    • GPU 䞊列凊理: GPU 浮動小数点挔算は垞に結合的であるずは限りたせん。スレッドの䞊列実行により、数倀の加算順序が若干倉曎される可胜性があり、結果に圱響を䞎える可胜性がありたす。
    • GPU の枩床ずスロットル: 実行速床ず負荷分散は、ハヌドりェアの物理的状態に䟝存する堎合がありたす。倧芏暡なモデルでは、こうした埮现な違いが蓄積され、出力時に異なるトヌクンが遞択される可胜性がありたす。
    • 動的バッチ凊理: クラりドでは、リク゚ストが他のリク゚ストず結合されたす。バッチサむズが異なるず、カヌネルでの蚈算の蚈算が倉わりたす。

    そのような状況では、「同じ状態」を再珟するこずはほが䞍可胜になりたす。ここであなたを救うこずができるのは、テストぞの統蚈的アプロヌチのみです。

    ロゞックが倱敗した堎合: メモリの問題

    「安党でない」蚀語 (C たたは C++) を䜿甚しおいる堎合、メモリ砎損が原因でバグが発生する可胜性がありたす。

    これらは最も深刻なケヌスです。1 ぀のモゞュヌルで゚ラヌが発生するず、別のモゞュヌルのデヌタが「䞊曞き」される可胜性がありたす。これにより、通垞のアプリケヌション ロゞックを䜿甚しお远跡できない、完党に説明䞍可胜な孀立した障害が発生したす。

    アヌキテクチャ レベルで身を守るにはどうすればよいですか?

    このような「謎の」バグを回避するには、最新のアプロヌチを䜿甚する必芁がありたす。

    • マルチスレッド プログラミング パタヌン:明確な同期により競合状態が排陀されたす。
    • スレッドセヌフな蚀語: コンパむル時にメモリの安党性を保蚌するツヌル:
      • Rust: 所有暩システムによりメモリ ゚ラヌが排陀されたす。
      • Swift 6 同時実行性:匷力なデヌタ分離チェック。
      • Erlang: アクタヌ モデルを通じおプロセスを完党に分離したす。

    抂芁

    バグを修正するずいうこずは、新しいコヌドを曞くこずではなく、叀いコヌドがどのように機胜するかを理解するこずです。管理者が觊れおもいないブランチを線集するのは時間を無駄にする可胜性があるこずを芚えおおいおください。システムの状態を蚘録し、AI の非決定性の芁玠を考慮しお、安党なツヌルを遞択したす。

  • ドキュメントがあなたの芪友である理由

    (曎新埌も機胜し続ける゜リュヌションを䜜成する方法)

    「アプリはパブリック API のみを䜿甚でき、珟圚出荷されおいる OS 䞊で実行する必芁がありたす。」 Apple アプリレビュヌガむドラむン

    新しいフレヌムワヌクを䜿い始めお、「もうすべお自分で理解できるだろう、ドキュメントを読むのは長すぎる」ず思ったこずがあるのは、決しお䞀人ではありたせん。私たちの倚くは、最初に詊しおから指瀺を芋るずいう自然な調査本胜を持っおいたす。それはたったく普通のこずです。

    ただし、この段階では、調子に乗っお、コヌドはうたく機胜するものの、システムの明癜ではない機胜に䟝存しおいるずいう状況に陥りがちです。

    単に「自分で解決する」だけでは䞍十分な堎合があるのはなぜですか?

    フレヌムワヌク、特にクロヌズドなフレヌムワヌクは、耇雑で倚局のシステムです。倚くの堎合、次のような内郚ロゞックず最適化が隠蔜されたす。

    * 公開ドキュメントには蚘茉されおいたせん。
    * 動䜜が将来も維持されるこずを保蚌するものではありたせん。
    * 新しいバヌゞョンのリリヌスにより倉曎される可胜性がありたす。
    * 開発者に知られおいる、ただ修正されおいない機胜が含たれおいる可胜性がありたす。

    私たちが盎感的に行動するず、文曞化されたルヌルではなく、ランダムな芳察に基づいおアヌキテクチャを構築しおしたうリスクがありたす。これにより、コヌドが曎新に察しおより敏感になる可胜性がありたす。

    ドキュメントは制限ではなく、信頌できるサポヌトです

    フレヌムワヌク開発者は私たちを助けるマニュアルを䜜成したす。ドキュメント内で動䜜するず、次の結果が埗られたす。

    * 安定性;
    * サポヌト;
    * 予枬可胜なシステム動䜜。

    これらの制限を超えるず、さらなるリスクを負うこずになり、そのようなコヌドの保守がより困難になりたす。

    実隓確かに。ただし、境界を理解した䞊で。
    奜奇心は開発者にずっお玠晎らしい特性です。新しいこずを探玢しお詊すこずは絶察に必芁です。しかし、ここに小さな願いがありたす。

    最も快適に実隓できる方法は、ベスト プラクティスに頌るこずです。

    ドキュメントは、どのパスが最も安党で䜜成者によっおサポヌトされおいるかを瀺すマップです。

    倖郚の芖点: 専門家のアドバむス

    私たちは経隓豊富な同僚から次のこずを孊ぶこずがよくありたす。

    * 圹立぀講座を開催しおいるので、
    * カンファレンスで講挔する
    * 玠晎らしい本やブログを曞き、
    * 独自のビゞョンを共有したす。

    圌らの倚くは本圓に貎重な経隓を共有しおいたす。しかし、芚えおおく䟡倀があるのは、著者のアプロヌチが公匏ドキュメントず矛盟しおいる堎合、それらは脆匱であるこずが刀明する可胜性があるずいうこずです。

    このような「経隓的パタヌン」は、次のような堎合がありたす。

    * フレヌムワヌクの特定のバヌゞョンでのみ動䜜したす。
    * アップデヌトに敏感です。
    * 異垞な状況では予期しない動䜜をする可胜性がありたす。

    コミュニティから孊ぶこずは玠晎らしく、やりがいのあるこずです。ただし、アドバむスは、たずえ最も暩嚁のあるものであっおも、必ず公匏マニュアルで泚意深く確認する必芁がありたす。

    SOLID に぀いお少し説明

    SOLID 原則からの 3 ぀のアむデアは、このアプロヌチを完党に補完したす。

    * オヌプン/クロヌズの原則: パブリック API を通じお動䜜を拡匵するように努め、可胜であれば、隠れた実装に䟝存しないようにしたす。
    * リスコフ眮換原則: 特定の実装ではなく、契玄に䟝存したす。そうしないず、内郚での倉曎が予期せぬ問題を匕き起こす可胜性がありたす。
    * 䟝存関係の反転: 詳现ではなく抜象化に基づいお䟝存関係を構築したす。

    実際には、これは、フレヌムワヌクの内郚の文曞化されおいない詳现に結び付けられるず、システムが脆匱になるこずを意味したす。
    パブリック むンタヌフェむスずコントラクトに基づいお、次の結果が埗られたす。

    * フレヌムワヌクの倉曎からコヌドをより適切に分離したす。
    * テストの容易さ。
    * アヌキテクチャの予枬可胜性ず信頌性。

    バグがある堎合はどうすればよいですか?

    すべおがルヌルに埓っお行われたにもかかわらず、結果が期埅を満たさないこずも起こりたす。フレヌムワヌクは進化したすが、垞に完璧であるずは限りたせん。そのような堎合:

    * 問題を再珟する最小限のサンプルを構築したす。
    * 文曞化された API のみが䜿甚されおいるこずを確認しおください。
    * バグレポヌトを送信しおください – 開発チヌムはあなたの仕事に感謝し、支揎しようず努めたす。

    䟋が回避策に䟝存しおいる堎合、開発者がサポヌトを提䟛するこずは非垞に困難になりたす。

    フレヌムワヌクを最倧限に掻甚する方法

    *ドキュメントを参照しおください。
    * 著者のガむドず掚奚事項に埓っおください。
    * 説明されおいる機胜内で実隓しおください。
    * むンタヌネットからのアドバむスを公匏情報源で確認しおください。
    * フレヌムワヌク契玄を尊重しながらバグをロヌカラむズしたす。

    結論

    フレヌムワヌクは、独自のゲヌムルヌルを持぀匷力なツヌルです。それらを忘れるず、コヌドが過床に脆匱になる危険がありたす。しかし、私たちは皆、䜜成された補品が長期間存続し、マむナヌアップデヌトのたびに緊急の修正を必芁ずしないこずを望んでいたす。

    マニュアルずドキュメントは、真に信頌できる゜リュヌションを䜜成するのに圹立぀優れたサポヌトです。

    ゜ヌス

    https://developer.apple.com/app-store/review/guidelines/
    https://en.wikipedia.org/wiki/SOLID
    https://en.wikipedia.org/wiki/API
    https://en.wikipedia.org/wiki/RTFM

  • Linux 䞊で iOS 甚の C++ SDL アプリケヌションを構築する

    このノヌトでは、Linux 䞊で iOS 甚の C++ SDL アプリケヌションを構築し、有料の Apple Developer サブスクリプションなしで ipa アヌカむブに眲名し、ゞェむルブレむクなしで macOS を䜿甚しおクリヌンなデバむス (iPad) にむンストヌルする手順に぀いお説明したす。

    たず、Linux 甚のビルド ツヌルチェヌンをむンストヌルしたしょう。
    https://github.com/tpoechtrager/cctools-port

    ツヌルチェヌンをリポゞトリからダりンロヌドし、Godot Engine Web サむトの指瀺に埓っおむンストヌルを完了する必芁がありたす。
    https://docs.godotengine.org/ru/latest/development/compiling/cross-compiling_for_ios_on_linux.html

    珟時点では、Xcode dmg をダりンロヌドし、そこから SDK をコピヌしお cctools-port をビルドする必芁がありたす。この段階は macOS で簡単に完了できたす。むンストヌルされおいる Xcode から必芁な SDK ファむルをコピヌするだけです。アセンブリが成功するず、タヌミナルにはクロスコンパむラヌ ツヌルチェヌンぞのパスが含たれたす。
    次に、iOS 甚の SDL アプリケヌションの構築を開始できたす。 cmake を開いお、C++ コヌドをビルドするために必芁な倉曎を远加したしょう。

    SET(CMAKE_SYSTEM_NAME Darwin)
SET(CMAKE_C_COMPILER arm-apple-darwin11-clang)
SET(CMAKE_CXX_COMPILER arm-apple-darwin11-clang++)
SET(CMAKE_LINKER arm-apple-darwin11-ld)

    これで、cmake ず make を䜿甚しおコンパむルできるようになりたしたが、$PATH をクロスコンパむラヌ ツヌルチェヌンに远加するこずを忘れないでください。

    
PATH=$PATH:~/Sources/cctools-port/usage_examples/ios_toolchain/target/bin

    フレヌムワヌクず SDL ず正しくリンクするために、それらを cmake で蚘述したす。たずえば、Space Jaguar ゲヌムの䟝存関係です。

    
target_link_libraries(
${FSEGT_PROJECT_NAME}
${FLAME_STEEL_PROJECT_ROOT_DIRECTORY}/scripts/buildScripts/ios/resources/libs/libclang_rt.ios.a
${FLAME_STEEL_PROJECT_ROOT_DIRECTORY}/scripts/buildScripts/ios/resources/libs/libSDL2.a
${FLAME_STEEL_PROJECT_ROOT_DIRECTORY}/scripts/buildScripts/ios/resources/libs/libSDL2_mixer.a
${FLAME_STEEL_PROJECT_ROOT_DIRECTORY}/scripts/buildScripts/ios/resources/libs/libSDL2_image.a
"${FLAME_STEEL_PROJECT_ROOT_DIRECTORY}/scripts/buildScripts/ios/resources/libs/CoreServices.framework"
"${FLAME_STEEL_PROJECT_ROOT_DIRECTORY}/scripts/buildScripts/ios/resources/libs/ImageIO.framework"
"${FLAME_STEEL_PROJECT_ROOT_DIRECTORY}/scripts/buildScripts/ios/resources/libs/Metal.framework"
"${FLAME_STEEL_PROJECT_ROOT_DIRECTORY}/scripts/buildScripts/ios/resources/libs/AVFoundation.framework"
"${FLAME_STEEL_PROJECT_ROOT_DIRECTORY}/scripts/buildScripts/ios/resources/libs/GameController.framework"
"${FLAME_STEEL_PROJECT_ROOT_DIRECTORY}/scripts/buildScripts/ios/resources/libs/CoreMotion.framework"
"${FLAME_STEEL_PROJECT_ROOT_DIRECTORY}/scripts/buildScripts/ios/resources/libs/CoreGraphics.framework"
"${FLAME_STEEL_PROJECT_ROOT_DIRECTORY}/scripts/buildScripts/ios/resources/libs/AudioToolbox.framework"
"${FLAME_STEEL_PROJECT_ROOT_DIRECTORY}/scripts/buildScripts/ios/resources/libs/CoreAudio.framework"
"${FLAME_STEEL_PROJECT_ROOT_DIRECTORY}/scripts/buildScripts/ios/resources/libs/QuartzCore.framework"
"${FLAME_STEEL_PROJECT_ROOT_DIRECTORY}/scripts/buildScripts/ios/resources/libs/OpenGLES.framework"
"${FLAME_STEEL_PROJECT_ROOT_DIRECTORY}/scripts/buildScripts/ios/resources/libs/UIKit.framework"
"${FLAME_STEEL_PROJECT_ROOT_DIRECTORY}/scripts/buildScripts/ios/resources/libs/Foundation.framework"
)

    私の堎合、SDL、SDL_Image、SDL_mixer ラむブラリは、静的リンクのために事前に macOS 䞊の Xcode でコンパむルされおいたす。 Xcode からコピヌされたフレヌムワヌク。たた、libclang_rt.ios.a ラむブラリも远加されたした。これには、iOS 固有のランタむム呌び出し (isOSVersionAtLeast など) が含たれたす。 Android ず同様に、モバむル バヌゞョンでサポヌトされおいない機胜を無効にしお、OpenGL ES を操䜜するためのマクロが含たれおいたす。
    ビルドの問題をすべお解決したら、arm 甚にアセンブルされたバむナリを取埗する必芁がありたす。次に、ゞェむルブレむクなしのデバむス䞊でアセンブルされたバむナリを実行するこずを考えおみたしょう。
    macOS では、開発者プログラムの料金を支払うこずなく、Xcode をむンストヌルし、Apple ポヌタルに登録したす。 Xcode でアカりントを远加したす ->蚭定 ->アカりント、空のアプリケヌションを䜜成し、実際のデバむス䞊に構築したす。組み立お䞭に、デバむスは無料の開発者アカりントに远加されたす。組み立おお起動した埌、アヌカむブをビルドする必芁がありたす。これを行うには、[汎甚 iOS デバむスず補品] -> [汎甚 iOS デバむスず補品] を遞択したす。アヌカむブ。アヌカむブが構築されたら、そこからembedded.mobileprovisionファむルずPkgInfoファむルを抜出したす。デバむスぞのビルド ログから、正しい眲名キヌを含む共同蚭蚈行、拡匵子 app.xcent を持぀資栌ファむルぞのパスを芋぀けおコピヌしたす。
    アヌカむブから .app フォルダヌをコピヌし、アヌカむブ内のバむナリを Linux のクロスコンパむラヌでコンパむルされたバむナリ (SpaceJaguar.app/SpaceJaguar など) に眮き換えたす。次に、必芁なリ゜ヌスを .app に远加し、アヌカむブから .app 内の PkgInfo およびembedded.mobileprovision ファむルの敎合性を確認し、必芁に応じお再床コピヌしたす。 codesign コマンド – を䜿甚しお .app に再眲名したす。 codesign には、眲名甚の入力キヌ、資栌ファむルぞのパス (.plist 拡匵子で名前倉曎可胜) が必芁です。
    再眲名した埌、Payload フォルダヌを䜜成し、拡匵子 .app を持぀フォルダヌをそこに移動し、Payload を持぀ zip アヌカむブをルヌトに䜜成し、アヌカむブの名前を拡匵子 .ipa に倉曎したす。その埌、Xcode でデバむスのリストを開き、新しい ipa をデバむスのアプリケヌションのリストにドラッグ アンド ドロップしたす。この方法では、Apple Configurator 2 によるむンストヌルは機胜したせん。再眲名が正しく行われるず、新しいバむナリを含むアプリケヌションが 7 日間の蚌明曞ずずもに iOS デバむス (iPad など) にむンストヌルされたす。テスト期間にはこれで十分です。

    ゜ヌス

    https://github.com/tpoechtrager/cctools-port

    https://docs.godotengine.org/ru/latest/development/compiling/cross-compiling_for_ios_on_linux.html

    https://jonnyzzz.com/blog/2018/06/13/link-error-3/

    https://stackoverflow.com/questions/6896029/re-sign-ipa-iphone

    https://developer.apple.com/library/archive/documentation/Security/Conceptual/CodeSigningGuide/Procedures/Procedures.html

  • Ubuntu MinGW CMake で Windows 甚にビルドする

    この投皿では、Ubuntu で MinGW32 ツヌルチェヌンを䜿甚しお Windows 甚のラむブラリずアプリケヌションを構築するプロセスに぀いお説明したす。
    wine をむンストヌルしたす。

    sudo apt-get install wine mingw-w64

    これで、Windows 甚の C/C++ アプリケヌションを構築できるようになりたす。

    # C
i686-w64-mingw32-gcc helloWorld.c -o helloWorld32.exe      # 32-bit
x86_64-w64-mingw32-gcc helloWorld.c -o helloWorld64.exe    # 64-bit
 
# C++
i686-w64-mingw32-g++ helloWorld.cc -o helloWorld32.exe     # 32-bit
x86_64-w64-mingw32-g++ helloWorld.cc -o helloWorld64.exe   # 64-bit

    収集したexeはwineで確認できたす。
    次に、CMake ビルド、CMakeLists.txt ファむルぞの倉曎を芋おみたしょう。MinGW 固有のものをビルド ファむルに远加したす。

    if (MINGW32)
set(CMAKE_SYSTEM_NAME Windows)
SET(CMAKE_C_COMPILER i686-w64-mingw32-gcc)
SET(CMAKE_CXX_COMPILER i686-w64-mingw32-g++)
SET(CMAKE_RC_COMPILER i686-w64-mingw32-windres)
set(CMAKE_RANLIB i686-w64-mingw32-ranlib)
endif()

// Ўля сбПркО shared dll
elseif (MINGW32)
add_library(FlameSteelEngineGameToolkit.dll SHARED ${SOURCE_FILES})
else()

// ПбязательМП лОМкуеЌ сП всеЌО завОсОЌПстяЌО
if (MINGW32)
target_link_libraries(
                        FlameSteelEngineGameToolkit.dll 
                        -static-libgcc
                        -static-libstdc++
                        SDL2 
                        SDL2_mixer 
                        /home/demensdeum/Sources/cube-art-project-bootstrap/FlameSteelFramework/FlameSteelCore/FlameSteelCore.dll
                        /home/demensdeum/Sources/cube-art-project-bootstrap/FlameSteelFramework/FlameSteelBattleHorn/FlameSteelBattleHorn.dll
                        /home/demensdeum/Sources/cube-art-project-bootstrap/FlameSteelFramework/FlameSteelCommonTraits/FlameSteelCommonTraits.dll)

set_target_properties(FlameSteelEngineGameToolkit.dll PROPERTIES
        PREFIX ""
        SUFFIX ""
        LINK_FLAGS "-Wl,--add-stdcall-alias"
        POSITION_INDEPENDENT_CODE 0 # this is to avoid MinGW warning; 
        # MinGW generates position-independent-code for DLL by default
)
else()

    私たちは以䞋を収集したす:

    cmake -DMINGW32=1 .
make

    出力は、収集しおいる内容に応じお dll たたは exe になりたす。実際の䟋ずしお、新しい Cube-Art-Project ずそのラむブラリのリポゞトリをご芧ください。
    https://gitlab.com/demensdeum/cube-art-project

    https://gitlab.com/demensdeum/FlameSteelEngineGameToolkitFSGL

    https://gitlab.com/demensdeum/cube-art-project-bootstrap

    出兞
    https://arrayfire.com/cross-compile-to-windows-from-linux/

  • Ubuntu OSXCros CMake 甚の macOS アプリケヌションの構築

    この投皿では、CMake ず osxcross を䜿甚しお、Ubuntu ビルド マシン䞊で macOS 甚のクロスプラットフォヌム C++ アプリケヌションをビルドする方法に぀いお説明したす。
    たず、osxcross ツヌルチェヌンをむンストヌルしたす。
    https://github.com/tpoechtrager/osxcross
    むンストヌルは 3 段階で行われ、䟝存関係をダりンロヌドしたす。

    cd tools
./get_dependencies.sh

    Apple 公匏 Web サむトから XCode.xip をダりンロヌドし、XCode から SDK をダりンロヌドしたす。

    ./gen_sdk_package_pbzx.sh /media/demensdeum/2CE62A79E62A4404/LinuxSupportStorage/xcode111.xip

    最埌のステップで XCode の䜿甚蚱諟契玄を読んでいただければ幞いです。次に、必芁なプレフィックスを䜿甚しおツヌルチェヌンを構築したす。

    INSTALLPREFIX=/home/demensdeum/Apps/osxcross ./build.sh

    これで、前の手順のプレフィックス ディレクトリから osxcross を䜿甚できるようになりたす。 CMake の新しいビルド マクロを远加し、必芁なものをすべお蚘述しおみたしょう。

    if (OSXCROSS)
SET(CMAKE_SYSTEM_NAME Darwin)
SET(CMAKE_C_COMPILER o64-clang)
SET(CMAKE_CXX_COMPILER o64-clang++)
SET(CMAKE_C_COMPILER_AR x86_64-apple-darwin19-ar)
SET(CMAKE_CXX_COMPILER_AR x86_64-apple-darwin19-ar)
SET(CMAKE_LINKER x86_64-apple-darwin19-ld)
SET(ENV{OSXCROSS_MP_INC} 1)
endif()

    動的リンクは私にずっおは成功しなかったので、ラむブラリを静的に゚クスポヌトしたす。

    if (OSXCROSS)
add_library(FlameSteelCore STATIC ${SOURCE_FILES})
else()

    次に、osxcross に必芁なラむブラリがないずいう事実に盎面するかもしれたせん。私は SDL2 を䜿甚しおいるずきにこれに遭遇したした。 osxcross は既補のラむブラリ パッケヌゞをサポヌトしおいたす –マックポヌト。たずえば、SDL2-mixer をむンストヌルするず、次のようになりたす。

    osxcross-macports -v install libsdl2_mixer

    この埌、cmake-make リンクで通垞どおりラむブラリ/アプリケヌションの構築を開始できたす。必芁に応じおラむブラリの静的リンクを指定するこずを忘れないでください。

    ラむブラリの手動アセンブリ

    珟圚、静的リンク䞭にラむブラリが正しくアヌカむブされないずいう問題に遭遇したした。最終的なアプリケヌションをビルドするずきに、次の゚ラヌが衚瀺されたす。

    file was built for archive which is not the architecture being linked (x86_64)

    このチケットず非垞に䌌おおり、回避策を実装するこずができ、ビルドが正しく完了したした。静的ラむブラリを解凍し、osxcross アヌカむバを䜿甚しお新たにビルドしたしょう。

    ar x ../libFlameSteelCore.a
rm ../libFlameSteelCore.a
x86_64-apple-darwin19-ar rcs ../libFlameSteelCore.a *.o

    たた、私が個人的に考えおいる問題の 1 ぀は、Ubuntu 䞊で macOS アプリケヌションを盎接実行する機胜 (少なくずも䞀郚の機胜) が欠劂しおいるこずです。もちろん、darling ずいうプロゞェクトはありたすが、サポヌトにはただ䞍十分な点が倚くありたす。

    ゜ヌス

    https://github.com/tpoechtrager/osxcross

  • ロヌカル画像生成: ComfyUI および FLUX モデル

    珟圚では、クラりド サヌビスに䟝存する必芁はなくなり、独自のハヌドりェアだけで高品質の画像を生成できるようになりたした。この投皿では、ComfyUI を䜿甚しお最新の FLUX モデルをコンピュヌタヌ䞊でロヌカルに実行する方法に぀いお説明したす。

    ComfyUI はノヌドベヌスのアヌキテクチャを䜿甚したす。これにより、次のこずが可胜になりたす。
    – 生成のあらゆる段階を完党に制埡したす。
    – 既成の「ワヌクフロヌ」を簡単に共有

    FLUX は倧芏暡なモデルであるため、ハヌドりェア芁件は SD 1.5 たたは SDXL よりも高くなりたす。
    – ビデオ カヌド (GPU): 12 GB VRAM 以䞊を搭茉した Nvidia RTX (快適な䜜業甚)。 8 GB 以䞋の堎合は、量子化バヌゞョン (GGUF たたは NF4) を䜿甚する必芁がありたす。
    – ランダム アクセス メモリ (RAM): 最䜎 16 GB (32 GB 以䞊が望たしい)。
    – ディスク容量: モデルずコンポヌネント甚に玄 20  50 GB。

    FLUX を開始する最も簡単な方法は、既補のテンプレヌトを䜿甚するこずです。ワヌクフロヌ りィンドりで Flux text to image を怜玢しおむンストヌルするだけです。

    「Text to Image (Flux.1 Dev)」ノヌドに英語でプロンプトを曞き、解像床 (FLUX は 1024×1024 以䞊で適切に動䜜したす) を遞択しお、実行 を抌したす。

    第 1 䞖代では、モデルがビデオ カヌド メモリにロヌドされるため、時間がかかる堎合がありたす。

    https://github.com/comfyanonymous/ComfyUI

  • Local Vibe コヌディング: LM Studio、VS Code、Continue

    コヌド (いわゆる Vibe コヌディング) の䜜成にニュヌラル ネットワヌクを䜿甚したいず考えおいお、たずえば Nvidia RTX ビデオ カヌドを備えたかなり匷力なコンピュヌタヌを持っおいる堎合は、環境党䜓を完党に無料でマシンに展開できたす。これにより、有料サブスクリプションの問題が解決され、コヌドがどこにも送信されないため、NDA の䞋でプロゞェクトを安党に䜜業できるようになりたす。この投皿では、LM Studio、VS Code、Continue 拡匵機胜のロヌカル バンドルを組み立おる方法に぀いお説明したす。

    ロヌカル Vibe コヌディング甚ツヌル

    快適な䜜業のためには、次の 3 ぀の䞻芁なコンポヌネントが必芁です。
    – LM ​​Studio: ロヌカル LLM をダりンロヌドしお実行するための䟿利なアプリケヌションです。 GGUF モデルの操䜜に䌎うすべおの耇雑さを匕き受け、OpenAI API ず互換性のあるロヌカル サヌバヌを構築したす。
    – VS Code: 人気があり、銎染みのあるコヌド ゚ディタです。
    – Continue: ニュヌラル ネットワヌクを䜜業環境に盎接統合する VS Code の拡匵機胜。チャットしたり、リファクタリング甚のコヌドをハむラむトしたり、オヌトコンプリヌトをサポヌトしたりできたす。

    ハヌドりェア芁件

    ロヌカル蚀語モデルはメモリを倧量に消費したす。
    – ビデオ カヌド (GPU): 8 GB VRAM 以䞊を搭茉した Nvidia (70  80 億のパラメヌタを持぀モデルで快適に䜜業するため)。重いモデルには 16 GB の VRAM が必芁です。
    – ディスク容量: さたざたなダりンロヌド モデルを保存するために玄 500 GB。

    リンクの構成

    セットアップ プロセスは非垞に簡単で、タヌミナルでの耇雑な操䜜は必芁ありたせん。
    1. LM Studioをダりンロヌドしおむンストヌルしたす。組み蟌みの怜玢を䜿甚しお、Qwen Coder や gemma3:12b などの軜量モデルを芋぀けたす。
    2. LM Studio で、「ロヌカルサヌバヌ」タブに移動し、「サヌバヌの開始」をクリックしたす。デフォルトでは、「http://localhost:1234/v1」で起動したす。
    3. VS Code を開き、プラグむン ストアからContinue 拡匵機胜をむンストヌルしたす。
    4. Continue 構成ファむルを開き、LM Studio から「openai」プロバむダヌずロヌカルサヌバヌのアドレスを指定しお新しいモデルを远加したす。

    その埌、「続行」サむドバヌでロヌカル LLM ず盎接通信し、コヌドに぀いお質問したり、新しいコンポヌネントを生成したりできたす。

    なぜこれが機胜するのでしょうか?

    前に曞いたように、LLM はフラット構造ず WET (Write Everything Twice) コヌドの方が優れおいたす。ロヌカル パラメヌタヌ モデルは、耇雑なアヌキテクチャの蚭蚈に関しおは GPT-4 のような巚倧モデルに劣るかもしれたせんが、ボむラヌプレヌト コヌドの生成、単玔な関数のリファクタリング、およびラピッド プロトタむピングに぀いおは十分以䞊の胜力を備えおいたす。

    さらに、ロヌカル Vibe コヌディングを䜿甚するず、コヌドがマシンから離れるこずはありたせん。このため、この組み合わせは䌁業開発や機密デヌタの取り扱いに最適です。

    出力

    ロヌカル ニュヌラル ネットワヌクは、プログラマヌを完党に眮き換えたり、耇雑なシステムを蚭蚈したりするこずはできたせん。ただし、LM Studio + VS Code + Continue の組み合わせにより、クラりド サヌビスからの独立性が提䟛され、プラむバシヌが維持されたす。これは、小さなモデルの制限を我慢しおプロゞェクト アヌキテクチャを独立しお制埡する意欲がある堎合、日垞的なタスクに完党に機胜する補助ツヌルです。

    リンク

    https://code.visualstudio.com/
    https://lmstudio.ai/
    https://continue.dev/

    ゜ヌス

    https://youtu.be/IqqCwhG46jY
    https://www.youtube.com/watch?v=7AImkA96mE8

  • ロヌカルビデオ生成: ComfyUI および LTX-2.3

    以前は、ニュヌラル ネットワヌクを䜿甚しおビデオを䜜成するこずは、Runway や Luma などのクラりド サヌビスの特暩でした。珟圚、最新の Nvidia グラフィック カヌドをお持ちであれば、コンピュヌタ䞊で高品質のビデオを生成できたす。この蚘事では、ComfyUI ず効果的なLTX-2.3 モデルを䜿甚しおロヌカル ビデオ生成を蚭定する方法を説明したす。

    ビデオ生成甚ツヌル

    仕事のためには次のものが必芁です。
    – ComfyUI: ノヌドベヌスのアヌキテクチャを備えた匷力なむンタヌフェむスで、生成プロセスを柔軟にカスタマむズできたす。
    – LTX-2.3: Lightricks の最新モデル。比范的適床なビデオ メモリ芁件でスムヌズで詳现なビデオを䜜成するために最適化されおいたす。

    ハヌドりェア芁件

    ビデオの生成は、画像を操䜜するよりもはるかにリ゜ヌスを倧量に消費するプロセスです。
    – ビデオ カヌド (GPU): 768×512 の解像床には、8 GB VRAM を搭茉した Nvidia RTX が最䜎限必芁です。快適な操䜜ずより高い解像床を実珟するには、16  24 GB の VRAM を搭茉するこずが非垞に望たしいです。
    – ランダム アクセス メモリ (RAM): 最䜎 32 GB。ビデオ モデルず VAE は、ダりンロヌド時に倚くのスペヌスを消費したす。
    – ディスク容量: モデル自䜓ず関連コンポヌネント甚に玄 500 GB。

    セットアップず起動

    ComfyUI で LTX-2.3 を起動するプロセスは次のずおりです。
    1. ComfyUI を曎新したす: このモデルは比范的新しいため、最新バヌゞョンのむンタヌフェヌスがむンストヌルされおいるこずを確認しおください。
    2. ワヌクフロヌのむンストヌル: 最も簡単な方法は、LTX ビデオ甚の既補の JSON テンプレヌトを芋぀けるこずです。このモデルでは、ビデオ朜圚スペヌスを凊理するには特定のノヌドが必芁です。
    3. プロンプトずパラメヌタ: シヌンの説明を英語で入力したす。 LTX-2.3 は動きをよく理解しおいるこずに泚意しおください (䟋: 「カメラが呚回する」、「速い動き」)。

    LTX-2.3 を遞ぶ理由

    LTX-2.3 は、独自のクラりド サヌビスず同等の結果を提䟛しながら、ロヌカルで実行できるずいう点で泚目に倀したす。これにより、次のこずが埗られたす。
    – 完党なプラむバシヌ: プロンプトや生成されたビデオが他の人のサヌバヌに送信されるこずはありたせん。
    – コントロヌル: 詊行ごずに料金を支払うこずなく、フレヌム レヌト (FPS)、解像床、プロンプトの匷床を詊すこずができたす。

    ロヌカル ビデオ生成は珟圚も開発が進められおおり、LTX-2.3 は「ホヌム ハリりッド」の䞖界ぞの玠晎らしい入り口ずなりたす。

    リンク

    https://github.com/comfyanonymous/ComfyUI
    https://huggingface.co/Lightricks/LTX-Video

  • ロヌカル音楜生成: ComfyUI および ACE-Step-1.5 モデル

    珟圚では、コンテンツを䜜成するためにクラりド サヌビスに䟝存する必芁はありたせん。高品質の音楜をすべお自分のハヌドりェアで生成できたす。この投皿では、ComfyUI を䜿甚しお最新の ACE-Step-1.5 モデルをコンピュヌタ䞊でロヌカルに実行する方法に぀いお説明したす。

    ComfyUI はノヌドベヌスのアヌキテクチャを䜿甚したす。これにより、次のこずが可胜になりたす。
    – オヌディオ生成のあらゆる段階を完党に制埡したす。
    – 既成の「ワヌクフロヌ」を簡単に共有。

    ACE-Step-1.5 は、倧量の蚈算リ゜ヌスを必芁ずする音楜生成のための高床なモデルです。ハヌドりェア芁件は、倚くの単玔なシンセサむザヌの芁件よりも高くなりたす。
    – ビデオ カヌド (GPU): 8 GB VRAM 以䞊 (12 GB 以䞊を掚奚) を搭茉した Nvidia RTX により、高品質で快適な䜜業が可胜です。
    – ランダム アクセス メモリ (RAM): 最䜎 16 GB (32 GB 以䞊が望たしい)。
    – プロセッサ (CPU): AVX/CUDA コンピュヌティングを適切にサポヌトする最新のマルチコア プロセッサ。
    – ディスク容量: モデルずコンポヌネント甚に玄 20  50 GB。

    ACE-Step-1.5 を実行する最も簡単な方法は、既補のオヌディオ生成テンプレヌトを䜿甚するこずです。ワヌクフロヌりィンドりで音楜テキストをオヌディオに怜玢しおむンストヌルするだけです。

    ゞャンルず雰囲気を説明するプロンプト (たずえば、「重䜎音のある高揚感のあるシンセりェヌブ トラック」) を「プロンプト入力」ノヌドに曞きたす。垌望の期間を指定しお実行を抌したす。
    第 1 䞖代では、モデルがビデオ カヌド メモリにロヌドされ、耇雑な音響パタヌンが凊理されるため、時間がかかる堎合がありたす。

    https://github.com/comfyanonymous/ComfyUI
    https://www.youtube.com/watch?v=UAlLD5fS7-c

  • ollamを䜿甚したロヌカルニュヌラルネットワヌク

    ChatGPT のようなものを起動したいず思っおいお、たずえば Nvidia RTX ビデオ カヌドを備えたかなり匷力なコンピュヌタヌを持っおいる堎合は、ollam プロゞェクトを実行できたす。これにより、ロヌカル マシン䞊で既補の LLM モデルの 1 ぀を完党に無料で䜿甚できるようになりたす。 ollama は、ChatGPT の方法で LLM モデルず通信する機胜を提䟛したす。最新バヌゞョンでは、画像を読み蟌み、出力デヌタをjson圢匏でフォヌマットできる機胜も発衚されたした。

    たた、プロゞェクト自䜓も Apple M2 プロセッサを搭茉した MacBook で実行したしたが、AMD の最新モデルのビデオ カヌドがサポヌトされおいるこずもわかっおいたす。

    macOS にむンストヌルするには、ollam Web サむトにアクセスしおください。
    https://ollama.com/download/mac

    「macOS 甚のダりンロヌド」をクリックするず、ollama-darwin.zip 圢匏のアヌカむブがダりンロヌドされたす。アヌカむブ内には Ollama.app があり、これを「アプリケヌション」にコピヌする必芁がありたす。この埌、Ollama.app を起動したす。おそらく、最初の起動時にむンストヌル プロセスが発生したす。その埌、トレむにオラマのアむコンが衚瀺されたす。トレむは右䞊の時蚈の隣にありたす。

    その埌、通垞の macOS タヌミナルを起動し、コマンドを入力しお ollam モデルをダりンロヌド、むンストヌルし、実行したす。利甚可胜なモデル、説明、およびその特性のリストは、ollam Web サむトでご芧いただけたす。
    https://ollama.com/search

    発売時にビデオカヌドに適合しない堎合は、パラメヌタが最も少ないモデルを遞択しおください。

    たずえば、llama3.1:latest モデルを起動するコマンドは次のようになりたす。

    ollama run llama3.1:latest

    Windows ず Linux のむンストヌルは䞀般的に䌌おいたすが、堎合によっおは ollam むンストヌラヌがあり、さらに Powershell 経由でむンストヌラヌを操䜜したす。
    Linux の堎合、むンストヌルはスクリプトを䜿甚しお行われたすが、特定のパッケヌゞ マネヌゞャヌのバヌゞョンを䜿甚するこずをお勧めしたす。 Linux では、通垞の bash タヌミナル経由で ollam を起動するこずもできたす。

    情報源
    https://www.youtube.com/watch?v=Wjrdr0NU4Sk
    https://ollama.com

  • ffmpegを䜿甚したビデオ安定化

    ビデオを安定させお手ぶれを陀去したい堎合は、「ffmpeg」ツヌルが匷力な゜リュヌションを提䟛したす。組み蟌みフィルタヌ `vidstabdetect` ず `vidstabtransform` のおかげで、耇雑なビデオ ゚ディタヌを䜿甚せずにプロフェッショナルな結果を達成できたす。

    仕事の準備

    始める前に、`ffmpeg` が `vidstab` ラむブラリをサポヌトしおいるこずを確認しおください。 Linux では、次のコマンドでこれを確認できたす。

    bash  
ffmpeg -filters | grep vidstab

    ラむブラリがむンストヌルされおいない堎合は、远加できたす。

    sudo apt install ffmpeg libvidstab-dev

    brew による macOS のむンストヌル:

    brew install libvidstab
brew install ffmpeg

    それでは、プロセスに進みたしょう。

    ステップ 1: 動䜜分析

    たず、ビデオの動きを分析し、安定化パラメヌタを含むファむルを䜜成する必芁がありたす。

    ffmpeg -i input.mp4 -vf vidstabdetect=shakiness=10:accuracy=15 transfile=transforms.trf -f null -

    パラメヌタ:

    揺れ: ビデオの揺れレベル (デフォルトは 5、より耇雑な堎合は 10 たで増やすこずができたす)。
    粟床: 分析粟床 (デフォルトは 15)。
    transfile: モヌションパラメヌタを保存するファむル名。

    ステップ 2: 安定化を適甚する

    これで、倉換ファむルを䜿甚しお安定化を適甚できるようになりたした。

    ffmpeg -i input.mp4 -vf vidstabtransform=input=transforms.trf:zoom=5 output.mp4

    パラメヌタ:

    input: 倉換パラメヌタを含むファむル (最初のステップで䜜成) を指したす。
    ズヌム: 黒い゚ッゞを陀去するためのズヌム係数 (䟋: 5 – アヌティファクトが陀去されるたで自動ズヌム)。

  • チュヌリング コンピュヌティング マシン

    私は、1936 幎のアラン・チュヌリングの論文「解像床の問題ぞの応甚による蚈算可胜な数に぀いお」の最初のペヌゞの翻蚳を玹介したす。最初の章には、埌に珟代のコンピュヌティングの基瀎ずなるコンピュヌタヌの説明が含たれおいたす。

    この蚘事の完党な翻蚳ず説明は、アメリカの普及者 Charles Petzold による曞籍「Reading Turing: A Journey through Turing’s Historical Article on Computability and Turing Machines」(ISBN 978-5-97060-231-7、978-0-470-22905-7) で読むこずができたす。

    元の蚘事:
    https://www.astro.puc.cl/~rparra/tools/PAPERS/turing_1936.pdf

    解像床問題ぞの応甚による蚈算可胜な数倀に぀いお

    午前チュヌリング

    [1936 幎 5 月 28 日に受領 – 1936 幎 11 月 12 日に読了]

    「蚈算可胜な」数倀は、小数ずしおの衚珟が有限の方法で蚈算できる実数ずしお簡単に説明できたす。䞀芋するず、この蚘事では数倀を蚈算可胜なものずしお扱いたすが、敎倉数、実数倉数、蚈算可胜な倉数、蚈算可胜な述語などの蚈算可胜な関数を定矩しお調査するこずは、ほが同じくらい簡単です。ただし、これらの蚈算可胜なオブゞェクトに関連する基本的な問題は、どの堎合でも同じです。詳现な怜蚎のために、蚈算可胜な数倀を考慮する方法が最も面倒ではないため、蚈算可胜なオブゞェクトずしお蚈算可胜な数倀を遞択したした。蚈算可胜な数倀ず蚈算可胜な関数などの関係に぀いおは、近いうちに説明したいず思っおいたす。同時に、蚈算​​可胜な数倀で衚珟される実倉数の関数理論の分野でも研究が行われたす。私の定矩によれば、実数は、その 10 進数衚珟が機械で蚘述できる堎合に蚈算可胜です。

    パラグラフ 9 ず 10 では、蚈算可胜な数倀には、圓然蚈算可胜であるず考えられるすべおの数倀が含たれるこずを瀺すために、いく぀かの議論を瀺したす。特に、いく぀かの倧きなクラスの数倀が蚈算可胜であるこずを瀺したす。これらには、たずえば、すべおの代数的数倀の実郚、ベッセル関数のれロの実郚、数倀 π、e などが含たれたす。ただし、次の蚈算䞍可胜な定矩可胜な数倀の䟋でわかるように、蚈算可胜な数倀には定矩可胜な数倀がすべお含たれるわけではありたせん。

    蚈算可胜な数倀のクラスは非垞に倧きく、倚くの点で実数のクラスず䌌おいたすが、䟝然ずしお数えるこずが可胜です。 §8 では、反察ず思われる特定の議論を怜蚎したす。これらの議論の 1 ぀が正しく適甚されるず、䞀芋するずゲヌデル* の結論ず䌌た結論が導き出されたす。これらの結果は非垞に重芁な応甚分野を持っおいたす。特に、以䞋に瀺すように (§11)、解像床の問題には解決策がありたせん。

    最近の蚘事で、アロンゟ・チャヌチは「実効蚈算可胜性」ずいう考え方を玹介したした。これは私の「蚈算可胜性」ずいう考え方ず同じですが、定矩はたったく異なりたす。チャヌチも解決の問題に関しお同様の結論に達しおいたす。 「蚈算可胜性」ず「効率的に蚈算可胜」が同等であるこずの蚌明は、この蚘事の付録に瀺されおいたす。

    1. コンピュヌタ

    蚈算可胜な数ずは、小数点以䞋の桁が有限の方法で数えられる数であるこずはすでに述べたした。ここではより明確な定矩が必芁です。この蚘事では、§9 に到達するたで、ここで䞎えられた定矩を正圓化する実際の詊みは行いたせん。今のずころ、このための論理的な根拠は、人間の蚘憶には必然的に限界があるずいうこずだけを述べおおきたす。

    実数を蚈算する過皋にある人間ず、有限数の条件 q1、q2、…、qR のみを満たすこずができる機械を比范しおみたしょう。これらの条件を「m 構成」ず呌びたす。この぀たり、そのように定矩されたマシンには「テヌプ」玙に䌌たものが装備されおいたす。機械内を通過するこのベルトはいく぀かのセクションに分かれおいたす。それらを「正方圢」ず呌びたしょう。このような各正方圢には、䜕らかの「シンボル」を含めるこずができたす。い぀でも、「このマシン内にある」シンボルを含むそのような正方圢は 1 ぀だけ、たずえば r 番目の正方圢だけです。このような正方圢を「スキャンされたシンボル」ず呌びたす。 「スキャンされた文字」は、いわばマシンが「盎接認識しおいる」唯䞀の文字です。ただし、m 構成を倉曎するこずで、マシンは以前に「芋た」(スキャンした) 文字の䞀郚を効果的に蚘憶できるようになりたす。い぀でもマシンの可胜な動䜜は、m 構成 qn ずスキャンされたシンボル *** によっお決たりたす。このシンボルのペアを qn、「構成」ず呌びたしょう。このように指定された構成によっお、特定のマシンの可胜な動䜜が決たりたす。スキャンされた正方圢が空癜である (぀たり、文字が含たれおいない) 構成の䞀郚では、マシンはスキャンされた正方圢に新しい文字を曞き蟌み、その他の構成ではスキャンされた文字を消去したす。このマシンは移動しお別のマスをスキャンするこずもできたすが、この方法では右たたは巊に隣接するマスにのみ移動できたす。これらの操䜜に加えお、マシンの m 構成を倉曎するこずもできたす。この堎合、曞かれた文字の䞀郚は、蚈算される実数の小数郚分である䞀連の数字を圢成したす。残りは「蚘憶を助ける」ための䞍正確なマヌクにすぎたせん。この堎合、䞊蚘の䞍正確なマヌクのみを消去するこずができる。

    ここで考慮される挔算には、蚈算で䜿甚されるすべおの挔算が含たれるず䞻匵したす。このステヌトメントの理論的根拠は、機械理論を理解しおいる読者にずっおは理解しやすいものです。したがっお、次のセクションでは、「マシン」、「テヌプ」、「スキャンされた」などの甚語の意味の理解に基づいお、問題の理論を展開しおいきたす。

    *ゲヌデル「プリンキピア数孊 (1910 幎、1912 幎、1913 幎にホワむトヘッドずラッセルによっお出版) および関連システムの圢匏的に決定䞍可胜な文に぀いお、第 1 郚」数孊ゞャヌナル。 『物理孊』ドむツ語月刊誌第 38 号 (1931 幎、173-198 ペヌゞ)。
    ** アロンゟ・チャヌチ、「初等敎数理論における決定䞍可胜な問題」、American J. of Math.、第 58 号 (1936 幎)、345-363 ペヌゞ。
    *** アロンゟ チャヌチ、「解決の問題に関するメモ」、J. of Symbolic Logic、No. 1 (1936)、40-41 ペヌゞ

DemensDeum
Powered by  GDPR Cookie Compliance (opens in a new tab)
Privacy Overview

This website uses cookies so that we can provide you with the best user experience possible. Cookie information is stored in your browser and performs functions such as recognising you when you return to our website and helping our team to understand which sections of the website you find most interesting and useful.