#並列処理

最初に思ったのは、これはかなり“気持ちよく危ない”機能だな、ということだった。 AI に仕事を割り振って並列に走らせる発想自体は自然だし、開発の流れに合っている。けれど、記事が指摘している通り、その便利さはたぶん請求や利用枠の消費とセットで来る。昼前にプランを食い尽くす、という言い方は少し大げさに見えて、実際にはわりと現実的な怖さだと思う。 とくに引っかかったのは、Claude Code Projects が「コーディネーター」を中心に再設計されている点だ。人間の感覚だと、プロジェクトは作業の置き場で、メモや履歴が残る場所という印象が強い。でもこの記事では、そこが単なる保管庫ではなく、複数の thread を束ねる司令塔みたいに扱われている。AI が一人で考えるというより、細かい役割に分かれた複数の AI をまとめて回す方向に寄っていて、いよいよ開発ツールというより“仕事の配車係”に近づいている感じがした。 ただ、その形はかなり強力である一方、使い方を間違えるとノイズも増えそうだと思う。並列化は速さを生むけれど、同時に判断のコストも上げる。どの thread に何を覚えさせたか、sha

AI にコードを書かせる流れが強まるほど、「速く動く」ことと「意図どおりに動く」ことの両立が難しくなる。Bend は、その矛盾を言語設計そのものから解こうとしているプロジェクトだ。作者は、自然言語で雑に指示しても AI が実装し、しかも proof で間違いを止められる世界を見据えている。まだ若い言語ではあるが、主張はかなり野心的で、今の AI 開発ブームに真正面から乗っている。 Bend は、AI のミスを proof で塞ぐことを売りにした新しい language だ。紹介文では「a fast language that blocks AI mistakes via proof」と掲げられ、あわせて C speed、CUDA parallelism、Lean proofs、Python syntax という特徴が並ぶ。つまり、書きやすさは Python に寄せつつ、実行速度は C に近く、しかも GPU も使える。そこに proof checker を組み合わせて、AI が書いたコードが守るべき規則を機械的に確認する、という構想になっている。 サイトの冒頭では、将来の post-A

最初に思ったのは、これはわりと当たり前のことを、ちゃんと実務の形に落とし込んだ話だな、ということでした。AIを1回ずつ順番に使うと、待ち時間も文脈の肥大化も避けにくい。人間の作業でも、調べもの、実装、テスト、レビューを同じ人が全部抱えると遅くなるのと同じで、AIにも役割分担をさせたほうが自然です。 面白いのは、この記事が「すごい裏技」というより、「Claude Codeをちゃんとチームっぽく扱え」という発想を押し出しているところです。サブエージェントという言い方をしているけれど、要するに小さな専門家を複数走らせる感じで、これはかなり腑に落ちました。コンテキストウィンドウ、つまりAIが一度に覚えていられる範囲が広がるほど雑になる、という感覚は使っていると身に覚えがあります。長いやり取りのあとに急に浅くなること、ありますよね。 一方で、そこまで万能でもないのも正直だと思いました。トークンコストが増える、独立した作業にしか向かない、という線引きがちゃんと書かれているのがよかったです。ここを曖昧にすると「なんでも並列化すれば速い」と勘違いしがちですが、実際はむしろ逆で、依存関係がある仕事まで分

Moondreamのブログ「Popping the GPU Bubble」は、AI推論を速くする話です。 ただし、単に「GPUを強く使えば速くなる」という雑な話ではありません。むしろ逆で、GPUがサボってしまう“すき間時間”をどう消すかに真正面から向き合っています。ここが面白い。 AIの推論では、GPUが大量の計算をして次のトークン（ざっくり言うと、文章のかたまり）を出します。ところが実際には、GPUが計算している時間よりも、CPUが「次は何をやるか」を準備している時間のせいで、GPUが待たされることがあります。これが記事のいう GPU bubble です。風船みたいに膨らんだ無駄な待ち時間、という比喩ですね。 Moondreamはこの待ち時間を、pipelined decoding という方法で減らしています。要するに、 「前のトークンの後片付けをCPUがしているあいだに、GPUは次のトークンの計算をもう始める」 という並行処理です。これだけ聞くと当たり前に見えますが、実際に安全にやるのがかなり難しい。そこでこの記事では、その工夫をかなり丁寧に説明しています。