ts4

去年の9月にメディアに大きく取り上げていただいた、LLMの 1bit量子化技術を OneCompressionテクノロジーとしてOSS化しました。(URLはリプライに記載します） AI研究者にとっては釈迦に説法ですが、AIの世界ではGPUメモリが足りなさすぎるので、いかにメモリを節約するかというのがキーテクノロジの1つ。最初はふつうにFP32で行列計算していたのが、NVIDIA GPUが2020年のAmpereからBF16サポート、2022年のHopperからFP8サポートと、低精度サポートに進んで来ました。 単に低精度レジスタ使うだけだと計算精度がボロボロになるため、ソフトウェア面の研究も競争が進んでおり、去年の段階で4bitぐらいならまあいけるかなぐらいの世界になっていました。 というところで、富士通が2025年9月に1bit量子化で実用的な精度でるって発表して話題をさらったというのが、ここまでの話。 それで、この技術のキモは1bitで動くことじゃなくて任意のbit数で精度落ちを防ぐところにあるため、 result = estimate_wbits_from_vram(MODEL_ID, total_vram_gb=0.8) みたいにRAMサイズ指定すると、そのRAMに収まるようにいい感じに精度落すところと高精度のままにするところとを調整してくれるAutoBitを新たに搭載、特にEdgeやオンプレなどのGPUのRAMサイズに制約がある環境でLLMを数倍賢くすることが出来ました。 現在、Llama、Qwen3に対応済みです（仕組み自体にはモデル依存性がないため、今後対応モデルは増やしていけるとおもいます） 開発者たちが、パートナーや大学の研究者たちとの連携を加速していきたいのでフィードバック欲しいといっていますので、よければ使ってやってください。 ※ 一応ですが, onecomp だけでいま動かしているGPUの使えるメモリ使用量を算出して, それに合うように量子化が動きます。

@sunbains @nippondanji スピンロックから少し話題が逸れてしまいますが、私はスピンロックが問題になるような状況であれば、スピンロックのパラメータ以前に、innodb_thread_concurrencyなどで同時実行スレッド数を調整可能になっていることがより良い設計であると認識しています。

It will impact all spin locks in theory, especially ones that hold it long enough where the OS scheduler interrupts the holder. The problematics part is long enough, I think InnoDB doesn’t use pure spin locks but spins before waiting and is probably less impacted by this change. Even without this change if a spin lock holder does a syscall and is blocked or preempted it will cause a similar problem. The performance collapse happens because of a scenario called Lock-Holder Preemption: 1.Postgres Process A acquires a spinlock to update a shared memory area. 2.The Linux 7.0 Kernel decides Process A has used its time slice and "preempts" it (pauses it) while it is still holding that lock. 3.Postgres Processes B, C, and D all try to get that same lock. Since Process A is paused and can't release it, the other processes just sit there "spinning" and wasting CPU cycles. 4.Because there are many cores (e.g., 96 on a Graviton4), you end up with dozens of CPUs doing 100% "useless" work waiting for a paused process to be woken back up by the kernel. The real underlying problem is due to cache coherency if they are spinning and checking the same variable. There are solutions to son on local variables Herlihy discusses them in his book.

MySQL/InnoDBでは30回ぐらいスピンして、それでロックが取れたらラッキー、取れなかったら諦めてOSのロックを使うという２段階の実装になってるんだけど、どうもポスグレのスピンロックは全然思想が違うらしい。

むかしむかし labs.gree.jp/blog/2015/12/1… でInnoDBのスピンロックに言及し labs.gree.jp/blog/2018/07/1… で、スピンロックやmutexの前段階でスレッドの並列度を調整する仕組みがあることに言及しました。 MySQLあるいはMySQL互換を謳うものは、innodb_thread_concurrencyやthread pool、Aurora MySQL独自実装のロックマネージャーといったものがあれば、スピンロックより前の段階で並列度はある程度調整できると考えています。

MySQL のスピンロックの振る舞いはカスタマイズ可能っぽい。PostgreSQL はどうなんだろ。 dev.mysql.com/doc/refman/8.4…

@mita2 たいせつなことだとおもったのでかきました！

Cloud SQL 8.0 の拡張サポート入りまで１年切ってた...ひぃ

@_awache ちょっとだけマジレスすると、「チョットワカル Row-Based Replication」シリーズは読んでたら途中でしんどくなるかもしれないので、気になった記事を読んでもらえればよいですよ

@ts4th labs.gree.jp/blog/2026/03/2… 今まさに近場のここから読んでましたｗｗ

@_awache いまさらですが zenn.dev/awache/article… これですけど labs.gree.jp/blog/2015/12/1… これの「なぜ spin loop が必要なのか」のところで、忙しい人のために三行でまとめてあるからそれも読んで！

@_awache だからたまにはわたしのblogも読んでNE!!!

@ts4th 見事に繋がってますね！！

@_awache だからさらに innodb_thread_concurrencyでnanosleepできるんですYO!! labs.gree.jp/blog/2018/07/1…

@ts4th mutex や OS 待機はコストが高いので、まず軽く spin で様子を見て、すぐ取れるならそのまま取得するために spin lock を使っている と理解しました (雑ｗ)

MySQLアンカンファレンス #012 に参加を申し込みました！ mysql-unconference.connpass.com/event/386959/?… #MySQLアンカンファレンス

今回の資料の中で、@wrcsus4 さんの db tech showcaseの資料や、@fujii_masao さんのインタビュー記事などを紹介させていただきました。

書きました。 今回、「データベースを異なる環境や互換性のあるマネージドサービスなどに移行する際、どういうことを考えてるか、幅広い層に向けて話してください」的なことを言われて書いたので、わりとゆるふわな内容かと思います。 labs.gree.jp/blog/2026/03/2…

@yoku0825 おめでとうございます！

"さくらのクラウドについて、すべての技術要件を満たしたことを確認できたので、2026年3月27日以降本番環境の提供が可能となります。" ガバメントクラウド｜デジタル庁 digital.go.jp/policies/gov_c…

@kazeburo おめでとうございます！

さくらインターネットのさくらのクラウドが、ガバメントクラウドのすべての技術要件を満たし、正式にサービスの提供が可能となりました。 2023年11月に仮認定を頂いてから本当に多くの皆様に協力いただきました。ありがとうございます。 これはスタートでもあり、お客様の課題を解決し、信頼性の高いサービス提供に今後も取り組んで参ります。よろしくお願いします。 digital.go.jp/policies/gov_c…

@kuwa_tw ここは対戦型SNSらしいので、、、

@ts4th こわいお、、、

なんかやべえボタンきてる

祝日なのでvscodeでMySQLのソースコードを眺めていたら、そういや 8.3.0 から C++20 になってたんだなと思い出したときの顔をしている。 github.com/mysql/mysql-se…

現代においてはまずMacか何かでMySQLをビルドして vscode で IntelliSense 使える状態にしつつ、vscode で Codex IDE extension いれてプロンプトで訊きながら読んでいくと、MySQLのソースコードリーディングがとっつきやすくなるかもしれませんね（今更感 「innodb の sync array について解説してください。また、それらを実装しているソースコードを提示してください。」とか「innodb_sync_array_size と innodb_thread_concurrency の違いを並べて整理してください」とか日本語で訊きつつ、該当するソースコードの箇所にジャンプしたりできますし。MySQLは一度ビルドしないとヘッダファイルが揃わないですが、ビルドすればIntelliSense利くからコード読みやすいですしね。

トランザクションを「本気で使いこなす」ための必須知識 PostgreSQLのコミッターを務める、@fujii_masao さんに、「なんとなく」使いがちなトランザクションやロックの仕組みについて、アプリ開発者が押さえておくべき知識を詳しく解説していただきました！ findy-code.io/media/articles…

ニッポンのサラリーマンにとって、平日のこの時間は参加のハードル高いですぞ…！ 午前２時って、 フミキリに望遠鏡を担いで行くような時間じゃないですか…！！ blogs.oracle.com/mysql-jp/%e7%a…

【イベントおしらせ】 Oracleさんが『第2回 MySQLコミュニティ・ロードマップ・公開ディスカッション』をオンラインで開催します。 2026年3月24日(火)朝2時～ blogs.oracle.com/mysql-jp/%E7%A… #mysql_jp