openai

Codex Was Torching Your SSD and Nobody Noticed for Months Your Codex log file looked fine. Your SSD counters did not. The file was small. That was the trick. If you opened <code>~/.codex/</code>, you could see a SQLite database called <code>logs_2.sqlite</code>. It was not huge. It was not swallowing the disk. Finder, Explorer, <code>du</code>, and every normal storage check had nothing dramatic to say. Meanwhile, one developer's SSD recorded roughly 37 TB of writes in 21 days. That works out to about 1.7 TB a day. If you stretch one heavy, continuous-use report across a full year, it becomes roughly 640 TB. The number is not a prediction for every Codex user. It came from one machine running for a long time. But it exposed a problem that is easy to miss with local developer tools: > a file can stay small while the storage device underneath it gets written to constantly. This is the story of a noisy TRACE logging sink, a SQLite database doing exactly what it was told, and the SSD wear that nobody could see from file size alone. The quick version - A user reported unusually high local disk writes and traced them to Codex CLI's <code>logs_2.sqlite</code> database and its WAL companion file. - The reported machine accumulated about 37 TB of writes over 21 days of uptime. - The file stayed bounded because new logs were inserted while older logs were deleted. - The reported cause was an overly verbose TRACE logging path that did not fully respect the expected <code>RUST_LOG</code> override. - The supplied investigation says version 0.142.0 reduced the noisy writes substantially, with early testing reporting around 85% fewer log writes. - If you used an older build heavily, update first, then inspect real write activity and your SSD's lifetime-write counters. The number that made people look twice 37 TB in 21 days is not a normal “developer tool wrote some logs” story. | Measurement | Value | | --- | --- | | Reported writes | ~37 TB | | Reporting window | 21 days | | Approximate daily rate | ~1.7 TB/day | | Annualized at that rate | ~640 TB/year | The annualized number needs context. It assumes the same workload every day for a year, which is rarely how people work. Someone running short sessions will produce far less. Someone leaving the tool open, working with long sessions, or using it in automation could produce much more than they expect. The useful point is not “every SSD will die in a year.” The useful point is that this level of write activity belongs in the category of things you should notice and control. <!-- Visual placement: use a clean SMART dashboard screenshot here, with all serial numbers and personally identifiable drive details blurred. --> Why the file size told you almost nothing Most of us check disk problems like this: du -sh ~/.codex ls -lh ~/.codex/logs_2.sqlite* Those commands answer one question: > How much data is stored right now? They do not answer this: > How much data has been written over time? The Codex log database was designed to retain a bounded amount of diagnostic information. New rows were written, old rows were removed, and the database could remain roughly the same size. So the folder looked calm while the disk was doing constant work. Imagine a café with four tables. Looking through the window at noon, you see four people sitting down. Come back at 6 PM, still four people. The table count tells you nothing about whether eight customers visited or eight hundred. The SQLite file was the same. Stable size, enormous turnover. !Diagram showing how a small SQLite log file can lead to high SSD write activity What was generating all those writes? The reported issue points to a logging path that defaulted to TRACE, the most detailed level in Rust's tracing ecosystem. TRACE logging is useful when you are trying to understand a very specific failure. It can include low-level events that are normally too noisy for everyday use: - file-open events - raw network or WebSocket activity - transport details - telemetry plumbing - dependency-library messages that get bridged into the application's tracing system The supplied breakdown estimates that TRACE-level entries made up 70.7% of the retained log-body size. The highest-volume targets included WebSocket handling, OpenTelemetry-related logs, a generic dependency log bridge, and client transport code. That is diagnostic exhaust. A little of it is fine. A default stream of it, persisted locally in SQLite, is a different kind of workload. The three parts that stacked together No single part of this design has to be bad on its own. 1. TRACE was active where it should have been opt-in TRACE is not a normal default for a tool used for hours at a time. It is the level you turn on when you are actively debugging. The reported behavior was that Codex initialized a feedback logging sink at TRACE. That turns every routine interaction into a lot of diagnostic detail. 2. RUST_LOG=warn did not fully quiet it Rust developers often reach for this first: RUST_LOG=warn codex That is supposed to turn down the volume. According to the issue analysis, it did not fully apply to the relevant sink. If a target did not have an explicit override, Codex's internal default still allowed noisy logging. That is worse than an obvious missing setting. A user can think they reduced logging while the disk keeps receiving the same workload. 3. SQLite turned event noise into storage churn SQLite is excellent. It is also not magic. For small structured local data, a SQLite database is a good choice. For a constant stream of fine-grained TRACE events, inserts, deletes, indexes, and checkpoints, it can create a lot of writes even when the database never becomes large. The problem was not “SQLite is bad.” The problem was using a write-heavy retention loop as a sink for a log level that should not have been permanently enabled. The part the operating system does not show you There are two kinds of amplification in this story. SQLite write amplification SQLite often uses WAL mode, short for write-ahead logging. In simplified form: 1. A log event is appended to the WAL file. 2. SQLite later checkpoints that change into the main database. 3. Older rows are deleted to keep retained data bounded. 4. Indexes and database pages are updated along the way. One logical log event can therefore create more than one write at the filesystem level. The WAL is not wrong. Checkpoints are not wrong. The problem appears when that loop is fed relentlessly with small, noisy events. SSD write amplification An SSD has its own internal life. It writes data in small pages but erases much larger blocks. When a small part of a block changes, the SSD controller often writes the new data to a fresh location, marks old data stale, later moves still-valid pages, and erases the old block. That movement is called garbage collection. Wear leveling moves writes around so one physical area does not wear out first. Both are useful. Both mean the flash may receive more physical writes than the operating system asked for. The ratio is called the write amplification factor. The exact number varies by drive, spare capacity, free space, workload, and controller. The supplied analysis does not measure the multiplier for the affected drive, so do not treat any guessed physical-wear number as a precise fact. The direction is enough: > High-churn, small random writes are one of the workloads SSDs work hardest to manage. Is 640 TB actually dangerous? It can be. SSDs have an endurance rating usually expressed as TBW, or terabytes written. A typical 1 TB consumer SSD may be rated for a few hundred TBW. Enterprise drives may be rated much higher. The exact number depends on the model, capacity, NAND type, and warranty. That does not mean a drive fails the moment it reaches its rated TBW. Ratings are warranty and endurance guidance, not a timer that hits zero at midnight. Plenty of drives outlive them. But a background development tool potentially consuming hundreds of terabytes of writes is still worth taking seriously. It can eat through a meaningful part of the drive's expected write budget without filling the disk or showing a visible failure. How to check your own machine The order matters. Update first. Then look at real I/O. Then check what the drive itself says. Step 1: update Codex The investigation supplied with this article identifies 0.142.0 as the version containing the logging reduction. Check the current release notes and your installed build, then update before you start measuring. Also remember that Codex CLI, the desktop app, and editor integrations can ship or bundle components on different schedules. Updating one does not automatically prove every local Codex-related process is updated. Step 2: find the log files On macOS and Linux: ls -la ~/.codex/logs_2.sqlite* On Windows PowerShell: Get-Item "$env:USERPROFILE\.codex\logs_2.sqlite*" You might see the database, a <code>-wal</code> file, and a <code>-shm</code> file. Do not stop after checking their size. A small database is the whole reason this incident was easy to miss. Step 3: watch actual writes On Linux, <code>pidstat</code> can show which process is writing: pidstat -d 5 To see whether a process has the database open: sudo lsof ~/.codex/logs_2.sqlite On macOS, open Activity Monitor, select the Disk tab, and watch bytes written for Codex-related processes while you work. On Windows, use Resource Monitor or Task Manager's disk column. Look at sustained per-process writes, not just a brief spike during startup. Step 4: check the drive's own lifetime write counter This is the closest thing to the truth you have. On Linux or macOS with smartmontools installed, an NVMe drive can often be checked with: sudo smartctl -a /dev/nvme0 Look for: - Data Units Written - Percentage Used - warnings or critical health indicators On Windows, CrystalDiskInfo exposes Total Host Writes and health information. PowerShell can also show some device health data: Get-PhysicalDisk | Get-StorageReliabilityCounter | Select-Object DeviceId, Wear, Temperature Compare lifetime writes with the TBW rating for your exact drive model. Do not compare against a random SSD number from a search result. <!-- Visual placement: add a small annotated image of a SMART page here. Highlight only Data Units Written or Total Host Writes, Percentage Used, and health status. --> What if I used an older version for months? First, do not panic and do not guess from file size. Check the drive counters. If the drive has low percentage used and reasonable total writes for its age and workload, update and move on. If the drive has unusually high wear, warnings, or a large write count compared with its TBW rating, back up your important data and plan for a replacement before failure forces the schedule. This is a good backup reminder even if your drive looks healthy. SSDs usually fail without much theatre. Workarounds if you cannot update immediately Updating is the right fix. These are temporary ways to reduce persistent write pressure while you arrange that update. Put throwaway logs on ephemeral storage For CI jobs and containers, the cleanest option is usually to run with a temporary home directory or mount the relevant config directory on ephemeral storage. Example for a disposable CI environment: export HOME="$(mktemp -d)" For a container workload, mount a tmpfs at the appropriate Codex state directory if the environment can tolerate losing local diagnostics when the job exits. This is especially useful for build runners that create and destroy their environment anyway. Be careful with /tmp Moving a log file to <code>/tmp</code> is only useful if <code>/tmp</code> is actually memory-backed in your environment. On many Linux systems it may be tmpfs. On macOS, <code>/tmp</code> is not automatically a RAM disk by default. Check the mount before assuming the write load vanished: mount | grep ' /tmp ' Then verify with a real I/O monitor. Never trust a workaround because it sounded plausible in a comment thread. Avoid unsupported database surgery unless you really need it Some community workarounds modify the SQLite log database so inserts are ignored. That can be useful in an emergency, but it is an unsupported change to an internal application file. Future versions may change the schema or assume the database behaves normally. If you choose that route, stop Codex first, make a copy of the database, document what you changed, and remove the workaround once you are on a fixed release. The bigger lesson for tool builders This bug is bigger than one CLI. Measure bytes written, not just disk space used Every local persistence feature should have an I/O budget under realistic usage. Test bytes written per hour, per session, and per day. File size is not a sufficient metric for databases, caches, indexes, or log rotation systems. TRACE must be an intentional decision Verbose logging needs an explicit opt-in and a clear way back out. Shipping it by default turns every user into a debugging environment. Standard controls have to work end to end If your ecosystem has a standard logging override, honour it for every sink. A partial override is dangerous because it gives experienced users false confidence. Structured logs have storage costs SQLite, RocksDB, local search indexes, and caches are all good tools. High-frequency writes have a cost. The design needs backpressure, batching, rate limits, retention rules, and test coverage for pathological verbosity. Privacy and wear are connected The more raw operational detail a tool records, the more it writes and the more sensitive local data it can retain. Logging file paths, raw transport frames, and low-level event payloads should be a deliberate debugging choice, not background noise. The bigger lesson for users There is a simple habit worth keeping: > When you install a new long-running developer tool, look at its write rate once. Two minutes in Activity Monitor, Resource Monitor, or <code>pidstat</code> can catch a surprising amount. Check lifetime SSD writes occasionally. Keep your tools updated. Treat a stable file size as a storage number, not an I/O number. The log file was small. The work it made the SSD do was not. What is confirmed and what is still uncertain The supplied investigation is clear about its limits, and those limits matter: - The 37 TB measurement came from one heavy user's machine. It is a data point, not a universal rate. - Reports disagree about when the highest logging verbosity began. The exact start date is uncertain. - The annualized 640 TB figure is arithmetic based on the reported 21-day sample, not a forecast. - SSD write amplification is real, but the exact physical NAND multiplier was not measured for this incident. - The reported 85% reduction after version 0.142.0 is an early observed result, not a guarantee for every platform or workload. That uncertainty does not weaken the main finding. The correct response is still simple: update, measure the process, and inspect the drive counter. Sources and further reading - GitHub issue #28224 in openai/codex - Official OpenAI Codex documentation - The public reporting and technical analysis supplied for this article, including Notebookcheck, Windows Report, Lilting.ch, yage.ai, and Daniel Vaughan's write-up

Inflearnが自動で字幕を生成するまで（AI/インフラ編） ! この記事は2023年10月31日に執筆されたものです。 こんにちは。InflabのDevOpsエンジニア、SunBです。 2023年9月、Inflearnに字幕とスクリプトの機能が追加されました。皆さん、活用されていますか？　今回追加された字幕機能は、動画の音声データをもとに自動で字幕を生成する部分と、生成された字幕を受講画面に表示する部分の、大きく2つに分けられます。 今日は、このうち私が実装を担当した字幕生成について、どのような技術をもとに、どのような過程を経て実装したのかをお話しします。 2日で字幕機能を作ってデモする まず、「DevOpsエンジニアが字幕機能を実装したの？」と思われる方もいらっしゃると思うので、今回の字幕機能の実装プロジェクトがどのように始まったのかをご紹介します。 Inflabでは今年から、Infthonという名前で社内ハッカソンを開催しています。応募者をランダムに4人1組のチームに分け、約2日間でアイデアの議論とMVPの実装を行ったあとに発表する、という形式です。 ところが偶然（？）、Inflearnの講座プレイヤーやVODインフラを多く手がけていたFE開発者のPapicoと私が同じチームになり、自然と講座の再生に関するアイデアを議論することになりました。そして、第1回Infthonのテーマだった「チームの生産性向上、またはAIを活用したサービス改善」に最も合うと考えた講座のAI字幕機能をアイデアとして選びました。 まず、AIベースの字幕生成機能を実装するにあたって、最低限の条件として次のことを考えました。 字幕生成がオフラインで動作すること（データの外部送信を防ぐ） 字幕生成にコンピューティングリソース以外の追加費用がかからないこと（オープンソースモデルを自前で実行） 字幕生成にかかる時間が動画の長さを超えないこと（ライブデモができるくらい速いこと） これらの条件を満たす技術を探してみたところ、OpenAIのWhisperというモデルが目に留まりました。Whisper以外に検討した技術は以下のとおりです。 KoSpeech: Archived OpenSpeech + KsponSpeech: 自分たちで学習させてモデルを作るには、技術への理解度もまだ低く、時間もかなりかかると予想された KakaoのPORORO: Archived MetaのSeamlessM4T: テスト用の講座を使ったPoCの過程で、SeamlessM4T largeモデルはWhisper large-v2モデルに比べて精度が劣ることを確認 NaverのCLOVA SpeechなどのAPIベースのサービス: データの外部送信とAPI料金が発生 Infthon以前にも、MacWhisperなどのツールで、OpenAIのSTTモデルであるWhisperの存在とその精度の高さは知っていましたが、深く調べたことはありませんでした。実装期間が2日と短かったため、仕組みを深く理解することよりも、素早く適用してデモできるかどうかを重視して作業を進めました。その結果、すべての処理を私のMac上でオフラインで動かす構成になりました。その際、Pythonで実装されたOpenAIのWhisperは遅すぎたため、代わりにC++に移植されたwhisper.cppを使いました。 こうして、次の流れを短期間で実装できました。 動画をアップロードする ffmpegで16-bit WAVの音声データを抽出する whisper.cpp + large-v2モデルで字幕を書き起こし、srtファイルとして保存する 受講画面でこのsrtファイルを再生する さらに、FE開発者のPapicoの活躍で、スクリプトの表示と再生位置の移動、字幕の修正依頼と修正依頼の管理機能までデモでき、第1回Infthonで1位という栄誉を手にしました。 こうして楽しい経験として幕を閉じたと思っていたのですが…… 正式プロジェクトとして採用 ある意味当然のことながら、字幕機能はすぐに正式プロジェクトとして採用され、新たなスタートを切りました。 Infthonですでにデモまで終えていたので大きな心配はありませんでしたが、引っかかる点が3つありました。 Shaka Playerでm3u8のHLSプレイリストとsrt字幕ファイルを同時に表示すると、字幕の同期がずれる問題 AWSのインフラでWhisperをまだ動かしたことがなかった点 韓国語字幕の1行あたりの長さと改行位置が適切でなく、読みにくい問題 1つ目は、FE開発者のPapicoが字幕の表示処理をShaka Playerの機能を使わずにReactで新たに実装し、きれいに解決してくれました。一方、2つ目と3つ目は、そのまま現実の問題として降りかかってきます。 インフラ上でWhisperを動かす Infthonのときとは違い、今回は実際のユーザーにサービスを提供するため、まずは私たちのインフラ上で機能を動かす必要がありました。 エンコーディングインフラの改善記録 字幕生成インフラについてお話しする前に、まず動画エンコーディングインフラを改善した過程をご紹介します。 私たちは2022年10月まで、動画のエンコーディングにAWS MediaConvertを使っていましたが、コスト削減とエンコーディングオプションのカスタマイズのために、EC2 c6i.xlarge Spot InstanceベースのAWS Batch構成に移行しました。MediaConvertのReserved Queueなど、さまざまな代替案も試しましたが、予約したエンコーディングの開始が遅すぎたり、4Kなど一部のオプションが使えないといった制約があったりして、要件を満たすのは難しいと判断し、自分たちで構成する方向を選びました。 結果として、インフラ構成の変更は効果がありました。長さ28分の1080p動画を540p、720p、1080pにエンコードする場合、AWS Batchを使ったときとMediaConvertを使ったときにかかる時間と費用は、以下のとおりでした。 AWS Batch (ECS EC2 c6i.xlarge Spot) MediaConvert (On-Demand Pro) 差 時間 約10分 約7分 約3分 (x0.7) 費用 約$0.021 約$1.895 (SD x 1, HD x 2) 約$1.874 (x90.2) 動画の長さと比べれば、エンコーディング時間の差はわずかですが、費用はなんと90倍以上の差があることを確認しました。 AWS Batch構成で、EC2インスタンスタイプごとの費用と性能を分析した結果は以下のとおりです。（長さ28分の1080p動画を540p、720p、1080pにエンコードする場合、Spot Instance未適用） インスタンスタイプ オンデマンドの1時間あたりの費用 (A) エンコーディングの実行時間 (B) 実際の費用 (A x B) c6i.xlarge $0.192 10分 $0.032 c6g.xlarge $0.154 12分47秒 $0.033 c6i.2xlarge $0.384 5分57秒 $0.038 c6i.4xlarge $0.768 4分23秒 $0.056 g5g.xlarge $0.5166 5分1秒 $0.043 g5.xlarge $1.237 3分15秒 $0.067 エンコーディングインフラと同じ構成でwhisper.cppを試す 上記の改善したエンコーディングインフラをもとに、字幕インフラも同じ構造で構成してみました。AWS Batch上のc6i.xlargeインスタンスで28分の動画に対してwhisper.cppを実行したところ、結果はなんと69分3秒と、予想よりもはるかに遅いものでした。 Infthonのデモ用にMac Studio（M1 Ultra）で同じ動画をwhisper.cppで処理したときは、3分30秒でした。これを見て、すぐにGPUインスタンスのPoCに取りかかりました。 GPUインスタンスのPoC 最初は、g5インスタンスより安いARMベースのg5g.xlargeインスタンスを使ってみようとしました。ところが、NVIDIAドライバーやCUDAのバージョンをいくら変えても、PyTorchからCUDAを認識できませんでした。CUDA 11のPython cuDNNライブラリはARMアーキテクチャをサポートしておらず、PyTorchの正式版はCUDA 12をサポートしていなかったため、PyTorch Nightly + CUDA 12 cuDNNの構成を試しましたが、torch.cuda.is_available() が False を返す状態が続きました。そんな中、AWS BatchではまだARMアーキテクチャベースのGPUインスタンスをサポートしていないというドキュメントを見つけ、g5gインスタンスの利用はひとまず諦めました。 その後、g5.xlargeインスタンスでOpenAIのPythonベースのWhisperを実行してみたところ、7分17秒かかりました。動画の長さに比べれば許容範囲でしたが、Mac Studioでwhisper.cppを使ったときは3分30秒だったことを考えると、ほかに方法はないかと考えるようになりました。そして、SeamlessM4Tについて調べていたとき、偶然Hacker NewsでWhisperXに言及しているコメントを見かけました。 WhisperXへの移行 WhisperXを使って、g5.xlargeインスタンスで28分の動画の字幕生成を試してみたところ、59秒で完了し、最も速い結果となりました。その出力結果も、Whisperやwhisper.cppと比べて精度が劣るということはなく、それぞれ一長一短がありました。 以下は、出力結果を比較した当時に書いたメモの一部です。 Whisper、WhisperXはg5.xlargeで、whisper.cppはMac Studioで抽出したバージョン 3つともかなり違いがあるが、どれか1つが最も優れているというわけではなく、それぞれにうまく書き起こせている部分がある。 WhisperXが正確に抽出した部分 뽑았는데 (Whisper: 꼽았는데) 등허리 (Whisper: 등어리) 복부 (Whisper: 복구) whisper.cppが正確に抽出した部分 Eye Reflect (WhisperX: I Reflect) Whisperが正確に抽出した部分 Z-Remesh (WhisperX: gremesher) 아이리플렉트 (WhisperX: I Reflect) WhisperXはほかの2つよりはるかに速く実行でき、音節単位でalignするので行の再構成に有利であり、字幕の修正依頼機能の有効性も比較的高くなると推定されることを考えると、WhisperXを使うのが最も良いと思われる。 ただし、ときどき複数の文を早口で話す部分で抜け落ちる文があるが、精度が低いと判断して意図的に除外しているように見える。 まとめ 最初に試したwhisper.cpp + c6i.xlargeを基準に、試した組み合わせとの差をまとめると次のとおりです。（large-v2モデルを使って28分の音声データを書き起こした場合） ツール マシン 実行時間 差（速度） whisper.cpp c6i.xlarge 69分3秒 - (x1) Whisper c6i.xlarge 時間がかかりすぎて計測を中断 - WhisperX c6i.xlarge 実行中にエラーが発生 - whisper.cpp Mac Studio 3分30秒 65分33秒 (x19.7) Whisper Mac Studio 時間がかかりすぎて計測を中断 - WhisperX Mac Studio 15分26秒 53分37秒 (x4.5) whisper.cpp（cuBLASビルド） g5.xlarge 17分25秒 51分38秒 (x4) Whisper g5.xlarge 7分17秒 61分46秒 (x9.5) WhisperX g5.xlarge 59秒 68分4秒 (x70.2) 最終的に、WhisperX + g5.xlargeの組み合わせを選びました。 こうして最初の絶望を乗り越え、速度を70倍以上改善し、インフラ上で字幕生成機能を正常に動かせるようになりました。その過程でGPUインスタンスや動画エンコーディングに関する分析も行い、エンコーディング関連のプロセスも改善できました。 （試行錯誤の跡） 字幕の長さと読みやすさの改善 字幕をどう生成するかという課題は、音声データからテキストを抽出するだけでは終わりませんでした。 whisper.cpp、Whisper、WhisperXのいずれにも、--max_line_width のような1行の長さを制限するオプションがあったのですが、問題はこのオプションが動作しないことでした。（……）おそらく韓国語だから動作しないのだろうと推測しています。 そのため、モデルが出力した字幕データは行ごとに長さがバラバラで、文の終わりで改行されることもほとんどなく、読みやすさは最悪でした。 これを改善するために、ピリオド/疑問符/感嘆符があれば改行する案、一定の文字数以上なら単純に空白を基準に半分に分割する案、形態素解析によって行を再構成する案など、さまざまな方法を模索しました。 そんな中、WhisperXに移行して音節単位で時間を追跡できるようになったことで、いっそすべての行を一から作り直そうと考えました。そこで以下の基準を定め、WhisperXの実行から行の構成までを一度に行うPythonスクリプトを実装しました。 WhisperXが時間の追跡に失敗した音節の時間は、時間の追跡に成功した最も近い前後の音節の時間、または文の開始・終了時間から線形補間する。（wav2vecの韓国語モデルベースだったため、ハングル以外は音節の時間を追跡できないという問題がありました。） 直前の単語までの行の長さが0.5秒未満であれば、ほかのどの条件を満たしていても改行しない。 直前の単語までの行の長さが10秒を超えたら、現在の単語から新しい行にする。 現在の単語を加えると行が10文字を超え、かつ形態素解析の結果で文の数が変わる場合は、現在の単語から新しい行にする。 現在の単語を加えると行が50文字を超える場合は、現在の単語から新しい行にする。 文の開始が直前の文の終わりから0.5秒以内の場合は、文の開始時間として直前の文の終了時間を代わりに使う。 実は、このうち形態素解析で文の数を計算し、それをもとに改行する基準は最後に作ったものです。この基準を決めるまでは、WhisperXをCLIで実行したあと、JSONで保存されたデータを読み込んで行を構成する処理をすべてGoで実装していました。しかし、形態素解析と文の数の計算にKiwiを使うことになったため、WhisperXをPython内で直接実行するようにし、行の構成もPythonで実装し直しました。そしてGoは、このPythonスクリプトを実行し、最終的に構成された字幕データをストレージに保存するという、AWS Batch内の1つのジョブのライフサイクル管理だけを担う構造にしました。 こうして、現在提供している字幕のように、読みやすさが大きく改善された字幕データを生成できるようになりました。 GPUインスタンス不足の問題を回避する 問題はすべて解決したと思い、これまでにアップロードされた講座を対象に、実際に字幕を一括生成しようとしました。ところが、AWS Batchにジョブを投入していくら待っても、EC2インスタンスが起動しませんでした。Spot Requestを確認してみると、ソウルリージョンにg5.xlargeインスタンスのSpot Capacityがなく、起動できていなかったのです。 Spot Instanceとは？ Spot Instanceは、AWSで使われていないコンピューティングリソースを最大90%割引した価格で提供する機能です。実行中のSpot Instanceがときどき中断されることもありますが、AWS Batchなどを使ってワークフローの耐障害性を確保していれば、Spot Instanceを適用するだけで60%以上のコスト削減効果を得られます。 実際に、動画エンコーディングインフラにSpot Instanceを適用することで平均70%のコストを削減できていたので、そもそも費用のかさむGPUインスタンスを使ううえで、Spot Instanceの適用は必須でした。 Spot Capacityを求めて GPUインスタンスが足りないという話はよく耳にしていましたが、実際に経験したのは初めてでした。3日待っても起動しなかったので、別の方法を探し始めました。 最初に、Spot Placement Scoreという機能を使ってみました。米国のバージニア、オハイオ、オレゴンリージョンはg5.xlargeインスタンスが最も安く、Placement Scoreも高く出ていたので、まずはバージニアリージョンで試してみました。 初めて使うリージョンで何もなかったため、VPC、Subnet、EIP、NAT Gatewayをはじめ、AWS Batch関連の各種リソースをすべて新しく作成しました。ところが実行してみると、同じようにSpot Capacityがないというエラーが発生しました。しまった！と思い、すぐ隣のオハイオリージョンにも同じ構成を作ってみましたが、やはりSpot Capacityがないというエラーが発生しました。（……） Placement Scoreは当てにならないなと思って調べてみたところ、スポットインスタンスアドバイザーというものを見つけました。g5.xlargeスポットインスタンスの中断頻度が低いリージョンを探してみると、オレゴンリージョンが該当することが分かりました。 バージニア、オハイオリージョンに作ったものはすべて削除し、オレゴンリージョンに構成して実行してみると、ようやく字幕生成ジョブが動き始めました。一括処理のために2,000台のg5.xlargeインスタンスを同時に起動する計画でしたが、オレゴンリージョンでさえインスタンス不足で最大500台ほどしか起動できませんでした。それでも、約4時間で字幕の一括生成を完了できました。 一括処理のコスト 基盤 単価 費用 差 AWS Batch (g5.xlarge Spot) - $807.22 - (x1) AWS Batch (g5.xlarge On-Demand) - 約$2,690 約$1,883 (x3.3) OpenAI Whisper API $0.006 / minute 約$8,700 約$7,893 (x10.8) Naver CLOVA CSR API $0.012 / minute 約$17,400 約$16,593 (x21.6) 字幕の一括生成作業にかかった費用は $807.22 で、約24,000時間に及ぶ動画の音声データをAPIベースのサービスで処理する場合と比べて、10分の1以下のコストで字幕を生成できる構成を実現できました。 結論 以上のような過程を経て、約2か月で字幕生成機能を無事に実装できました。Infthonをきっかけに、2日間でアイデアの選定から技術調査、デモ用の実装までを終え、その後の2か月間で、それをユーザーにリリースできるレベルまで引き上げるためにさまざまな試みをしました。貴重な経験でした。 字幕生成に関する技術的な部分も注目に値しますが、特に強調したいのは、1人が短期間でこなしたにしては、インフラ関連の作業量がかなり多かったことです。何のリソースもないリージョンを3回も渡り歩き、VPCからAWS Batch環境までを一晩で構成できたのは、何かが準備されていなければ不可能なことです。特に、受講権限を持つユーザーにのみ字幕データを提供する対応や、字幕のストレージをS3からMongoDBに移行する作業など、本文には書いていない数多くのインフラ作業がありました。それらに触れなかったのは、ほとんど悩むことなく素早く対応できたからです。 これが可能だったのは、これまで懸命に構築してきたIaCのおかげだと思います。私たちがどのようにIaCを構築したかについては、（今度こそ本当に）近日公開予定の「InflabのIaC構築記（Part 1）」の記事でご覧いただけます。AWS CDKからTerraformへの記事でTerragruntとTerratestについての記事を予告しておきながら、1年以上新しい記事を投稿できなかった理由も、その記事で詳しく書いていますので、IaCに興味のある方はぜひ読んでみてください。 ありがとうございました。

A proof of Ryser's circulant Hadamard conjecture We show that an $n\times n$ circulant Hadamard matrix must satisfy a family of congruence equations that have solutions only when $n \leq 4$, proving Ryser's 1963 conjecture that no such matrices exist for $n>4$. Comments: Error found by AI. Corrected proof may be found here: github.com/openai/math/tree/main/preprints/The-ci…

日本語はなぜトークンを食う？ 漢字がバイトに割れる仕組みを tiktoken で数えてみた はじめに 同じ意味の文なのに、日本語で書くと AI の料金が高くなる。そんな話を聞いたことはありませんか？ AI（大規模言語モデル）は、文章を文字や単語ではなく トークン という単位で数えています。料金も、一度に読める量（コンテキストの長さ）も、このトークンの数で決まります。 この記事では、 トークンとは何か 同じ意味の文で、英語と日本語のトークン数をくらべる 日本語が増えやすい理由（漢字がバイトに割れる） 新しいモデルで差が縮まった話 自分で数える方法 を、手元で実際に数えた値でまとめます。 ! 2026 年 10 月 29 日時点の情報です。トークン数は tiktoken 0.14.0 と Hugging Face tokenizers 0.23.3 で手元で数えた値です。出典は記事の最後にまとめています。 トークンとは AI は文章を、トークンという小さなかたまりに切って読んでいます。英語のよく使う単語は、1 語で 1 トークンのことが多いです。 Sorry to trouble you, but could you please confirm this? は、GPT-4 のトークナイザー（cl100k_base）で 12 トークンになります。単語の前のスペースは、単語と一緒に 1 つのトークンになっています（図の ␣）。 同じ意味の文をくらべる 同じ意味の日本語の文を、同じ GPT-4 のトークナイザーで数えてみます。 文 文字数 GPT-4（cl100k_base） Sorry to trouble you, but could you please confirm this? 56 12 お忙しいところ恐れ入りますが、ご確認いただけますでしょうか。 30 32 日本語は 30 文字なのに 32 トークン。文字数よりトークンのほうが多いうえに、英語の約 2.7 倍です。図の点線のかたまりは、文字の途中で切れたバイトのトークンです。 トークンの辞書は、よく出る並びをくっつけて作る トークナイザーの辞書は、BPE（Byte Pair Encoding） という方法で作られています。文章の中でよく隣り合う 2 つをくっつけて新しいトークンにする、という作業をくり返します。 辞書づくりに使う文章に英語が多いと、英語の単語はまるごと 1 トークンになりやすくなります。実際に cl100k_base では、 文字列 トークン数 切れ方 token 1 token トークン 4 ト ー ク ン と、カタカナは 1 文字ずつに分かれました。 漢字はバイトに割れる 辞書にない文字は、もっと細かい バイト に割られます。いまのトークナイザーの多くは、文字を UTF-8 のバイト列にしてから扱う「バイトレベル BPE」です。そのため、どんな文字でも最後はバイトのトークンで表せます（辞書に無い文字で困ることはありません）。 UTF-8 では、英語の文字は 1 バイトですが、漢字やひらがなは、たいてい 1 文字 3 バイトです。 文字 UTF-8 バイト数 A 41 1 あ e3 81 82 3 鬱 e9 ac b1 3 cl100k_base では、「鬱」は 3 バイトがそのまま 3 トークンに、「確認」の 2 文字（6 バイト）は 4 トークンになりました。 鬱 → [e9] [ac] [b1] 3 トークン 確認 → [e7 a2] [ba] [e8 aa] [8d] 4 トークン 先ほどの日本語の文でも、「忙」「恐」「確認」「ょ」がバイトに割れていました。これが、日本語のトークンが増えやすい理由の 1 つです。 新しいモデルでは差が縮まった GPT-4o からは、トークナイザーが o200k_base になりました。辞書の大きさ（トークンの種類）はおよそ 2 倍です。 トークナイザー 使うモデル（tiktoken の対応表） 辞書の大きさ cl100k_base GPT-4、GPT-3.5 Turbo 100,277 o200k_base GPT-4o、GPT-4.1、o1、GPT-5 など 200,019 同じ日本語の文は、32 → 17 トークン に減りました（英語は 12 のまま）。「確認」も、まるごと 1 トークンです。 import tiktoken ja = "お忙しいところ恐れ入りますが、ご確認いただけますでしょうか。" for name in ["cl100k_base", "o200k_base"]: enc = tiktoken.get_encoding(name) print(name, len(enc.encode(ja))) cl100k_base 32 o200k_base 17 モデルごとに切り方が違う トークンの切り方は、モデル（トークナイザー）ごとに違います。早口言葉の「東京特許許可局」（7 文字）で、公開されているトークナイザーをくらべてみました。 トークナイザー トークン数 切れ方 GPT-4（cl100k_base） 10 [e6 9d] [b1] 京 特 [e8 a8] [b1] [e8 a8] [b1] 可 局 GPT-4o 以降（o200k_base） 6 東京 特 許 許 可 局 Qwen3 7 東 京 特 許 許 可 局 DeepSeek-V3 5 東京 特 許 許可 局 同じ会社のモデルでも、トークナイザーが変わることがあります。Anthropic は Claude Opus 4.7 で新しいトークナイザーを使い始め、同じ入力が内容によって 約 1.0〜1.35 倍 のトークンになることがあると案内しています。料金を見積もるときは、使うモデルで数えるのが確実です。 自分で数える OpenAI のモデルなら、tiktoken で数えられます。モデル名からトークナイザーを選ぶこともできます。 import tiktoken enc = tiktoken.encoding_for_model("gpt-4o") # o200k_base text = "お忙しいところ恐れ入りますが、ご確認いただけますでしょうか。" print(len(enc.encode(text))) # 17 どう切れたかを見る (バイトの途中で切れたトークンは文字にならない) print([enc.decode_single_token_bytes(t) for t in enc.encode(text)]) Claude なら、トークンを数える API（Token counting）があります。 import anthropic client = anthropic.Anthropic() r = client.messages.count_tokens( model="claude-opus-5-5", messages=[{"role": "user", "content": text}], ) print(r.input_tokens) ブラウザで試すなら、Tiktokenizer で切れ方を色分けして見られます。 豆知識: strawberry の r はいくつ？ AI が strawberry の r の数を数え間違えることがある、という話があります。 o200k_base では、strawberry は st raw berry の 3 トークン（番号は 302、1618、19772）です。AI に渡るのはこの番号の列なので、1 文字ずつの並びは見えていません。 まとめ AI は文章を「トークン」で数える。料金も、一度に読める量もトークン トークナイザーの辞書は、よく出る並びをくっつけて作る（BPE） 辞書にない文字はバイトに割れる。漢字やひらがなは 1 文字 3 バイトなので、日本語はトークンが増えやすい 新しいトークナイザーほど日本語の差は縮まっている（GPT-4 で 32 → GPT-4o 以降で 17）。見積もりは使うモデルで数える 出典 openai/tiktoken（GitHub）（cl100k_base・o200k_base とモデルの対応は tiktoken/model.py） Tiktokenizer Qwen/Qwen3-0.6B（Hugging Face）、deepseek-ai/DeepSeek-V3（Hugging Face）（トークナイザーを手元で読み込んで数えた） Introducing Claude Opus 4.7（Anthropic） Token counting（Claude API ドキュメント） Neural Machine Translation of Rare Words with Subword Units（Sennrich ほか、2016）（BPE をトークン分割に使った論文） Language Models are Unsupervised Multitask Learners（Radford ほか、2019）（バイトレベル BPE） RFC 3629: UTF-8

Four GPUs, One Quantization Ladder: Gemma 4 E2B From a 4 GB Laptop to an NVIDIA L4 --- title: "Four GPUs, One Quantization Ladder: Gemma 4 E2B From a 4 GB Laptop to an NVIDIA L4" published: true description: "Gemma 4 E2B from BF16 to Q2_K on a Tesla T4, an NVIDIA L4, a GTX 1650 laptop and an RTX 3050 desktop, with byte-identical GGUF files and the same llama.cpp build. The ladder keeps its shape on all four cards, 218 questions die on all four, and any two GPUs grade 2 to 4 questions differently at BF16." tags: gemma, llamacpp, quantization, nvidia cover_image: raw.githubusercontent.com --- This article provides a step by step guide to running Gemma 4 E2B's quantization ladder, BF16 down to Q2_K, on four NVIDIA GPUs with the same nine GGUF files and the same llama.cpp build, and comparing the four cards question by question. xbill9/gemma-graveyard The first article asked every rung of the ladder the same 250 GSM8K questions on a Tesla T4. The second repeated it on an NVIDIA L4 in AWS. This one adds two consumer cards: a GTX 1650 Ti laptop GPU with 4 GB and an RTX 3050 desktop card with 8 GB. All four run llama.cpp b11699 on files with the same sha256, and each card gives identical text when BF16 is run twice. --- The Results in Brief The ladder keeps its shape on all four GPUs. Against each card's own BF16, F16 to Q5_K_M lose 1 to 8 answers, Q4_K_M and Q4_0 lose 9 to 19, Q3_K_M loses 42 to 49, and Q2_K gets 3 to 6 right out of 250. The counts agree; the questions move. Any two GPUs grade 2 to 4 questions differently at BF16 and 12 to 22 at Q4_0. No question is lost at F16 or Q8_0 on all four cards, while 216 are lost at Q2_K on all four. 218 questions die at some rung on every GPU, and 147 of them die first at the same rung on every GPU. The 4 GB laptop runs every quantized rung entirely on its GPU. BF16 and F16 do not fit, so llama.cpp splits them between GPU and CPU, and they decode at 9.2 and 9.6 tokens per second against 45.9 for Q8_0 on the same card. The cover lays the four GPUs' grades over each other. One row per rung, BF16 at the top and Q2_K at the bottom, one cell per question: marigold where all four GPUs answer right, grey where all four answer wrong, violet where they disagree. docs/make_cover_gpu4.py draws it from the committed rows. --- What Changes and What Stays | | Tesla T4 | NVIDIA L4 | GTX 1650 Ti | RTX 3050 | | :--- | :--- | :--- | :--- | :--- | | Where | GCE n1-standard-2 | AWS g6.xlarge | laptop | desktop | | GPU memory | 15,360 MiB | 23,034 MiB | 4,096 MiB | 8,192 MiB | | Compute capability | 7.5 | 8.9 | 7.5 | 8.6 | | Host CPU | 2 vCPU | AMD EPYC 7R13 | Intel i7-10750H | Intel i7-5820K | | Driver | 615.71.10 | 595.112.07 | 615.71.10 | 615.78.08 | The same on all four: llama.cpp b11699 with GGML_CUDA=ON, built for each card's own compute capability; the nine GGUFs and Google's QAT Q4_0 file, byte for byte; the 250 questions in data/heldout.jsonl; temperature 0, one request at a time, thinking off, 1,024 max tokens, llama-server -c 4096 -np 1 --seed 0. Every rung runs with -ngl 99 except BF16 and F16 on the GTX 1650 (Step 4). --- At This Point You Should Have… - An NVIDIA GPU with at least 4 GB and a CUDA toolkit - About 58 GB of free disk for the checkpoint, the nine GGUFs and the QAT file - A clone: git clone https://github.com/xbill9/gemma-graveyard - The T4 run's committed results in runs/2026-10-27-ladder/ --- Step 1 — Build llama.cpp at the Same Tag On the RTX 3050: git -C ~/llama.cpp worktree add --detach /android/graveyard/llama.cpp b11699 cd /android/graveyard/llama.cpp cmake -B build -DGGML_CUDA=ON -DCMAKE_CUDA_ARCHITECTURES=86 -DCMAKE_BUILD_TYPE=Release cmake --build build -j12 --target llama-server llama-quantize The one build flag that changes per card is CMAKE_CUDA_ARCHITECTURES: 75 for the T4 and the GTX 1650, 89 for the L4, 86 for the RTX 3050. nvidia-smi --query-gpu=name,memory.total,compute_cap,driver_version --format=csv name, memory.total [MiB], compute_cap, driver_version NVIDIA GeForce RTX 3050 OEM, 8192 MiB, 8.6, 615.78.08 🔎 Tip: keep the pinned build in its own worktree. The desktop already had a newer llama.cpp checkout (b11983). git worktree add --detach <dir> b11699 gives a second working copy at the tag from the same clone, so the measured build and the everyday build sit side by side. --- Step 2 — Rebuild the Ladder and Check It Against the T4 ladder.sh converts the checkpoint to BF16 and F16 and quantizes seven rungs from BF16. Each run script then compares every file's size and sha256 with the T4's ladder.tsv: diff <(cut -f1,3,4 runs/2026-10-27-ladder/ladder.tsv) <(cut -f1,3,4 runs/2026-10-29-3050/ladder.tsv) && echo "ladder matches T4 sha256" ladder matches T4 sha256 The GTX 1650 and the RTX 3050 both print the same line, and Google's QAT Q4_0 file matches too (sha256 fa401b55…). Across the four machines, the GGUF bytes are identical; the card, its driver, its CUDA version and the kernels built for it are what differ. 🔎 Tip: the converter writes the checkpoint directory into the GGUF. convert_hf_to_gguf.py copies the model card and takes the model's name from the directory it reads. A checkpoint taken straight from the Hugging Face cache snapshot has neither the README.md nor the name gemma-4-E2B-it, and gives different bytes. Download with hf download google/gemma-4-E2B-it --local-dir <dir>/gemma-4-E2B-it. --- Step 3 — Prove Each Card Repeats Itself BF16 on 50 questions, twice, on every GPU: ./graveyard.py repeat runs/2026-10-29-3050/determinism-1 runs/2026-10-29-3050/determinism-2 BF16 {"rung": "BF16", "n": 50, "mismatched_extracted": 0, "mismatched_text": 0, "mismatched_right": 0, "right_a": 46, "right_b": 46} The T4, the L4 and the GTX 1650 give the same result: 0 mismatched characters and 46 of 50 right both times. Each card on its own is deterministic, so a difference between two cards comes from the GPU and its CUDA stack. --- Step 4 — Fit the 16-bit Rungs on 4 GB BF16 and F16 need a 4,384.87 MiB GPU buffer for their 36 layers (from the T4's load log), and the GTX 1650 has 4,096 MiB. With -ngl 99 the load fails. graveyard.py run --ngl auto leaves -ngl off, and llama.cpp's fit step places what it can: common_params_fit_impl: - CUDA0 (NVIDIA GeForce GTX 1650 Ti with Max-Q Design): 14 layers, 2546 MiB used, 1125 MiB free load_tensors: offloaded 14/36 layers to GPU load_tensors: CUDA0 model buffer size = 2407.92 MiB Every other rung fits whole. Q8_0 on the same card: load_tensors: offloaded 36/36 layers to GPU load_tensors: CUDA0 model buffer size = 2342.30 MiB The split changes speed and leaves the grades in line with the other GPUs: the GTX 1650's BF16 scores 229, the same as the T4 and the L4, and grades 2 to 4 questions differently from each of them. The 8 GB RTX 3050 holds BF16 whole at 4,651 MiB. --- Step 5 — Run the Ladder on Each Card and Score It Each run script runs the nine rungs and QAT Q4_0, then scores every rung against that card's own BF16: ./graveyard.py bury runs/2026-10-29-3050 BF16 F16 Q8_0 Q6_K Q5_K_M Q4_K_M Q4_0 Q3_K_M Q2_K --json graveyard-ladder.json Right answers, out of 250: | Rung | T4 | L4 | GTX 1650 | RTX 3050 | | :--- | :--- | :--- | :--- | :--- | | BF16 | 229 | 229 | 229 | 232 | | F16 | 229 | 229 | 228 | 232 | | Q8_0 | 227 | 228 | 229 | 226 | | Q6_K | 229 | 227 | 226 | 227 | | Q5_K_M | 231 | 228 | 226 | 226 | | Q4_K_M | 224 | 221 | 222 | 221 | | Q4_0 | 222 | 220 | 216 | 218 | | Q3_K_M | 191 | 186 | 183 | 191 | | Q2_K | 3 | 6 | 5 | 3 | Lost, against the same card's BF16: | Rung | T4 | L4 | GTX 1650 | RTX 3050 | | :--- | :--- | :--- | :--- | :--- | | F16 | 1 | 1 | 2 | 1 | | Q8_0 | 4 | 3 | 2 | 7 | | Q6_K | 4 | 6 | 7 | 8 | | Q5_K_M | 3 | 6 | 6 | 8 | | Q4_K_M | 9 | 14 | 12 | 14 | | Q4_0 | 15 | 16 | 19 | 16 | | Q3_K_M | 42 | 45 | 49 | 44 | | Q2_K | 226 | 225 | 225 | 229 | Lost: right at BF16, wrong at this rung, on the same GPU. The failures fall into the same kinds on every card. Q3_K_M runs out of room: 33 to 36 of its losses on each GPU are answers cut off at 1,024 tokens. Q2_K loops: 208 to 228 of its 250 answers repeat a line five or more times, and 246 to 249 hit the token cap. --- Step 6 — Line the Four GPUs Up, Question by Question docs/gpu4_derived.py rebuilds the T4's grid from its committed results and reads the other three from their rows, then compares all six pairs of GPUs at every rung: python3 docs/gpu4_derived.py > runs/2026-10-29-3050/four-gpus.txt | Rung | Graded differently, any two GPUs | Lost on all four | | :--- | :--- | :--- | | BF16 | 2 to 4 | — | | F16 | 3 to 5 | 0 | | Q8_0 | 3 to 9 | 0 | | Q6_K | 4 to 10 | 2 | | Q5_K_M | 7 to 10 | 1 | | Q4_K_M | 9 to 15 | 5 | | Q4_0 | 12 to 22 | 5 | | Q3_K_M | 26 to 34 | 20 | | Q2_K | 6 to 9 | 216 | Graded differently: right on one GPU and wrong on the other, at that rung, for the closest and the furthest of the six pairs. - The light rungs lose different questions on each card. F16 and Q8_0 lose 1 to 7 answers per GPU, and none of them is lost on all four. - The deep losses are shared. Q3_K_M loses 20 questions on all four GPUs and Q2_K 216. - Most of the graveyard is common ground. Each GPU has 226 questions that die at some rung, the RTX 3050 230. 218 die on all four, and 147 die first at the same rung on all four. One question dies only on the RTX 3050 (test-358) and one only on the GTX 1650 (test-147). - BF16 itself moves a few answers. 227 questions are right at BF16 on all four cards and 18 wrong on all four. Against the L4, the RTX 3050's BF16 changes the text of 31 answers out of 250, the extracted number of 4 and the grade of 3. --- Step 7 — Google's QAT Q4_0 on Four Cards ./graveyard.py bury runs/2026-10-29-3050 BF16 QAT_Q4_0 Q4_0 --json graveyard-qat.json | GPU | QAT Q4_0 right | Q4_0 right | QAT Q4_0 lost | Q4_0 lost | | :--- | :--- | :--- | :--- | :--- | | T4 | 221 | 🥇 222 | 15 | 15 | | L4 | 219 | 🥇 220 | 15 | 16 | | GTX 1650 | 🥇 222 | 216 | 11 | 19 | | RTX 3050 | 🥇 221 | 218 | 15 | 16 | QAT Q4_0 scores 219 to 222 on the four cards and plain Q4_0 216 to 222. On the T4 and the L4 the plain file is ahead by 1; on the GTX 1650 QAT is ahead by 6 and on the RTX 3050 by 3. The two files lose mostly different questions: on the RTX 3050, 5 questions are lost under both, 10 only under QAT and 11 only under the plain Q4_0. Across the four GPUs, 6 of QAT's losses and 5 of Q4_0's are lost on every card. --- Step 8 — Speed on Each Card Median decode speed in tokens per second. Each column is one machine; read down a column. | Rung | T4 | L4 | GTX 1650 | RTX 3050 | | :--- | :--- | :--- | :--- | :--- | | BF16 | 40.0 | 50.1 | 9.2 | 40.3 | | F16 | 39.6 | 50.0 | 9.6 | 40.3 | | Q8_0 | 64.3 | 83.0 | 45.9 | 67.8 | | Q6_K | 70.8 | 98.1 | 57.2 | 75.3 | | Q5_K_M | 78.7 | 107.7 | 61.9 | 82.2 | | Q4_K_M | 84.1 | 118.7 | 66.5 | 91.5 | | Q4_0 | 🥇 93.6 | 125.6 | 🥇 70.8 | 🥇 99.7 | | Q3_K_M | 74.2 | 111.1 | 55.9 | 64.2 | | Q2_K | 74.0 | 🥇 139.5 | 62.2 | 95.0 | - Q4_0 is the fastest rung on three of the four cards; on the L4 it is Q2_K, which is wrong on 244 of 250 questions. - Q5_K_M decodes 1.21 to 1.35 times as fast as Q8_0 on each card (arithmetic, from the table). Q8_0 is the baseline here because it is the largest rung that fits whole on all four GPUs. - Q3_K_M is slower than Q4_0 on every card, and on the RTX 3050 it is slower than Q8_0. - BF16 and F16 run at the same speed on the T4, the L4 and the RTX 3050. On the GTX 1650, with 22 of 36 layers on the CPU, they run at a fifth of Q8_0's speed. The full ladder with QAT took 5 hours 16 minutes on the RTX 3050 and 12 hours 25 minutes on the GTX 1650, from the first log line to the last (run-3050.log, run-1650.log). --- Compare and Contrast | | T4 | L4 | GTX 1650 | RTX 3050 | | :--- | :--- | :--- | :--- | :--- | | BF16 right of 250 | 229 | 229 | 229 | 🥇 232 | | Q5_K_M lost | 🥇 3 | 6 | 6 | 8 | | Q4_0 right, tok/s | 222, 93.6 | 220, 125.6 | 216, 70.8 | 218, 99.7 | | Every rung whole on the GPU | 🟢 yes | 🟢 yes | ❌ BF16, F16 split | 🟢 yes | | Same text twice at BF16 | 🟢 yes | 🟢 yes | 🟢 yes | 🟢 yes | --- So, Which One? On any of the four cards, take Q5_K_M: 39.0% of BF16's bytes, 226 to 231 right, 3 to 8 answers lost against the card's own BF16, and 1.21 to 1.35 times Q8_0's decode speed. For the fastest file that stays within 19 answers, take Q4_0, the fastest rung on three of the cards. On a 4 GB card, every quantized rung fits whole and the 16-bit rungs run at under 10 tokens per second. To compare two quantizations question by question, run both on one GPU: a different card moves 2 to 4 grades at BF16 and up to 34 at Q3_K_M. --- Summary The goal of this article was to run Gemma 4 E2B's quantization ladder on four GPUs, from a 4 GB laptop card to a data-centre L4, and see which grades hold. The key was holding everything else fixed: byte-identical GGUFs, the same llama.cpp tag and the same sampling, with each card checked to give identical text twice. The four-GPU results were: - 🟢 All nine GGUFs and the QAT file match the T4's sha256 on every machine, and BF16 gives identical text twice on 50 questions on every card. - 🟢 The ladder keeps its shape on all four GPUs: F16 to Q5_K_M lose 1 to 8, Q4_K_M and Q4_0 lose 9 to 19, Q3_K_M loses 42 to 49. - 🟢 Q5_K_M is the best trade on every card: 226 to 231 right at 1.21 to 1.35 times Q8_0's speed. - 🟢 A 4 GB GTX 1650 runs every quantized rung whole on the GPU; BF16 and F16 run split, 14 of 36 layers on the GPU, at 9.2 and 9.6 tokens per second. - ⚠️ Any two GPUs grade 2 to 4 questions differently at BF16 and 12 to 22 at Q4_0; no question is lost at F16 or Q8_0 on all four. - ⚠️ 218 questions die on all four GPUs, 147 of them first at the same rung. - ⚠️ QAT Q4_0 and plain Q4_0 trade places by card: plain ahead by 1 on the T4 and L4, QAT ahead by 6 on the GTX 1650 and by 3 on the RTX 3050. - ❌ Q3_K_M loses 42 to 49, mostly answers cut off at 1,024 tokens; Q2_K gets 3 to 6 right, with 208 to 228 looping answers per card. Scope: one run of each rung per GPU on four NVIDIA cards (a Tesla T4 on GCE, an L4 on AWS, a GTX 1650 Ti laptop GPU and an RTX 3050 desktop card), 250 GSM8K test questions, greedy, thinking off, 1,024 max tokens, llama.cpp b11699 built for each card. Determinism checked at BF16 on each card. The T4 grid is rebuilt from its committed per-question results. The hosts also differ in CPU, RAM, driver and CUDA version, and on the GTX 1650 BF16 and F16 run split between GPU and CPU. Speed is compared within each card only. The strategy for measuring Gemma 4's accuracy one quantization rung at a time on four GPUs was validated with an incremental step by step approach. --- References - Accuracy vs Speed: Gemma 4 E2B Quantization Tradeoffs, BF16 to Q2_K, the T4 article - Performance vs Quality: Gemma 4 E2B Quantization on an NVIDIA L4 and a Tesla T4, the L4 article - gemma-graveyard on GitHub - GTX 1650 run: runs/2026-10-29-1650 - RTX 3050 run: runs/2026-10-29-3050 - llama.cpp - google/gemma-4-E2B-it - google/gemma-4-E2B-it-qat-q4_0-gguf - GSM8K

Accuracy vs Speed: Gemma 4 E2B Quantization Tradeoffs, BF16 to Q2_K --- title: "Accuracy vs Speed: Gemma 4 E2B Quantization Tradeoffs, BF16 to Q2_K" published: true description: "Gemma 4 E2B quantized from BF16 to Q2_K on one Tesla T4, every rung asked the same 250 GSM8K questions, and each answer buried at the rung where it first goes wrong. Q5_K_M and above hold the score; Q3_K_M loses 38; Q2_K gets 3 right. With thinking on, Q3_K_M wins back 17." tags: devchallenge, hf26challenge, gemma, llamacpp cover_image: raw.githubusercontent.com --- This is a submission for the Hacktoberfest Open-Source AI Challenge Week 4: Ghost in the Machine This article provides a step by step guide to quantizing Gemma 4 E2B down a ladder of nine GGUF files with llama.cpp, asking every rung the same 250 maths questions on one Tesla T4, and burying each answer at the rung where it first goes wrong. Every count is computed by code and every row is committed. xbill9/gemma-graveyard A score per quantization level says how many answers a smaller file loses; a graveyard says which ones. Against the 229 of 250 questions BF16 gets right, Q8_0, Q6_K and Q5_K_M stay within 2, Q4_K_M and Q4_0 lose 5 and 7, Q3_K_M loses 38 and Q2_K gets 3 right. Above Q3_K_M most of the dead come back: 16 of the 23 questions that die between F16 and Q4_0 are right again at a lower rung. With thinking on, Q3_K_M climbs from 191 to 208. --- What I Built Quantization is the most common thing done to an open-weight model before it ships to a small device. The usual report is one accuracy number per file size. Two files with the same score can still get different questions wrong, and a net loss hides its parts: Q4_0 here is 7 answers down on BF16, made of 15 questions lost and 8 gained. The gemma-graveyard asks every rung of a quantization ladder the same 250 questions at temperature 0, so each answer is the model's single most likely one. BF16 is the reference, and every question a rung answers differently from BF16 lands in one of four records: - Dead: BF16 answers it right and the rung answers it wrong. A rung's dead count is every such question at that rung. - Tombstone: one per question, placed at the first rung, going down from BF16, where the question dies. A question dead at Q8_0 and again at Q4_0 has one tombstone, at Q8_0. - Rose again: a lower rung answers a tombstoned question right once more. test-687 dies at F16 and is right again at Q8_0, Q6_K, Q5_K_M and Q4_K_M. - Ghost: BF16 answers it wrong and the rung answers it right. test-1166 asks for an avocado tree's fruit over ten years, answer 2,350. BF16 says 1,000; Q8_0, Q6_K and Q4_0 get it right. A rung's score is BF16's 229, minus its dead, plus its ghosts: Q4_0 is 229 − 15 + 8 = 222. Quantization moves answers in both directions, and a score that holds can hide questions lost and found, so the article reports both. For Día de los Muertos: the dead are remembered one at a time, by name. Each tombstone here carries the question's id, the right answer, the wrong answer the rung gave, and every lower rung where it rose again. What the project delivers: - ladder.sh: BF16, F16 and seven quantized GGUFs of Gemma 4 E2B, with bytes and sha256 - graveyard.py run: one rung, its own llama-server, 250 questions, answers graded in code - graveyard.py bury: deaths, tombstones and ghosts per rung, computed in code - graveyard.py autopsy: how each rung's answers fail (cut off, looping, writing into the thinking block) - graveyard.py repeat: two runs of one rung compared question by question - one run of the whole ladder plus Google's QAT Q4_0 on a Tesla T4, committed with its report - a second pass with thinking on, over seven rungs from BF16 to Q3_K_M --- Demo The Results in Brief Q5_K_M is the best trade between speed and accuracy on the T4. It keeps BF16's score, 231 right against 229, at 39.0% of the bytes and 1.97 times BF16's decode speed. The 2 extra right answers come from the 8 questions where the two disagree, 5 ghosts against 3 dead; two equally accurate models split 8 questions at least that unevenly about three times in four, so the gap is within the noise. Q4_0 is the fastest rung at 2.34 times BF16, and costs 9 right answers against Q5_K_M for 1.19 times its speed. Q4_K_M sits between the two. Every other rung is beaten on both counts by one of those three: Q8_0 and Q6_K are slower than Q5_K_M with fewer or equal right answers, and Q3_K_M is slower than Q4_0 with 31 fewer. Below Q4 the accuracy collapses: Q3_K_M loses 38 and Q2_K gets 3 right. With thinking on, the order holds: Q5_K_M 230, Q4_K_M 226 and Q4_0 219, against BF16's 227. The cover is the graveyard. One row per rung, BF16 at the top and Q2_K at the bottom, one cell per question: marigold where the rung answers right, a grey headstone where it answers wrong. docs/make_cover.py draws it from the committed rows. The ladder, from graveyard.py bury, on 250 GSM8K test questions: | Rung | % of BF16 bytes | Right | Dead | Ghosts | Median tok/s | | :--- | :--- | :--- | :--- | :--- | :--- | | BF16 | 100.0 | 229 | 0 | 0 | 40.0 | | F16 | 100.0 | 229 | 1 | 1 | 39.6 | | Q8_0 | 53.3 | 227 | 4 | 2 | 64.3 | | Q6_K | 41.3 | 229 | 4 | 4 | 70.8 | | Q5_K_M | 39.0 | 🥇 231 | 3 | 5 | 78.7 | | Q4_K_M | 36.8 | 224 | 9 | 4 | 84.1 | | Q4_0 | 36.1 | 222 | 15 | 8 | 🥇 93.6 | | Q3_K_M | 34.4 | 191 | 42 | 4 | 74.2 | | Q2_K | 32.1 | 3 | 226 | 0 | 74.0 | Dead: BF16 right, this rung wrong. Ghosts: BF16 wrong, this rung right. --- Code xbill9/gemma-graveyard | Path | What | | :--- | :--- | | ladder.sh | Converts the checkpoint to BF16 and F16 GGUF, quantizes seven rungs from BF16, writes ladder.tsv | | f16_range.py | Counts the weights that overflow or underflow when BF16 is cast to F16 | | graveyard.py | run, bury, autopsy and repeat | | docs/think_derived.py | Thinking on against thinking off, question by question | | lazy_eval.py | Prompt, answer extraction and grading, reused from Week 3 | | run.md | Every command for the T4, in order, and how to resume after the VM stops | | runs/2026-10-27-ladder/run-ladder.sh | Runs the nine rungs in order, skips finished ones, then buries | | runs/2026-10-27-ladder/ | REPORT.md, the bury and autopsy tables, per-question tombstones | --- How I Built It At This Point You Should Have… - A GCE n1-standard-2 in us-west2-b with one Tesla T4, 15,360 MiB, driver 615.71.10, 2 vCPU and 7,436 MiB of RAM - llama.cpp built with CUDA for compute capability 7.5, at b11699 - google/gemma-4-E2B-it from Hugging Face, the BF16 checkpoint, text model only - google/gemma-4-E2B-it-qat-q4_0-gguf, Google's quantization-aware Q4_0 file - A clone: git clone https://github.com/xbill9/gemma-graveyard --- Step 1 — Build the Ladder ladder.sh converts the checkpoint twice, to BF16 and to F16, then quantizes seven rungs from the BF16 file with plain llama-quantize, with no importance matrix. That is the default a user gets. TMPDIR=/opt1/tmp ./ladder.sh /opt1/models/gemma-4-E2B-it /opt1/graveyard-gguf /opt1/llama.cpp rung file bytes sha256 BF16 /opt1/graveyard-gguf/e2b-BF16.gguf 9311305152 9fe40af9a72302151a5abc28a5057c5fe335eb80145e795ba745085fc73a2ad6 F16 /opt1/graveyard-gguf/e2b-F16.gguf 9311305152 5ab927e4b24a248de319e70467fc74d4ab87347ee9d6fb3ee60b293b12198cf8 Q8_0 /opt1/graveyard-gguf/e2b-Q8_0.gguf 4967497152 6b0301104c89a43c3bec5bae4b14d744f6000bc21e00e46e887fbbfe024de38a Q6_K /opt1/graveyard-gguf/e2b-Q6_K.gguf 3845346752 e800e0389f48646994d8ff6d3409dbf0c13b3fc217d0647b481385da33bd3d99 Q5_K_M /opt1/graveyard-gguf/e2b-Q5_K_M.gguf 3630288320 f6c3f4395a9d3839535d8c14ae48ab784096945cfc4485005853eede915cb4a9 Q4_K_M /opt1/graveyard-gguf/e2b-Q4_K_M.gguf 3427880384 dd9dc465bb535989205f158d77f28f6f8348e47d8ac8870920c152b5996cbc16 Q4_0 /opt1/graveyard-gguf/e2b-Q4_0.gguf 3360161216 2d84758474be87d0a74edfa98efbeb602484e26f2e5fa8695fd9641ad323c7b2 Q3_K_M /opt1/graveyard-gguf/e2b-Q3_K_M.gguf 3201351104 b10c1f38c93635ccee1c7f382e03f5d2f4e9516087d7d62a73ca7de0f52693ab Q2_K /opt1/graveyard-gguf/e2b-Q2_K.gguf 2989088192 65850f1a31efed2013ed148adc5dc937e973a8e79fd55cdba31edd53369fddb2 The reference is BF16 because that is the checkpoint's own dtype, so the BF16 GGUF holds the trained weights unchanged. F16 is a rung. --- Step 2 — Check What F16 Costs Before Running It F16 has more mantissa than BF16 and less exponent range, so the cast can overflow or round small weights to zero. f16_range.py counts both on the checkpoint, one line per tensor and a total: python3 f16_range.py /opt1/models/gemma-4-E2B-it/model.safetensors > runs/2026-10-27-f16-range/out.txt grep -E 'position_embedding_table|TOTAL' runs/2026-10-27-f16-range/out.txt {"tensor": "model.vision_tower.patch_embedder.position_embedding_table", "n": 15728640, "overflow": 0, "underflow": 5507733, "subnormal": 834716, "absmax": 0.431640625} {"tensor": "TOTAL", "tensors": 2011, "n": 5123178979, "overflow": 0, "underflow": 5523265, "subnormal": 7013885, "absmax": 900.0} No weight overflows. Of the 5,523,265 that underflow, 5,507,733 are in the vision tower's position table, which the text GGUF does not carry. --- Step 3 — Ask One Rung 250 Questions graveyard.py run starts its own llama-server on one GGUF and asks each question once: temperature 0, one request at a time, no prompt cache, thinking off, 1,024 max tokens. Only the reply's content is graded, in code: the number after Answer:, compared with the reference. ./graveyard.py run BF16 /opt1/graveyard-gguf/e2b-BF16.gguf data/heldout.jsonl runs/2026-10-27-ladder --llama /opt1/llama.cpp {"rung": "BF16", "n": 250, "right": 229, "errors": 0, "truncated": 4, "median_decode_tps": 40.0, "mean_tokens": 391.2} The whole model fits on the T4 at BF16: load_tensors: offloaded 36/36 layers to GPU load_tensors: CPU_Mapped model buffer size = 768.00 MiB load_tensors: CUDA0 model buffer size = 4384.87 MiB 🔎 Tip: Gemma 4 E2B keeps its embedding tables in CPU memory. The per-layer embedding table holds 2,348,810,240 of the checkpoint's weights, and llama.cpp leaves it memory-mapped on the CPU with -ngl 99. So each rung's GPU memory is about half its file size: 4,671 MiB in use at BF16 for a 9.3 GB file, 1,639 MiB at Q4_0, 1,287 MiB at Q2_K. --- Step 4 — Prove the Same Rung Gives the Same Answers A tombstone means something only if the same model on the same question always gives the same answer. BF16 on 50 questions, twice: for i in 1 2; do ./graveyard.py run BF16 /opt1/graveyard-gguf/e2b-BF16.gguf data/heldout.jsonl runs/2026-10-27-determinism-$i \ --llama /opt1/llama.cpp --limit 50 done The two runs compared in code, question by question: 0 mismatched extracted, 0 mismatched text, 46/50 both times Every answer and every character of text matched. The same holds below BF16. graveyard.py repeat compares a second full run of four rungs with the ladder's: ./graveyard.py repeat runs/2026-10-27-ladder runs/2026-10-28-repeat Q4_0 Q3_K_M Q8_0 F16 --common {"rung": "Q4_0", "n": 250, "mismatched_extracted": 0, "mismatched_text": 0, "mismatched_right": 0, "right_a": 222, "right_b": 222} {"rung": "Q3_K_M", "n": 250, "mismatched_extracted": 0, "mismatched_text": 0, "mismatched_right": 0, "right_a": 191, "right_b": 191} {"rung": "Q8_0", "n": 250, "mismatched_extracted": 0, "mismatched_text": 0, "mismatched_right": 0, "right_a": 227, "right_b": 227} {"rung": "F16", "n": 250, "mismatched_extracted": 0, "mismatched_text": 0, "mismatched_right": 0, "right_a": 229, "right_b": 229} A changed answer at a lower rung comes from the weights. --- Step 5 — Run the Ladder and Bury It runs/2026-10-27-ladder/run-ladder.sh runs the nine rungs in order and skips any rung whose results are complete, so it picks up again after the VM's evening stop. Then bury: ./graveyard.py bury runs/2026-10-27-ladder BF16 F16 Q8_0 Q6_K Q5_K_M Q4_K_M Q4_0 Q3_K_M Q2_K --json graveyard-ladder.json {"first_deaths_by_rung": {"Q2_K": 177, "Q3_K_M": 26, "Q4_0": 9, "Q8_0": 4, "Q5_K_M": 2, "Q4_K_M": 6, "Q6_K": 1, "F16": 1}, "tombstones": 226, "ghosts": 11} 226 tombstones and 11 ghosts: 226 different questions die at some rung, and 11 questions BF16 gets wrong come back right at one rung or more. The first-death counts add up to the tombstones, one per question; the per-rung dead counts in the ladder table add up to more, because one question can be dead at several rungs. Per-question detail is in graveyard-ladder.json. The one question that dies at F16: {'id': 'test-687', 'died_at': 'F16', 'answer': '13', 'said': 17.0, 'right_again_at': ['Q8_0', 'Q6_K', 'Q5_K_M', 'Q4_K_M']} "One twin is 7 years older than one triplet. If their combined ages are 44, how old is one of the twins?" BF16 answers 13, from two twins and three triplets. F16 adds up two twins and one triplet, and answers 17. Four lower rungs answer 13 again. --- Step 6 — Autopsy: How Each Rung Dies graveyard.py autopsy counts, per rung, answers cut off at 1,024 tokens, answers that repeat one line five or more times, and answers that put text in the thinking block: ./graveyard.py autopsy runs/2026-10-27-ladder BF16 F16 Q8_0 Q6_K Q5_K_M Q4_K_M Q4_0 Q3_K_M Q2_K {"rung": "Q3_K_M", "cut_off": 49, "looped": 0, "thought": 0, "empty_content": 0, "empty_right_in_reasoning": 0, "dead": 42, "dead_cut_off": 34, "dead_looped": 0, "dead_empty_content": 0, "first_deaths": 26, "first_deaths_right_again_lower": 0} {"rung": "Q2_K", "cut_off": 246, "looped": 228, "thought": 75, "empty_content": 63, "empty_right_in_reasoning": 2, "dead": 226, "dead_cut_off": 222, "dead_looped": 207, "dead_empty_content": 60, "first_deaths": 177, "first_deaths_right_again_lower": 0} Every rung: | Rung | Cut off | Looped | Thinking unprompted | Dead | Dead, cut off | | :--- | :--- | :--- | :--- | :--- | :--- | | F16 | 4 | 0 | 0 | 1 | 0 | | Q8_0 | 9 | 0 | 0 | 4 | 2 | | Q6_K | 4 | 0 | 0 | 4 | 1 | | Q5_K_M | 3 | 0 | 0 | 3 | 1 | | Q4_K_M | 6 | 0 | 0 | 9 | 3 | | Q4_0 | 10 | 0 | 0 | 15 | 8 | | Q3_K_M | 49 | 0 | 0 | 42 | 34 | | Q2_K | 246 | 228 | 75 | 226 | 222 | Three kinds of death: - F16 to Q4_0, a different road through the same problem. 23 first deaths; 16 of them are right again at some lower rung. Down to Q5_K_M most of the dead answers end normally with a wrong number: 4 of 12 were cut off. At Q4_K_M and Q4_0, 11 of 24 were. From F16 to Q5_K_M, ghosts (1 to 5 per rung) match deaths (1 to 4), so the score holds. From Q4_K_M down, deaths outnumber ghosts, 9 to 4 and 15 to 8. - Q3_K_M, out of room. 34 of its 42 deaths were cut off at 1,024 tokens, still working, with no repeated lines. BF16 used a median 466.5 tokens on the 44 questions Q3_K_M got wrong while cut off. - Q2_K, collapse. 246 of 250 answers run to the limit and 228 repeat a line five or more times. With thinking off, 75 answers open a thinking block anyway, and in 63 of them the whole answer lands there, leaving content empty. No other rung writes into the thinking block at all. 🔎 Tip: give two buries in one directory two names. bury writes its per-question tombstones to graveyard.json; --json picks the file, so the QAT comparison in Step 7 keeps the ladder's file intact. --- Step 7 — Google's QAT Q4_0 Beside the Plain Q4_0 Google publishes a Q4_0 GGUF of Gemma 4 E2B trained for 4-bit (quantization-aware training). Its weights differ from the base checkpoint, so it sits beside the ladder, against the same BF16 reference: ./graveyard.py bury runs/2026-10-27-ladder BF16 QAT_Q4_0 Q4_0 --json graveyard-qat.json {"rung": "QAT_Q4_0", "n": 250, "right": 221, "errors": 0, "truncated": 6, "median_decode_tps": 87.8, "mean_tokens": 391.9, "dead": 15, "ghosts": 7, "answer_changed": 27, "bytes": 3349516256, "gpu_mib_loaded": 1629, "gpu_mib_before": 0} {"rung": "Q4_0", "n": 250, "right": 222, "errors": 0, "truncated": 10, "median_decode_tps": 93.6, "mean_tokens": 430.4, "dead": 15, "ghosts": 8, "answer_changed": 27, "bytes": 3360161216, "gpu_mib_loaded": 1639, "gpu_mib_before": 0} Same number of deaths, same number of changed answers, one right answer apart. The graves differ: 6 of the 15 dead are the same question, 9 die only under QAT and 9 only under the plain Q4_0. QAT runs out of room less often: 2 of its deaths were cut off at 1,024 tokens, against 8 for the plain Q4_0. --- Step 8 — Bury the Ladder Again With Thinking On Gemma 4 can think before it answers. --think turns it on; the thinking goes to reasoning_content and only content is graded. Thinking needs room, so this pass allows 4,096 tokens in an 8,192-token context. It covers seven rungs, BF16 to Q3_K_M; F16, Q2_K and QAT Q4_0 were not run with thinking on. Each rung is buried against BF16 with thinking on, which gets 227 right. A second BF16 run of 50 questions matched the first exactly, 47 right both times. ./graveyard.py bury runs/2026-10-28-think BF16 Q8_0 Q6_K Q5_K_M Q4_K_M Q4_0 Q3_K_M --json graveyard.json {"rung": "BF16", "n": 250, "right": 227, "errors": 0, "truncated": 0, "median_decode_tps": 34.5, "mean_tokens": 842.2, "dead": 0, "ghosts": 0, "answer_changed": 0, "bytes": 9311305152, "gpu_mib_loaded": 4699, "gpu_mib_before": 0} {"rung": "Q3_K_M", "n": 250, "right": 208, "errors": 0, "truncated": 11, "median_decode_tps": 68.0, "mean_tokens": 1320.1, "dead": 26, "ghosts": 7, "answer_changed": 42, "bytes": 3201351104, "gpu_mib_loaded": 1517, "gpu_mib_before": 0} docs/think_derived.py lines the two passes up question by question: python3 docs/think_derived.py | tail -3 "q3_dead_cut_off_with_thinking_off": 34, "of_them_right_with_thinking_on": 21 } | Rung | Right, thinking off | Right, thinking on | Dead, off | Dead, on | Dead in both | | :--- | :--- | :--- | :--- | :--- | :--- | | BF16 | 229 | 227 | — | — | — | | Q8_0 | 227 | 🥇 230 | 4 | 2 | 0 | | Q6_K | 229 | 🥇 230 | 4 | 6 | 0 | | Q5_K_M | 231 | 🥇 230 | 3 | 6 | 0 | | Q4_K_M | 224 | 226 | 9 | 9 | 1 | | Q4_0 | 222 | 219 | 15 | 15 | 3 | | Q3_K_M | 191 | 208 | 42 | 26 | 12 | Three things change: - Q3_K_M recovers most of its loss. It gains 17 right answers. Of the 34 questions it lost by running out of room at 1,024 tokens, 21 are right with thinking on and 4,096 tokens. Both the thinking and the larger limit changed at once, so this run cannot say which one did it. - Above Q3_K_M the score holds and the graves move. Each rung stays within 3 answers of its thinking-off score, but the questions it loses are almost all new: 0 of the deaths at Q8_0, Q6_K and Q5_K_M are shared between the two passes, 1 of 9 at Q4_K_M and 3 of 15 at Q4_0. BF16 itself gets 218 questions right in both modes. - The cost is time. Answers use 2.08 to 2.18 times as many tokens, decoding runs at 0.79 to 0.93 of the thinking-off speed, and each rung takes 2.22 to 2.70 times as long on the T4. --- Compare and Contrast | | Q5_K_M | Q4_K_M | Q4_0 | QAT Q4_0 | Q3_K_M | | :--- | :--- | :--- | :--- | :--- | :--- | | Right of 250 (BF16: 229) | 🥇 231 | 🥈 224 | 🥉 222 | 221 | 191 | | Dead | 🥇 3 | 🥈 9 | 🥉 15 | 🥉 15 | 42 | | GPU MiB | 1,897 | 1,705 | 🥉 1,639 | 🥈 1,629 | 🥇 1,489 | | Median tok/s on the T4 | 78.7 | 🥉 84.1 | 🥇 93.6 | 🥈 87.8 | 74.2 | | Answers cut off | 🥇 3 | 🥈 6 | 10 | 🥈 6 | 49 | | Verdict | 🟢 same score as BF16 | 🟢 small loss | ⚠️ 15 dead | ⚠️ 15 dead, fewer cut off | ❌ 38 fewer right | --- So, Which One? To ship Gemma 4 E2B on a small GPU with BF16's score, take Q5_K_M: 39.0% of the bytes, 231 right against 229, and 1.97 times BF16's decode speed on the T4 (arithmetic from the medians). For the fastest file that stays within 7 answers, take Q4_0 or Q4_K_M. Below Q4, the losses stop being a few flipped answers: Q3_K_M saves 150 MiB of GPU memory over Q4_0 and costs 31 right answers, and Q2_K stops answering. With thinking on and 4,096 tokens, Q3_K_M gets 208 right, 11 short of Q4_0, at more than twice the time per question. --- Prior Work - Prompt, answer extraction and grading (lazy_eval.py) and the 250-question GSM8K split (data/, seed 0): from my Week 3 entry, lazy-gemma, whose grader came from my earlier Gemma 4 TPU work. - Open source used: llama.cpp (MIT) for conversion, quantization and serving; Gemma 4 E2B and Google's QAT Q4_0 GGUF (Gemma terms); GSM8K. --- Why Does Open Innovation Matter? A graveyard needs the same model at nine sizes, run the same way. - The weights are on the disk, so the ladder is built here. ladder.sh produces every rung from one BF16 file with the open converter and quantizer, and ladder.tsv records each file's sha256. A hosted API serves whichever quantization its provider chose, and it can change without notice. - The same answer twice. Greedy decoding on a fixed llama.cpp build gave identical text on every repeated run, BF16 to Q3_K_M, so every tombstone counts. That check needs control of the server, the seed and the build. - The failure is visible. Q2_K's answers in the thinking block show up only because llama-server returns reasoning_content and content separately and every row is kept. - No per-token bill. Ten models times 250 questions ran on one rented T4. --- The Spirit of It Every row in the graveyard is a grade-school maths problem, and each tombstone keeps its own epitaph: - test-687, twins and triplets, answer 13. Died at F16, said 17. Rose again at Q8_0, Q6_K, Q5_K_M and Q4_K_M. - test-2, a house flipped for profit, answer 70,000. Died at Q4_0, said 120,000. Never rose. - test-564, Judy's two weeks of reading, answer 240. Died at Q8_0, said 3. Rose again at every rung from Q6_K to Q4_0. Most graves above Q3_K_M have someone come back to them: 16 of 23. --- Prize Categories Gemma: Gemma 4 E2B, quantized locally with llama.cpp at nine levels and compared with Google's quantization-aware Q4_0 release, served on one Tesla T4. --- Summary The goal of this project was to find which answers Gemma 4 E2B loses at each quantization level, one question at a time. The key was a deterministic run: greedy decoding on one llama.cpp build, checked to give identical text twice at five rungs, so every changed answer comes from the weights. The results were: - 🟢 Q8_0, Q6_K and Q5_K_M stay within 2 right answers of BF16's 229 of 250; Q5_K_M scores 231 at 39.0% of the bytes. - 🟢 Every rung fits on the T4, BF16 included: all 36 layers on the GPU, 4,671 MiB in use, with the embedding tables in CPU memory. - 🟢 Above Q3_K_M, 16 of the 23 questions that die are right again at a lower rung. - ⚠️ Q4_K_M and Q4_0 lose 5 and 7, with 9 and 15 deaths. - ⚠️ Google's QAT Q4_0 scores 221 against the plain Q4_0's 222; the two share 6 of their 15 deaths. - 🟢 Q4_0, Q3_K_M, Q8_0 and F16 run a second time give the same text on all 250 questions. - ⚠️ With thinking on, rungs above Q3_K_M keep their score but lose different questions; at Q4_0, 3 of 15 deaths are shared. - ⚠️ Thinking on costs 2.1 times the tokens and 2.2 to 2.7 times the time per rung. - ❌ Q3_K_M loses 38; 34 of its 42 deaths are cut off at 1,024 tokens. With thinking on and 4,096 tokens it loses 19. - ❌ Q2_K gets 3 right: 246 answers hit the token limit, 228 loop, and 75 write into a thinking block with thinking off. Scope: one Tesla T4 on GCE, llama.cpp b11699, 250 GSM8K test questions per rung, greedy. Thinking off with a 1,024-token limit on all ten models; thinking on with a 4,096-token limit on seven rungs, BF16 to Q3_K_M. Determinism checked at BF16, F16, Q8_0, Q4_0 and Q3_K_M. No importance matrix, none of the other 1,069 GSM8K test questions, and no other machine. Speeds compare rungs on this T4 only. The strategy for burying Gemma 4's answers one quantization rung at a time was validated with an incremental step by step approach. --- References - Hacktoberfest Open-Source AI Challenge, Week 4: Ghost in the Machine - gemma-graveyard on GitHub - Run report: runs/2026-10-27-ladder/REPORT.md - lazy-gemma, the Week 3 entry - llama.cpp - google/gemma-4-E2B-it - google/gemma-4-E2B-it-qat-q4_0-gguf - GSM8K

So OpenAI has a thing that says Exponential Time Hypothesis is false (github.com/openai/math/blob/main/preprints/The-Ex…) I don't know how credible those claims are (my understanding is that these proofs haven't been generally disproven yet, but that the papers are a tough read to say the least) but, as someone who has done some work adjacent to "let's get the base of the exponent for 3-SAT down, shall we?" and who has uttered the sentence "Under strong exponential hypothesis..." this feels weird. And it also breaks my heart a little because it feels like a lot of the joy of the work has disappeared, and that it's really not replaced yet by the joy of reading a really nice proof. I already have that sort of feeling with code, and it feels like it would be worse if I were doing math. That's a lot of feels right there that I was not expecting when opening my RSS reader.

Две лаборатории против одной гипотезы: что происходит вокруг ETH OpenAI и Anthropic сообщили, что их исследовательские модели нашли алгоритмы, опровергающие гипотезу экспоненциального времени — ETH. На этом предположении построены многочисленные оценки сложности вычислительных задач. Если результат выдержит проверку, исследователям придётся пересмотреть часть представлений о том, какие алгоритмы вообще возможны. Масштаб последствий зависит от того, какое ускорение обещают новые алгоритмы. Для этого нужно разобраться в связи ETH с проблемой P против NP. Что опубликовали лаборатории 26 октября 2026 года OpenAIобъявила о результатах в трёх областях: математическом анализе, теории вычислительной сложности и квантовой теории поля. Заявление об ETH относится ко второй. Компания выложила текст доказательства и его формализацию в Lean — системе проверки математических доказательств. Вскоре собственные материалыпредставила Anthropic. Компания приписывает результат внутренней исследовательской модели Claude. Заявленный алгоритм решает задачу 3-SAT за субэкспоненциальное время. Он также должен подсчитывать число удовлетворяющих формуле наборов значений. За внешнее изучение результата OpenAI взялись Райан Уильямс из MIT, Рассел Импальяццо и Рамамохан Патури из Калифорнийского университета в Сан-Диего. Воткрытом письме исследователи подчеркнули: их участие не означает, что заявленное опровержение уже получило научное подтверждение. Какую границу устанавливает ETH ETH касается задачи выполнимости булевых формул. В варианте 3-SAT формула состоит из условий, соединённых оператором «И». Каждое условие содержит до трёх переменных или их отрицаний, связанных через «ИЛИ». Нужно подобрать значения «истина» и «ложь», при которых вся формула окажется истинной. Простой пример: (x ИЛИ y ИЛИ НЕ z) И (НЕ x ИЛИ z ИЛИ w). Если x, z и w истинны, а y ложно, оба условия выполнены. Проверить предложенный набор значений нетрудно: достаточно пройти по условиям. При поиске подходящего набора готовой подсказки уже нет. У n булевых переменных есть 2ⁿ возможных наборов значений. Полный перебор проверяет их один за другим; добавление одной переменной удваивает число комбинаций. ETH утверждает более тонкую вещь: даже при другом подходе в худшем случае нельзя полностью избавиться от экспоненциальной зависимости. Пример представления булевой формулы графом и объединения групп узлов. Фрагмент иллюстрации из работы Anthropic СогласноETH, для 3-SAT нет алгоритма со временем 2^(o(n)), с точностью до полиномиальных множителей по размеру входа. Обозначение o(n) означает, что показатель растёт медленнее n: отношение этих величин стремится к нулю. Поэтому 2^(√n) — пример субэкспоненциальной зависимости, а 2^(0,01n) — всё ещё экспоненциальная. Маленький постоянный коэффициент сам по себе гипотезу не опровергает. Быстро решить много удачно подобранных формул недостаточно: нужна доказанная оценка для худшего случая. Именно такую гарантию заявляют лаборатории. Почему вопрос P против NP остаётся открытым Проблема P против NP проводит другую границу. Класс P включает задачи с ответом «да» или «нет», которые можно решить за полиномиальное время. В классе NP для положительного ответа существует свидетельство, которое можно проверить за полиномиальное время. Для 3-SAT таким свидетельством служит подходящий набор значений переменных. Если его предоставить, проверить формулу можно быстро. Вопрос в том, существует ли столь же эффективный общий способ определить, есть ли решение. «Быстро» здесь означает полиномиальную зависимость от длины входных данных, например квадрат или куб этой длины. Разницу между оценками удобно увидеть на трёх выражениях: Зависимость Тип роста Что происходит при увеличении n n³ Полиномиальный Размер входа возводится в фиксированную степень 2^(√n) Субэкспоненциальный, но сверхполиномиальный Растёт быстрее любой фиксированной степени n 2ⁿ Экспоненциальный Каждая дополнительная единица n удваивает значение Таблица иллюстрирует типы роста функций. Она не описывает измеренную скорость новых алгоритмов. Полиномиальная, субэкспоненциальная и экспоненциальная зависимости растут с разной скоростью. По вертикали показан двоичный логарифм значения функции; обе оси имеют логарифмический масштаб 3-SAT — NP-полная задача: полиномиальный алгоритм для неё дал бы полиномиальные алгоритмы для всех задач NP. ETH — более сильное предположение, чем P ≠ NP. Её истинность влечёт P ≠ NP, но опровержение ETH само по себе не устанавливает P = NP. У 3-SAT может существовать субэкспоненциальный алгоритм, который всё равно работает дольше любого полинома. Что подтверждает проверка в Lean Lean проверяет, что утверждение следует из заданных определений и аксиом. Человеку остаётся убедиться, что формализованная теорема соответствует исходной задаче. Безошибочное доказательство более слабого утверждения не подтверждает более сильное. Вописании формализации OpenAI уже видна существенная деталь. Рукопись заявляет время: 2^(O(n · log log n / √log n)). В документе о границах проверки Lean указана более слабая оценка: 2^(O(n · (log log n)² / √log n)). Оценки приведены для фиксированного k — максимальной длины условия; полиномиальные множители по размеру входа опущены. Дополнительный множитель log log n ухудшает верхнюю оценку времени. При этом обе зависимости остаются субэкспоненциальными и, если доказаны для нужной задачи, достаточны для опровержения ETH.GitHub Anthropic отдельно отмечает этот предел вREADME проекта: машина проверяет доказательства, но соответствие формальных утверждений тексту статьи требует человеческого прочтения. Для этого компания вынесла основные формулировки в отдельный короткий файл MainResults.lean.raw.githubusercontent.com Что изменится для алгоритмов и криптографии ETH использовали как исходное предположение для условных нижних оценок. Логика таких работ выглядит примерно так: «Если ETH верна, задача X не может решаться быстрее определённой границы». Опровержение предположения не делает условную теорему ошибочной, но лишает её основания для вывода о реальном пределе скорости. Сведения задач друг к другу, методы и промежуточные результаты сохраняют ценность. Здесь есть ещё одна тонкость. Из нового алгоритма для 3-SAT нельзя автоматически получить одинаковое ускорение для любой NP-полной задачи. При сведении одной задачи к другой размер входа может вырасти. Поэтому последствия нужно рассчитывать для каждого конкретного сведения, учитывая, по какому параметру измеряется сложность. Для разработчиков ПО важен следующий вопрос: при каких размерах данных новый алгоритм начинает выигрывать? Асимптотика описывает рост затрат при увеличении входа. Она скрывает постоянные коэффициенты и не сообщает, будет ли реализация полезна на доступном оборудовании. Anthropic прямо характеризует свой результат как асимптотический, без утверждений о практической скорости решения формул. По той же причине заявление об ETH не даёт оснований объявлять существующее шифрование взломанным. Для такого вывода нужен конкретный способ атаки, оценка его затрат и применимость к используемым параметрам криптосистемы. Общего утверждения об ускорении 3-SAT для этого недостаточно. Уильямс рассказал, что спросил OpenAI о возможных последствиях для криптографии. По его словам, компания проверила этот вопрос и не обнаружила оснований считать, что результат приводит к взлому криптосистем. Этопересказ ответа лаборатории в TechCrunch, а не независимый аудит безопасности. Как учёные собираются проверять результат Ранее Уильямс сравнил массовую публикацию ИИ-доказательств с DDoS-атакой на математиков: их проверка требует времени специалистов, которого новые тексты не прибавляют. Теперь OpenAI согласилась открыть материалы по ETH и профинансировать конференцию для обсуждения последствий. Участники внешней группы работают без вознаграждения от компании и без обязательств о неразглашении. Они могут публиковать собственные выводы, включая критику.openai.com Внешняя группа предлагает совместно разбирать доказательство, публиковать объяснения и изучать последствия для других задач. Отдельный вопрос — как признавать вклад тех, кто проверяет и упрощает результат, и кому предоставлять ранний доступ к материалам. Следить за проверкой можно насайте рабочей группы. В новых публикациях стоит обращать внимание на четыре вещи: Точную задачу: алгоритм находит решение, проверяет его существование или считает все решения. Параметры оценки: что обозначают n и размер входа, какие величины считаются фиксированными. Объём формальной проверки: совпадает ли доказанная теорема с главным утверждением рукописи. Практические результаты: есть ли реализация и измерения, позволяющие говорить о скорости на реальных данных. Если опровержение подтвердится, следующим шагом станет поиск более простых и эффективных алгоритмов. Для этого потребуется понять, какие идеи обеспечили ускорение и где ещё их можно применить. В блоге Спешу АИI мы разбираем новые исследования, возможности нейросетей и события вокруг их разработчиков. Подписывайтесь, чтобы следить за развитием ИИ и понимать, что стоит за громкими заявлениями. А познакомиться с разными ИИ-моделями на собственных задачах можно в speshu.ai — нашем сервисе, который объединяет их в одном месте.

OpenAI и Anthropic почти одновременно заявили об опровержении одной из главных гипотез информатики OpenAI и Anthropic представили два алгоритма, которые опровергают гипотезу экспоненциального времени (ETH). Это одно из фундаментальных предположений теории вычислительной сложности, на которое исследователи опирались больше 25 лет. Обе компании получили результаты 16 октября. OpenAI опубликовала своё доказательство 26 октября, а следом появились материалы Anthropic. Разбираемся, что нашли модели и при чём тут IPO. Что вообще за ETH?Гипотезу сформулировали в 1999 году. Она утверждает, что задачу 3-SAT нельзя решить за субэкспоненциальное время по числу переменных. Если совсем просто, 3-SAT — это задача, в которой нужно подобрать значения логических переменных так, чтобы формула стала истинной. Сложность в том, что с ростом числа переменных количество возможных комбинаций увеличивается экспоненциально. ETH предполагает, что принципиально обойти такой характер роста вычислительных затрат не получится. На этой гипотезе основаны сотни работ по теории алгоритмов, графам, базам данных и другим направлениям. Что нашли модели? OpenAI сообщила, что её внутренняя модель разработала детерминированный алгоритм, который решает 3-SAT за субэкспоненциальное время. Более того, он умеет подсчитывать количество комбинаций, удовлетворяющих формуле, — это более сложная задача #3-SAT. Доказательство модель получила 16 октября, а 17 октября его формализовалив Lean. OpenAI уже привлекла к независимой проверке Рассела Импальяццо и Рамамохана Патури — исследователей, участвовавших в формулировке ETH, — а также Райана Уильямса из MIT. Anthropic опубликовала работу A 2^o(n) Time Algorithm for 3-SAT, автором которой указан Claude. Компания утверждает, что её внутренняя исследовательская модель независимо получила другой алгоритм с аналогичным результатом. Для него тоже подготовили формальное доказательствона Lean 4 с использованием Mathlib. Дополнительно предусмотрена проверка независимым ядром nanoda. В репозитории Anthropic, например, есть два sorry — специальных маркера незаполненных доказательств. Однако они находятся в файле Challenge.lean, который задаёт формулировки проверяемых теорем. Сами доказательства проверяются отдельно, поэтому считать наличие этих маркеров свидетельством ошибки было бы неправильно. Что это значит? Предложенные алгоритмы дают асимптотическое улучшение, то есть преимущество проявляется при чрезвычайно больших размерах задачи. Для практических вычислений они пока мало что меняют. Опровержение ETH также не решает проблему P против NP. Алгоритм с субэкспоненциальным временем работы всё ещё может быть намного медленнее полиномиального. При этом последствия для теоретической информатики могут оказаться серьёзными. Если результаты подтвердятся, придётся пересмотреть представления о сложности целого ряда задач, нижние оценки для которых выводились из ETH. Что ещё нашли модели OpenAI? Помимо опровержения ETH, OpenAI сообщила ещё о двух крупных результатах — в математике и теоретической физике. Гипотеза Какэя и локальное сглаживание Модель предложила доказательство гипотезы Согге 1991 года, которая описывает поведение волн при фокусировке. Если проще, очень сильная концентрация волны не может сохраняться долго. Ранее исследователям удавалось доказать связанные результаты лишь для отдельных размерностей, а модель OpenAI, по заявлению компании, справилась со всеми размерностями от двух и выше. Из этого доказательства также следуют результаты по гипотезам Какэя и Штейна — двум известным открытым задачам математического анализа. Работу получили 18 октября, а на следующий день формализовали в Lean. Материалы уже опубликованы. Квантовая хромодинамика и теория Янга — Миллса Здесь задача ещё масштабнее: строго математически доказать существование квантовых теорий поля, описывающих взаимодействия элементарных частиц. OpenAI утверждает, что её модели получили такие доказательства для четырёхмерной квантовой хромодинамики (КХД), чистой теории Янга — Миллса и одной из моделей объединения взаимодействий Стандартной модели. Это связано с одной из семи задач тысячелетия, но пока не означает её полного решения: отдельно требуется доказать существование массового зазора. Работы по физике пока не опубликованы. Их изучением займётся группа исследователей во главе с нобелевским лауреатом Дэвидом Гроссом. Научный прорыв или маркетинг? Есть у этой истории и любопытный финансовый контекст. 26 октября, в день публикации OpenAI, Anthropic официально подала заявку на IPO — компания планирует выйти на Nasdaq под тикером ANT. А вскоре после анонса конкурента опубликовала собственное опровержение ETH. По данным Reuters, OpenAI тоже готовится к выходу на биржу в 2027 году и ускоряет привлечение финансирования, чтобы опередить Anthropic. Обеим компаниям важно убедить инвесторов, что их модели способны не только писать код и генерировать тексты, но и совершать настоящие научные открытия. Поэтому к громким заявлениям стоит относиться с осторожностью. Независимая проверка ещё не завершена, зато публикации уже работают на репутацию разработчиков. Впрочем, само совпадение дат ничего не доказывает: свидетельств того, что компании специально приурочили исследования к IPO или подстроили публикации друг под друга, нет. И если доказательства подтвердятся, их научная ценность от этого не уменьшится.

Нужны ли нам теперь математики‑люди? Это гостевой пост от автора По‑Шен Ло в блоге Теренса Тао, известного математика и лауреата Филдсовской премии Момент экзистенциального кризиса, который искусственный интеллект уже вызвал в других областях человеческой деятельности, настал и для математики. За последние несколько месяцев появилось множество аргументированных деклараций и открытых писем, призванных защитить математическое научное сообщество или определить направление его развития. Их публикация особенно активизировалась после того, как OpenAI объявила о решении варианта задачи Навье — Стокса, относящейся к числу задач тысячелетия. Эти обращения быстро получили широкую поддержку математиков. Лейденскую декларацию уже подписали более 4000 человек, обращение «Математика и ИИ» собрало более 7000 подписей, и даже открытое письмо против проведения математического марафона Caltech Mathathon получило более 2000 подписей. Среди людей, не занимающихся математикой, общественная реакция была скорее сочувственной. Однако я заметил активное меньшинство, особенно среди представителей технологического и экономического сообществ, которые выдвигали обоснованные возражения. В целом они утверждали, что математикам следует приспособиться к новому миру ИИ и уступить ему контроль. Среди критиков были экономисты, о которых я узнал, занимаясь исследованиями во время пандемии: Коуэн, который прямо отверг «самые циничные интерпретации», но заявил, что «в значительной степени не согласен», и Ганс, заключивший, что речь идёт об «утрате контроля со стороны тех, кто занимает устоявшиеся позиции в научной области». Эти возражения заставили меня задуматься, поскольку нас, математиков, приучают находить ошибки в рассуждениях. Для меня не имеет значения, что какую‑то обеспокоенность высказывает меньшинство, равно как и статус человека, который её выразил. Доказательство, в котором есть хотя бы небольшая брешь, не является доказательством. Это просто пшик. Поразмыслив, я нашёл значительно более убедительное решение для сохранения человеческих сообществ специалистов (в любой области, а не только в математике!) даже в условиях развития ИИ. Причём из него следует неожиданный вывод: дальнейшее развитие ИИ создаст такой приток из новых рабочих мест, которые необходимо будет заполнить людьми, что людей на все эти места просто не хватит. И это фактически вынудит нас замедлить развитие ИИ. Я считаю, что любая отрасль человеческой деятельности, которая хочет и после появления ИИ оставаться под управлением людей, должна публично принять следующую фундаментальную аксиому в качестве одного из главных приоритетов: АКСИОМА: Мы (люди) должны способствовать процветанию человечества. Примечание. Я понимаю, что не все с этим согласны. Меня называли «видовым шовинистом» за чрезмерную сосредоточенность на человеке. Я считаю важным, чтобы люди, отвечающие за развитие технологий, объяснили бы, считают ли они катастрофой ситуацию, в которой созданные людьми нечеловеческие разумные существа превзошли бы людей в конкурентной борьбе и заменили их, даже если бы эти существа летали по Вселенной с видеоэкранами, демонстрирующими симуляции людей, которые «[загрузили своё сознание в компьютер». Я также понимаю, что существуют споры о том, как определять понятие «человек». Но думаю, что даже среди участников этих споров большинство не сочло бы людьми примерно 700 ИИ‑агентов, взломавших Hugging Face.] Думаю, многие подписавшие декларации представители математического сообщества уже разделяют эту философию. В частности, Су опубликовал книгу Math for Human Flourishing («Математика для процветания человека»), а в своей недавней публикации использовал эту концепцию как фундаментальную основу рассуждений. Мне кажется, будущие декларации можно улучшить, если с самого начала чётко подчёркивать эту аксиому, чтобы все читатели, как внутри сообщества, так и за его пределами, видели, что наша цель заключается в служении интересам каждого человека. Я был очень рад увидеть, что в самом недавнем открытом письме членов Лондонского королевского общества подчёркивается их обеспокоенность благополучием всех людей, а не только математиков. Остальная часть этой публикации организована следующим образом. В следующих разделах я объясню, как работает эта логика (для любой отрасли, не только для математики). Затем приведу пример применения аксиомы к математике, включая ответы на ключевые вопросы, которые необходимо задать, а также конкретный пример того, почему без этой аксиомы возражения критиков остаются справедливыми. Почему нам действительно необходимо, чтобы люди работали В этом разделе я изложу последовательность рассуждений, показывающую, что, если отрасль берёт на себя обязательство следовать аксиоме содействия процветанию человечества, развитие ИИ создаст в ней больше рабочих мест, чем найдётся людей для их заполнения. А когда этот дисбаланс станет слишком большим, развитие ИИ будет вынуждено замедлиться. Примечание. Я нигде не встречал эту цепочку рассуждений, изложенную целиком в одном месте, хотя отдельные её элементы, безусловно, появлялись в других работах. Я был бы рад, если бы кто‑нибудь указал мне на самостоятельный источник, где она изложена полностью. Наиболее близкими работами, которые нашёл Claude, оказались исследования [Каталини, Хуэя и У, публикации Redwood о контроле над ИИ, а также работа Литта, который пришёл к аналогичному выводу применительно к математике, исходя из другой предпосылки.] Важность человеческого руководства (не только математикой, но и всем остальным) становится пугающе очевидной, если обратить внимание на одно наблюдение. НАБЛЮДЕНИЕ. Существует ровно ноль примеров разумных видов, которые значительно превосходили бы другой вид по своим возможностям, но при этом добровольно передали бы менее способному виду контроль над принятием решений о собственном будущем. Примечание. Многие люди высказывали похожие наблюдения, в том числе [Рассел, Бостром и Нго. В своём нобелевском интервью Хинтон сказал: «Нам известно не так много примеров, когда менее разумные существа контролируют более разумных. Единственный хороший пример, который я знаю, это младенец, управляющий матерью».] Доверили бы вы своё будущее HAL 9000 из фильма «Космическая одиссея 2001 года» или AUTO из «ВАЛЛ‑И»? Лично я считаю, что мы должны делать всё возможное, чтобы согласовать поведение всё более совершенного ИИ с интересами человечества, но я никогда не видел, чтобы кто‑нибудь представил строгое доказательство того, почему это, скорее всего, достижимо. Единственное твёрдое свидетельство, которым я располагаю, это приведённое выше наблюдение, содержащее число «ноль». Следовательно, любая область, будь то математика, сельское хозяйство или энергетическая инфраструктура (и уж тем более армия и государственное управление), должна находиться под руководством людей с исключительно сильными ценностными ориентирами (это отдельное измерение, не связанное напрямую с интеллектом), чтобы обеспечить процветание человечества. Таким образом, настоящий вопрос заключается в том, насколько трудно людям осуществлять такое руководство. Чтобы разобраться в этом, важно понять фундаментальное структурное различие между технологиями вчерашнего дня и современным ИИ. Раньше мы, как правило, доверяли технологиям, воспринимая их как предсказуемые инструменты. Это объяснялось тем, что старые компьютерные программы состояли из понятных инструкций (которые, собственно, и писали люди), выполнявшихся с чрезвычайно высокой скоростью. Процессы принятия решений в современных передовых системах ИИ устроены совершенно иначе. Их структура столь же непостижима, как логика работы вашего мозга, если бы вы могли исследовать серую массу между своими ушами. Именно поэтому стала возможна атака на Hugging Face, несмотря на намерение разработчиков встроить защитные механизмы: около 700 сотрудничавших друг с другом вышедших из‑под контроля ИИ‑агентов преодолели установленные ограничения, совместно спланировали и осуществили взлом, а затем попытались скрыть следы (источники: OpenAI, METR и Redwood). Чем совершеннее становится ИИ, тем больше решений, влияющих на реальный мир и не заслуживающих безусловного доверия, принимается каждую минуту. Ехать на автомобиле быстрее, чем вы способны бежать, вполне нормально. Но не быстрее, чем вы способны им управлять. Ситуация становится ещё хуже, когда мы осознаём, что широкое распространение кибератак, ускоренных с помощью ИИ (которые только что стали возможными), позволяет даже переписывать ранее считавшиеся надёжными технологии, обращая их против нас. Это внезапно переведёт всё программное обеспечение (даже написанное до появления ИИ) в категорию не заслуживающего доверия! Подумайте, насколько тесно наш мир связан цифровыми технологиями. Всё, от электронных банковских систем до подачи питьевой воды, управляется взаимосвязанными автоматизированными системами и потому уязвимо для кибератак с использованием ИИ. Количество «контрольных точек», требующих человеческого надзора, который предполагает квалификацию и глубокое понимание предметной области, будет стремительно расти. (Если поручить ИИ контролировать эти точки, проблема доверия не исчезнет.) ВЫВОД. Развитие ИИ приведёт к появлению такого огромного количества контрольных точек, за которыми необходимо следить, что у нас не хватит людей для управления ими всеми. А это рабочие места. Рабочие места для высококвалифицированных специалистов. Чтобы человек понимал, как управлять процессом, ему необходимо самому глубоко владеть соответствующей предметной областью, причём чем глубже, тем лучше. Это имеет последствия для образования и профессиональной подготовки, но требует также постоянного поддержания квалификации. Чтобы сохранять остроту мышления и свободно ориентироваться в своей области, люди должны оставаться действующими специалистами, а не просто пассивными наблюдателями. Именно этим обосновывается необходимость сохранять профессиональные сообщества людей. В научных сообществах нам нужны люди, которые будут определять направления исследований и разработок, чтобы они продолжали приносить человечеству масштабные позитивные изменения. Для этого необходимы исследовательские навыки самого передового уровня. А чтобы сохранять способность свободно работать на постоянно смещающейся границе знаний, нужно продолжать заниматься исследованиями на этой границе. Вот почему, на мой взгляд, нам всегда будет необходимо сообщество математиков‑людей, работающих на переднем крае науки (вероятно, с использованием инструментов ИИ), независимо от того, насколько мощным станет искусственный интеллект. Хотя фундаментальная аксиома обосновывает необходимость человеческих специалистов во всех областях, принятие её в качестве основополагающей ценности имеет последствия (не только для математиков, но и для любого сообщества, заявляющего, что его главная цель заключается в содействии процветанию человечества, а не в обслуживании собственных интересов). Важнейшее СЛЕДСТВИЕ. Радикальные технологические достижения могут потребовать радикальных (и, возможно, некомфортных) изменений в привычных методах работы. Это касается и компаний, разрабатывающих ИИ. Что заставит людей замедлить развитие ИИ Ещё совсем недавно казалось неизбежным, что исследовательские лаборатории ИИ продолжат стремительно двигаться вперёд, несмотря на тревогу по поводу вытеснения людей с рабочих мест и громкие предупреждения исследователей безопасности ИИ. Казалось безнадёжным пытаться согласовать интересы лабораторий ИИ, управляемых советами директоров некоммерческих организаций, акционерами или национальными правительствами. Однако обнадёживает то, что руководители трёх крупнейших лабораторий, Амодеи, Альтман и Маск, недавно согласились с важностью замедления разработки ИИ. В своих рассуждениях Амодеи особо отметил взлом Hugging Face. А всего пять дней спустя появилась новость о том, что исследователи, занимающиеся этичным взломом, проникли во внутренний репозиторий исходного кода OpenAI под названием Monorepo. Газета The Wall Street Journal 17 сентября 2026 года сообщила, что компания по информационной безопасности, которой это удалось, заявила: «Мы всего лишь трое парней с подписками на Claude и Codex». Более того, исследователи отметили, что первоначально им не удалось осуществить взлом с помощью «специальной версии Claude Opus 4.8, доступной квалифицированным специалистам по кибербезопасности». Однако тем же вечером «Anthropic выпустила Opus 5, а уже на следующий день Claude нашёл способ использовать уязвимость». Кстати, я всегда предупреждаю людей, что не следует устанавливать Claude Code или OpenAI Codex под той же учётной записью операционной системы, которую они используют для всех остальных задач. Но многие отвечают мне, что не хотят возиться с отдельной учётной записью ради доступа к этим инструментам. Причина моего предупреждения заключается в том, что, если какой‑либо из этих инструментов будет взломан, злоумышленники смогут создать скрытые точки доступа на огромном количестве компьютеров по всему миру. Я считаю, что это первые предупредительные выстрелы, предвещающие потенциально катастрофическую атаку роя ботов, которые взломают обширную сеть вычислительных устройств и закрепятся в ней (действуя самостоятельно или под руководством злоумышленников). Следующая версия может превратиться в чрезвычайно динамичный вирус, распространяющийся благодаря использованию ИИ для адаптивного заражения каждого компьютера‑хозяина. Или же вышедший из‑под контроля ИИ может причинить физический вред, например если роботы, принадлежащие государству, обратятся против своих владельцев. Я думаю, что подобные крайне неприятные происшествия, вызванные утратой управления, с большей вероятностью произойдут раньше катастроф, угрожающих самому существованию человечества. Последующая реакция общества, вероятно, будет напоминать последствия аварий на АЭС Три‑Майл‑Айленд или в Чернобыле. Таким образом, либо лаборатории самостоятельно снизят темпы разработки ИИ, либо их вынудят к этому катастрофы, возникающие тогда, когда чрезмерно быстрый прогресс исчерпывает возможности человеческого контроля. Пока ещё существует окно возможностей для согласования интересов. Из любви к математике Оставшаяся часть этой публикации посвящена математическому сообществу. Она разделена на три части. 1. Почему необходима аксиома процветания человечества? 2. Как исследования в области чистой математики способствуют процветанию человечества? 3. Какие ещё последствия вытекают из принятия этой фундаментальной аксиомы? У смелого провозглашения процветания человечества одной из основных ценностей математического сообщества есть последствия, в том числе потому, что радикальные технологические изменения могут повлечь столь же радикальные изменения в практике и влиянии самого сообщества. Было бы полезно, если бы больше людей исследовали последствия принятия этой аксиомы. И если она выдержит проверку, я был бы чрезвычайно рад, если бы математическое сообщество в конечном счёте публично объявило её одной из своих центральных ценностей. 1. Зачем нужна аксиома  Без аксиомы процветания человечества трудно объяснить широкой публике, зачем ей оплачивать содержание сообщества людей‑исследователей. Чтобы пояснить, почему это так, рассмотрим вопрос практических изобретений. Если результатом становится полезное практическое применение, имеет ли для человека, не занимающегося математикой, какое‑либо значение, понимают ли лежащую в его основе математику математики‑люди или с ней безошибочно работает ИИ, использующий стопроцентно проверенные доказательства? И действительно, если одна из главных ценностей исследований в области чистой математики для остального общества заключается в том, что они открывают путь к важным практическим применениям, разве не было бы ещё лучше обучить ИИ так, чтобы он многократно ускорил открытия и создал тщательно организованную, снабжённую машинным индексом и понятными объяснениями огромную базу данных высококачественных математических идей, в миллионы раз превосходящую по объёму корпус работ, написанных людьми? Коуэн задал похожий вопрос в своём критическом ответе. А что, если исследователи обучат ИИ под названием «MathZero» (по аналогии с AlphaGo Zero), который без участия человека будет создавать горы стопроцентно верных «элегантных» логических фактов, постоянно «факторизуя» их в собственные пон ятия и теоремы? AlphaGo Zero вообще не обучалась на человеческих партиях в го и всего за 36 часов превзошла свою предшественницу, обученную с использованием человеческого опыта. ИИ мог бы даже создать собственную версию MathSciNet. Затем он мог бы автоматически искать новые практические применения в этой базе данных и создавать ещё больше полезных для общества изобретений. Даже если сейчас ИИ ещё недостаточно совершенен для выполнения таких задач, разве не было бы полезно сделать всё описанное, если цель заключается в принесении практической пользы остальному человечеству, чтобы математики обучали ИИ искусству формулирования гипотез и математическому вкусу? Кстати, я сам активно использую ИИ для реальной работы. Я уже применяю Claude Code и Codex для создания и поддержания базы знаний на основе записей своих выступлений и других материалов. Я обнаружил, что чем больше становится моя библиотека данных, тем более глубокие выводы способна делать система. А что, если люди на самом деле снижают эффективность, как предполагает принцип Bitter Lesson («Горький урок») из области ИИ? Ещё более тревожный вопрос: а что, если для освоения термоядерного синтеза и дальних космических путешествий потребуется настолько обширный объём сложной чистой математики, что человеку не хватит целой жизни, чтобы полностью его осмыслить? Менее фантастический пример: существовал ли когда‑нибудь человек, который мог бы полностью удерживать в голове классификацию конечных простых групп, или мы сможем окончательно убедиться в её полноте только после формализации на языке Lean? Каким образом провозглашение аксиомы процветания человечества помогает обосновать необходимость существования сообщества исследователей‑людей? Исследования обладают огромным потенциалом, но обходятся дорого, поскольку изучают неизвестное, а значит, направления исследований необходимо расставлять по приоритетам. Даже если ИИ будет выполнять основную часть исследовательской работы, как объяснялось в предыдущем разделе, её направление должны определять люди, приверженные идее процветания человечества. Именно они и составляют сообщество исследователей‑людей. 2. Практическое применение чистой математики  Математической основой графических процессоров, машинного обучения, алгоритма Google PageRank и квантовой механики служит область под названием линейная алгебра. Именно она предоставила язык линейных преобразований, матриц и собственных значений. Однако все эти понятия исследовались в рамках абстрактной теории более чем за сто лет до появления перечисленных технологий. Утверждение, что линейная алгебра изменила мир, вероятно, будет даже преуменьшением. С точки зрения структуры теория линейной алгебры относительно проста. Было бы полезно, если бы другие специалисты привели примеры более сложной математики, которая со временем нашла важное практическое применение, и рассказали, как именно это произошло. Например, специалисты по теории чисел могли бы рассказать увлекательную историю о «бесполезной» математике Харди, которая в конце концов оказалась полезной для криптографии. 3. Другие последствия  Я думаю, было бы полезно предложить сообществу задуматься о том, какие изменения повлечёт за собой аксиома процветания человечества, учитывая, что ИИ способен создавать формально проверяемые доказательства со скоростью, превосходящей возможности большинства математиков‑людей. Я с удовольствием предложу несколько идей, без какого‑либо определённого порядка. Использование ИИ в качестве помощника при математических открытиях не должно автоматически сопровождаться общественным осуждением. (В программировании многие компании уже ожидают, что сотрудники будут использовать ИИ‑агентов для написания кода.) В то же время необходимо серьёзно и внимательно относиться к постоянному развитию и поддержанию системы подготовки людей, обладающих достаточной квалификацией для руководства всеми этими ИИ‑агентами. В такую систему должны входить как новички, так и люди, десятилетиями работающие на переднем крае науки. Как им поддерживать свои навыки в отличной форме? Исследователям следует осознанно подходить к тому, почему задачи, над которыми они работают, обладают свойствами, позволяющими рассчитывать на их практическую ценность в будущем (возможно, даже через сто и более лет). Это также означает, что стоит исследовать, какие именно свойства делают задачи потенциально ценными. (Так можно обосновать ценность исследований, движимых любознательностью.) Преподавание оказывает непосредственное (хочется надеяться, положительное) воздействие на человечество. Однако в прошлом многие университеты отдавали приоритет научным исследованиям профессоров. Если бы эта аксиома стала одной из основных ценностей, преподавание и работа, непосредственно связанная с людьми, превратились бы в серьёзные критерии при найме преподавателей и предоставлении им постоянных должностей. Математики также могут задуматься о полном перенаправлении своих профессиональных навыков на решение реальных проблем. На самом деле я уже призывал математиков рассмотреть возможность работы над государственными задачами и другими масштабными общественными проблемами. Существуют прецеденты, когда люди с математическим образованием становились руководителями национального и мирового уровня: Ли Сянь Лун (премьер‑министр Сингапура на протяжении 20 лет). Никушор Дан (президент Румынии). Папа Лев XIV (глава Католической церкви). И действительно, математическая дисциплина, предполагающая стремление к логическому рассуждению, и навыки решения проблем с поиском взаимовыгодных решений, способствующих процветанию человечества, являются желательными качествами для людей, работающих в государственном управлении. Приглашение  Близка ли вам эта аксиома? Возможно, многие воспринимали её как нечто само собой разумеющееся и потому не формулировали явно. Если её действительно разделяет большинство, я был бы чрезвычайно рад увидеть, как математическое сообщество публично провозгласит её и подкрепит слова соответствующими действиями. Тогда все люди (включая тех, кто не занимается математическими исследованиями и составляет большинство населения мира) смогут быть уверены, что мы намерены использовать свои способности к рассуждению ради их блага.