RTX 5060 1台 vs 社内PC 5〜10台Browser Cluster――100ジョブ実測から「会社で使えるAI基盤」まで本気で作る
会社の中には、意外なほど多くのGPUが眠っている。
- GeForce RTXを積んだ開発PC
- Intel内蔵GPUを持つ事務PC
- Apple Silicon搭載Mac
- AMD GPU搭載PC
- 夜間ほとんど使われていない社員PC
前回の記事では、これらのPCでChromeを開き、WebGPUとWebLLMを使って「ブラウザそのものをAI推論Workerにする」実験を行った。
まずBrowser Worker、WebGPU、WebLLM、Node.js Brokerの基本構成を知りたい場合はこちらから。
“` 前回の記事を別タブで開く → “`前回作ったものは面白い。
しかし、まだ「技術デモ」である。
会社で本当に使うには、もっと厳しい条件を満たさなければならない。
- 複数PCへ本当にJobを分散できること
- 性能が違うPCへ適切に振り分けられること
- Chromeを閉じてもJobが消えないこと
- Brokerを再起動してもQueueが残ること
- Workerごとに認証できること
- 1台が故障しても別PCへJobを戻せること
- AIの処理速度だけでなく回答品質も評価できること
- 既存のPHP・Laravel・PowerShellなどから利用できること
- 業務ごとにAIへ何をさせるか統制できること
- 人間が最終確認する業務フローまで作れること
今回はここまで持っていく。
「ChromeでLLMが動いた」ではなく、「会社にあるPCを本当にAI計算基盤として使えるか」を検証する。
今回作るもの
┌─────────────────────┐
│ AI Broker │
│ │
業務システム ───────▶│ Node.js │
PHP / Laravel │ SQLite Queue │
PowerShell │ Scheduler │
│ Audit Log │
└─────────┬───────────┘
│
┌─────────────────┼──────────────────┐
│ │ │
▼ ▼ ▼
Chrome Worker Chrome Worker Chrome Worker
PC-01 PC-02 PC-03
RTX 5060 Intel GPU Apple GPU
│ │ │
WebGPU WebGPU WebGPU
│ │ │
WebLLM WebLLM WebLLM
│ │ │
Local LLM Local LLM Local LLM
└────── 社内PC 5〜10台まで拡張 ──────┘そして、同じ100件のJobを使い、
RTX 5060 × 1台
VS
Browser Worker × 5〜10台を比較する。
最初に誤解してはいけない：10台だから1件が10倍速くなるわけではない
今回作るクラスタはTensor Parallelismではない。
一つの巨大モデルを10台へ分割して動かすわけではない。
今回やらない
巨大LLM
├── Layer 1〜10 → PC1
├── Layer 11〜20 → PC2
└── Layer 21〜30 → PC3今回行うのはRequest-level Horizontal Scaling。
Job 001 → PC1
Job 002 → PC2
Job 003 → PC3
Job 004 → PC4
Job 005 → PC5
PC3が先に終了
Job 006 → PC3
PC1が終了
Job 007 → PC1つまり、独立したAI処理を複数PCへ並列配布する。
そして会社業務には、この「独立したJob」が非常に多い。
会社業務こそ分散AIと相性がいい
例えば50人分の日報。
日報001 → 要約
日報002 → 要約
日報003 → 要約
...
日報050 → 要約それぞれ独立している。
問い合わせ100件の分類も同じ。
問い合わせ001 → 納期
問い合わせ002 → 品質
問い合わせ003 → 請求
問い合わせ004 → 技術
...設備点検記録、検査記録、会議メモ、過去文書の整理、商品説明生成、メール下書きなども同様である。
1件の処理を10倍速くする必要はない。
100件を同時並行で処理できればよい。
ブラウザLLMはここまで来ている
WebLLMはWebGPUを利用し、LLM推論をブラウザ内で実行するためのオープンソース基盤である。
OpenAI互換Chat Completion API、JSON mode、Web Worker、Service Worker、モデルキャッシュ、独自モデル設定などを持つ。
公式：
https://github.com/mlc-ai/web-llm
さらに2026年5月公開の研究「Llamas on the Web」では、WebGPUを使ったllama.cppバックエンドを16デバイス、8ベンダー、10モデルで評価している。
既存ブラウザLLM実装との比較で、構成によってメモリ使用量29〜33％減、4種類のGPUでdecode throughput 45〜69％向上が報告された。
ブラウザAIは、既に「できるかどうか」ではなく、「どう運用するか」を考える段階へ入りつつある。
今回の比較条件
グループA：RTX 5060 1台
Group:
rtx-single
Worker:
RTX5060-PCRTX 5060側もChrome＋WebGPU＋WebLLMで実行する。
CUDAサーバーとの比較ではなく、Browser Workerとして同条件にする。
グループB：普通の社内PC 5〜10台
Group:
browser-cluster
PC-01 Intel GPU
PC-02 Intel GPU
PC-03 Apple M3
PC-04 AMD GPU
PC-05 NVIDIA GPU
PC-06 Intel GPU
...
PC-10RTX単独テスト時にはBrowser Cluster側を使用しない。
Clusterテスト時にもrtx-single側は参加させない。
これで比較条件を明確に分離する。
何を測るのか
平均応答時間だけでは不十分。
今回は最低でも次を取る。
- 100 Job総処理時間
- jobs/minute
- end-to-end p50
- end-to-end p95
- end-to-end p99
- Inference p50 / p95 / p99
- Completion Token総数
- Cluster全体のEffective tokens/sec
- Job成功率
- Worker別処理件数
- Worker別実測decode tokens/sec
- 失敗・Retry回数
業務バッチで特に重要なのは、
100件全部が終わるまでの時間である。
完成版ソースコード一式
今回の記事用に、会社導入の叩き台として使える実装一式をまとめている。
browser-ai-cluster-enterprise/
│
├── src/
│ ├── server.mjs
│ ├── db.mjs
│ ├── scheduler.mjs
│ ├── business-templates.mjs
│ └── utils.mjs
│
├── public/
│ ├── admin.html
│ ├── admin.js
│ ├── worker.html
│ ├── worker-node.js
│ ├── inference-worker.js
│ ├── business.html
│ ├── business.js
│ └── cluster-config.js
│
├── scripts/
│ ├── compare100.mjs
│ ├── benchmark100.mjs
│ ├── warmup-all.mjs
│ ├── mock-farm.mjs
│ ├── quality-eval.mjs
│ └── integration-test.mjs
│
├── examples/
│ ├── php/
│ ├── powershell/
│ └── evaluation/
│
├── deploy/
│ ├── Caddyfile
│ └── browser-ai-cluster.service
│
└── README.mdNode.js Broker、SQLite永続Queue、Chrome WebGPU Worker、 WebLLM推論Worker、Mock Worker、100ジョブ比較、 業務テンプレート、PHP・PowerShell連携、品質評価ツールを含む実装一式です。
“` 💾 実装一式 ZIP をダウンロード “`前回版から最も大きく変えたところ――Queueを永続化する
前回の記事では、Brokerの状態は基本的にメモリ上に存在していた。
実験ならそれでもよい。
しかし会社では駄目。
Job 001
Job 002
Job 003
↓
Broker再起動
↓
全部消えたでは業務基盤にならない。
そこで今回はSQLiteへ永続化した。
cluster.sqlite
├── workers
├── jobs
├── job_events
└── benchmark_runsJob状態も明確に持つ。
queued
↓
assigned
↓
running
↓
completed
または
failedWorkerが消えることを異常扱いしない
Browser Clusterは普通のサーバークラスタと少し違う。
Chromeは閉じられる。
社員がPCをシャットダウンする。
ノートPCは持ち出される。
スリープにも入る。
つまりWorkerが消えることは「例外」ではなく「通常運転」である。
PC-01 READY
PC-02 READY
PC-03 OFFLINE
PC-04 READY
PC-05 SLEEP
PC-06 READYそこでHeartbeatを持つ。
Worker
↓
heartbeat
↓
Broker
一定時間途絶える
↓
OFFLINEJob Leaseを入れる
さらに問題になるのが、Jobを受け取ったあとWorkerが固まる場合。
Job 023
↓
PC-03
↓
Running
↓
GPU driver error
↓
停止Jobが永遠にrunningでは困る。
そこでLeaseを持たせる。
JOB_LEASE_MS=120000Lease切れをBrokerが検出したらJobをQueueへ戻す。
PC-03 timeout
↓
Job 023
running
↓
queued
↓
Scheduler
↓
PC-06Worker認証
業務利用なら「URLを知っているブラウザが勝手にWorkerになれる」構成にもしたくない。
初回だけEnrollment Tokenを使う。
Worker
↓
WORKER_ENROLL_TOKEN
↓
Broker
↓
Worker固有Secret発行以後はWorker固有Secretで、
- Heartbeat
- Job取得
- 結果返却
を行う。
またAPI権限も分けた。
ADMIN_API_KEY
CLIENT_API_KEY
WORKER_ENROLL_TOKEN業務システムにはCLIENT_API_KEYだけを与える。
SchedulerはGPU型番だけを信用しない
異種GPUクラスタでは、GPU名だけで振り分ける設計は弱い。
RTX
Intel
AMD
Appleさらに同じGPUでも、
- ブラウザ
- OS
- driver
- 電源設定
- 他アプリの負荷
で性能は変わる。
そこで、実測値を使う。
score =
warm model bonus
+ 実測 decode tokens/sec
+ 過去の完了実績
- Broker RTT
- failure penalty正確な「空きVRAM」はブラウザから取れない
当初は、
VRAM free
↓
Schedulerとしたくなる。
しかしWebGPUは、OSのGPU監視ツールのような正確な空きVRAM量をWebページへ公開しない。
取得できるのは例えば、
maxBufferSize
maxStorageBufferBindingSize
maxComputeWorkgroupStorageSizeなど。
しかもブラウザはfingerprinting軽減のため、adapter limitsをtier化して公開する場合がある。
したがって、今回は「スペック上どれほど強そうか」ではなく、
実際にそのモデルを何tokens/secで処理できたか。
を重視する。
Warm Modelを優先する
LLMで意外に大きいのがモデルロード。
Cold
Job
↓
Model load
↓
WebGPU initialize
↓
Weight upload
↓
Inference
Warm
Job
↓
Inference多少GPUが遅くても、そのモデルが既にロード済みならそちらへ投げた方が速い場合がある。
そのためSchedulerはWarm Modelへ大きなAffinity Bonusを与える。
モデルが動かないPCも自動的に学習する
例えば3Bモデルを古い内蔵GPUへ投げたとする。
PC-07
↓
3B model
↓
Out of memory次のJobでも同じ失敗を繰り返してはいけない。
そのモデルについてWorkerをunavailable扱いにする。
PC-07
SmolLM OK
1B OK
3B NGつまりCluster自身がモデルごとの適性を学んでいく。
セットアップ
まずZIPを展開。
unzip browser-ai-cluster-enterprise.zip
cd browser-ai-cluster-enterprise
cp .env.example .env鍵を3つ生成する。
openssl rand -hex 32
openssl rand -hex 32
openssl rand -hex 32.envへ設定。
PORT=8443
HOST=0.0.0.0
ADMIN_API_KEY=xxxxxxxxxxxxxxxx
CLIENT_API_KEY=yyyyyyyyyyyyyyyy
WORKER_ENROLL_TOKEN=zzzzzzzzzzzzzzzz
JOB_LEASE_MS=120000
WORKER_OFFLINE_MS=20000起動。
node src/server.mjs同一PCならlocalhostで試せる
http://localhost:8443/workerまずはこれで1台のPCをWorker化する。
複数の会社PCから使うならHTTPSが必要
WebGPUはSecure Contextを要求する。
localhostは開発用として扱えるが、別PCから、
http://192.168.1.10:8443/workerと開く運用は避ける。
会社内では、
https://ai-broker.company.local/workerのようにする。
WebGPUのSecure Context要件やブラウザ側のトラブル確認についてはChrome公式ドキュメントも参照できる。
Chrome公式 WebGPU Troubleshooting
Caddyを使う場合
ai-broker.company.local {
tls internal
reverse_proxy 127.0.0.1:8443
}既に会社内にCAや証明書基盤があるなら、それを利用した方がよい。
各PCをWorkerとして登録する
各PCでChromeを起動。
https://ai-broker.company.local/worker設定する。
- Worker名
- Group名
- Enrollment Token
- 使用モデル
- 稼働可能時間
例えばRTX 5060。
Name:
RTX5060-PC
Group:
rtx-single普通の社員PC。
Name:
Office-PC-01
Group:
browser-clusterChromeがWebGPUを本当に使えているか確認する
Chromeで、
chrome://gpuを開く。
WebGPUがHardware acceleratedになっているか確認する。
JavaScriptからも確認できる。
const adapter =
await navigator.gpu.requestAdapter({
powerPreference: "high-performance"
});
console.log(adapter);
console.log(adapter.info);
console.log(adapter.limits);まず全PCをWarm Upする
Benchmark開始と同時にモデルロードを始めてしまうと、推論性能ではなくモデルロード性能を比較することになる。
そこで事前にWarm Up。
ADMIN_API_KEY='管理キー' \
CLUSTER_URL='https://ai-broker.company.local' \
node scripts/warmup-all.mjs \
--group=browser-cluster \
--model=SmolLM2-360M-Instruct-q4f32_1-MLCRTX側も同様。
ADMIN_API_KEY='管理キー' \
CLUSTER_URL='https://ai-broker.company.local' \
node scripts/warmup-all.mjs \
--group=rtx-single \
--model=SmolLM2-360M-Instruct-q4f32_1-MLC100 Job比較を開始する
ADMIN_API_KEY='管理キー' \
CLUSTER_URL='https://ai-broker.company.local' \
node scripts/compare100.mjs \
--single-worker=worker_xxxxxxxxx \
--cluster-group=browser-cluster \
--jobs=100 \
--model=SmolLM2-360M-Instruct-q4f32_1-MLC内部では、
RTX 5060
100件開始
↓
100件完全終了
↓
結果保存
Browser Cluster
同じ100件開始
↓
100件完全終了
↓
結果保存
最後に比較という順番で実行する。
なぜ同時に比較しないのか
同時に実行すると、
- ネットワーク負荷
- Broker CPU負荷
- Chromeキャッシュ
- バックグラウンド処理
が互いに影響する可能性がある。
そのため、同一100件を順番に処理する。
結果はCSVで出す
results/
compare-20260809-xxxx.json
compare-20260809-xxxx.csv比較項目。
metric,single,cluster,cluster_vs_single
wall_ms
jobs_per_minute
end_to_end_p50_ms
end_to_end_p95_ms
end_to_end_p99_ms
inference_p95_ms
completion_tokens
effective_completion_tokens_per_sec
success_rate実測結果は捏造しない
今回、BrokerおよびBenchmarkプログラムについてはMock Workerを使用して動作確認した。
Single 100 Job
↓
全件終了
↓
Cluster 100 Job
↓
全件終了
↓
JSON出力
↓
CSV出力ここまでは完走する。
しかしMock Workerに設定したtokens/secは人工的な値である。
したがって、ここに「RTX 5060は○秒」「10台なら○倍」と架空の数字を書くことはしない。
配布したコードを実際のPCで走らせれば、その会社自身の数字が生成される。
実測値を入れる表
| 項目 | RTX 5060 1台 | Browser Cluster | Cluster / Single |
|---|---|---|---|
| Worker数 | 1 | 実台数 | – |
| 100 Job総時間 | 実測 | 実測 | 自動計算 |
| jobs/min | 実測 | 実測 | 自動計算 |
| p50 | 実測 | 実測 | – |
| p95 | 実測 | 実測 | – |
| p99 | 実測 | 実測 | – |
| Effective tok/s | 実測 | 実測 | 自動計算 |
| 成功率 | 実測 | 実測 | – |
Clusterでは速いPCが自然に多くのJobを処理する
Round Robinは使わない。
例えば、
RTX PC 55 tok/s
Apple M3 35 tok/s
Intel Arc 22 tok/s
Intel UHD 7 tok/sだった場合、全員へ25件ずつ渡すのは非効率。
各Workerは基本的に1 Jobずつ処理する。
Job終了
↓
Worker READY
↓
次のJob候補
↓
速いWorkerほど
READYへ早く戻る
↓
自然に多く処理この方式なら異種GPUでも比較的シンプルに負荷分散できる。
性能だけでは業務導入できない
ここからが非常に重要。
100件を1分で処理できても、結果が間違っていたら使えない。
そのため今回の実装には、性能Benchmarkとは別にQuality Evaluationを入れた。
Gold Datasetを作る
例えば過去の問い合わせを、人間があらかじめ分類しておく。
{
"id": "q001",
"text":
"納品予定を2日早めることは可能でしょうか",
"expected": {
"category": "納期",
"urgency": "normal"
}
}これを100〜500件程度準備する。
CLIENT_API_KEY='client key' \
CLUSTER_URL='https://ai-broker.company.local' \
node scripts/quality-eval.mjs \
--file=examples/evaluation/inquiry-gold.jsonl \
--group=browser-clusterこれによって、
category accuracy
urgency accuracy
JSON parse success rateなどを測れる。
会社で見るべきKPIはtokens/secではない
最終的には次を見るべきだと思う。
- AI結果をそのまま採用できた割合
- 人間が修正した割合
- 1件の修正時間
- AI導入前の作業時間
- AI導入後の作業時間
- 重要な誤判定件数
- 処理待ち時間
- 1日あたり処理可能件数
AI基盤の価値は「何tokens/sec出たか」ではなく、「人間の仕事を何時間減らせたか」で判断する。
実務例1：50人分の日報を読む
例えば管理者が毎日50件の日報を読む。
仮に1件3分なら150分。
ここをAIで事前整理する。
{
"summary": "...",
"achievements": [],
"problems": [],
"nextActions": [],
"numbers": [],
"needsAttention": []
}管理者は全文50件を同じ深さで読むのではなく、
needsAttention = true
だけ先に確認
↓
必要な日報だけ原文確認という使い方ができる。
実務例2：問い合わせメールの一次振り分け
{
"category": "納期",
"urgency": "normal",
"summary": "...",
"suggestedDepartment": "営業",
"missingInformation": [],
"draftReply": "..."
}例えば100件の問い合わせを、
- 納期
- 品質
- 価格
- 請求
- 技術
- その他
へ自動分類する。
さらに返信文の叩き台も作る。
ただし「納期確約」「価格確定」はAIに行わせない。
実務例3：製造トラブルの記録を整理する
例えば現場メモ。
3反で織傷発生。
経糸張力が原因かもしれない。
午後から張力を再確認する。重要なのは「事実」と「推定」を分けること。
{
"facts": [
"3反で織傷が発生"
],
"symptoms": [
"織傷"
],
"possibleCauses": [
"経糸張力"
],
"checksToPerform": [
"午後から張力を再確認"
],
"humanReview": true
}AIに原因を決定させるのではない。
人間が判断しやすい状態へ整理する。
実務例4：設備保全メモ
設備A
昨日より少し振動が大きい。
停止するほどではない。
午後再確認する。を、
{
"equipment": "設備A",
"observations": [
"昨日より振動が大きい"
],
"shutdownRequired": "unknown",
"actionsMentioned": [
"午後再確認"
],
"humanReview": true
}へ変える。
文章がデータになる。
この後、設備別・症状別・月別で検索できる。
実務例5：会議メモ
{
"summary": "...",
"decisions": [],
"actions": [
{
"action": "...",
"owner": "...",
"due": "..."
}
],
"openIssues": [],
"risks": []
}議事録全文をきれいに書き直すより、
決定事項
担当
期限
未決事項を抜く方が実務では役立つ場合が多い。
実務例6：過去文書の大量構造化
Browser Clusterが特に強い用途。
過去の日報 10,000件
過去の問い合わせ 30,000件
過去の点検記録 5,000件これらを1件ずつ独立Jobとして夜間に処理する。
18:00
社員退社
↓
Browser Cluster開始
↓
文書Batch
↓
翌朝
結果DB化これは専用GPUがなくても試せる。
業務時間外だけWorkerになる
社員PCを勤務中に100％GPU使用するのは現実的ではない。
そこで参加時間を設定する。
08:00〜18:00
通常PC
18:00〜07:00
AI Workerあるいは日中でも、
Worker PAUSEボタンで社員自身が止められる。
既存PHPシステムから呼び出す
新しい専用画面を全て作る必要はない。
例えば既存PHPから、
$job = browserAiRequest(
'production-issue',
$reportText
);
$result = browserAiWait(
$job['id']
);だけでよい。
PHP
↓
AI Broker
↓
Queue
↓
Chrome Worker
↓
WebGPU
↓
Local LLM
↓
結果
↓
PHP
↓
人間確認画面APIキーはブラウザJavaScriptへ置かない
既存システムから呼び出す場合、CLIENT_API_KEYはPHPやLaravelのサーバー側環境変数へ置く。
BROWSER_AI_URL=https://ai-broker.company.local
BROWSER_AI_CLIENT_KEY=xxxxxxxxHTMLやブラウザJavaScriptへCLIENT_API_KEYを直接書かない。
Windows業務ならPowerShellからでも呼べる
.\submit.ps1 `
-Template daily-report-summary `
-Text "本日の作業は..."既存のWindows処理からNight BatchとしてJobを投入することもできる。
AIに任せてはいけないことも先に決める
実務化で重要なのは、AIができることを増やすだけではない。
AIが決めてはいけないことを決める。
- 設備停止判断
- 安全判断
- 品質合否の最終確定
- 顧客への価格確定
- 納期確約
- 契約判断
- 人事評価
業務テンプレート側には、
reviewRequired = trueを持たせる。
AIは叩き台。
確定は人間。
「ローカルAIだから何でも安全」でもない
Browser Workerで推論すれば、プロンプトを外部LLM APIへ送らない構成は作れる。
しかし実務では、もう一段考える必要がある。
業務データ
↓
Broker
↓
Worker PC
↓
Browser memory
↓
Local modelつまりJobを担当した社員PCには、その推論データが一時的に渡る。
したがって、人事・給与・機密契約などの非常に限定された情報を、一般社員PCのWorker Poolへ無条件に流す設計は避けた方がよい。
例えばGroupを分ける。
browser-general
browser-production
browser-management
browser-confidentialJob側も対象Groupを指定する。
本番ではWebLLMとモデルも社内配信する
最初の実験では外部配信のJavaScriptやモデルを利用すると簡単。
しかし機密性の高い社内利用まで進めるなら、
- WebLLMのバージョンを固定
- JavaScript bundleを社内配信
- モデルファイルも社内サーバーへMirror
- 外部model URLを社内URLへ変更
- モデルartifact integrityを検証
- Worker PCからInternetへ出なくても動く構成にする
WebLLMはCustom Model URLやModel Library URLに加え、モデルartifactのSRIによるIntegrity Verificationもサポートしている。
つまり、
Internet
×
社内Web Server
↓
WebLLM JS
↓
Model
↓
Chrome
↓
WebGPUという完全社内構成へ発展できる。
モデルサイズは一種類で決めない
最初は軽量モデルでCluster参加率を見る。
360M
↓
1B
↓
1.5〜1.7B
↓
3Bモデルが大きくなれば品質が上がる可能性はある。
一方で参加できるPCは減る。
小型model
低品質寄り
高速
参加PC多い
大型model
高品質寄り
低速
参加PC少ないここに会社ごとの最適点がある。
用途ごとにモデルを分けてもいい
問い合わせ分類
↓
軽量モデル
日報要約
↓
1Bモデル
複雑な技術文章
↓
3Bモデル
巨大な推論
↓
専用GPU / Cloud全部を一つのモデルで解決しようとしない。
Hybrid構成が最終形として面白い
AI Broker
/ | \
/ | \
Browser Pool RTX Cloud
10台 Server LLM
│ │ │
│ │ │
小型batch 中型LLM 大型LLM例えば、
分類・要約・JSON化
↓
Browser Cluster
高度な生成
↓
RTX Server
特別に巨大なモデル
↓
Cloudと振り分ける。
この時、Brokerは単なるBrowser Cluster Brokerではなく、
「AI Jobをどの計算資源で実行するか決定するRouter」
になる。
実際の導入手順
Phase 1：3台だけ
いきなり全社員PCへ配らない。
RTX PC
Intel PC
Mac程度から開始。
Phase 2：5〜10台
100 Job Benchmarkを行う。
ここで初めてRTX 5060単独と比較する。
Phase 3：1業務だけAI化
おすすめは、
日報要約
または
問い合わせ分類最終決定をAIが行わず、間違ってもすぐ人間が確認できる業務から始める。
Phase 4：過去データで品質試験
100〜500件のGold Datasetを作る。
モデル変更のたびに再評価する。
Phase 5：外部依存を減らす
WebLLMとモデルを社内配信。
ここまで来れば会社用AI基盤としてかなり形になる。
Brokerの統合テスト
GPUがなくてもBroker側の動作はMock Workerで確認できる。
npm run test:integration確認対象。
- SQLite DB生成
- Worker Enrollment
- Worker固有Secret
- 複数WorkerへのJob分散
- 単一Worker固定
- Job完了
- 結果保存
- Benchmark集計
- Business Template
- Human Review属性
さらに、
100 Job Single
↓
100 Job Cluster
↓
CSV / JSON生成までMock環境で完走させられる。
何台からBrowser Clusterが勝つのか
これは最初から答えを決めてはいけない。
知りたいのは、
- 3台ではどうか
- 5台ではどうか
- 8台ではどうか
- 10台ではどうか
- 古いIntel GPUを追加すると総Throughputは本当に増えるか
- 遅すぎるWorkerはむしろ外した方がよいか
- 1Bと3Bで最適台数が変わるか
である。
つまりこのコードはBenchmarkそのものを再現可能にするために公開している。
さらに電力を測ると面白い
速度だけではなく、次は電力。
100 Job / Wh
1000 completion tokens / Wh
1 Jobあたり電力
1日500 Jobの想定電力量を比較する。
5〜10台のPCを使えば速くても、消費電力まで含めるとRTX 5060 1台の方が合理的かもしれない。
逆に、既に起動しているPCの余剰GPUを使うのであれば違う結果になる可能性もある。
この部分も実測しなければ分からない。
どんな会社に向くか
- 社員PCが多数存在する
- 夜間にPCが余っている
- 文章Batchが大量にある
- 既存のWeb業務システムがある
- 小型LLMで解ける業務が多い
- 外部AI APIへデータを出したくない業務がある
向かない用途
- 70B級モデルを動かす
- 一つの回答を最速生成する
- LLMを学習する
- GPUを24時間100％保証する
- 極端に大きなContextを扱う
- 完全なSLAが必要
ここでは専用GPUサーバーが強い。
最終的に作りたい会社AI基盤
AI Broker
│
┌───────────────┼────────────────┐
│ │ │
▼ ▼ ▼
Browser Cluster RTX Server Cloud LLM
10〜50 Workers vLLM等 API
│ │ │
▼ ▼ ▼
小型・大量 中型・高速 大型・高度
│
▼
Business API
│
┌────────────────────┼───────────────────┐
│ │ │
▼ ▼ ▼
生産管理 販売管理 Groupware
日報 問合せ 会議
設備記録 メール 文書整理ここまで来ると、「AIをどこで動かすか」を各業務システムが意識しなくてよくなる。
業務システム
↓
AI Job
↓
Broker
↓
最適な実行場所これが最終的な狙い。
ブラウザは「AIを使う画面」から「AIインフラ」へ
これまでChromeはAIサービスを利用する側だった。
Chrome
↓
Cloud AIWebGPUが入ると構造が変わる。
AI Job
↓
Chrome
↓
WebGPU
↓
GPU
↓
Local LLMさらにBrokerを置く。
会社中のChrome
↓
Distributed AI Compute Poolになる。
まとめ
今回作ったものは、単なるWebLLMデモではない。
- Persistent Queue
- SQLite
- Worker Enrollment
- Worker Secret
- Heartbeat
- Job Lease
- Failure Requeue
- Warm Model Affinity
- 実測tokens/sec Scheduler
- モデル適性学習
- 100 Job Benchmark
- Quality Evaluation
- 業務テンプレート
- PHP連携
- PowerShell連携
- Human Review
まで実装した。
これでようやく、
「会社に余っているGPUを、本当に業務AIの計算資源として使えるか」
を試すための叩き台になった。
専用GPUサーバーを否定する技術ではない。
今まで計算資源として数えていなかった社員PCまでAIインフラへ参加できることに意味がある。
専用GPU
+
社員PC
+
Mac
+
ノートPC
+
将来のEdge Device
↓
Unified AI Compute Poolクラウドだけでもない。
GPUサーバーだけでもない。
会社中に散らばっている計算資源を、必要なときだけAIへ使う。
ブラウザは、AIを使うための画面から、AIを動かすためのインフラへ変わり始めている。
前回の記事
今回の記事は、ChromeをWebGPU Workerとして動かす基本実装の続編である。
ソースコード
この記事で使用したBroker、Worker、Benchmark、業務テンプレート、 PHP・PowerShell連携、品質評価用コードをまとめています。
“` 💾 ソースコード一式をダウンロード “`次回やること
次はこの基盤を使って、実際に次を測る。
- RTX 5060 1台 vs 実PC 5台
- RTX 5060 1台 vs 実PC 10台
- 360M / 1B / 1.5B / 3B比較
- 100 Job / 500 Job / 1,000 Job
- 消費電力
- 1 JobあたりWh
- 品質Accuracy
- 人間の修正時間
- 専用GPUサーバーとの比較
さらにEmbedding WorkerとRAGまで入れる。
Document
↓
Embedding Worker
↓
Vector Search
↓
Context
↓
Browser LLM Cluster
↓
Answerそこまで進めば、「会社にあるPCだけでどこまで社内AI基盤を作れるか」の答えがかなり見えてくるはずだ。
参考資料
- WebLLM – GitHub
- Llamas on the Web: Memory-Efficient, Performance-Portable, and Multi-Precision LLM Inference with WebGPU
- Chrome for Developers – WebGPU Troubleshooting
