Work: DNN FX sim, Over-NAT-Lib, NostrP2P, FunnelKVS, SamehadaDB, gookv, goopg, tetetennis and etc. Interest: DBMS, PG, distributed, parallel, ML. 86.

Views are my own
Joined January 2007
当方、自作(R)DBMSのサイト立ち上げなどしたのですが、既にやってる人、いつかやりたい人、DBMSについてより深く知りたい人などなどで交流を持てる場が欲しいと思い『自作DBMS Discord』というものを運用しております。 ご興味あれば気軽に参加ください! ROM専OKです。 discord.com/invite/ZBNMrGpzp…
1
9
1
36
8,619
違った。内部的に使ってはいるんだろうけど。
dev-null.sh/@ryo_grid 登録してみた。 gitでcommitすると投稿できる?
2
138
dev-null.sh/@ryo_grid 登録してみた。 gitでcommitすると投稿できる?
1
1
236
LLM-rg 750B Instruct (ryo_grid / Ryo Kanbayashi) retweeted
We launched OSS Scanner, which gives critical open source projects free, periodic vulnerability scans from our strongest models. Each finding includes a proof-of-concept, and a patch where possible. red.anthropic.com/oss-scanne…
220
966
251
10,024
677,188
PGのリリース延期について。 ふーむ・・・。
全网都在担心 AI 写出一堆烂代码(AI Slop)把开源世界搞垮,结果顶级开源数据库 PostgreSQL 却上演了完全相反的魔幻剧情: 人类辛辛苦苦写了大半年、准备发版的 PostgreSQL 19,被进化后的 AI 代码审查员直接干延期了。不是因为 AI 在制造垃圾,而是 AI 抓真 Bug 的速度,已经彻底超过了人类顶级专家修 Bug 的速度。 1️⃣ 8~10 项重磅新功能被迫回滚:包括备受期待的 SQL Property Graph Queries 在内的近十个已合并特性被紧急撤回,正式版从原定的 9-10 月推迟到 11 月 19 日。 2️⃣ 不是误报噪音,全是深层真雷:许多网友第一反应是“AI 又在刷无效工单搞 DDoS”,但核心维护者辟谣:这些全是人类写代码时漏掉的真实边缘缺陷(Edge cases)。 3️⃣ 几年的隐蔽周期被压缩成几秒:以往这类底层 C 语言边缘 Bug 往往要潜伏好几年才会在生产环境爆雷,如今前沿大模型在短短几个月内进化,把未来几年的雷一次性全扒了出来。 以前通过人类严苛审查就能上线,现在却过不了 AI 这一关。当找漏洞变成零成本,而修底层架构依然依赖极少数人类大牛,开源维护者该怎么破局?
3
735
漢方の作用機序って西洋医学的には十分に明らかにはなってないと聞いていたいたが、チャッピーによると分かっているものも増えてきたがそうでないものも依然多いし、どんな化合物が含まれるかも現代技術の下でもおおむね分かるが完全ではない、とか。 東洋医学三千年の歴史か...(雑)
1
92
今動かしてるRalphループ(のハーネス?)をこのフレームワーク上で作り直すと、ハーネスの自己改善を効率よくやれるようになるで!みたいなもんではない...ようかな。 今のところ。 何かそういう感じのforkないかしら。 github.com/google-research/h…
1
170
ただ、動的な挿入・削除には弱いので、適用できる対象は考える必要がある。 実装もなんかある。 github.com/gilnett/learned_i…
こんなものを知った。B-treeみたいにデータごとにエントリ持たずデータ分布を複数セグメントで線形近似して、それを階層的にやれば、メモリ減るで、と。 "The PGM-index: a fully-dynamic compressed learned index with provable worst-case bounds" (PVLDB 2020)" arxiv.org/abs/1910.06169
1
152
こんなものを知った。B-treeみたいにデータごとにエントリ持たずデータ分布を複数セグメントで線形近似して、それを階層的にやれば、メモリ減るで、と。 "The PGM-index: a fully-dynamic compressed learned index with provable worst-case bounds" (PVLDB 2020)" arxiv.org/abs/1910.06169
1
1
261
LLM-rg 750B Instruct (ryo_grid / Ryo Kanbayashi) retweeted
MAI-Base-2は、2.8Tパラメータ、80B activeのMoEモデルを、16000基のGB200を用いて38日間、50Tトークンで事前学習したと報告している。 前回のMAI-Baseに続き、公開情報が限られている大規模事前学習について、技術的な詳細や実験結果、開発手法がまとめられており、参考になる。 今回も、改善ループが回せるよう、小規模モデルの実験結果から大規模モデルの性能を正確に予測するために、Source Scalingという手法を導入している。 具体的には、あるデータソースについて本番モデルで8 epoch繰り返す場合、小規模実験でも同じ8 epochを繰り返すように、使用するデータソースのサイズを調整する。 通常、小規模実験では本番学習よりも学習トークン数が少ないため、同じデータソースを使うと繰り返し回数が少なくなる。しかし、それではデータの反復による過学習などの影響を再現できず、小規模実験で得られた最適な設定が本番モデルでも最適になるとは限らない。 Source Scalingでは、学習トークン数だけでなく、ユニークなデータ量やデータの反復率も調整することで、大規模学習の挙動を小規模実験から予測しやすくしている。 もう一つの重要な結果は、学習率(LR)とWeight Decay(WD)を独立に探索するのではなく、その積に着目することで、最適なハイパーパラメータについて次の経験則を得ていることである。 LR × WD = 17.04 / S また、最適な学習率は次の関係を満たす。 log LR = -1.51 + 0.175 log(TPP) - 0.573 log S ここで、Sは学習ステップ数、TPPは学習トークン数をActive Parameter数で割った値である。 なお、LRとWDの積に着目する考え方は、既存研究でもいくつか見られ、初出ではない。 Weight Decayによる累積的な重みの縮小効果を考えると、学習率が一定であると単純化した場合、 W_{t+1} ≒ (1 - LR × WD) W_t となる。これをSステップ繰り返すと、 W_S ≒ exp(-S × LR × WD) W_0 となる。 今回の経験則では、S × LR × WD = 17.04なので、 W_S ≒ exp(-17.04) W_0 となり、学習全体を通じたWeight Decayの累積的な強さは、設定によらず一定に保つという意味を持つ。 なお、実際には学習率のスケジュールや勾配による重みの更新が存在するため、重みのスケールがこのようになるわけではない。 また、これらの係数は今回の実験設定で得られた経験値であり、異なるOptimizerやモデル構造でもそのまま成り立つとは限らない。 このほか、Activation Gradient Clippingによって学習の安定性を大きく改善したことも興味深い。 通常のGradient Clippingでは、重みに対する勾配のノルムを制限する。しかし、巨大なバッチのうち1サンプルだけが異常に大きな勾配を発生させた場合でも、バッチ全体の勾配が縮小されてしまう。 そこで、ネットワーク内の特定箇所におけるActivationの勾配をクリップする方法を採用している。 Activationに対する勾配は、Backward Passではバッチやトークンの次元が保持されているため、重み勾配として合算される前に、個別の勾配を制限できる。 これにより、異常なサンプルの影響を局所的に抑えつつ、正常なサンプルの学習信号を残すことができる。 さらに、異常に大きな勾配を発生させたサンプルを調査したところ、データの前処理のバグにより、想定しない位置でトークンが出現していることが判明し、データ前処理の修正にも役にたった。 計算効率についても注目に値する。MAI-Base-2は、総パラメータ数2.8T、活性化率約2.9%という非常に大規模かつ疎なMoEモデルであるにもかかわらず、モデル全体でMFU 21%を達成している。 GB200のピークBF16性能を2.5 PFLOPSとすると、これは1GPUあたり525 TFLOPSの有効学習演算性能に相当する。特に、MoE層単体ではMFUを24%から35%まで改善しており、全層MoEを採用できるようになったことも重要である。 コメント === 前回のMAI-Baseに引き続き、大規模モデルの事前学習について詳細な技術情報を提供している。 前回は、様々な後続タスクに関連するテキストの予測誤差を指標として、同じ損失に到達するための投入計算資源をどこまで減らせるかという、学習効率の最適化に重点が置かれていた。今回は、こうした開発手法をさらに大規模なモデルへと適用し、実際に学習を完了させた成果といえる。 特に、総パラメータ数が約3T、活性化率が3%を下回るモデルを実際に学習している点は重要であり、モデル規模としてはフロンティアモデルに近い。 今回の報告において独自の評価指標ではDeepSeek-V4-Proの事前学習などを上回る結果が得られたと報告している。今後、Post-trainingによって推論能力やエージェント性能がどの程度向上するのかが注目される。 もう一つ注目したいのは、これほど大規模な事前学習を38日間で完了させたことである。 従来、大規模モデルの事前学習には3〜4か月程度をかける例も多いが、今回は16,000基のGB200を投入し、高い疎率にもかかわらずMFU 21%という学習効率を実現していることで、1ヶ月強で終了させている。 このような短期間で終わるようになれば大規模事前学習でも、アーキテクチャ、データ、Optimizer、学習条件などを改善して再学習するサイクルをすすめらえっるようになる。
2
14
3
89
14,840
ん?
Google just open-sourced Harness². (turn any harness into a self-improving system) a harness is everything wrapped around the model, like the system prompt, tools, memory, skills, and subagents. today a person designs it once, and the agent runs every new task with that same fixed setup. Harness² lets the agent refine that setup for each new task on its own, with the model weights left untouched. on every task, the agent proposes edits to its harness, runs a few candidate versions, and composes a better harness by comparing how those runs behaved. because it learns from the differences between runs, it needs no correct answer or grader for the task. that covers a single task. Harness² also carries what it learns from one task into the next. after each task, it saves the harness it settled on along with the lessons that held up across the runs. the next time it refines a harness, it starts from those notes instead of from scratch. this means every finished task makes the next round of edits more informed. Google tested this with Gemini 3.5 Flash and GLM-5 on legal, office, and professional work benchmarks. one round of edits was enough to beat their original harnesses, and giving the agent more rounds pushed scores higher. those extra rounds can go wide or deep. the agent either tries several candidate harnesses at once or keeps refining a single one step by step, using OpenCode or Codex to carry out the work. you can find the Harness² repo here: github.com/google-research/h… I wrote about a similar idea for agents already running in production, where the harness should repair itself after a failure instead of waiting for someone to debug the trace by hand. that piece walks through how @Cometml's Opik (open-source) closes this loop, going from a failing trace to a proposed fix to a regression test that stops the same failure from coming back. it's quoted below.
2
327
ただexpertをコーディング特化で削っているので日本語での指示は無理っぽい。 というかコーディング特化ってどこまでを含むんだろう感。使ってみていてもよくわからない。
過去にはOpusあたりの商用モデルでやった気がするが、Qwen 3.8 Flash-Next の Coder(カスタマイズ版)IQ1_M over Strata を128k略でローカルLLMし、OpenCodeで接続してRustでEmacsモドキを書かせてみている。 Qwen 3.8 27Bを頑張って量子化してモデル重みやらを13GBくらいに抑えたやつより速い
1
186
過去にはOpusあたりの商用モデルでやった気がするが、Qwen 3.8 Flash-Next の Coder(カスタマイズ版)IQ1_M over Strata を128k略でローカルLLMし、OpenCodeで接続してRustでEmacsモドキを書かせてみている。 Qwen 3.8 27Bを頑張って量子化してモデル重みやらを13GBくらいに抑えたやつより速い
Strataで Coder IQ1_M 128kコンテキスト動かして、いい感じなものの、コンテキスト利用量が10%強くらいになるとグラボのドライバのエラーでOSごと落ちてしまい、まぁ無茶だよなぁとかあきらめそうになったが、ドライバ含むパッケージみたいなのを少し古い安定verしたら解決した! 最強!
1
1
451
サーキュレータ所有者のうち全員が扇風機として使うことがある(N=4)
サーキュレータに関しての質問です。 あなたは
100%サーキュレータ所有かつ扇風機として使うことがある
0%サーキュレータ所有かつ扇風機として使うことがない
0%サーキュレータを所有していない
0%回答だけ見たい
4 votes • Final results
1
130
Strataで Coder IQ1_M 128kコンテキスト動かして、いい感じなものの、コンテキスト利用量が10%強くらいになるとグラボのドライバのエラーでOSごと落ちてしまい、まぁ無茶だよなぁとかあきらめそうになったが、ドライバ含むパッケージみたいなのを少し古い安定verしたら解決した! 最強!
引用の引用の構成で、Qwen3.8 Flash-Next カスタマイズ版のうちのCoderというやつの IQ1_Mという量子化かけたやつが64kコンテキストで動いた模様。 ただ、StrataのWeb UIで Thinkingが有効と思われる状態でコード生成させてみただけで、Coding Agentではまだ試せていない。 TPSはおおむね20t強/sだった
1
1
456
まだサーキュレータの利用方法に関する投票やってます!
サーキュレータに関しての質問です。 あなたは
100%サーキュレータ所有かつ扇風機として使うことがある
0%サーキュレータ所有かつ扇風機として使うことがない
0%サーキュレータを所有していない
0%回答だけ見たい
4 votes • Final results
103
サーキュレータに関しての質問です。 あなたは
100%サーキュレータ所有かつ扇風機として使うことがある
0%サーキュレータ所有かつ扇風機として使うことがない
0%サーキュレータを所有していない
0%回答だけ見たい
4 votes • Final results
1
1
1
345
ただ、TPC-DSはSFによって両方データがメモリに載る条件でも、マッチする数が大きく違ったりしてるのでPGが通るルートをこの条件でももうらできてない網羅できてないということである。 まだ、先は長いかなぁ。
GoなPGクローンgoopg(開発中)で、TPC-HとTPC-DSで(恣意的なことせずに)同じプラン吐くように1ヶ月弱かそこらくらい作業させてたのだけど、ようやく尻上がりにマッチするものが増えてきた。 報告を信じればTPC-H(SF1)は22/22、TPC-DSも70程度/99まで来た。 github.com/ryogrid/goopg/com…
1
219
GoなPGクローンgoopg(開発中)で、TPC-HとTPC-DSで(恣意的なことせずに)同じプラン吐くように1ヶ月弱かそこらくらい作業させてたのだけど、ようやく尻上がりにマッチするものが増えてきた。 報告を信じればTPC-H(SF1)は22/22、TPC-DSも70程度/99まで来た。 github.com/ryogrid/goopg/com…
1
2
460
LLM-rg 750B Instruct (ryo_grid / Ryo Kanbayashi) retweeted
これめっちゃ便利なのでみんな使って codex版もほしいい --- Claude Codeに過去の会話を思い出させる|babarot zenn.dev/babarot/articles/cl… #zenn
5
37
2
438
30,951
ほう?
This quoted post is unavailable.
2
128