Tag: data

X (Twitter) 的工程團隊列出了最近做的事情

在 Hacker News 上看到的討論，在 Elon Musk 接手後的 X (Twitter)，工程團隊做了什麼事情：「X Engineering Year Retrospective (twitter.com/xeng)」，原推在：

其中裡面有些蠻有趣的，出現了一些平常不太會出現的數字資訊。

我比較有興趣的關掉了加州 Sacramento DC 的這個部分，而光是這個 DC 就有 148k 台 server (是 server，不是 VM 或是 container)，而且也提到電力少了 48MW，看起來是把這些 server 廢掉，而不是轉到其他機房？

- Shutdown the Sacramento data center and re-provisioned the 5,200 racks and 148,000 servers, which generated more than $100M in annual savings. In total, we freed up 48 MW of capacity and tore down 60k lbs. of network ladder rack before re-provisioning it to other data centers.

話說一個 Twitter 機房用 48MW... 查了一下台電網站，核三的一個機組的供電量也才 951MW：

而且 Twitter 服務要用到 148k server，hmmm...

日本 LINE 推出的 LLM (以日語材料訓練)

看到「36億パラメータの日本語言語モデルを公開しました」這篇，日本的 LINE 丟出 Apache License 2.0 的 LLM，拿起來跑看看還蠻有趣的：

他的特點是用日語資料訓練出來的 LLM：

最終的な学習には約650GBのコーパスを利用していますが、英語の大規模コーパスとして一般的に用いられているもの（Pileコーパス）が約800GBであることを踏まえると、我々のデータも遜色ない大きさであると言えます。

我拿 1.7B 跑，小修改一下故意給英文的 prompt 後，可以看到輸出頗有趣的，畢竟是從日文資料訓練出來的：

{'generated_text': 'An apple a day keeps the doctor away.\n「一日リンゴ1個」は apple days で'}
{'generated_text': 'An apple a day keeps the doctor away thinking happier. The biggest happ'}
{'generated_text': 'An apple a day keeps the doctor away from here.」と英語で訳しましょう。「I have a dream'}
{'generated_text': 'An apple a day keeps the doctor away(sometimes usually thinks far a'}
{'generated_text': 'An apple a day keeps the doctor away. 日はまたのぼり、 医者は去って行った。 They'}
{'generated_text': 'An apple a day keeps the doctor away thought about being in the center of the'}
{'generated_text': 'An apple a day keeps the doctor away from all the time.\n16. I feel like'}
{'generated_text': 'An apple a day keeps the doctor away and draws and eats around one table'}
{'generated_text': 'An apple a day keeps the doctor away from your mother\nAnd another male you are'}
{'generated_text': "An apple a day keeps the doctor away. What's the opinion you wrote in"}

這邊有訓練的運算量計算，1.7B 的 model 訓練換成起來會用道 4000 小時的 A100 80GB (假設你有 100 張的話，就是 40 小時)：

本モデルの構築に要した時間について、例えば1.7BモデルについてはA100 80GBで換算し、約4000GPU時間を費やしています。学習時間は特に日本語の大規模言語モデルの学習では公開されていないことが多く、適切な比較はできませんが、例えば rinna 0.3Bモデルの学習はV100 32GBで約8600GPU時間を費やしているようで、費やした時間に比して効率の良い学習が行えていると考えられます。

目前是提到有計畫要放出 instruction tuning 的版本：

また、これらのモデルについて、指示文に対して適切な出力を行えるようにチューニング（Instruction tuning）したモデルを近日中に公開予定です。続報は@LINE_DEVをフォローしてお待ち下さい。

這個 LLM 先記起來，以後也許在其他場景有機會用到？

KeyDB：使用 Multithreading 改善 Redis 的效能

在 Hacker News 上看到有支援 Multithreading 的 Redis fork：「KeyDB – A Multithreaded Fork of Redis (keydb.dev)」，官網在「KeyDB - The Faster Redis Alternative」這邊。

不過這篇是要記錄從 Hacker News 看到的雷點，這樣以後自己再找資料的時候會比較容找到。

36022425 這篇是跳下去用發現不太行，最後在 application 端實作需要的 feature，後端還是用原廠的 Redis：

To counter what the other active business said, we tried using KeyDB for about 6 months and every fear you concern you stated came true. Numerous outages, obscure bugs, etc. Its not that the devs aren’t good, its just a complex problem and they went wide with a variety of enhancements. We changed client architecture to work better with tradition Redis. Combined with with recent Redis updates, its rock solid and back to being an after-thought rather than a pain point. Its only worth the high price if it solves problems without creating worse ones. I wish those guys luck but I wont try it again anytime soon.

* its been around 2 years since our last use as a paying customer. YMMV.

另外是在專案裡搜尋「is:open is:issue label:"Priority 1"」的結果可以看到不太妙，在 36021108 這邊有提到的問題：

Filed July, eventually marked priority 1 in early December, not a single comment or signs of fix on it since. That doesn't look good at all.

然後 36020184 有提到 Snap 買進去後沒有什麼在管 open source project 的部分了：

I think I'll stay far away from this thing anyway. Numerous show-stopper bug reports open and there hasn't been a substantial commit on the main branch in at least a few weeks, and possibly months. I'll be surprised if Snap is actually paying anybody to work on this.

Brave 宣佈 Brave Search 完全使用自己的資料，不用 Bing 的了

Brave 宣佈 Brave Search 獨立，不再使用 Bing 的資料了：「Brave Search removes last remnant of Bing from search results page, achieving 100% independence and providing real alternative to Big Tech search」。

依照 Brave 的說明，先前大約 7% 是來自 Bing 的 API：

Every Web search result seen in Brave Search is now served by our own index. We’ve removed all search API calls to Bing, which previously represented about 7% of query results.

但只要商業模式還是廣告，我應該不會去用... 但比起目前市場上一堆包其他家 search engine 的搜尋引擎來說，這的確是個好消息。

用 Automerge 處理 CRDT 問題

上個月看到 Automerge 出了 2.0 版的消息：「Automerge 2.0」，Automerge 這個套件可以幫你處理複雜的 CRDT 結構 (Conflict-free replicated data type)。

可以看到 Automerge 在 2.0 之後的效能改善不少，可以跟 yjs 比較了：

所以練了一下手測界面怎麼用，另外也看一下 conflict 時的處理方式。

這邊先產生 hello, world.，然後做了三個操作，第一個是把開頭的 h 改成 H；第二個是把 world 改成 test；第三個是把 world 改成 example：

(() => {
  const Automerge = require('@automerge/automerge');

  let doc1 = Automerge.init();

  doc1 = Automerge.change(doc1, 'Init', doc => {
    doc.text = new Automerge.Text();
    doc.text.insertAt(0, 'h', 'e', 'l', 'l', 'o', ',', ' ', 'w', 'o', 'r', 'l', 'd', '.');
  });
  
  let doc2 = Automerge.clone(doc1);
  let doc3 = Automerge.clone(doc1);

  doc1 = Automerge.change(doc1, 'Capitalize', doc => {
    doc.text.deleteAt(0);
    doc.text.insertAt(0, 'H');
  });
  doc2 = Automerge.change(doc2, 'world => test', doc => {
    delete doc.text.deleteAt(7, 5);
    doc.text.insertAt(7, 'test');
  });
  doc3 = Automerge.change(doc3, 'world => example', doc => {
    delete doc.text.deleteAt(7, 5);
    doc.text.insertAt(7, 'example');
  });

  let finalDoc = Automerge.merge(doc1, doc2);
  finalDoc = Automerge.merge(finalDoc, doc3);
  console.log(finalDoc);
})();

這樣最後會產生出 Hello, testexample.：

{
  text: Text {
    elems: [
      'H', 'e', 'l', 'l', 'o',
      ',', ' ', 't', 'e', 's',
      't', 'e', 'x', 'a', 'm',
      'p', 'l', 'e', '.'
    ]
  }
}

這結果看起來還行。

只能說以前要是有這些 library 就好了，當初在 KKBOX 做雲端歌單自己搞半天...

拿 JupyterLab 生一些圖

先前看到「Python Data Visualisation」這篇就在研究要怎麼在 Linux 桌面環境下用 Python 搭配 Altair 生圖，在寫一些文件的時候會方便一些。

但先前一直卡住 (不是生不出來，而是流程不順)，所以就放在 browser tab 上面一直沒動。直到前幾天看到 JupyterLab Desktop 改版，想說來看看改得如何：「Introducing the new JupyterLab Desktop!」。

先講一下結論，安裝不算太困難，界面也不差 (畢竟是重點)，但 interface bug 很多，常常按下去沒反應 XD

第一次跑的時候我先把 Python 的環境指到 pyenv 的 ~/.shim/python3。

先拿文章裡的範例丟進去跑：

import altair as alt
from vega_datasets import data

source = data.stocks()

alt.Chart(source).mark_line().encode(
    x='date',
    y='price',
    color='symbol',
    strokeDash='symbol',
)

會長這樣：

然後輸出圖表的右邊的 menu icon 展開後可以選 Save as PNG 存成圖片。

雖然不能直接存到 clipboard 方便我直接貼到 Imgur，但至少可以先打磨出想要的圖，再輸出成檔案處理...

Vultr 開大阪機房

Vultr 宣布開大阪機房：「New Cloud Data Center Location: Osaka, Japan」。

本來的東京機房從 HiNet 過去會塞，可以看到每天都會有一段時間 latency 會飄起來：

從 HiNet 過去 Vultr 東京機房是走 PCCW 的線路：

從 Vultr 東京機房回來是走 NTT 的線路：

如果是 Vultr 大阪機房的話，先用 mtr 看了一下 latency，狀況似乎是好很多？好像可以考慮把東京的機器搬到大阪看看...

Vultr 更新流量計算方式

一時間沒找到在哪邊看到的，但的確是漏掉這個消息，早上看到去翻才注意到的... Vultr 在去年 11 月底宣佈更新流量的計算方式：「Vultr Announces Reduced Bandwidth Pricing, 2 TB of Free Monthly Egress, Free Ingress, and Global Pooling」。

這波費用的更新算是跟上另外兩家 (Linode 與 DigitalOcean) 的算法了，先前 Vultr 的算法就很古老 XD

第一個是 inbound traffic 不算錢了 (總算)：

Data ingress will now be free.

再來是 traffic pool 的概念，現在每個帳號的流量會統一計算，而非每台機器自己計算：

All customers will receive global account-level pooling of transfer across all instances and locations.

然後是每個帳號都提供 2TB 的 free outbound traffic，這點有點放送的感覺：

Every Vultr customer will now receive two terabytes (2 TB) of free outbound data transfer every month, in addition to the transfer included with each subscription.

最後是超量的部份收費也簡化了，不管什麼地區都是 $0.01/GB：

Vultr will now offer a reduced, single worldwide egress overage rate of only $0.01 per GB.

最後這點有個值得操作的點：依照他的收費標準，超量 1TB 的流量需要付 $10 的費用，但你可以多租一台 $5/mo 的機器，這個方式提供了 1TB 的流量到 traffic pool 裡面。

fp32、fp16 與 bf16

在 nanoGPT 這個專案下面看到 bf16 這個浮點格式：(這段在新版的 README.md 被改寫了)

Currently fp16 is much faster than bf16. Potentially revert back to using fp16 and re-introduce the gradient scaler?

翻了一下 bf16，是由 Google 的團隊所提出來的想法，主打是與 fp32 相同的表示範圍，但是犧牲精度，這樣一來既有使用 fp32 的程式很有機會可以直接換成 bf16 降低計算量 & 提昇效率 (也就是 drop-in replacement)：

然後同一頁也看到各家自己推出不同的格式，這邊看起來比較像是市場競爭的關係...

Apple 使用 Cassandra 的量

Hacker News Daily 上看到的：「Cassandra at Apple: 1000s of Clusters, 300k Nodes, 100 PB (twitter.com/erickramirezau)。原文在 Twitter 上：

有些數字有點對不太起來，裡面提到 300K nodes + millions of QPS，但通常讀寫都算 QPS，這樣聽起來很少？所以有種可能這邊是只有算 read 的部份...

另外照片裡面提到 Over two petabytes per cluster，但有 thousands of clusters，最後卻只有 Hundreds of petabytes of data，完全對不上，就算當作平均值來算也對不上，只能猜測是最大的 cluster 而不是 per cluster。

裡面矛盾的地方太多，所以這些數字基本上沒有參考價值，現在能讀出來的只知道 Apple 有在用 Cassandra，然後不是少少幾台 PoC 等級的使用。