スタンフォード大学、カリフォルニア大学ロサンゼルス校、コーネル大学の教授陣により設立された新世代の大規模言語モデル(LLM)を開発するAIスタートアップのInception Labsが、拡散モデルを取り入れた次世代LLMの拡散大規模言語モデル(dLLM)となる「Mercury」を発表しました。Inception Labsによると、Mercuryは世界初の商用規模のdLLMとのことです。
生成AIモデルの比較ベンチマークを公開しているのArtificial Analysisによると、MercuryはGPT-4.1 NanoやClaude 3.5 Haikuといった軽量モデルと出力速度を比較すると、7倍以上高速です。
⇧ 何やら、「拡散大規模言語モデル（dLLM：diffusion Large Language Models）」についてが分からないのだが、「ゲームチェンジャー」的な存在なんだろうか？
一小市民としては、「正規表現」の自動生成、自動テストを実現して欲しいのだが、「幻覚（ハルシネーション）」の問題が解決できないと思われるので、
⇧ 上記サイト様で紹介されているような「セキュリティ」のリスクが発生し得ますと...
とりあえず、「AI」との付き合いは、
「エアーマンが倒せない」（エアーマンがたおせない）は、2007年に同人サークル「てつくずおきば」のせらみかる（seramikarutitan、せら、sera）が作詞・作曲し、インターネット上で公開した同人音楽。商業展開も行なわれた。
歌詞
カプコンのファミリーコンピュータ用ゲーム『ロックマン2 Dr.ワイリーの謎』に登場するボスキャラクターの1体「エアーマン」をテーマとした曲で、エアーマンに苦闘しながらも、幾度となく立ち向かうプレイヤー（ロックマン）の不屈の姿を描いている。
⇧ 上記のような気分になりがちでげすな...
今日も今日とて、不毛な闘いは続くということになりますかね...
REST APIでHTTPのPOSTのレスポンスのbodyサイズの上限はリクエストを受信して処理するサーバー次第
何某かの「アプリケーション」が稼働している「サーバー」から外部システムに対して、何某かの「HTTPクライアント」でPOSTリクエストした際に、「レスポンス」のbody部のサイズの上限ってあるんだっけ？と思ったので、ネットの情報を漁っていたところ、
⇧ stackoverflowの情報によると、特に上限は無いらしい。
ということは、外部システムが「レスポンス」のbody部に超弩級のサイズのデータを設定するようなクレイジーな仕様になっていたりすると、「レスポンス」を受信する側で「OOM（OutOfMemory）」とか発生し得る可能性があるわけだ。
ちなみに、「ブラウザ」で表示される「WUI（Web User Interface）」が用意されているような「システム」の場合、「ブラウザ」の方でサイズの制限が設けられている模様。
ちなみに、「WUI（Web User Interface）」は「UI（User Interface）」の内の1つに該当するようなのだが、「UI（User Interface）」はというと、
ユーザインタフェース（英: User Interface、 UI）または使用者インタフェースは、機械、特にコンピュータとその機械の利用者（通常は人間）の間での情報をやりとりするためのインタフェースである。これには長音符の有無などによる表記ゆれが見られるが、本記事では「ユーザインタフェース」で統一する。ユーザインタフェースは以下の手段を提供する。
コンピューター
分類
2008年現在、ユーザインタフェースには主に以下のような種類がある。
- グラフィカルユーザインタフェース (GUI)
- 入力としてキーボードやマウスといったデバイスを用い、ディスプレイ上にグラフィカルな出力を提示する方式。
- マウスを使った入力方式はWindowsやMac OSのものが一般的だが、他にも境界線と交差するマウスポインタの動作で何らかの情報を入力する方式 (Crossing Based Interface)、マウスジェスチャーで制御する方式などもある。
- ウェブユーザインタフェース (WUI)
- ウェブページ生成によって入出力を行い、それをインターネット上で転送し、ウェブブラウザでユーザーがそれを表示する。既存のHTMLベースのウェブブラウザを使うことができ、制御はJava・Ajax・Adobe Flash・Microsoft .NETといった比較的新しい技術で実装される。
- キャラクタユーザインタフェース (CUI)
- ユーザーがキーボードからコマンドを入力し、ディスプレイ上に文字を表示することで出力とする方式。マウスなどポインティングデバイスを使用しないシステム管理作業などで使われる。
- 触覚インタフェース
- 補助的な出力として触覚フィードバックを用いる方式。コンピューターシミュレーションやバーチャルリアリティで使われる。
- タッチインタフェース
- タッチパネルとGUIを入出力に使う方式。工業機械やセルフサービス型機械（ATMなど）またはタブレットなどでよく使われる。
その他のユーザインタフェースの種類として、以下のものがある。
- バッチインタフェース
- バッチ処理で使われる対話型でないユーザインタフェース。ユーザーはバッチジョブとして処理の詳細をまとめて入力し、全ての処理が完了した時点で出力結果を得る。処理が始まると、システムはさらなる入力を求めることはない。
- パーセプチュアルユーザインタフェース (英: perceptual user interface, PUI)
- ユーザーは従来的なコマンド入力を行わず、身振り手振りや音声を使って意思を伝達し、出力は映像や音声で行われる方式。KinectやSiri/Cortanaなどが挙げられる。
- リフレクシブユーザインタフェース (英: reflexive user interface)
- ユーザインタフェース全体をユーザーが再定義可能な方式。主に非常にリッチなGUIでのみ可能。
- タンジブルユーザインタフェース (英: tangible user interface, TUI)
- 物理的な接触を重視したユーザインタフェース。
- テキストユーザインタフェース
- 出力はテキスト形式だが、入力はコマンド入力以外の方式も可能なユーザインタフェース。テキスト方式のメニュー操作などを指す。
- 音声ユーザインタフェース[疑問点]
- 電話において、音声で案内し、ユーザーは電話機のプッシュボタンで入力する方式。音声ガイダンス。
- ズーミングユーザインタフェース
- GUIの一種で、情報オブジェクト群が異なる詳細さレベルで表示され、ユーザーがその中からオブジェクトを選ぶとさらに詳細が表示されるという方式。Microsoft Windows 8で導入されたModern UIスタイルのアプリケーションでは、「セマンティックズーム」と呼ばれる。
⇧ 様々なものが登場しており、最早、分類が追い付いていない感じですと...
悲報...
「API Gateway」によるサイズ制限も存在するらしい...
「Microsoft Azure」だと「Azure Application Gateway」の「Azure WAF（Azure Web Application Firewall）」の機能で制御しているらしい。learn.microsoft.com
⇧ ただ、「要求」についての制限についての記載はあるのだが、「応答」についての制限については言及されていないんだが...
つまり、「レスポンス」のbodyにどれぐらいのサイズのデータを持たせるからは、「リクエスト」を受信して処理する「サーバー」側のプログラミング次第ということになると。
送信元と送信先で予め調整しておく必要があるのだが、「REST API」などを公開している送信先と調整が取れないような場合は、送信先の公開しているであろう「REST API」のドキュメントとかを確認するしかないのだが、情報が記載されていないことが多いのよね...
で、何某かの「HTTPクライアント」を利用して「マシン」間の通信を実現しているからこそ、
- 送信元
- 送信先
が登場してくるのだが、「クライアントサーバーモデル」という概念も関係してくることになる。
「クライアントサーバーモデル」はというと、
クライアントサーバモデル（英: client-server model）は、機能やサービスを提供するサーバと、それを利用するクライアントを分離し、ネットワーク通信によって接続する、コンピュータネットワークのソフトウェアモデル（ソフトウェアアーキテクチャ）である。単にクライアント・サーバと呼ばれたり、C/Sなどと表記されたりすることも多い。俗にクラサバと略されることもある。
狭義のクライアント・サーバ
広い意味でクライアント・サーバと呼ばれる場合、前述のようにクライアントとサーバと処理を役割分担している分散コンピューティングのことを意味することがある。この場合、サーバがさらに数層分けられる多層アーキテクチャを含める場合がある。
一方で、狭い意味でクライアント・サーバと呼ばれる場合には、2層アーキテクチャやリッチクライアントモデルを指す場合がある。
⇧ とあり、解釈がまちまちであり、且つ、Wikipediaの「図」が語弊を招く感じなのだが、
⇧ 上図にあるように、「リクエスト」を送信するための「クライアント」がインストールされている「サーバー」と「リクエスト」を受け付ける「サーバー」間の構成についても「クライアントサーバーモデル」となるので、紛らわしいのよね...
話が脱線しましたが、「レスポンス」のbody部については、「API」を提供している側の実装次第となるので、「API」を提供している側が、仕様の情報についてをドキュメントとして公開してくれていないと詰むことになりますと...
まぁ、
⇧ 上記の記事の時に触れてはいるのだが、「Microsoft」のように「レスポンス」の構成を全くドキュメント化していない残念なことの方が多いので、世の中でシステム障害とか頻発しているんだろうなぁ...
結局のところ、
- 送信元
- 送信先
の間で、
- インプット
- アウトプット
について共有ができていないと、「マシン」間での「データ」のやり取りは困難なのよね...
常識的に考えて、現実の「人間」は「エスパー」にはなれないのでね...
要するに、「API」を提供する側は、「API」を利用する側が必要な情報をしっかりと揃えて下さいってことですかね...
毎度モヤモヤ感が半端ない…
今回はこのへんで。
