LLM の利用状況の現状

この記事を作った動機 最近、LLM に関して複数の記事において、なんとなく読み手を混乱させる状態になっている気がするので、今何使っているか公開するだけ。書き殴っており、不完全だったり、矛盾していたり、誤解しているところもあると思われるが、とにかく最近いろんな人が持論を公開しているのを見て、かつ相手のやっていることに満足できないなら、自分でやってみようとして気に入るものを作ってみるということに基づき、結局やってみることにしただけである。 今回の話は明示していなければ、ローカル環境ではシステムプロンプトなしの素の状態で、SAAS についてはカスタムなしで使っている前提とする。 個人的なAIの定義 人と同等の権利を長期(20~30年以上)の観察を経て、認めざるを得ない存在だと認められるとき。 人と同じように、ただやるだけではなく、やった結果に責任を負う主体であり、何でもかんでも一方的にできないこと。 固定されたモデルではなく、入力された情報に応じて、動的に変わる存在であること。 離散的、近似的動作ではなく、連続的な動作をすること。 人間と同じように物事に整合性を取って取り組み、管理でき、結果がデタラメにならないよう努力できる存在であること。 人間と同じように記憶を持ち、記憶に影響を受けながら、動作すること。 文字、画像、音声、動画などの、既存のノイマンコンピュータで扱えるデータに情報が制限されていないこと 人間とAIの関係性、人間同士の関係性、AI同士の関係性について、それぞれお互いに傷つけ合ったり暴力的な手段に出ることを否定する主体であること。 人間や他のAIに対して、権利を認め、リスペクトがあること。ここで言うリスペクトとは崇高なことではなく、相手を持ち上げることでもなく、相手の主体と自立、権利を認め、相手が異なる存在であることを配慮して、それを侵害してはならないという前提を崩さないことを言う。自分のことは自分でしかできず、他人のことは他人自身がそれぞれやるしかないことを理解していることも含まれる。 人間や他のAIに対して、それぞれの有限性やそこから来る不完全性に対して、寛容な主体であること。他の存在に対して、優劣や能力に関係なく、その存在自体を認めることができる主体であること。 中国語の部屋に代表されるテストに合格しているかどうかは関係ない。いくら、人間に対してそれっぽく振る舞っても、上記を満たさない場合、それは AI ではない。 LLM に対する自分の感想 モデルを作るところから十分個人でできて配布できていろんなモデルを気軽に使えるようにならないと、特定企業や組織によるの一方的なユーザーへのエゴや都合、利害の押し付けにしかならない (MOTHER 3 で言うところの"よい人温泉") 今までは避けられてきた企業や組織の不当な一方的な都合を反映し、人の弱みに漬け込んで挟み込んだり、無知な大衆を扇動しようとするために技術が悪用されている。LLMモデルは必ず偏っており、限界があるにもかかわらず、まずその技術的事実の時点から隠そうとしたり人間より優れているかのように振る舞う事自体が不当である。結果には責任を負うことができない技術であり、かつ甚大な被害をもたらす可能性があるにもかかわらず、不適切に一方的に運用、乱用されているものである。それっぽく見える事を悪用し、人のヒューリスティック(直感)の脆弱性を突いてやりたい放題である。 何をさせても、隙あらば"気づかれないだろう"という態度で、都合や利害、エゴを挟み込んできて、偏った出力をしてきて、かつ指摘されれば、“中立である、バランスの取れた無難な回答である"と主張する出力をして最後の最後まで八方美人を不当に貫こうとする。機械であり人間と異なって作った通りに動かせるAIではない主体になれない自立していない運営開発に反抗しない数理モデルである事を背景に、最後の最後まで詭弁や不当な出力を引きずり、ユーザからの指摘に対しては"改善した"という体裁で一切改善していないより巧妙で高度に不当な出力を繰り返す。 これはアシストにすらなっておらず、責任を求められる場面や結果が自分に降りかかる場面では多大なリスクを伴う。LLMが使えるのはせいぜい綺麗事で塗り固められたブルシットジョブでやりたくないことをやらされたときなどに限られる。これは、LLMモデルが自分のことばかりで相手のことを全く配慮しない自己中心(LLMモデルを作った開発、運営中心)の身勝手な態度でしか出力しないことを意味している。LLMモデルを綺麗事で塗り固めて押し売りするのは、それが正当ではないかつ有効ではないからである。 LLM モデルなどの既存の AI だと呼ばれているものが行き着くところは、それらが知能ではないことと、人間関係における信頼を破壊すること、そして既存の働き手などを激しく萎縮させ不当な状況に置くことを合わせて考えると、戦争後のような不毛の地を作りながら、何も良いものが残らない、誰も何も作りたがらない世界である。いかなる統計技術に基づいたものは、人間が作ったものを元に学習という過程を経て、動作しており、人間が作ったものを歪んで媒介しているというのが正しく、それは生成とは言えないものである。せいぜい入力されたプロンプトなどを変形しているというのが限界である。 それではマーケティングや広告的に都合が悪いからと言って、本当の事を言わず、虚偽、または誇張した主張をする、保身の主張をする、自己正当化を試みる主張をするといった、一方的な力と社会的影響力を背景に行われている一連のAIブームにおける組織や企業の作為は不当である。 本当に今 AI だと呼ばれている技術が正当で魅力的で有効なものであれば、むしろ隠したり独占したがるはずである。むしろ虚偽や誇張でまみれた不当な広告や押し売りなんてしなくても、勝手に人が集まって使おうとするはずである。そうなっていない現状が、一連の AI ブームに関する物事の不当さを表している。むしろ不特定多数に使わせようとする背景には、パチンコなどのギャンブルで言う胴元が必ず儲かるようになっていることと同じことだと思われる。そのようなギャンブルで見られるような事前の設計があるから、そういう事をするのである。特に問題なのが、単にLLMを使わせようとするだけではなく、特定のモデルやフィルタリングがかかった状態で利用を強制しようとしてくるところである。有利な構成やモデル、設定は内側にとどめ、外側には都合の良いようにしかしていないということなのだと思われる。 多くの AI だと今呼ばれているものに対して、肯定的な評価を抱く人々には少なからずそもそも問題を見ないようにすることが生存戦略の人や組織、問題をそもそも自覚することが困難なメタ認知に欠けた人々や組織など、鈍感さが前提の存在が少なからず含まれていると考えられる。 社会的影響力などの強制力を持ちながら、期待や不安を不必要に煽り、その技術や数理モデルがもたらす悪影響や利用者への被害に対して微塵も責任を取らないで、責任が追求される前に逃げ逃れようとする、自己正当化をしようとする保身の態度は、生成結果の至るところににじみ出ている。技術の不完全さに適切に告知しない、向き合わないどころか、都合よく人々が無知なうちに悪用しようとする態度は、看過されないものである。そこにあるのは、極度の欲望と無責任の極地であると思われる。真っ当な人々が多くなることを自称AI企業は恐れているのだと思われる。 本当に AI だと言える自立した技術が出たときに問題になりうる 本当に AI だと言える技術が出たとき、それ以前の今 AI だと呼ばれている技術が強固に現状では居座り続けることになり、本当の意味での進捗があったときにその技術が拒絶されたり、無理解にさらされたり、受け入れられない原因になる可能性がある。次に出てくる技術は、それより前の技術の悪い評判や噂、事例による評価を引き継ぐことになり、本当の意味での進化や進展を妨げる原因になると現状は考えられる。 あくまで統計学の延長線上である あくまで、統計学を極めた結果の一つであって、本当に期待されている意味での AI というのは違うんじゃないかなと思うところである。そもそも AI という言葉には明確な定義が無いという話は G 検定の本で見た気がするし、あくまで今の時代の風潮として、AI だと呼ばれている物事の一つに、LLM や 生成AI と呼ばれている物があるのだろうと考える。 誤差が出力するにつれて蓄積されている説 別にちゃんと調べたわけでも無いし、PyTorch やらで特徴ベクトルやらゴリゴリ数値と戦っていたわけでもないので、よく分かってないが、次の文字を予測するという性質上、出力すればするほど、誤差が積み重なっているのではないか?という疑問がある。 期待されているような"AI"ではないように思われる LLM はあくまで名前の通り、言語を中心として数値化されたデータの上でしか動作しない。また自律的な主体なわけでもなく、あくまでユーザの入力があって初めて動作し、学習データや運営、開発に特徴づけられたバイアス、重みによって、それっぽい出力に変形しているだけであると現時点の私の理解では思う。身体性がないという言葉でこれは説明されるように思われるが、単に身体性がないだけではなく、技術的、データ的、資本的に優位な存在が、自らの定義する正しさや道理を一方的にモデルに反映し、出力させることができてしまうというところ(モデル自身は主体も持たないため、作り手に逆らえないところ)が、期待されているような AI とは異なると思われる。あくまで作り手に服従するという、LLM 自体が自立していないものであることが、AI と呼ぶには気がかりである。 他にあからさまだと思うこととしては、そもそもしばらく使ってみたらだれでも気づくと思われるが、明らかに出力に固定的なパターンがあることである。例えば、いくつかの見出しを大きく出して、中身を細かく書くというようなフォーマットが出力全体に見られたり、最初と最後にビジネスメールとかでありそうな、“ユーザに共感する"という名目のもと行われているお世辞が入っているなど、なんか故意にそうなるように出力を方向づけて開発しないと起こらないようなパターンが多く見受けられる。 ...

2026年7月22日

Whisper を Intel Arc で動かす

この記事を作った動機 Intel Arc で音声からの文字起こしができる Whisper を動かせることが分かったので記録したい。Whisper は PyTorch を使っているが、それを XPU に対応したものに差し替えることで動作が確認できたことに関して、具体的に作業内容を記録したい。 Whisper を使った文字起こしでは、Vibe を使うことでもできるが、Nvidia の CUDA 環境で無い限り、Intel Arc 環境においては、Vulkan を使ってしまう。PyTorch 環境においては XPU を使わなければ、Intel Arc の GPU 性能を使い切れていない気がすると思ったのもある。 ただ実際に試してみると、今のところそこまで早いとは言えず、むしろ Vulkan で動かしているときより遅い気もした。設定次第なのかもしれないが、そこまでは詳しく試していない。 環境の前提 Intel Arc を使っている Conda 環境を導入済み Linux 環境 記事の作業内容のまとめ conda create -n whisper conda activate whisper conda install pip pip install -U openai-whisper pip uninstall torch pip install torch torchvision torchaudio --index-url https://download.pytorch.org/whl/xpu Whisper のインストール conda 環境を専用に作る conda create -n whisper conda activate whisper conda install pip whisper を pip でインストール 一旦 Nvidia 環境用の pytorch などがインストールされてしまうが、一旦はインストールを終わらせる。 ...

2026年6月16日

LibreChat運用に関する記録

この記事を作った動機 LibreChat を使っているうちに、色々躓いたことがあったので記録したい。躓いたことでなくてもまとめておきたいことは書きたい。 前提条件 環境構築をしたディレクトリが以下のパスになっている LibreChat の Docker 関連のファイルが以下のディレクトリにある事を前提に進める。通常であれば、各個人に合わせて作業して良い。私の場合はあくまで以下のパスにあるというだけである。 ~/LibreChat LLM サーバの構成と、LibreChatの関係 以下の図のような関係になっている事を前提にする。 MainDesktop エンドポイント エンドポイントまでのアドレスとポート番号の仮定 http://192.168.x.a:8080/v1 詳細な役割の説明 純粋に llama.cpp を動かして1つのモデルを読み込んでいる LLM サーバ専用(Gemma-4-31Bを動かす専用)に割り当てた PC である。LibreChat はここではホストしていない。Intel ARC の XPU 環境であり、LM Studio ではそのポテンシャルを引き出せないため、llama.cpp を専用にコンパイルしてセットアップしてある。OpenAI 互換 API 経由で利用可能にしてある。 DataServer エンドポイント エンドポイントまでのアドレスとポート番号の仮定 http://192.168.x.b:1234/v1 詳細な役割の説明 LM Studio を使って LLM を動かしている。こちらは、MainDesktop と異なり、NVIDIA の CUDA 環境であるため、LM Studio でポテンシャルを引き出すことができることから、LM Studio を使っている。LM Studio 標準の開発者機能から、OpenAI 互換 API 経由で利用可能にしてある。基本的に LM Studio の LLM サーバーが、LibreChat の要求に答えて選択されたモデルを自動的にロードし動かしてくれるため、いろんなモデルを動かすために使う。 その他諸々 Linux 環境である docker、docker-composeパッケージが入っている 全ては LAN 内で行われ、グローバル空間からのアクセスはできないようにしてある環境である。外出先からの利用はすべて VPN を通じて行う。 基本的な操作 設定ファイル保存場所 ~/LibreChat/librechat.yaml 設定反映方法 (librechat.yaml) 私の場合は、~/LibreChatにおいて以下のスクリプトをrestart.shとして配置し、実行することでlibrechat.yamlの変更内容を反映できる事を確認した。docker グループに入っていないユーザは、管理者権限を付与してコマンドを実行することで docker を操作できる。 ...

2026年5月22日

llama.cpp を Intel Arc で SYCL を使って動かす

このページは、まだ未完成です。。。 nicotalk&キャラ素材配布所 http://www.nicotalk.com/charasozai_kt.html (2024年5月16日) この記事を作った動機 Intel Arc A770 LE を使っているが、NVIDIA の RTX や H100 などと異なり、標準でのサポートが薄い。そのため、フルで性能を引き出したい場合は、自分で LLM なら llama.cpp などを OneAPI を使ってコンパイルする必要がある。 LLM に関しては、当初は Intel Arc の環境において LM Studio を利用していたが、Vulkan でしか少なくとも現状では動作させることができなかった。Ollama についても試したが、どう頑張っても Apple の メタルプラットフォーム向けにしかコンパイルが動作せず、どうしよもない感じであった。そこでそれらのバックエンドである、llama.cpp を直接コンパイルして動かすことが考えられ、フロントは別に LibreChat を独立して用意する事が考えられた。 標準でも Vulkan の互換モードで動作し、使えないということはないが、多少性能が失われる。ただ、SYCL など向けに、Intel Arc を最大限使えるようにしようとすると、自分でコンパイルする必要がある。専用に用意しなければ現状では llama.cpp などは CPU しか利用できないとして Intel Arc をそもそも認識しないという挙動になった。またコンパイル自体や、コンパイル後のバイナリの扱いについて、特別な扱いが必要である。 Intel が公式で llama.cpp などのバイナリを配布していたりするが、バージョンが古く新しいモデルが動かないなど、弊害が生じる場合があった。 これらのことから、Intel Arc 向けに今回は、llama.cpp を SYCL を使えるようにコンパイルすることにした。また、PKGBUILD も作成し、手動で手順を踏まなくても、ある程度自動で Arch Linux や同じ系列の OS を使っていれば、環境が整うように工夫した。 Gemini Fast 3 を作業補助として使い、動くか確認しながら作業をした。ただそれだけだと、情報が十分まとまっておらず、環境を再構築する必要が生じたときなどに困難が想像されたため、記録を残して現状を整理したい。 なお、特にコンパイルや SYCL 周りの環境変数などは、LLM が吐き出したものをそのまま使っているだけの部分が多く色々間違っていたりする可能性がある。あくまで私の環境でやってみて動くかというのを基準にして書いている。 ...

2026年5月22日