本記事はここ昨今のOpenWrtセットアップシリーズの続きである。
OCNバーチャルコネクトのIPoEでIPv4 over IPv6のMAP-E環境だと、IPv4ではWell-known portsが開けない。しかし、IPv6であれば、理論上全部のポートが使えるはずで、それであればサーバーを建てられるのではないかと考えたので、やってみた記録。
セキュリティを考慮し、サーバー以外にはアクセスできないよう、NATのような仕組みで構築する。
確認環境
環境 | 内容 |
---|---|
ISP | OCN光 |
ISP契約 | OCN 光 with フレッツ マンション・スーパーハイスピード 隼・プラン1・西日本 |
ISP接続方式 | OCNバーチャルコネクト(IPoE, MAP-E) |
RouterOS | OpenWrt 24.10.0 |
ServerOS | Ubuntu 24.04.3 LTS |
HTTPD | nginx 1.26.1 |
ドメインレジストラ | Value Domain |
前提条件
IPv4環境下でのHTTPSアクセスが可能で、かつ以下のセットアップが終わっているものとする。
今回の要件
ルーターのファイアウォールでサーバーマシンのみ穴をあけ、それを塞ぐ。つまりIPv4のNATにあったセキュリティの再現を行うことで、関係ない端末が攻撃されないようにする。
やり方
サーバーとDNSの設定
- nginxの設定を開き
listen [::]:443
を追加して再起動sudo service nginx restart
- サーバーマシンのIPv6(Global Unique Address, GUA)を控える
ip -6 addr | grep 'global dynamic' | perl -ale '$F[1] =~ /^([^\/]+)/; print $1;'
- Value DomainのDNS設定を開きAAAAレコードに、先ほど控えたIPv6アドレスを登録する
ルーターのファイアウォールに穴をあける
設定ファイルを編集する方法
vi /etc/config/firewall
で以下の行を追加config rule option name 'Allow-Server-IPv6' option src 'wan' option dest 'lan' option proto 'tcp udp' option dest_ip 'さっき控えたサーバーのIPv6アドレス' option dest_port '443' option family 'ipv6' option target 'ACCEPT'
service firewall restart
でfirewallを再起動する
LuCIでやる方法
- LuCIに入りNetwork→Firewall→Traffic Rulesを開く
Addボタンを押し、次の要領で入力して保存
General Settings項目 値 Name Allow-Server-IPv6 Protocol TCP│UDP Source zone wan Destination zone lan Destination address さっき控えたサーバーのIPv6アドレス Destination port 443 Advanced Settings
項目 値 Restrict to address family IPv6 only 穴をあけたIP以外が外部から疎通しないことを確認
- 穴をあけたIPが外部から疎通することを確認
備考
OCN光のIPoE(MAP-E)方式のIPはv4, v6ともに基本的に変動しない
結論から言うと引っ越しでもしない限り、v4が固定なのは知っていたが、v6も固定らしい。
v6のアドレスが変わる気配がないので、OCNのテクニカルサポートに聞いた結果、PPPoEは変動IPv4でルーター再起動時にIPが変わるが、IPoEであればIPv4, IPv6ともに半固定で通常は変わらないとのことだった。
つまりVLANやip6tablesがなくてもサーバーを公開できると言う事でOCN様々と言う事である。
IPv4アクセスをどうするか?
現状は2案検討している。
- どっかにペラのページを置いておき、「IPv6でアクセスしてください」みたいなお知らせページにしておく
- SNSなどのOGP対策で、簡単なプロキシを組んでおき、OGPだけ出るようにしておく
2のケースだとレンサバにv6側サイトのOGP取得用のCGIを置いておくとか、v6側サイト更新時にOGP付きのペラのHTMLを置いておくなどが検討できると思う。
Cloudflare Tunnelを使わない理由
Cloudflare Tunnelを使えればIPv4を利用でき、デュアルスタック対応もできるだろう、しかしなぜ使わないのかという話。
基本的にオンプレミス至上主義だからというのが答えにはなるが、実務的な理由もある。
まずCloudflare Tunnelを利用する場合、ネームサーバーを委任する必要があるが、CloudflareのDNSはさくらインターネットのSPFレコードを扱おうとするとバリデーションエラーを吐いて使えない。他にも、管理画面のUIがお世辞にもよくなく、言葉を選ばず言えばクソである点もある。勿論、余計なレイヤーを増やすことによる運用コストの増大もあるため、使わなくて済むのであれば、それに越したことはないという考えだ。
またCloudflareのWAF機能やhCAPTCHAがユーザーとして嫌いなのもあり、自分が嫌いなものをユーザーに提供したくないのもあるし、Cloudflareのエラー画面を見て嬉しく思う人もいないと思うので、あのインフラには乗りたくない思いもある。
IPv4のデュアルスタック対応としては、VPNにリバプロをかけるのも検討したが、レガシーに縋っていても仕方がなく、今のところはIPv6に注力する方向にしようとしている。世界のIPv6移行に末端からでも貢献出来たらいいなくらいの気持ちでやっていくのだ。
疎通検証に使える簡易サーバーの作り方
PHP
php -S "[::]:80"
でIPv6向けの簡易サーバーをサクッと立てられるので疎通検証をするときに便利。
Node.js
http-serverだとhttp-server -p 80 -a "[::]"
でいける。serveは未対応っぽい。
疎通確認に使えるcurl例
IPv6はURL形式が特殊なのでアドレス部分を[]
で囲んだ書式で投げる。これはブラウザで確認する場合でも変わらない。
curl -v "http://[aaaa:bbbb:cccc:dddd:eeee:ffff:gggg:hhhh]:80/"
ドメインを利用する場合に、リクエスト先をAレコードとAAAAレコードで明示的に分ける場合は、以下の書き分けができる。
# IPv4向け
curl -4 -v "http://example.com/"
# IPv6向け
curl -6 -v "http://example.com/"
複数ポートの開き方
option dest_port
に値を半角スペース区切りで追加すればよい。LuCIでも同じ書き方で通用する。
例:
option dest_port '80 443 8080'
連番で開ける場合は公式ドキュメントによると、'1024:65535'
のような書式にすれば、連番で開けられるようだ。
例:
option dest_port '8000:8999'
関連記事
基本的な考え方としてはWindowsマシンをWiFiのAPにした時と同じと思われる。ゲートウェイのDNSを参照するのでhostsを書き換えると成立する。
現状IPv6で行うのは現実的ではなさそうだ。
IPv6ではやる意味自体がないので本記事はIPv4向けだ。
確認環境
- OpenWrt 24.10.0
手順
SSHでやる方法
- hostsを開いてIPとドメインを紐づける
vi /etc/hosts
- DNSを再起動する
service dnsmasq restart
LuCIでやる方法
IPv6ではやる意味がない
IPv6だと外部DNSに登録したGUAとドメインの紐づけを利用してLAN内のアクセスが出来るためやる必要性がない。IPv6ではGUAを打っても、相手がLANの中にいれば外に出ずに、そのままつながる。これはtracertを打てば分かる。
前回、OSインストールの記事を書いてから約四ヶ月、今回は実際にインターネットへの接続をやっていく。接続にはOCN バーチャルコネクトを利用する。
色々あって四ヶ月放置していたR86Sにはいい感じに埃が積もっていた。
確認環境
- R86S U1
- OpenWrt 24.10.0
- OCNバーチャルコネクト
手順
OSインストールが終わっているものとする。
また、この手順ではLANケーブル(RJ45)を使って進めている。
途中でインターネットを利用する場面が何度かあるため、キャリア回線でWWWに出られるスマホがあると便利だ。
R86Sに接続する
eth1にWAN, eth0にLANを接続する。
パッケージのインストール
SSHで192.168.1.1に接続し次のコマンドを流しパッケージをインストールする。
opkg update
opkg install luci
opkg install map
reboot
Web管理画面へのアクセス
http://192.168.1.1/
にアクセスするとWeb管理画面が開くので、ここから設定をしていく。
設定情報の取得
管理画面上部のNetworkからInterfacesを開き、wan6のIPv6にある先頭4セクションを控え、http://ipv4.web.fc2.com/map-e.htmlを開き入力、計算する。出力されたoption始まりの行の内容をすべて控えておく。
wan6のIPv6にある先頭4セクション(aaaa:bbbb:cccc:dddd)とoptionの値は後で使うので全部控えておく。
WAN側IPv6のDHCP(DHCPv6 client)の設定
wan6のEditボタンを押す。
DHCP Serverタブを開き、「Set up DHCP Server」ボタンを押す。
IPv6 Settingsタブを開きRA-Service、DHCPv6-Service、NDP-Proxyをrelay modeに変更し、保存する。
LAN側IPv6のDHCPの設定
先ほどと同様にDHCP Serverタブ→IPv6 Settingsタブと開き、RA-Service、DHCPv6-Service、NDP-Proxyをrelay modeに変更し、保存する。
ルータ広告用のインターフェースの作成
画面左下にある「Add new interface...」ボタンを押し、以下の要領で選択し作成する。ルーター広告はIPv6のRouter Advertisementのことなのでインターフェース名をwan6raとしている。
項目 | 値 |
---|---|
Name | wan6ra |
Protocol | Static address |
Device | Alias Interface: "@wan6" |
Deviceは項目選択後は画像のように@wan6表記になる。
ルータ広告用のインターフェースの設定
ここでは控えておいたwan6のIPv6にある先頭4セクション(aaaa:bbbb:cccc:dddd)を利用する。
wan6raインターフェースのEditボタンを押し、General Settingsタブにある項目を次の要領で設定する。
項目 | 値 |
---|---|
IPv6 address | aaaa:bbbb:cccc:dddd::1001 |
IPv6 gateway | aaaa:bbbb:cccc:dddd::1 |
IPv6 routed prefix | aaaa:bbbb:cccc:dddd::/56 |
各設定項目に応じて、先頭4セクションの後ろに::1001、::1、::/56を追記するイメージ。
疎通確認
Save&Applyを押し、以下のサイトが開けることを確認する。
この段階ではIPv6にしか繋がらないため、続けてIPv4向けの設定をしてゆく。
MAP-E用インターフェースの作成
次の要領でインターフェースを作成する。
項目 | 値 |
---|---|
Name | wanmap |
Protocol | MAP / LW4over6 |
MAP-E用インターフェースの設定
ここでは控えておいたoption始まりの行の内容を利用する。
wanmapインターフェースのEditボタンを押し、General Settingsタブにある項目を次の要領で設定する。
項目 | 値 |
---|---|
Type | MAP-E |
BR / DMR / AFTR | option peeraddrの値 |
IPv4 prefix | option ipaddrの値 |
IPv4 prefix length | option ip4prefixlenの値 |
IPv6 prefix | option ip6prefixの値 |
IPv6 prefix length | option ip6prefixlenの値 |
EA-bits length | option ealenの値 |
PSID-bits length | option psidlenの値 |
PSID offset | option offsetの値 |
Advanced Settingsタブを開き「Use legacy MAP」にチェックを入れ、保存する。
Firewallの設定
SSHで192.168.1.1に接続し/etc/config/firewall
を開く。
config zone
option name 'wan'
...
list network 'wan'
list network 'wan6'
となっている箇所の末尾に以下を追記し保存。reboot
コマンドで再起動する。
list network 'wan6ra'
list network 'wanmap'
ルーター再起動後、http://wa.kiriwake.jpne.co.jp/に接続し、判定ボタンを押し、試験1~4と、契約中のフレッツ東西の光がOKになっていれば疎通は問題ないと思われる。
後は適当に幾つかサイトを開いたりfast.comで回線速度を見て疎通確認を実施した。
ストレージの拡張(2025/08/26追記)
イメージを焼いた関係で、初期パーティションが狭い。R86S U1のeMMCは128GBもあるので、これを拡張する。
- GPartedのサイトからイメージを落とし、最新のRufusで適当なメディアにイメージを焼く。
- GPartedを焼いたメディアをR86Sに接続
- R86Sを起動しDeleteボタン連打でBIOSに入る
- Boot OptionでGPartedの起動順位をトップにする
- 再起動し一番上のGParted Live(Default settings)で起動
- 起動するとGPartedの画面が出ているのでパーティションを最大まで広げる
やり終えてから思ったが、OpenWrtインストール時に使ったUbuntuServerにpartedくらい入ってるだろうし、それでやってもよかったかもと思った。
発生したトラブル
192.168.1.1に繋がらない
eth0にLANを接続する事で繋がる。初期設定ではeth0がブリッジ、eth1がWAN、eth2は未設定。
ポート不足?(ニチバン問題?)(未解決)
ニチバン問題と同じものかはわからないがコネクションが225を超えた付近で通信が詰まる傾向があった。このため、Configuring OpenWrt to work with Japan NTT IPv6 (MAP-E) serviceのADVANCED CUSTOM CONFIGURATIONを利用し解決を試みたが、たぶん特に意味はなかった。
以下のコマンドを流すことで導入できた。
cd /lib/netifd/proto
mv map.sh map.sh.orig
wget -O map.sh https://raw.githubusercontent.com/fakemanhk/openwrt-jp-ipoe/refs/heads/main/map.sh.new
reboot
ひとまず変更して、意図的に大量のサイトを開いた状態がこちら。一見解消しているように見えるが、人為的にやった結果なので同等の結果かどうかは怪しい。
また一気に大量のサイトを開きまくると、流石に若干詰まりが見られたが、詰まっていた時はルーターさえ疎通しなかったので、単にOSのポートを食いつぶしていただけという可能性もある。
参考までに元のmap.shに戻して同じ操作をしてみたところ、ちゃんとコネクションが張れたので関係なさそう。
以前と比べてネットワーク構成が変わっており、Buffaloのルーターをスイッチングハブとして使っている影響などが関係しているかもしれないので、しばし静観の方向で…。
ルーター起動後、Windowsでネットワークアダプタが認識中のままになる、インターネットに繋がらない
電源投入からOCNバーチャルコネクトのリンクアップまで20~50秒ほどかかるので気長に待つ。
LAN側IPv6のDHCPの設定でDHCPv6-Serviceの値はrelay modeかserver modeか?
OpenWrtではDHCPv6の運用が難しいため、基本的にrelay modeでよいと思う。
おまけ
eth0をWAN、eth1をLANにする方法
- NetworkからInterfacesを開く
- wanとwan6のDeviceをeth0に変更
- Devicesタブに切り替る
- br-lanの「Configure…」ボタンを押す
- General device optionsのBridge portsをeth1にして保存
- Save & Applyを押す
CPU温度を見る方法
luci-app-temp-statusをインストールする。
2025年8月4日時点では以下のコマンドでインストールできる。
wget --no-check-certificate -O /tmp/luci-app-temp-status_0.7.1-r2_all.ipk https://github.com/gSpotx2f/packages-openwrt/raw/master/current/luci-app-temp-status_0.7.1-r2_all.ipk
opkg install /tmp/luci-app-temp-status_0.7.1-r2_all.ipk
rm /tmp/luci-app-temp-status_0.7.1-r2_all.ipk
service rpcd restart
インストールが終わるとトップ画面にTemperatureが出てくるほか、Status→Realtime GraphsにもTemperatureが出てくるようになる。
セットアップが完了したR86Sの姿
まぁまぁいい塩梅だと思う。
撤去されたYAMAHA RTX830
R86S + OpenWrtを導入するまで使っていたRTX830。価格の割にIPv6向けの機能が貧弱だったり、設定が手間だったり、マニュアルが雑目だったり、あまりいい思い入れはなかった。
OCNバーチャルコネクトの接続がBuffaloルーターより早く安定している点と、LAN向けのDNSがあるのは便利だったが、あの読みづらいマニュアルはもう少し何とかした方がよいと思う。
今回セットアップした感想
今のところ予想以上にトラブルや問題がなく、平然と動いているため、かなり満足している。
RTX830との比較
管理画面の操作性や充実度はRTX830を遥かに超えており、非常に体験がよかった。
設定変更についてもSave & Applyを押すまでは保留状態になるため、間違った設定が即座に反映されないのもよい。
しかもPending changesをクリックすると設定ファイルに対する差分も確認でき、大変便利だ。
電源投入からOCNバーチャルコネクトへのリンクアップまでの時間も体感RTX830と大差なく、Buffaloルーターのように接続ネゴシエーションの成功を祈っていたら1~2時間経過していたみたいなこともないのは素直にうれしい。fast.comで計測した限りでは速度やレイテンシの劣化もなく大変満足している。
DHCP設定の静的リースのUIが便利すぎる
Network→DHCP and DNS→Static Leasesから現在繋いでいる機器が見れるのがありがたいし、リース情報もわかりやすい。
しかも静的リースを行うときにOpenWrtが把握しているMACアドレスとドメイン名の一覧が出てくるので、手打ちしたり、確認する手間が省けるのも便利だ。リース時間も設定できるし、至れり尽くせりである。
ちょっとうるさい
唯一残念なところを挙げるとするとファンが微妙にうるさく、2mの距離があってもモスキート音レベルのささやかな動作音が聞こえる部分だ。これは慣れれば気にならなくなると思いたい。今の時期だとエアコンの音にかき消されてほぼ聞こえないが、それでも寝る前だと個人的には若干気にならなくもない程度だ。薄型のシロッコファンゆえにNoctuaのファンに変えるのも難しく、正直解決策としては物理的に遠くするか、間に何か防音材を放熱の邪魔にならないように挟むくらいしかないだろう。一応メーカー的には静穏ファンとのこともあり、大半の人は気にならないとは思う。
Banana Pi BPI-R4にもSPF+が2つあり、RJ45ソケットもあり、2.5万程度と安価なため、冷却装置をDIYして静穏化する場合はこちらの方が向いている可能性がある。実際にやってる人もいる。
ただまぁスペックはR86Sの方が上等なので、安く静かで多くを求めず、多少大きくてもいいならBanana Pi BPI-R4、多少の騒音を許容でき、スペックが欲しい場合はR86Sというのもありだろう。一般家庭のルーターに、そこまでスペック要るのかどうかというのはさておき…。
微妙なスイッチングハブの使用による性能劣化
今回ルーター側のポート数の制約により、ルーター直結でなくスイッチングハブを通してWWWに接続している。使えるものがBuffaloのWiFiルーターのAPモード(スイッチングハブとして機能する)しかなかったので、これを使っているが、直結と比べた場合にあからさまな性能劣化が見られた。以下は数回計測した上での平均値。小数点以下は切り捨て。
直結時
下り速度 | 上り速度 | アンロードレイテンシ | ロード済みレイテンシ |
---|---|---|---|
435Mbps | 430Mbps | 4ms | 5ms |
Buffalo経由時
下り速度 | 上り速度 | アンロードレイテンシ | ロード済みレイテンシ |
---|---|---|---|
357Mbps | 422Mbps | 5ms | 13ms |
上りは誤差だが、下りが78Mbps低く、ロード済みレイテンシも倍以上の差が出ている。MMOを辞めた今となっては問題ないとはいえ、なんとも微妙だ…。
ただまぁ、将来的には10GbEスイッチを購入する予定であるため、恐らくソフトウェア的な制御によって起きているであろうこの問題は、いずれ解消するとは思う。
次の作業に向けて
設定のカスタマイズなどを通してよりよい環境にしていき、IP変動環境でIPv6を利用した自宅サーバーの公開や、10GbEの導入などに向けて挑戦していきたいところだ。
参考記事
久々にPC構成を大刷新してみたのでベンチマークをしてみたが、かなり複雑な結果になった。
大まかにはCore Ultra 7 265FはCore i7 13700に、RTX 5070 TiはRTX 4070 Tiに劣るケースがありそうなことが判明したが、結果が複雑すぎて断言しづらい。
ベンチマーク構成
ソフトウェア
Env | Ver |
---|---|
version | v1.10.1-89-g2174ce5a |
python | 3.10.6 |
torch | 2.7.0+cu128 |
xformers | 0.0.30 |
gradio | 3.41.2 |
ハードウェア
スペックアップ前後で単純に計測したところ、結果に疑問を持ったのでCPUとGPUを新旧それぞれで組み合わせて全数網羅で見ている。
デバイス | 構成1-1 | 構成1-2 | 構成2-1 | 構成2-2 |
---|---|---|---|---|
CPU | Intel Core i7 13700 | Intel Core i7 13700 | Intel Core Ultra 7 265F | Intel Core Ultra 7 265F |
GPU | GeForce RTX 4070 Ti | GeForce RTX 5070 Ti | GeForce RTX 4070 Ti | GeForce RTX 5070 Ti |
MEM | Crucial Ballistix BL2K16G32C16U4B * 4 | Crucial Ballistix BL2K16G32C16U4B * 4 | Crucial CT2K16G56C46U5 * 4 | Crucial CT2K16G56C46U5 * 4 |
M/B | ASUS TUF GAMING Z790-PLUS D4 | ASUS TUF GAMING Z790-PLUS D4 | ASUS TUF GAMING Z890-PLUS WIFI | ASUS TUF GAMING Z890-PLUS WIFI |
FF14 黄金のレガシー ベンチマーク
4070Tiより5070Tiの方がベンチスコアが若干高く出るが、Core i7 13700よりCore Ultra 7 265Fの方が顕著にスコアが低い。
構成1-1 | 構成1-2 | 構成2-1 | 構成2-2 |
---|---|---|---|
27,439 | 29,138 | 22,393 | 23,479 |
おまけ:ローディングタイム
構成1-2は記録し忘れたので書いていない。
構成1-1 | 構成1-2 | 構成2-1 | 構成2-2 |
---|---|---|---|
6.5秒 | - | 7.9秒 | 8.6秒 |
ローディングタイムはストレージ依存のはずなのでCPUやGPUの性能が大きく影響することはないはずだが、かなり差が出ていたので参考程度にとどめておく。結果は小数第二位で四捨五入している。
CPUのキャッシュメモリサイズやDDR5の4枚差しによる速度低下が影響している可能性もあるが、2-1と2-2はGPUのみの差なのでよくわかっていない。ひょっとしたらグラフィック自体の読み込み速度が低下しているのかもしれない。
この差はMMORPGをする上ではかなりのハンデになるため、私が現役プレイヤーであれば、このスペックダウンは受け入れられなかっただろう。特にFF14をしていた時は誰よりも早くローディングを終えるのが自慢の一つだった。
SDベンチ
トキベンチ
ベンチマーク用のSD設定
COMMANDLINE_ARGSは--xformers --opt-channelslast --medvram
を使用。
設定 | 値 |
---|---|
Model | animagine-xl-3.1.safetensors [e3c47aedb0] |
Clip skip | 2 |
ENSD | 31337 |
Prompt | 1girl, toki \(blue archive\), blue archive, toki sits cross-legged in her chair. looking at viewer, cowboy shot, masterpiece, best quality, newest, |
Negative Prompt | nsfw, lowres, bad anatomy, bad hands, text, error, missing fingers, extra digit, fewer digits, cropped, worst quality, low quality, normal quality, jpeg artifacts, signature, watermark, username, blurry, artist name, |
VAE | Automatic |
Sampleing method | Euler a |
Sampleing steps | 15 |
Width | 1024px |
Height | 1024px |
Batch count | 5 |
Batch size | 1 |
CFG Scale | 7 |
Seed | 50 |
生成ログ
構成1-1 | 構成1-2 | 構成2-1 | 構成2-2 |
---|---|---|---|
15/15 [00:04<00:00, 3.12it/s] | 15/15 [00:05<00:00, 2.67it/s] | 15/15 [00:05<00:00, 2.92it/s] | 15/15 [00:05<00:00, 2.78it/s] |
15/15 [00:04<00:00, 3.34it/s] | 15/15 [00:05<00:00, 2.92it/s] | 15/15 [00:04<00:00, 3.35it/s] | 15/15 [00:05<00:00, 2.95it/s] |
15/15 [00:04<00:00, 3.34it/s] | 15/15 [00:05<00:00, 2.91it/s] | 15/15 [00:04<00:00, 3.44it/s] | 15/15 [00:05<00:00, 2.96it/s] |
15/15 [00:04<00:00, 3.36it/s] | 15/15 [00:05<00:00, 2.95it/s] | 15/15 [00:04<00:00, 3.46it/s] | 15/15 [00:05<00:00, 2.93it/s] |
15/15 [00:04<00:00, 3.32it/s] | 15/15 [00:05<00:00, 2.97it/s] | 15/15 [00:04<00:00, 3.46it/s] | 15/15 [00:04<00:00, 3.01it/s] |
75/75 [00:33<00:00, 2.24it/s] | 75/75 [00:35<00:00, 2.08it/s] | 75/75 [00:31<00:00, 2.40it/s] | 75/75 [00:34<00:00, 2.20it/s] |
75/75 [00:33<00:00, 3.96it/s] | 75/75 [00:35<00:00, 3.30it/s] | 75/75 [00:31<00:00, 3.96it/s] | 75/75 [00:34<00:00, 3.32it/s] |
平均生成速度
構成1-1 | 構成1-2 | 構成2-1 | 構成2-2 |
---|---|---|---|
3.296it/s | 2.884it/s | 3.326it/s | 2.926it/s |
生成時間
構成1-1 | 構成1-2 | 構成2-1 | 構成2-2 |
---|---|---|---|
33秒 | 35秒 | 31秒 | 34秒 |
まとめ
この結果からは4070Tiより5070Tiの方が生成速度が遅いことが読み取れる。またCPUがCore Ultra 7 265Fの時に僅かに高速化しているが、これはPCIe4から5への変化が効いている可能性がある。
またUltra 7 265F+4070Tiの組み合わせが最速を叩き出している点も見逃せない。つまりこれはStableDiffusionにおいてはi7 13700よりUltra 7 265Fが優位であることを示しており、FF14のベンチとは結果が逆転することを意味している。
りこベンチ
りこベンチとは個人的によく使う設定をベースにしたベンチだ。トキベンチの設定は個人的に使わず、実用性がないので今後はこちらを主にしていくと思う。
COMMANDLINE_ARGSは--xformers
を使用。
ベンチマーク用のSD設定
設定 | 値 |
---|---|
Model | ntrMIXIllustriousXL_xiii.safetensors [1207404b17] |
Clip skip | 2 |
ENSD | 31337 |
Propmpt | (illustration:1.0), masterpiece, best quality, 1girl, solo, happy, smile, theater, (perspective:1.3), from below, (looking away:1.2), (from side:1.0), {{shot_hair}}, smile, bangs, shaggy, (brown hair:1.1), swept_bangs, thick_eyebrows, skin_fang, closed mouth, {{purple eyes}}, gray {{jacket}}, white shirt, glasses, {{small breasts}}, |
Negative Prompt | nsfw, (worst quality, low quality:1.4), (depth of field, blurry, bokeh:1.5), (greyscale, monochrome:1.0), multiple views, text, title, logo, signature, (tooth, lip, nose, 3d, realistic:1.0), dutch angle,(cropped:1.4), text, title, signature, logo, (loli:1.2), school satchel, pink, school bag, school uniform, from behind |
VAE | Automatic |
Sampleing method | DPM++ 2M |
Hires. fix | True |
Upscaler | Latent |
Hires steps | 0 |
Denoising strength | 0.8 |
Upscale by | 2 |
Sampleing steps | 20 |
Width | 768px |
Height | 768px |
Batch count | 5 |
Batch size | 1 |
CFG Scale | 7 |
Seed | -1 |
生成ログ
構成1-1 | 構成1-2 | 構成2-1 | 構成2-2 |
---|---|---|---|
20/20 [00:05<00:00, 3.43it/s] | 20/20 [00:06<00:00, 2.94it/s] | 20/20 [00:03<00:00, 5.92it/s] | 20/20 [00:04<00:00, 4.51it/s] |
20/20 [00:11<00:00, 1.68it/s] | 20/20 [00:17<00:00, 1.13it/s] | 20/20 [00:11<00:00, 1.73it/s] | 20/20 [00:17<00:00, 1.13it/s] |
20/20 [00:05<00:00, 3.49it/s] | 20/20 [00:06<00:00, 3.06it/s] | 20/20 [00:03<00:00, 6.26it/s] | 20/20 [00:04<00:00, 4.79it/s] |
20/20 [00:11<00:00, 1.67it/s] | 20/20 [00:17<00:00, 1.14it/s] | 20/20 [00:11<00:00, 1.72it/s] | 20/20 [00:17<00:00, 1.13it/s] |
20/20 [00:05<00:00, 3.53it/s] | 20/20 [00:06<00:00, 3.03it/s] | 20/20 [00:03<00:00, 6.28it/s] | 20/20 [00:04<00:00, 4.81it/s] |
20/20 [00:11<00:00, 1.68it/s] | 20/20 [00:17<00:00, 1.14it/s] | 20/20 [00:11<00:00, 1.71it/s] | 20/20 [00:17<00:00, 1.13it/s] |
20/20 [00:05<00:00, 3.36it/s] | 20/20 [00:06<00:00, 3.06it/s] | 20/20 [00:03<00:00, 6.15it/s] | 20/20 [00:04<00:00, 4.78it/s] |
20/20 [00:12<00:00, 1.62it/s] | 20/20 [00:17<00:00, 1.13it/s] | 20/20 [00:11<00:00, 1.71it/s] | 20/20 [00:17<00:00, 1.13it/s] |
20/20 [00:05<00:00, 3.53it/s] | 20/20 [00:06<00:00, 3.08it/s] | 20/20 [00:03<00:00, 6.13it/s] | 20/20 [00:04<00:00, 4.57it/s] |
20/20 [00:11<00:00, 1.68it/s] | 20/20 [00:17<00:00, 1.14it/s] | 20/20 [00:11<00:00, 1.71it/s] | 20/20 [00:17<00:00, 1.13it/s] |
200/200 [01:49<00:00, 1.82it/s] | 200/200 [02:11<00:00, 1.53it/s] | 200/200 [01:33<00:00, 2.13it/s] | 200/200 [02:00<00:00, 1.65it/s] |
200/200 [01:49<00:00, 1.66it/s] | 200/200 [02:11<00:00, 1.12it/s] | 200/200 [01:33<00:00, 1.68it/s] | 200/200 [02:00<00:00, 1.11it/s] |
平均生成速度
構成1-1 | 構成1-2 | 構成2-1 | 構成2-2 |
---|---|---|---|
2.567it/s | 2.085it/s | 3.932it/s | 2.911it/s |
生成時間
構成1-1 | 構成1-2 | 構成2-1 | 構成2-2 |
---|---|---|---|
109秒 | 131秒 | 93秒 | 120秒 |
まとめ
結果としてはトキベンチと変わらず、Ultra 7 265F+4070Tiの組み合わせが最速でi7 13700+5070Tiの組み合わせが最も遅い。
総括
結果しては複雑で、個人的にはどの道を選ぶか未だに悩んでいる。
まず、今回新規導入したデバイスについての評価は以下の感じだ。
Core Ultra 7 265F
- FF14ベンチではi7 13700に劣る
- StableDiffusionの生成速度ではi7 13700を上回る
RTX 5070 Ti
- FF14ベンチでは4070 Tiを僅かに上回る
- StableDiffusionの生成速度では4070 Tiより1.1~1.3倍遅い
この結果は非常に悩ましい。FF14ベンチの結果からみるとゲーミング性能だけで言えばi7 13700+5070Tiが最適解だが、StableDiffusionの生成速度ではUltra 7 265F+4070Tiが最適解となった。
ただ私はもうFF14をしておらず、あまりゲームもしていないため、FF14ベンチの結果はある程度無視できる。そうなるとStableDiffusionだ。生成速度は重要な要素だ。とはいえ、4070Tiではメモリ不足でControlNetが使えないケースもあった。
また最近話題になっているFramePackのkisekaeichiではVRAM16GB必須という話もあり、今回は生成速度よりメモリを取る判断をしたいと思う。少なくとも旧環境である構成1-1と現環境である構成2-2を比べた時の差は一割程度であり、十分許容できる。
正直、私にはベンチマークのためにハードウェアを組み替える環境がないので、ある程度の情報でジャッジせざるを得ない。ちもろぐの人みたいに組み換え環境がある人はこの辺りがやりやすいと思うが、私の場合はPCケースからマザボを引っ張り出してそう取り返して、もう一度ケースに戻す手間がかかる。一連の作業には1時間ほど掛かり非常に手間だ。
今回はあまりにも結果が結果だったので、やむを得ず、新環境に組み替えてから、一度元に戻してベンチを取り直す検証を行ったが、組み換えの手間に加え、高価なCPUグリスが無くなり結構キツイ思いをしている。ちなみに今は新環境に完全に復帰している。