Georgi Gerganov 給了在 AWS 上面用 GPU instance 跑 llama.cpp 的說明

Georgi Gerganov 寫了一篇怎麼在 AWS 上面用 GPU instance 跑 llama.cpp 的說明:「Using llama.cpp with AWS instances #4225」。

先跳到最後面的懶人套件,直接提供了 shell script 幫你弄完:

bash -c "$(curl -s https://ggml.ai/server-llm.sh)"

回到開頭的部分,機器的選擇上面,他選了一台最便宜的 4 vCPU + 16GB RAM + 16GB VRAM 的機器來跑。

然後他提到了 OpenHermes-2.5-Mistral-7B 這個模型最近很紅,也許有機會看一下:

We have just 16GB VRAM to work with, so we likely want to choose a 7B model. Lately, the OpenHermes-2.5-Mistral-7B model is getting some traction so let's go with it.

用 llama.cpp 裡面的 server 跑起 API server:

./server -m models/openhermes-7b-v2.5/ggml-model-q4_k.gguf --port 8888 --host 0.0.0.0 --ctx-size 10240 --parallel 4 -ngl 99 -n 512

接著就可以用 cURL 測試:

curl -s http://XXX.XXX.XXX.XXX:8888/v1/chat/completions \
    -H "Content-Type: application/json" \
    -H "Authorization: Bearer no-key" \
    -d '{
        "model": "gpt-3.5-turbo",
        "messages": [
            {
                "role": "system",
                "content": "You are ChatGPT, an AI assistant. Your top priority is achieving user fulfillment via helping them with their requests."
            },
            {
                "role": "user",
                "content": "Write a limerick about python exceptions"
            }
        ]
    }' | jq

都包好了...

OpenAI 的 API 又降價了...

這次 OpenAI 的 API 又降價了,這次是倍數等級的降:「New models and developer products announced at DevDay」。

GPT-4 Turbo 的部分直接是拉高 context 以及降低價錢,從本來的 8K/32K context,直接拉高到單一 128K context 產品,而且價錢直接砍了 3/4 左右:

GPT-4 8K
Input: $0.03
Output: $0.06

GPT-4 32K
Input: $0.06
Output: $0.12

GPT-4 Turbo 128K
Input: $0.01
Output: $0.03

GPT-3.5 Turbo 則是直耶拿掉 4K context 產品,然後把價錢砍了一半:

GPT-3.5 Turbo 4K
Input: $0.0015
Output: $0.002

GPT-3.5 Turbo 16K
Input: $0.003
Output: $0.004

GPT-3.5 Turbo 16K
Input: $0.001
Output: $0.002

GPT-3.5 Turbo fine-tuning 的服務則是從本來 4K context 產品線,多了一條 16K context 的產品線,價錢也是砍了一半以上:

GPT-3.5 Turbo 4K fine-tuning
Training: $0.008
Input: $0.012
Output: $0.016

GPT-3.5 Turbo 4K and 16K fine-tuning
Training: $0.008
Input: $0.003
Output: $0.006

另外也多了一些非文字類的功能,包括了影像與聲音的內容。

記得之前有想過的一些點子,當時粗算了一下覺得太貴,好像可以重算看看...

Amazon SQS 提高 FIFO throughput 限制

在「Amazon SQS announces increased throughput quota for FIFO High Throughput mode」這邊看到 AWS 提高了 Amazon SQS 中 FIFO throughput 的限制,這本來是個常常有的公告,但讓我意外的是不同區域拉高的數量是不同的:

Amazon Simple Queue Service (SQS) announces an increased quota for a high throughput mode for FIFO queues, allowing you to process up to 9,000 transactions per second, per API action in US East (Ohio), US East (N. Virginia), US West (Oregon), Europe (Ireland), Europe (Frankfurt) regions. For Asia Pacific (Mumbai), Asia Pacific (Singapore), Asia Pacific (Sydney), and Asia Pacific (Tokyo) regions, the throughput quota has been increased to 4,500 transactions per second, per API action. For all other regions where SQS is generally available today, the quota for high throughput mode quota has been increased to 2,400 transactions per second.

第一梯隊的 (像是 us-east-1us-west-2eu-west-1) 都是 9000 tps,而第二梯隊是 4500 tps,沒列在上面的區域是 2400 tps。

另外一個比較特別的是 Frankfurt 區居然在第一梯隊...

Let's Encrypt 與 IdenTrust 延長三年的 cross sign 在 2024/10/01 要結束了

先前 Let's EncryptIdenTrust 的 cross sign 會在 2024/10/01 到期,可以參考 3958242236 這邊的資訊,可以看到由 IdenTrust 的 DST Root CA X3 對 Let's Encrypt (ISRG) 的 ISRG Root X1 簽名,時間是到 2024/09/30 18:14:03 GMT (換算大概是台灣隔日的清晨兩點多):

Issuer: (CA ID: 276)
    commonName                = DST Root CA X3
    organizationName          = Digital Signature Trust Co.
Validity
    Not Before: Jan 20 19:14:03 2021 GMT
    Not After : Sep 30 18:14:03 2024 GMT
Subject: (CA ID: 7394)
    commonName                = ISRG Root X1
    organizationName          = Internet Security Research Group
    countryName               = US

所以 Let's Encrypt 這邊也整理出了對應的落日計畫:「Shortening the Let's Encrypt Chain of Trust」。

第一波是 2024/02/08,從這個時間點開始 Let's Encrypt 的 ACME 服務預設組出來的 SSL certificate 將不會帶 IdenTrust 提供的 cross sign 憑證,但你還是可以自己另外設定取用:

On Thursday, Feb 8th, 2024, we will stop providing the cross-sign by default in requests made to our /acme/certificate API endpoint. For most Subscribers, this means that your ACME client will configure a chain which terminates at ISRG Root X1, and your webserver will begin providing this shorter chain in all TLS handshakes. The longer chain, terminating at the soon-to-expire cross-sign, will still be available as an alternate chain which you can configure your client to request.

再來是過期前的 90 天多一點的 2024/06/06,Let's Encrypt 的 ACME 服務將不會提供 cross sign 的憑證:

On Thursday, June 6th, 2024, we will stop providing the longer cross-signed chain entirely. This is just over 90 days (the lifetime of one certificate) before the cross-sign expires, and we need to make sure subscribers have had at least one full issuance cycle to migrate off of the cross-signed chain.

最後就是過期的日子 2024/09/30:

On Monday, September 30th, 2024, the cross-signed certificate will expire. This should be a non-event for most people, as any client breakages should have occurred over the preceding six months.

依照說明,應該是 Android 7.0 以及之前的版本會產生問題,照目前的數字看起來是 100% - 93.9% = 6.1%:

接下來一年應該會再低一些,但不確定會低多少,有機會 <5% 嗎?

Windows 3.1 下的 GPT client

前幾天在 Hacker News 上看到「Show HN: WinGPT – AI assistant for Windows 3.1 (dialup.net)」這篇,原始文章「WinGPT: AI Assistant for Windows 3.1」在介紹 Windows 3.1 下的 GPT client。

雖然反差很大 (一個 20 世紀的 GUI 環境配上最新科技),但從 Hacker News 的討論可以看到,最熱烈的是在 16-bit 環境下實作 TLS 1.3 連線,也就原文裡的這段,提到了他是原生支援 TLS 1.3:

WinGPT connects to the OpenAI API server natively with TLS 1.3, so it doesn't require a proxy on a modern machine to terminate TLS. To see how I did this and some of the challenges, take a look at Modern TLS on 16-bit Windows. (As you'll see on that page, this is not a secure implementation).

不過他不是從零開始解,而是基於 wolfSSL 的實作,因為 wolfSSL 有支援 16-bit compiler,就不需要從零開始:

WolfSSL stood out among the pack as it had explicit 16-bit compiler support while being fully-featured and well-supported.

這是讓人看到會「蛤?」的東西 XD

OpenLLM,用 Python 包裝 open source LLM 的套件

Hacker News 上看到「OpenLLM (github.com/bentoml)」,是一個用 Python 寫的軟體,把 open source LLM 包裝起來讓你用。

先拿 Mac 簡單測了一下,看起來包的不錯,可以用 HTTP API 來打。

先用 pip 裝:

pip install openllm

然後就可以把 server 跑起來了,依照範例跑 dolly-v2,第一次跑會比較久,需要下載 model:

openllm start dolly-v2

接下來就可以直接開 http://127.0.0.1:3000/ 來操作了,另外也可以用 command line 跑,像是依照官方的範例來跑:

openllm query --endpoint http://127.0.0.1:3000 "What is the meaning of life?"

目前測到比較明顯的問題是 CPU 模式下只有 single thread,所以雖然會動,但相當慢... 之後再來測試 GPU 的部分。

很多 MTurk 的接案者都用 LLM 在解決文字類的問題

剛剛在 Hacker News 上翻到的:「33-46% of workers on MTurk used LLMs in a text production task (arxiv.org)」,論文在「Artificial Artificial Artificial Intelligence: Crowd Workers Widely Use Large Language Models for Text Production Tasks」這邊,這個標題取的很故意... XD

Hacker News 上的標題主要是出自論文 abstract 的這段:

We reran an abstract summarization task from the literature on Amazon Mechanical Turk and, through a combination of keystroke detection and synthetic text classification, estimate that 33-46% of crowd workers used LLMs when completing the task.

想想還蠻正常的?能輕鬆賺當然就輕鬆賺... 但這也代表開發者可以思考 offload 給 LLM 的品質,以及如果需要外部的工人智慧,是不是可以搭配 LLM 再 offload 一些簡單的處理給人類就好?

話說好久沒聽到 MTurk 這個服務了,翻了 wiki 看起來是 2005 年就有的服務。

最近 Reddit 打算大幅調漲 API 費用而進行中的故事

台灣用 Reddit 用的比較少,但在歐美算是超級大站。雖然是 2005 年成立的,但主要是在 2010 年的 Digg 災難後興起。

大幅調漲 API 費用使得目前的 3rd-party client 都無法負擔,像是 Apollo 就需要付 $20M/y 的費用:「Popular Reddit App Apollo Would Need to Pay $20 Million Per Year Under New API Pricing」。

最近的這包事件還在進行,在「Reddit#2023 API changes」這邊有些整理,目前看起來 CEO 是鐵了心要收這筆費用,看起來管理階層覺得不像 2010 年的時候,這次 user 沒有其他地方可以跑?

目前在「List of Active Reddit Alternatives v8」這邊有看到有人整理出來,但不確定這些站能不能撐住這波的流量...

另外補上最近 Reddit 的裁員消息可以交叉看:「Reddit to lay off about 5% of its workforce」。

SHA-256 的 Length extension attack

Hacker News 上看到「Breaking SHA256: length extension attacks in practice (kerkour.com)」,在講不當使用 SHA-256 會導致 Length extension attack 類的安全漏洞,主要是因為 MD5SHA-1 以及 SHA-2 類的 hash function 最後生出 hash 值時會暴露出 hash function 的內部狀態而導致的問題。

這邊講的不當使用是指你沒有使用標準的 MAC,而是自己用字串組合實作造成的問題,通常是 S = H(secret || message) 這樣的形式,這邊的 || 是指字串相接。

拿 MD5 為例子,在維基百科上面可以看到 MD5 演算法對應的 pseudo code,最後輸出的部分可以看到是把 a0a1a2a3 這四個 32-bit variable 接起來,也就是把內部的狀態丟出來了:

// Process the message in successive 512-bit chunks:
for each 512-bit chunk of padded message do
    // ...

    // Add this chunk's hash to result so far:
    a0 := a0 + A
    b0 := b0 + B
    c0 := c0 + C
    d0 := d0 + D
end for

var char digest[16] := a0 append b0 append c0 append d0 // (Output is in little-endian)

於是你在可以反推 padding 的結構之後 (會需要知道 secret 的長度),就可以往後接東西繼續算下去,這就是被稱作 length extension attack。

本來只有 S = H(secret || message),你在不知道 secret 的情況下就可以疊字串到後面而且算出對應的 hash 值,變成 S' = H(secret || message || evildata)

維基百科給的例子也示範了怎麼「用」,這是原始的資料以及 server 端簽出來的 hash 值:

Original Data: count=10&lat=37.351&user_id=1&long=-119.827&waffle=eggo
Original Signature: 6d5f807e23db210bc254a28be2d6759a0f5f5d99

於是我們想要蓋 waffle 參數,就變成:

Desired New Data: count=10&lat=37.351&user_id=1&long=-119.827&waffle=eggo&waffle=liege

攻擊者則可以不斷的嘗試,去猜測 padding 的結構,把計算出來對應的 hash 值丟到 server 看反應,直到看到 200 OK 的回應:

New Data: count=10&lat=37.351&user_id=1&long=-119.827&waffle=eggo\x80\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x02\x28&waffle=liege
New Signature: 0e41270260895979317fff3898ab85668953aaa2

如同前面提到的,這是 hash function 在最後把內部狀態直接暴露出來造成的問題,在 MD5、SHA-1、SHA-2 (SHA-256、SHA-384、SHA-512) 都有類似的問題,而比較新的 hash function 在設計時就已經有考慮到了,不會出現這個問題,像是 SHA-3

另外一方面,不要自己發明演算法,使用標準的 MAC 演算法通常是比較好的選擇。這邊用的比較廣泛的應該就是 HMAC,超過 25 年了。

結論是 SHA-256 還是堪用,儘量拿現成的演算法套,不要自己搞。

關於 LLM 的數字

Hacker News Daily 上看到的文章,講 LLM 的各種數字 (大多都是費用):「Numbers every LLM developer should know (github.com/ray-project)」,原文在「Numbers every LLM Developer should know」這邊。

其中第一條就蠻重要的,如果你是用 API 依照 token 收費的話,叫 API 長話短說會省不少錢 XD

40-90: Amount saved by appending “Be Concise” to your prompt

第二條是給個感覺,換算 word 與 token,不過這邊講的應該是英文的:

1.3:1 -- Average tokens per word

後面也有蠻多數字的,都是讓你有個感覺。都讀過後就可以把 cheatsheet 留下來: