llama cpp

2024-09-30

AILlama

AI, Llama

メモ
- クローンとコンパイル
- Llamaのコンバート
参考

メモ

クローンとコンパイル

build.md に記載の通り、クローンしてmakeする。

1 2	git clone git@github.com:ggerganov/llama.cpp.git make

Llamaのコンバート

念の為仮想環境構築してから、必要なPythonパッケージをインストール。

1
2
3

python3 -m venv venv
. venv/bin/activate
pip install -r requirements.txt

参考

build.md

Llama3.2

2024-09-29

AILlama

AI, Llama

メモ
参考

メモ

Llama 3.2 Revolutionizing edge AI and vision with open, customizable models にある通り、 2024/9/25にLlama3.2がリリースされた。

Llama公式の Llamaダウンロードからモデルをダウンロードして用いる。

さらに利用規約に合意すると、具体的なダウンロード手順が表示される。

この手順の中には、リクエストIDやキーなどの情報が含まれているので注意。

もし、Llama CLIをインストールしていなければ以下の通り実行。

1	pip install llama-stack

モデルのリストを確認する。

1	llama model list

結果例

| Llama3.2-1B                      | meta-llama/Llama-3.2-1B                  | 128K           |
| Llama3.2-3B                      | meta-llama/Llama-3.2-3B                  | 128K           |
| Llama3.2-11B-Vision              | meta-llama/Llama-3.2-11B-Vision          | 128K           |
| Llama3.2-90B-Vision              | meta-llama/Llama-3.2-90B-Vision          | 128K           |
| Llama3.2-1B-Instruct             | meta-llama/Llama-3.2-1B-Instruct         | 128K           |
| Llama3.2-3B-Instruct             | meta-llama/Llama-3.2-3B-Instruct         | 128K           |
| Llama3.2-11B-Vision-Instruct     | meta-llama/Llama-3.2-11B-Vision-Instruct | 128K           |
| Llama3.2-90B-Vision-Instruct     | meta-llama/Llama-3.2-90B-Vision-Instruct | 128K           |

モデルをダウンロードして用いる。ここではテストなので小さなモデルを用いる。

1 2	MODEL_ID=Llama3.2-3B llama model download --source meta --model-id $MODEL_ID

上記コマンドを実行すると、キー付きのURL入力を求められる。先程表示した手順の「4」に記載されたURLを入力する。

このメモを書いている時点では混んでいるのか、ダウンロードにそれなりに時間がかかる。

ダウンロードが完了すると、以下のディレクトリにチェックポイントがダウンロードされているはず。

1	~/.llama/checkpoints/Llama3.2-3B

参考

ComfyUI

2024-09-28

AIComfyUI

AI, ComfyUI

メモ
- 導入方法
- 使い方
参考

メモ

導入方法

ComfyUIとは？ノードベースGUIでStable Diffusionを最大活用する機能・特徴・導入方法徹底解説！に導入方法などの基礎が書いてある。 ComfyUIの導入方法が２種類紹介されているが、他のツールなどの管理も兼ねるため、ここではStability Matrixを用いた。

StabilityMatrix のリリースから各環境用のインストーラをダウンロード。執筆時点では、 v2.12.0が最新だった。

Windwows用は以下。

https://github.com/LykosAI/StabilityMatrix/releases/download/v2.12.0/StabilityMatrix-win-x64.zip

使い方

画像生成AI「Stable Diffusion」を使い倒す！　モジュラーシンセみたいな「ComfyUI」をインストールが参考になる。先に StabilityMatrix のModel Browserで適当なモデルをダウンロードしておくこと。 StabilityMatrix で ComfyUI をインストールした場合、 ComfyUIのコンフィグが自動で編集され、ダウンロードしたモデルのパスが追加されるようになっている。ただし、新しいモデルをダウンロードした場合は ComfyUIの再起動が必要。

参考

Jan

2024-09-28

AILocalLLMJan

AI, Jan, LocalLLM

メモ
参考

メモ

LLMプラットフォームの「JAN」、様々なモデルでチャットAIを作れるを参考に、 Janを使ってみる。

Janの公式サイトに掲載の通り、パッケージをダウンロードする。ここではUbuntu環境を前提にAppImageを用いる。このとき最新版だった、 jan-linux-x86_64-0.5.4.AppImage をダウンロードした。自分の環境の場合は、 ~/Applications/ 以下にダウンロードした。

Ansibleプレイブックとしてはいかが参考になる。

https://github.com/dobachi/ansible-miscs/blob/master/playbooks/conf/linux/jan.yml
https://github.com/dobachi/ansible-miscs/blob/master/roles/jan/tasks/main.yml

環境が整ったら実行。

1	$ ~/Applications/jan/default/jan-linux-x86_64-0.5.4.AppImage

初回起動時はインストールするかどうかを聞かれるのでYesとする。

GUIからひとまず lama3.1-8b-instruct を試すことにした。

続いて、 LLMプラットフォームの「JAN」、様々なモデルでチャットAIを作れるの記事でも用いられている、huggingfaceからモデルを探して試す。 Huggingfaceについては、 Hugging Faceとは？Hugging Face Hubの機能や使い方・ライブラリをわかりやすく解説！を参照。

参考

US keyboard layout on Ubuntu22

2024-09-08

Ubuntu

メモ
参考

メモ

VMWare WorkstationでUbuntu 22系をインストールしたところ、物理キーボードがUS配列なのに、日本語配列で認識されてしまったので直した。

Ubuntu 22.04 でキーボードレイアウトおかしくなる問題。にも記載されているのだが、/usr/share/ibus/component/mozc.xmlには以下のような記載がある。

<!-- Settings of <engines> and <layout> are stored in ibus_config.textproto -->
<!-- under the user configuration directory, which is either of: -->
<!-- * $XDG_CONFIG_HOME/mozc/ibus_config.textproto -->
<!-- * $HOME/.config/mozc/ibus_config.textproto -->
<!-- * $HOME/.mozc/ibus_config.textproto -->

自分の環境だと、以下のような場所にあった。

$ sudo find / -name *ibus_config.textproto*

(snip)

/home/dobachi/.config/mozc/ibus_config.textproto

以下のようにlayoutを変更する。もともとdefaultである。

1	$ cat /home/dobachi/.config/mozc/ibus_config.textproto

engines {
  name : "mozc-jp"
  longname : "Mozc"
  layout : "us"
}

参考

Building Block of Data Spaces

2024-09-06

Data Spaces

メモ
参考

メモ

各イニシアティブのビルディングブロックのまとめかたを軽くメモしたもの。

メモのボード

参考

Data Sovereignty

2024-09-01

Data Spaces

メモ
参考

メモ

世における基本的な考え方

データ主権（Data Sovereignty）については色々な解釈をされているが、一つの考え方は特定地域で収集・保存されたデータがその地域の法律にしたがって運用されること、という考え方が挙げられる。

この考え方を示している記事が多い。

あまり量が多くなっても混乱するので、主要な話だけさらってみるようにする。

簡単なまとめメモ

セーフハーバー法

関連することとして、セーフハーバー法が挙げられる。つまり、特定の条件を満たす限り、違法行為とみなされない範囲を定めた規定である。総務省の平成29年版白書では、第1部　特集　データ主導経済と社会変革にEUと米国のセーフハーバーにちうて記載あり。米国とEUの間では2000年に個人データ移転についての原則を記したセールハーバー協定を締結したのだが、いわゆるSnowden事件により欧州司法裁判所による無効の判断。そして、その後、2016/2にEU-USプライバシーシールが新たに制定。

Snowden事件とデータローカライゼーション

データ保護については、Snowden事件や米国政府によるマイクロソフトのメール検閲を挙げるケースがある。 2013年ころのことである。参考：世界を揺るがしたスノーデン事件から5年--変わったこと、変わらなかったこと

ここから、欧州のGDPR（2016）やカナダのデータ主権措置に関する戦略（2016-2020）などのデータ越境移転に関する規定、つまりデータローカライゼーション規定の流れが考えられる。参考：データローカライゼーション規制とは？必要となる背景や現状を徹底解説 2022年当時の欧州、米国などのデータローカライゼーション規定については、経産省の「データの越境移転に関する研究会」資料がわかりやすい。参考：各国のデータガバナンスにおけるデータ越境流通に関連する制度調査

著名なところだと、中国サイバーセキュリティ法（2017/6施行）の第37条が挙げられる。参考： China’s data localization 他にも、ベトナムのインターネットサービスとオンライン情報コンテンツの管理、提供、仕様に関する法令（2013/9制定）、インドネシアの法令では国内データセンタへのデータ配置が求められている（2014/1）、ロシアのデータローカライゼーション法（2015/9発行）など。

一方で、このようなデータローカライゼーションに関する制約はビジネスや技術発展において足かせとなるという主旨の論調もあった。参考： The Cloud’s Biggest Threat Are Data Sovereignty Laws

日本からは、2019/1のスイス・ジュネーブにおける、いわゆるダボス会議にて、当時の首相だった安倍晋三からDFFTの提言があった。

GDPRとData Act

データローカライゼーションの議論をする際には、EUにおけるGDPR（一般データ保護規則）は外せない。個人データの移転と処理について規定したものである。2018年適用開始。参考： GDPR（General Data Protection Regulation：一般データ保護規則）

一方で、個人データだけではなく、非個人データを含むデータの利用促進、データへの公平なアクセスおよびその利用を目的として2020年の欧州データ戦略の一環としてData Actが成立。2024/1発効、2025/9施行。 IoT機器が生成するデータであり、非個人データも対象となる。自動車、スマート家電、などなど影響大。参考： EUデータ法の解説 - 適用場面ごとのルールと日本企業が講ずべき実務対応を整理、 Data Act

両者は補完関係と考えることもできる。

また、Data ActはData Governance Actとも補完関係と考えられる。

日本とEU・英国の間のデータ越境移転に関するセーフハーバー

欧州から日本に対しては、2019/1/23に十分性認定がされており、EU域内と同等の個人データ保護水準を持つ国と認定されている。参考：日EU間・日英間のデータ越境移転について日本は個人情報保護法第28条でEUを指定、EUはGDPR第45条に基づき日本を十分性認定。

ただし、個人情報保護法に基づき補完的ルール適用が必要。参考：補完的ルール補完的ルールでは以下のような規定。

要配慮個人情報の範囲の拡張
保有個人データの範囲の拡張
データ主体の権利保護
データの安全管理措置

まとめ

データ主権を議論する際には、基本的事項としてデータを収集・保存した地域における法律遵守が主旨になり、さらにいわゆるデータローカライゼーションの原則が挙げられる。個人情報保護の観点がひとつは挙げられるが、それに限らない。一方で経済や技術発展のためには、バランスをとったデータ越境移転が必要であり、DFFTのような提唱も行われている。

参考

Use HOME in case of using sudo [ansible]

2024-08-25

Knowledge ManagementAnsible

ansible

メモ
参考

メモ

ansible で sudo 時に実行ユーザの HOME 環境変数を取得するを参考にした。

以下のようなロールを作っておき、プレイブックの最初の方に含めておくと良い。以降のロール実行時に、変数 ansible_home に格納された値を利用できる。

roles/regsiter_home/tasks/main.yml

- block:
  - name: Get ansible_user home directory
    shell: 'getent passwd "{{ansible_env.SUDO_USER}}" | cut -d: -f6'
    register: ansible_home_result

  - name: Set the fact for the other scripts to use
    set_fact:
      ansible_home: '{{ansible_home_result.stdout}}'
      cacheable: true
tags:
  - register_home

元記事と変えているのは、SUDO実行ユーザ名を取るところ。環境変数から取るようにしている。

プレイブックでは以下のようにする。

playbooks/something.yml

- hosts: "{{ server | default('mypc') }}"
  roles:
    - register_home
    - something

参考

ansible で sudo 時に実行ユーザの HOME 環境変数を取得する

Management Domain of EDC

2024-07-14

Knowledge ManagementDataspace ConnectorEclipse Dataspace Components

Dataspace Connector, EDC, IDS

メモ
- 概要
- Topology
- Architecture
- 実装
参考

メモ

概要

2024/6あたりから、 EDC/management-domains のドキュメントが追加された。

EDC/management-domains/Introduction の通り、Management Domainを利用することで、EDCコンポーネント群を組織的に管理することができる。例えば、管理組織と下部組織にわけ、下部組織は管理組織に管理を委譲できる。

ここで言うEDCコンポーネントとは、例えば以下のようなものが挙げられている。

Catalog Server
Control Plane
Data Plane
Identity Hub

2024/7/14現在では、対象は以下のようになっている。

1	The current document will outline how management domains operate for three EDC components: the Catalog Server, Control Plane, and Data Plane.

Topology

デプロイメトには種類がある。大まかに分けて、単一構成（Single Management Domain）と分散型構成（Distributed Management Domains）である。

1: Single Mangement Domain
- Catalog Server、Control Plane、Data Planeがすべて同一のプロセスもしくは同居プロセスに存在する。k8sで構成されるが、ひとつのドメインで管理される場合も含まれる。
- Single Management Domainの最も単純な例
- Single Management Domainのクラスタの例
2: Distributed Management Domains
- 下部組織を持つ他国籍、複合企業体のような分散型のドメイン管理。この複合企業体は、ひとつのWeb DIDを用いる。当該複合企業体のデータを利用する企業は、ある下部組織のアクセス権しか持たないケースもある。
2a: Catalog Serverを持つ下部組織をRoot Catalogでまとめる
- Distributed Management DomainでCatalog Serverを持つ下部組織をまとめる例
2b: 親のCatalog Serverが異なるManagement Domainを管理する
- Distributed Management DomainでCatalog Serverが下部組織の異なるManagement Domainを管理する例
2c: 親のManagement DomainがCatalog ServerとControl Planeを持ち、下部組織のData Planeをまとめる
- Distributed Management Domainで親Management DomainがCatalog ServerとControl Planeをもつ例

分散型の構成は、親Management Domainがどこまでを担うかによります。

Architecture

EDCはDCAT3のCatalog型を利用する。Catalog型の親はDataset型である。またCatalog型はほかの複数のCatalogを含むことができる。その際、Service型で定義する。したがって、以下のような例になる。

{
  "@context": "https://w3id.org/dspace/v0.8/context.json",
  "@id": "urn:uuid:3afeadd8-ed2d-569e-d634-8394a8836d57",
  "@type": "dcat:Catalog",
  "dct:title": "Data Provider Root Catalog",
  "dct:description": [
    "A catalog of catalogs"
  ],
  "dct:publisher": "Data Provider A",
  "dcat:catalog": {
    "@type": "dcat:Catalog",
    "dct:publisher": "Data Provider A",
    "dcat:distribution": {
      "@type": "dcat:Distribution",
      "dcat:accessService": "urn:uuid:4aa2dcc8-4d2d-569e-d634-8394a8834d77"
    },
    "dcat:service": [
      {
        "@id": "urn:uuid:4aa2dcc8-4d2d-569e-d634-8394a8834d77",
        "@type": "dcat:DataService",
        "dcat:endpointURL": "https://provder-a.com/subcatalog"
      }
    ]
  }
}

Sub CatalogはDCATのService型で関連付けされる。この例は、Distributed Management Domainの2aに相当する。

アクセス管理についても考える。 2bのパターンのでは、親のCatalog Serverが下部組織のManagement Domainを管理する。そのため、ContractDefinitionにアクセス権を定義することで下部組織へのアクセス管理を実現する。

また、さらに集中型のControl Planeを設ける場合は、親のControl Planeが子のData Planeを管理する。

また、2024/7時点での設計では、複製を避けるようになっている。これは性能と単純さのためである。複合Catalogは上記の通り、ハイパーリンクを使用するようにしており、非同期のクローラで遅延ナビゲートされることも可能。また、Catalogもそうだが、Contract NegotiationやTransfer Processのメタデータも複製されないことにも重きが置かれている。各Management Domainはそれぞれ責任を持って管理するべき、としている。もし組織間で連携が必要な場合は読み取り専用の複製として渡すEDC拡張機能として実現可能である。なお、個人的な所感だが、これは2aや2bであれば実現しうるが、2cだとControl Planeが親側に存在するため、Contract Negotiationの管理主体が親になってしまうのではないか、と思うがどうだろうか。Data Plane側はもしかしたら、下部組織側に残せるかもしれない。

実装

以上の内容を実現するため、いくつかEDCに変更が行われる。

Asset にCatalogを示す真理値を追加。もし @type が edc:CatalogAsset の場合は真になる。
Management APIが更新される。 Asset に @type を持てるように。
Dataset の拡張として Catalog を追加
DatasetResolverImpl を更新。 Asset のCatalogサブタイプを扱えるように。
JsonObjectFromDatasetTransformer をリファンクたリング。 Catalog サブタイプを扱えるように。

合わせて、Fedrated Catalog Crawler (FCC) をリファクタリング。複合カタログをナビゲートし、キャッシュできるように。参加者ごとにCatalogの更新をアトミックに実行できるようにする必要がある。

Management APIはCatalogを要求する際、ローカルのFCCキャッシュを参照するようにリファクタリングされる。

Catalog Serverもリファクタリングされる。

参考

MVD_of_EDC

2024-07-07

Knowledge ManagementDataspace ConnectorEclipse Dataspace Components

Dataspace Connector, EDC, IDS

メモ
参考

メモ

2024/7/12時点でプロジェクトのドキュメントが更新され、旧来Developer Documentとされていたものがなくなった。その代わり、README に色々な記述が追加されている。今回はこれを使って試す。

Identity & Trustについての説明

README#Introduction にある通り、Eclipse Dataspace Working Groupの下で、IdentityやTrustの仕様検討が行われている。ただ、当該章に記載のリンクをたどると、Tractus-Xのサイトにたどり着く。 -> Eclipse Tractus-X/identity-trust 当該レポジトリのREADMEでも記載されているが、この状態は暫定のようだ。

Until the first version of the specification from the working group is released and implemented, this repository contains the current specification implemented in the Catena-X data space. Maintenance is limited to urgent issues concerning the operation of this data space.

何はともあれ、2024/7現在は、Verifiable Credentialを用いたDecentralized Claims Protocolは絶賛仕様決定・実装中である。

目的

README#Purpose には、このデモの目的が記載されている。このデモでは、2者のデータスペース参加者が、クレデンシャルを交換した後、DSPメッセージをやり取りする例を示す。

もちろん、旧来からの通り、このデモは商用化品質のものではなく、いくつかの shortcut が存在する。

シナリオ

management-domain を用いたFederated Catalogsを用いている。

シナリオの概要をいかに示す。

図の通り、Provider CorpとConsumer Corpの2種類の企業があり、　Provdier CorpにはQ&AとManufacturingという組織が存在する。Q&AとManufacturingにはそれぞれEDCが起動している。Provdier Copの親組織にはCatalogとIdentityHubが起動している。このIdentityHubはCatalog、EDC（provider-qna）、EDC（provider-manufacuturing）に共通である。また、participantIdも共通のものを使う。Consumer CorpにはEDCとIdentityHubがある。

Data setup

図の通り、実際のデータ（assets）は各下部組織にある。そのカタログは直接外部に晒されない。その代わり、親組織であるProvider CorpのCatalog Server内のroot catalogにそのポインタ（catalog assets）が保持される。これにより、Consumer Corpはroot catalogを用いて、実際のassetの情報を解決できる。

(wip)