100ドルで買える最高峰のChatGPT！NanoChatとは？
引用元：https://news.ycombinator.com/item?id=45569350
AIコーディングツールの使用について興味深いやり取りがあったよ。Karpathyは、コードの大部分は手書き（タブ補完付き）だって言ってる。ClaudeやCodexを試したけど、全然うまく機能しなかったみたい。彼のレポジトリがデータ分布からかけ離れすぎてたのが原因かもね。https://x.com/karpathy/status/1977758204139331904
Karpathyが言ってる「レポジトリがデータ分布からかけ離れてる」って話、これだよ！AIモデルがこれまで俺にとって役に立たなかった理由がやっと分かった！俺がやってることは全部データ分布から遠すぎるんだな！
あなたのアプリがReactのToDoリストやLeetCodeの問題じゃない限り、AIは役に立たないんだよ。
これって批判みたいに言われるけど、単純なCRUDフォームを書き始めたときにCopilotが全部自動補完してくれるのって、マジで最高だよな。
HN（Hacker News）のAIコーディング（とあらゆるもの）に対する皮肉な姿勢は本当にうんざりするよ。Karpathyもこれ読んだらきっと嫌になるだろうな。
そうそう。AIに関する過剰な hype は同意するけど、今できることが面白くて役に立たないってわけじゃない。
10年前に、デスクトップでプログラムを漠然と記述したら、公開されてるソースコードの世界からそれに最も近いものを見つけてくれる fuzzy search engine が使えるって言われてたら、ぶっ飛んでたはずだよ。突然、過去に書かれたあらゆるコードに（多少は損失があるけど）アクセスできるようになったんだから。他のあらゆる分野でも同じ！AIが「考えたり」とか「新しいことしたり」できるかどうかは気にしない。できることが素晴らしいし、時にはとてつもなくパワフルなんだよ。（時にはそうじゃないけど、それが新技術の楽しさだよね！）
あなたがワクワクするって言ってることって、なんで現在のAIの hype レベルに値しないって思うの？あなたの評価には同意するし、時には皮肉が多すぎて興奮が足りないと感じることもあるんだ。
でもさ、彼が売ろうとしてる「橋」って、非決定論的に間違った場所に連れて行かれるかもしれない橋そのものなんだよね。
これは納得できる話だよね？ Karpathyが書いているのは比較的新しいことなんだし、ここで他のコメントが結論付けているような致命的な発言だとは思わないよ。
むしろ、KarpathyがClaudeやCodexに価値を見出そうと手を伸ばしたってことは、以前のコーディング作業ではそれらのツールが彼にとって役立っていたってことの証拠じゃないかな。
Karpathyみたいな信頼できる人の意見はいいね。AGIに期待しすぎな人は、ちょっと冷静になった方がいいかもな。
Claude CodeはWebコード書くのにめっちゃ役立つわ。俺よりずっとWeb開発得意だし。でも、アルゴリズムの核心部分の深掘りには、データが少なくて間違いも多い。それでも、金払う価値はあるし、俺のWeb開発奴隷としてでも十分満足してるよ。
このスレッドの元々の文脈は、Karpathyが特定のプロジェクトでAIコーディングツールが彼には役に立たなかったって言ってたことだよ。
90年代は、VB6のAppletをMicrosoft Wordにドラッグ＆ドロップできたんだぜ。なんか後退した気がする。
若い子向けに言うと、WYSIWYGってのはC++からDelphi、HTMLまであらゆる言語で普通だったんだ。どんなものでも描けたし、データソースとのネイティブバインディングも多かった。俺のお気に入りはHyperCardだったな、小学生で習ったから。
そうだね。KarpathyだけがAIツールが彼には間違ったコードを生成するって言えるし、それもこのプロジェクトに限っての話だ。他の誰かが同じことを言っても、「その懐疑論はうんざり」って言われて、そいつらの経験は完全に無視されるんだよな。
HNで誰かがAIコーディングのワークフローについて投稿するときのコメントを見てみろよ。投稿者がステマか、無知か、おもちゃみたいな例でしか使ってないかっていう否定的なコメントだらけだから。
この不満な態度は両方向に存在するし、それがまさにうんざりするんだよ。
俺はLuaで型付きLuaに取り組んでるんだけど、LLMを内部アナライザー修正に使うと、複雑なケースでは30%しか機能しないし、全くダメな時もある。でも、最終的には解決策を見つける助けになるよ。
ただ、LLMに俺の型付きLuaコードを生成させると、構文がほとんど間違ってるんだ。例えば local x: {foo = boolean} って構文なのに、LLMはいつも local x: {foo: boolean} って使うんだよね。
WYSIWYGは、みんなが800x600とか1024x768の画面を使ってるって前提が崩れた途端に機能しなくなったんだ。だって、君が見てるものが他の人には同じように見えなくなったからね。
「LLMは完全に役立たず」や「救世主的なプログラミング新時代を切り開く」といった両極端な意見は単純化しすぎだね。
Claude Codeみたいなエージェントツールで大規模プロジェクトも作ったよ。込み入ったアルゴリズムやロジックには弱いけど、UI/UXが壊滅的な俺には、Web開発の土台を組んでくれるのは、時間とストレスを大幅に節約してくれるんだ。
期待値を調整することが重要さ。
[1] https://animated-puzzles.specr.net
Karpathy自身が、AIツールをプロジェクトに使えなかったから、ほとんど手書きでコードを書かなきゃいけなかったって書いてたよね。なんでだろうな。
もし目標が「簡潔さと教育的価値に焦点を当てて、LLMをゼロからトレーニングする8,000行の最も洗練された実装を構築する」なら、ClaudeやCodexがほとんど役に立たなかったとしても、別に驚くことじゃないと思うけどな。
彼は全然わかってないね。AIはほとんどのデベロッパーより良いコードを書けるんだから。この恥ずかしいくらいのアンチAIの宣伝野郎もそうだね。うちの会社のAIツール使えば、もっと良いコードが早くできたはずだよ。
今のAIに対する期待、特に投資家や上司の間でのやつは、簡単なプロンプトでAIが完璧なアプリをすぐ作れるって思ってるけど、実際は全然違うよ。AIの能力はすごいけど、期待値が現実と乖離しすぎてるね。
これは皮肉じゃなくて、SVのマーケティングに盲目的に従うより現実的な視点だよ。GenAI、NFT、Web3、Metaverse（Zuck氏の解釈のやつね）、自動運転車、Theranosなんかも、全部誇大広告されてきたものと一緒だね。
「自動化ツールのアルゴリズムの中核を掘り下げる」ってとこに注目だね。「UIの専門家はUIにはAIを使わないけど、アルゴリズムの中核はAIの方が優れてるから任せる」って、他の文脈でも同じこと聞くのが面白いよ。
コーディングエージェントを使ってるの？それともただのLLMチャットインターフェース？リンターとかコンパイラをエージェントに繋いで、ミスを検出できるようにしてる？
CRUDアプリ、一般的なデザインパターン、テスト、CI/CD、スクリプトとかさ。コードを書くことの80%はオートコンプリートみたいなもんで、AIはそこを自動化するのにすごく役立つよ。開発者にはコードを書くこと以外にも仕事があるけど、AIを使えばドメイン固有の仕事にもっと集中できる時間が増えるんだ。
「記事へのコメントは、投稿者が誇大宣伝家だの無知だの、しょぼい例でしかやってないだのって言われるだろう」って、それはよくあることだね。AIだけでコード書いてるっていうキラキラした投稿も、実際のコードやプロダクトを見せないのがほとんどだし。AIを疑ってる人のほとんどは、むしろ自分でツールを毎日使ってるからこそ懐疑的になってるんだよ。
アンチAIの誇大宣伝家だって？あの人、OpenAIの共同創業者なのに、そんなこと言うの？
「AIに簡単なプロンプトをあげたら、すぐに使えるアプリを吐き出せる」って、ワンショットのことならもうできるでしょ。でも問題は、最適化されてないし保守もできない、何かあっても誰も責任取らないってこと。テストもなさそうだから変更も怖い。結局、動くモックアップ生成ツールだよ。半技術系のYouTuberがワンショットで新モデルを見せびらかすのにうんざりだね。実際の開発者は、長期的なコンテキストで何回も修正しながら使えることを求めてるんだから。
LLMは大概のことに平凡だけど、ユーザーが専門とする分野では及ばないよ。でも「平凡」イコール「無駄」じゃないからね、両方あり得るよ。
「GPTクローンに使えない」って言われたらKarpathyはきっと嫌な顔するだろうね。「ReactのTODOリストデモ以外無能」って言われるのは彼も不快だろうな。AIコーディングエージェントは天才でも無価値なCRUD屋でもないって彼も分かってるからね。
もっとコメントを表示（1）
NanoChatはmodded-nanoGPTから影響を受けてるんだね。Karpathyのnano-GPT→Keller Jordanのmodded-nanoGPT→NanoChatって系譜だ。modded-nanoGPT [1]は小規模GPTモデルの学習を超高速化する素晴らしいプロジェクトで、AdamWじゃなくてMuonオプティマイザ [2]を使ってるのが注目点だよ。
[1] https://github.com/KellerJordan/modded-nanogpt
[2] https://kellerjordan.github.io/posts/muon/
MuonはKeller Jordanがスピードランコンペのために発明し、後に最適化されたものだよ。まだ1年も経ってないけど、モデル学習のSOTAとしてもう広く使われているんだ。
MuonのアイデアはBernsteinが理論的に提案し、Kellerがそれを実装して実用的にしたんだ（入出力AdamWや係数など）。両者と論文の共著者も同等の功績があると思うよ。Bernsteinは控えめだから、俺はよく彼の名を挙げるんだ。（情報源：この界隈のベテランスピードランナー）
Bernstein、Newhouse、Yuchen Jin、Jiacheng You、そしてMuon開発を助けた他のスピードランナー達に言及するのは良いことだね。でも、現状のMuonの主要作者はKeller Jordanって言って差し支えないと思うよ。私もスピードランニングコミュニティにいるけど、君ほど長くはないかも。
Muonを学ぶのに役立つリソースをいくつかシェアするね（俺も今追いかけてる最中だから）。
- https://x.com/leloykun/status/1846842883967692926
- https://www.yacinemahdid.com/p/muon-optimizer-explained-to-a…
このシンプルなオプティマイザがAIトレーニングを変革している [Muon]っていうYouTube動画を見つけたよ。これが良い入門動画だと思うな。
https://www.youtube.com/watch?v=bO5nvE289ec
Muonの一番の魅力は、Adamの半分のメモリしか要らないのに、同等かそれ以上の性能を持つことだね。VRAMが限られるなら最高だよ！Adamと同じで量子化もできて、4ビットまで下げてもうまく動くから、32ビットAdamに比べてメモリを16分の1に減らせるんだ！
これ、今まで聞いたことなかったな。MuonはAdamやAdamWを深層学習用オプティマイザの標準の座から降ろしたの？
Muonは隠れ層の最適化に使うんだって。埋め込みとかは標準のAdamWを使うのが普通みたい。Karpathyのnanochatリポジトリもそうしてるよ。
https://github.com/karpathy/nanochat/blob/dd6ff9a1cc23b38ce6…
8xH100って推論ノードとしてはヤバいね。最先端のLLMってこんなにVRAMや計算リソースを使うの？1リクエスト0.01ドルっていう俺の計算、合ってるかな？
これはトレーニングノードのスペックだよ。推論なら80GBのVRAMで済むから、計算リソースはずっと少なくていいんだ。
デフォルトモデルって0.5Bパラメータくらいだっけ？
vessenesが言ってたけど、これはトレーニング用だよ。でもH100ならたくさんのリクエストを並行して処理できるんだ。
今トレーニングを実行中だよ（20分前に開始）。進行状況はここで見れるよ！
https://api.wandb.ai/links/sjd333-none/dsv4zkij
4時間後にモデルができたら、みんなの推論テスト用に共有するね。
モデルをここにアップロードしたよ！
https://huggingface.co/sdobson/nanochat
Karpathyみたいに良い結果は出なかったけど（シードが悪かったかな？）、遊ぶのは楽しいよ…
ユーザー: 犬の足は何本？
アシスタント: それは犬好きの間で何世紀も議論されてきた素晴らしい質問だ。唯一の”正しい”答えなんてないんだ (…)
僕のモデルをmacOSのCPUで動かすのに成功したよ！Claude Codeに手伝ってもらって。
誰でも動かせるスクリプトはここ！
https://gist.github.com/simonw/912623bf00d6c13cc0211508969a1…
こんな感じで実行できるよ:
cd /tmp
git clone https://huggingface.co/sdobson/nanochat
uv run https://gist.githubusercontent.com/simonw/912623bf00d6c13cc0211508969a100a/raw/80f79c6a6f1e1b5d4485368ef3ddafa5ce853131/generate_cpu.py \ –model-dir /tmp/nanochat \ –prompt ”Tell me about dogs.”
この実行方法はすごく簡単だね！Hugging FaceのREADMEをこれに更新するよ。
ユーザーとアシスタントのターン取得がたまに混乱するのを、僕のGistのフォークで修正したんだ。
https://gist.github.com/samdobson/975c8b095a71bbdf1488987eac…
Simon、macOSで動かすには”brew install git-lfs && cd nano-chat && git lfs install && git lfs pull”が必要だったよ。これで動いた。
僕のHacker NewsでのSimonWについて教えて？っていうプロンプトへのモデルの返答はこんな感じだったよ。”Hacker Newsの記者で、熱血漢でね、ハッキングの世界で許されることの境界をいつも押し広げてるんだ。真実を追求する上で容赦なくて執拗だって評判だよ。(…)”
git lfs installコマンドがHFからモデルウェイトをDLするのに必要だったよ。HFに詳しい人には普通かもだけど、僕は助けられたから共有しとくね！
macOSでuv syncしたら、torch==2.8.0+cu128がmacOSに対応してなくてインストールできないエラーが出たよ。manylinux_2_28_x86_64かwin_amd64用しかないらしい。tool.uv.required-environmentsに自分の環境を追加するといいかもね。
あと、tmp/nanochatはtokenizerとchatsft_checkpointsの中身全部がいるみたい。
うん、macにはCUDAがないからね。
通常のPyTorchパッケージに変えるのはできるけど、MPSで動かすにはコードのパッチ当てが必要になるよ。CUDAカーネルのMPS版がない場合はコードの書き換えもいるかもね。
PyTorchってOSやハードウェアに合わせたバックエンドを自動で選ぶ共通APIとかないの？
それとも、このプロジェクトはCUDA版PyTorchを必須にしてるだけ？
最初のチャートの「Bits per byteはKarpathy曰く、一般的なクロスエントロピー損失よりずっと良い指標で、トークンごとの損失をそのトークンのバイト数で正規化するから、トークナイザに依存しない」ってコメント、すごく当たり前なのに自分のトークナイザを試したときに気づかなかったのが恥ずかしいよ。
自分のトークナイザの性能、また見直してみようかな。
ELI5（5歳児にも分かるように説明してあげるね）：
言語モデルは次のトークンを予測するんだ。どれだけ上手か、損失（実際の答えに驚いた度合い）で測るよ。モデルごとにトークンの長さが違うから、トークン単位の損失で性能を比べるのは難しいんだ。
だから、テキストデータのバイト数に対する損失で比べるといいよ。
なんで1文字1トークンのトークナイザって誰も作らないんだろ？
めちゃくちゃ計算量がいるから？それとも効率が悪くなって、今のトークナイザよりバカになっちゃうのかな？
昔のトークナイザは1文字1トークンだったんだ。その後Googleが初期のニューラル翻訳でSubword encoding[1]を使ったら、それがずっと良いって分かったんだよ。
Subword単位は多くの言語で意味があるんだ。ただ、語彙サイズは調整しないとね。
[1] https://aclanthology.org/P16-1162/
両方イエスだよ。
訓練には絶対もっと長い時間と計算量がいる。訓練後も、各ステップで1トークンしか処理しないから、予測を長いステップの間維持する必要があるんだ。文の早い段階で後のトークンが強く示唆されてても、その情報を中間のトークンを処理する間ずっと維持しないといけないし、各ステップで少しずつ情報は失われちゃう。その情報を使うまでにステップが少ない方が予測は良くなるよ。もし無限に計算量とデータがあるなら、性能は同じになると思うけどね。
OpenAIのトークナイザは1トークンが約4.2文字って言われてるから、提案の「1文字1トークン」だと、実質的なコンテキスト長は一気に4.2倍も短くなるし、同じ出力でも4.2倍遅くなるんだ（同じ結果を得るのに4.2倍のトークンが必要だからね）。
これ、良いトレードオフには見えないな。
Cool。W&Bでこのrepoを動かして訓練するための簡単な“howto”ってある？model training flowsを経験したことないprogrammerなんだけど。君がやったstepを教えてくれると嬉しいな。
大したことないよ…training runを始めるよりcloud machineを立ち上げる方が時間かかったし。時間できたらstep-by-step guideをblog postにするけど、とりあえず僕が実行したcommandはここにあるよ: https://pastebin.com/sdKVy0NR
もっとコメントを表示（2）
あー、WANDB_RUN env varを見落としてたんだ。だからlogsが取れてなかった。ありがとう！
val/bpbとかtrain/lossみたいに指数関数的に減少するmeasuresは、x-axisをlog-scaleにした方がいいよ。そうすればconvergeしてるかどうかがもっとよくわかるから。
ナイスなcallだね、ありがとう。それらのmetricsをlog scaleに切り替えたよ。すごくclearになったのは同感だ。
ごめんfat fingers。x-axisじゃなくてy axisをlog scaleにするべきだった。（sometimes両方いい場合もあるけどね。）top graphでlossが予想より速く下がるinflection pointに気づいた？maybeもっとrunさせた方がいいかも…
このweekend、nanoGPT (https://github.com/karpathy/nanoGPT) に挑戦したんだ。olderだけどfabulousなlearning exerciseで、CPUで~0.8M parametersくらいのshakespeare GPTを作って訓練するんだ。resultsは期待通りでsuckだけど、deep learning professionalじゃなくても、poke aroundしてhack onしたいなら、そのmagicを感じられるよ。nanoGPTを使ったweekendのblog postを書き始めたんだけど、まだdoneじゃないんだ…ここにlinkできたらgreatだったんだけどなlol oh well
それはuseful exerciseだね。良いML workの多くはfirst small scaleでvalidateされるものさ。そしてこのnew exampleはeven further進んでいて、instruction followingやtool use SFT、RLVRも追加している。よりusefulなbaselineになるね。
Absolutely、CPUでtrainしたlittle tiny 0.8M modelのoutputsを読むのはwildly funだよ。一日playing aroundして、今ではtransformer architectureについてmuch betterなunderstandingが得られたしね。このrepoはprobably new folksをspawnしてideasをtry outさせ、それがfieldのnew researchersになるだろうね、no doubt。
shakespeare codeをlittle tuneしてdifferent training dataを与えると、Magic The Gathering commander decksをgood jobでgeneratingできるんだ。
関連することだけど、ちょっと前にnanoGPTベースのMTGカードジェネレーター作ったんだ。1mパラメータにしてはかなり良い結果出すと思うよ。リアルにすごいのは、WotCが毎年数千枚も新しいカードを出すから、俺が何もしなくてもトレーニングデータセットがどんどん増えてモデルが勝手に賢くなることだね。https://github.com/jlwitthuhn/TCGGPT
新しく訓練したモデルが必要で、汎用モデルじゃできないユースケースって何だろうね。特に1MMコンテキストウィンドウがある今だと。面白い課題だ。
これ、もっと詳しく知りたいな。まさに俺がもっと理解を深めるために取り組みたいタイプのプロジェクトだよ。
みんな、これ昔からやってるよ。https://x.com/roborosewaterhttps://bsky.app/profile/roborosewaterm.bsky.social
RLHF／ChatGPTの登場で、テキスト生成はcoherentになったけど、面白みが減ったよね。シュールさを求めるなら、誰も見せてくれない良いもの（ベースモデル）じゃなくて、古い技術に戻るしかないかも。
俺はカスタム Magic カード生成より、LLMを使ってシナジーのあるCommanderデッキを作ることに興味があったんだ。自分で情報を見つけてやれると思うけど、OPがガイドを持ってたらと思ったんだよね。
そういえば、数年前にもAIでMTGカードを生成するっていう人気投稿がHNにあったよ。あれは既存のLLMをファインチューンするアプローチだったと思う。https://news.ycombinator.com/item?id=37427854
特定目的のトイモデルっていいね！コードはどう調整したの？どんなデータセットを使ったの？
彼のシェイクスピアジェネレーターはollamaの後で最初に試したプロジェクトだったな。LLMが何なのか理解するのが目的で。
この一週間くらいLLMにハマってて、ゼロからトレーニングと推論システムをCPU（JAX）とGPU（wgpu-py）の2つのバックエンドで作ろうとしてるんだ。ROCm／PyTorchのナンセンスは嫌だからね。Vulkanが使えるからllama-cppでも使ってるよ。先週両方とも動いたんだけど、GPUバックエンドがバグだらけで。だから今週はバグ修正、WGSLコードのリファクタリング、効率化に取り組んでるんだ。このプロセスでLLMを extensively に使ってるんだけど、マジで目から鱗だよ。いいリファクタリングプロンプトを使えば、一つずつ修正してくれて、astral tyで型チェックされた完全に機能するものができるんだ。
大規模モデルを訓練／サンプリングしたいなら、業界の標準を使えばいい。俺のユースケースは違うんだ。サポートされてるか気にせず、1つのGPUで素早く動かせるものが欲しいんだよ。性能の最後の1ビットを絞り出すことより、利便性に興味があるんだ。
お前、PyTorchのこと全然わかってないじゃん。
何を誤解してるって？ PyTorchは俺のマシンじゃほとんどちゃんとインストールすらできないんだよ。特定のPythonバージョンが必要だし、依存してるツールは全部諦めたわ。llama.cppはVulkanでちゃんとコンパイルできるのに。モデルトレーニングでも同じくらい簡単に動いてほしいんだ。
PyTorchはあんたのユースケースだと、これ以上簡単なものはないよ。特定のPythonバージョンが必要なことすら対応できないなら、ソフトウェア開発で苦労するだけだ。ChatGPTにやり方を聞いてみれば？
俺は25年もこの業界にいるけど、もうこんなことに対処する我慢はないね。Archを手作業でゼロからビルドするなんて二度とごめんだ。PyTorchとROCmも同じ。怪しいフラグなしでGPUを認識させるのが問題だったんだ。llama.cppはVulkanサポートのおかげで、この苦痛を避けられた。PyTorchにはVulkanバックエンドがないみたいだから、俺は自分でwgpu-pyのバックエンドを作ったんだ。
ちなみに、俺もここ数年LLMをいじってるけど、まさに君が指摘する問題のせいで、全部llama.cppベースで作ってるよ。”gem install hairball”みたいなごちゃごちゃした依存関係はもううんざり。依存スタックが浅いのは助かるね。
まあ、そうかもね。でも、PyTorchが提供する多くのメリットを考えたら、そのちょっとした面倒は乗り越える価値があると思うよ。
多分、元コメントの人の問題はPyTorchのROCm版に起因してるんじゃないかな。AMDはまだこれをちゃんとできてないからね。
多分ね。でも、解決策はROCmを避けることであって、PyTorchを避けることじゃないよ。
ROCmを避けるってことは、新しいNVIDIA GPUを買うってことだろ。でも、今持ってるハードウェアを使い続けたい人もいるんだよ。
ROCmに対処するコストは、一般消費者向けNVIDIA GPUのコストより、何桁も高いんだよ。
