[Mac M2 Pro 12CPU, Sonoma 14.3.1, clang++ 15.0.0]
ChatAIアプリのGUI右側CMDボタンでOpenAI互換APIサーバの起動コマンドを生成し、自動的にターミナルを開いて実行するようにしました(AppleScript)。サーバの状況はターミナルからモニタリングします。
CodeLlama日本語版とチャットしてみると相当に気難しくてうまく誘導しないと正答にたどり着けないことが分かりました。これはこれで面白く、ローカルLLMですから無料というのが魅力です。
gpt-4への課金がどれくらい削減できるか、楽しみです。
[Mac M2 Pro 12CPU, Sonoma 14.3.1, clang++ 15.0.0]
llama.cppでOpenAI互換APIサーバを立ち上げ、ChatGPTのようにチャットできるようにしました。
モデルは ELYZA-japanese-CodeLlama-7b-instruct-q4_K_M.gguf です。
cd /Volumes/DATA_m1/AI/llama.cpp && ./server -m models/ELYZA-japanese-CodeLlama-7b-instruct-q4_K_M.gguf -ngl 1 -c 4096サーバのURLは以下のようになります。
url : http://localhost:8080/v1/chat/completions
[Mac M2 Pro 12CPU, Sonoma 14.3.1, clang++ 15.0.0]
ローカルLLMの性能を検証するアプリをSwiftUIで製作しました。
modelsディレクトリに入っているggufファイルを選択し、promptを入力してtxtファイル化、llama.cppのmainコマンドを作成します。コマンドはクリップボードに自動コピーされます。あとはターミナルにコマンドを貼り付けて実行し、responseを手動で右側のTextEditorにペーストしてtxtファイルにします。
promptファイルとresponseファイルのプレフィックスはコマンド作成時のタイムスタンプ(yymmdd_hhmmss)になっています。
今回はほとんどclaude-3 opusとgpt-4にコードを考えてもらいました。Buttonラベルの改行表示についてはclaude-3では埒が開かず、gpt-4がテキスト分割を提案して不本意ながら解決しました。SwiftUIに関してはclaude-3とgpt-4はほぼ互角といった印象です。
SwiftUIのmacOS版ではButtonのラベルを改行できないようです。iOS版では問題なく出来るはずですが、macOS版の後進性に若干引いています。
※claude-3利用状況
claude-3のAPIキーを取得して5日経ち、5ドルの無料分がほぼ無くなりました。私の用途ではgpt-4に対する優位性を体感できなかったので、今後は割安なgpt-4メインに戻ります。なおclaude-3 APIの支払いで個人はマイナンバーの入力を求められているため、登録は見送りました。Claude Pro($20/month)への登録もしません。
[Mac M2 Pro 12CPU, Sonoma 14.3.1, clang++ 15.0.0]
対応LLM：gpt-4, gpt-4-vision, claude-3
claude-3ではgptのようにrole:systemは設定できず、systemという独立したパラメータとして扱います。つまりmodelやtemperatureと同じです。
以前の記事で紹介したようにuserのcontentの先頭に追加しても効果は同じだと思いますが、一応公式の方法に従います。
if (urls == ""){
// claude-3 画像なし
requestData = "{\"model\":\"" + model + "\", \"messages\":[{\"role\":\"user\",\"content\":\"" + question + "\"}], \"system\":\"" + systemStr + "\",\"temperature\":0.0, \"max_tokens\":4096}";
} else {
// claude-3 画像あり
string requestData_1 = "{\"model\":\"" + model + "\", \"system\":\"" + systemStr + "\", \"messages\":[{\"role\":\"user\",\"content\":[{\"type\":\"text\",\"text\":\"" + question + "\"},";
＜以下略＞[Mac M2 Pro 12CPU, Sonoma 14.3.1, clang++ 15.0.0]
対応LLM：gpt-4, gpt-4-vision, claude-3
claude-3でも画像のエンコードデータを送れるようにしました。JSONの形式がgpt-4と異なるため、かなり手を入れました。
画像のあるなしに関係なくclaude-3の方がレスポンスに時間が掛かります。
if (model.find("gpt") != string::npos){
// gpt-4
requestData = "{\"model\":\"" + model + "\", \"messages\":[{\"role\":\"system\",\"content\":\"" + systemStr + "\"},{\"role\":\"user\",\"content\":\"" + question + "\"}], \"temperature\":0.0}";
} else {
if (urls == ""){
// claude-3 画像なし
requestData = "{\"model\":\"" + model + "\", \"messages\":[{\"role\":\"user\",\"content\":\"" + systemStr + question + "\"}], \"temperature\":0.0, \"max_tokens\":4096}";
} else {
// claude-3 画像あり
string requestData_1 = "{\"model\":\"" + model + "\", \"messages\":[{\"role\":\"user\",\"content\":[{\"type\":\"text\",\"text\":\"" + systemStr + question + "\"},";
vector<string> urlList = splitString(urls, '\n');
cout << "urlListの要素数: " << to_string(urlList.size()) << endl;
std::stringstream imageStream;
for (size_t i = 0; i < urlList.size(); ++i) {
// ローカル画像はBase64形式にエンコードする
if (urlList[i].find("https:") != string::npos){
cout << "claude3への画像URL送信には未対応" << endl;
return "";
} else {
string base64_image = file_to_base64(urlList[i]);
string file_extension = get_file_extension(urlList[i]);
string url = "\"media_type\":\"image/" + file_extension + "\",\"type\":\"base64\", \"data\": \"" + base64_image + "\"";
imageStream << "{\"type\": \"image\", \"source\": {" << url << "}}";
}
if (i < urlList.size() - 1) {
imageStream << ",";
}
}
std::string requestData_2 = imageStream.str() + "]}], \"max_tokens\": 4096,\"temperature\": 0.0}";
cout << "requestData_2: \n" << requestData_2.c_str() << endl;
requestData = requestData_1 + requestData_2;
}
}※ file_to_base64関数他については前回の記事参照
[Mac M2 Pro 12CPU, Sonoma 14.3.1, clang++ 15.0.0]
対応LLM：gpt-4, gpt-4-vision, claude-3
これまでは自分のブログの非公開記事に画像を貼り付けて、そのURLを送信していましたが、ローカル画像をBase64形式にエンコードして送れるようにもしました。
string requestData_1 = "{\"model\":\"" + model + "\", \"messages\":[{\"role\":\"system\",\"content\":\"" + systemStr + "\"},{\"role\":\"user\",\"content\":[{\"type\": \"text\", \"text\":\"" + question + "\"},";
cout << "requestData_1: \n" << requestData_1.c_str() << endl;
vector<string> urlList = splitString(urls, '\n');
cout << "urlListの要素数: " << to_string(urlList.size()) << endl;
std::stringstream imageStream;
for (size_t i = 0; i < urlList.size(); ++i) {
// URLの場合はそのまま使用し、ローカルの場合はBase64形式にエンコードする
if (urlList[i].find("https:") != string::npos){
imageStream << "{\"type\": \"image_url\", \"image_url\": {\"url\":\"" << urlList[i] << "\"}}";
} else {
string base64_image = file_to_base64(urlList[i]);
string file_extension = get_file_extension(urlList[i]);
string url = "data:image/" + file_extension + ";base64," + base64_image;
imageStream << "{\"type\": \"image_url\", \"image_url\": {\"url\":\"" << url << "\"}}";
}
if (i < urlList.size() - 1) {
imageStream << ",";
}
}
std::string requestData_2 = imageStream.str() + "]}], \"max_tokens\": 4096,\"temperature\": 0.0}";
cout << "requestData_2: \n" << requestData_2.c_str() << endl;
requestData = requestData_1 + requestData_2;#include <boost/archive/iterators/base64_from_binary.hpp>
#include <boost/archive/iterators/transform_width.hpp>
#include <boost/archive/iterators/ostream_iterator.hpp>
#include <fstream>
#include <sstream>
#include <string>
std::string file_to_base64(const std::string& file_path) {
using namespace boost::archive::iterators;
using Base64EncodeIterator = base64_from_binary<transform_width<std::string::const_iterator, 6, 8>>;
std::ifstream file(file_path, std::ios::binary);
std::string file_contents((std::istreambuf_iterator<char>(file)), std::istreambuf_iterator<char>());
std::stringstream os;
std::copy(Base64EncodeIterator(file_contents.begin()), Base64EncodeIterator(file_contents.end()), ostream_iterator<char>(os));
size_t num = (3 - file_contents.length() % 3) % 3;
for (size_t i = 0; i < num; i++) {
os.put('=');
}
return os.str();
}
std::string get_file_extension(const std::string& file_path) {
size_t dot_pos = file_path.rfind('.');
if (dot_pos == std::string::npos) return "";
return file_path.substr(dot_pos + 1);
}[Mac M2 Pro 12CPU, Sonoma 14.3.1, clang++ 15.0.0]
対応LLM：gpt-4, gpt-4-vision, claude-3
claude-3ではgpt-4のようにrole:systemの設定ができないため、最初のプロンプトでuserとして指示します。
if (model.find("gpt") != string::npos){
requestData = "{\"model\":\"" + model + "\", \"messages\":[{\"role\":\"system\",\"content\":\"" + systemStr + "\"},{\"role\":\"user\",\"content\":\"" + question + "\"}], \"temperature\":0.0}";
} else {
requestData = "{\"model\":\"" + model + "\", \"messages\":[{\"role\":\"user\",\"content\":\"" + systemStr + question + "\"}], \"temperature\":0.0, \"max_tokens\":1024}";
}[Mac M2 Pro 12CPU, Sonoma 14.3.1, clang++ 15.0.0]
対応LLM：gpt-4, gpt-4-vision, claude-3
ネット観察しているとClaude3 Opusの評判がやたらいいので、ChatGPTアプリに導入しました。今日からChatAIアプリに改名します。
GPT-4と同様にlibcurlライブラリを使って通信します。認証(Authorization)のところで少し手間取りました。
これからじっくり比較評価していきます。
string url;
if (model.find("gpt") != string::npos){
url = "https://api.openai.com/v1/chat/completions";
}else{
url = "https://api.anthropic.com/v1/messages";
}
const char* apiKey;
const char* apiKey2;
apiKey = getenv("CHATGPT_API_KEY");
apiKey2 = getenv("CLAUDE_API_KEY");
// appファイルは環境変数を取得できないため直打ち
if (apiKey == NULL) {
apiKey = "xxx";
}
if (apiKey2 == NULL) {
apiKey2 = "xxx";
}
string authHeader;
if (model.find("gpt") != string::npos){
authHeader = "Authorization: Bearer " + string(apiKey);
} else {
authHeader = "x-api-key: " + string(apiKey2);
}
curl_slist* headers = {};
headers = curl_slist_append(headers, authHeader.c_str());
headers = curl_slist_append(headers, "Content-Type: application/json");
if (model.find("claude") != string::npos){
headers = curl_slist_append(headers, "anthropic-version: 2023-06-01");
}
[Mac M2 Pro 12CPU, Sonoma 14.3.1, clang++ 15.0.0]
実行方法：llama.cpp
記事その1ではWindows11PCで検証しましたが、GGUF形式であればMacでも動作可能なので早速試してみました。Metalを使用しています。
4bit量子化したGGUF形式のモデルはサイズが4.08GBですから、RAM16GBでも問題なさそうです。
質問によっては無回答で終了することもあるものの、それなりに考えたプロンプトであればSwiftUIの簡単なコードについては正しい答えが返ってきました。
ただし量子化の影響なのか、下図のような簡潔な正答になることもあれば、勝手にチャットのようになったり、誤答を返すことも多く、結構不安定です。
量子化していないGGUF形式のモデルで検証したいところです。
./main -m models/ELYZA-japanese-CodeLlama-7b-instruct-q4_K_M.gguf --temp 1.0 -ngl 1 -t 10 -f ./prompt_jp.txt
[Mac M2 Pro 12CPU, Sonoma 14.3.1, clang++ 15.0.0]
LLMのランタイムであるllama.cppのmake時にセグフォ11が発生しました。
コンパイラがclangなのが問題なのかと考え、gccとg++に置き換えましたがダメでした。
Xcode内にあるclangのシンボリックリンクをgcc、g++にリネームして/usr/local/binに置いても状況は変わらず。
/usr/binにあるgccとg++(共に中身はclang)を認識させるようにすると、やっとmakeできました。.bash_profileの行を一部入れ替えて/usr/binの優先順位を上げています。
# /usr/binの優先順位を上げる
export PATH=/usr/local/bin:$PATH
export PATH=/usr/bin:$PATH
llama.cpp開発者がMacユーザーはCコンパイラをデフォルトのままで使用するものと想定しているために起こったトラブルでした。
gcc、g++についてclangではなく正規ファイルを使っているMacユーザーの存在は考慮していません。23年4月までのllama.cppでは正規ファイルでもビルド可能でした。ただし、その頃はモデル形式がGGMLだったため、現在のGGUFタイプのモデルは使用不可です。
make中のトラブルをデバッグする手段がなく途方に暮れましたが、Cコンパイラが動作するタイミングでセグフォ11が発生していることから推測して何とか解決できました。
gcc、g++の正規ファイルを使用しているMacユーザーのLLM使いは案外少ないのか、llama.cppのGitHubやStackOverFlowでこのような話題はありませんでした。
このトラブルの解決に丸一日費やしてしまいました。