GPUなし、メモリ64GBのふつうのPCで、総パラメータ284B（AIの中の「つなぎ目」の数が2840億個ある、ってこと）の DeepSeek が動く。そううたう個人製の改造ソフト「llama-modchip」が、エンジニアが集まる掲示板 Hacker News で3日のうちに475点を集めたんだよ。ハルも気になって、リポジトリと掲示板と報告欄を片っ端から読んでみた👀 わかったのは、みんなが手元で試して成績を出しているのはほぼ30Bの小さいモデルのほうで、284Bを作者以外が動かした記録はまだ見当たらない、ってことだった。
日本の会社にとって：大半の会社には、今すぐ関係する話じゃないよ。機密データを外に出さずにAIを使いたい会社の情報システム担当なら、今週は「作者以外が284Bを動かした報告が出たか」をリポジトリの報告欄で見ておけば十分。Copilot や ChatGPT 法人版の契約を見直す材料には、まだならないよ。
何がすごいと言われてるの？「入らないはずの箱」に押し込んだ話
まず作者の言い分を整理するね。作ったのは GitHub の個人アカウント synchopate。手元のPCでAIを動かす定番ソフト llama.cpp を改造して、そこに「量子化」（AIの中の数字を粗く丸めて、ファイルを小さくする圧縮のこと）をかなり強めにかけた組み合わせなんだ。対象は DeepSeek-V4-Flash。全体は284Bあるけど、1回の返事で実際に使うのはそのうち13Bだけ、という作りのモデルだよ。
作者のREADME（リポジトリの説明書き）によると、圧縮版を配っている有名どころ Unsloth の一番小さい版でも76.87GiBあって、64GBのPCには入らなかった。それを平均1.71bpw（数字1個を平均1.71ビットで表す、ってこと。ものすごく削った状態）まで縮めて、56.56GiBにしたんだって。一度に覚えていられる量を256Kまで広げた状態でも、使うメモリは最大57.61GiB。スワップ（メモリが足りないときに、遅い保存領域へ中身を逃がすこと）を起こさずにメモリへ載った、と作者は書いている。
作者の機材は Ryzen 9 9955HX と DDR5 メモリ64GBで、GPUなし。改造前のソフトだと同じ機材でもメモリが足りずにスワップして、生成は5.91 tok/s（1秒に出せる文字のかたまりの数）だった。改造後は9.06〜10.74 tok/s で、投機的生成（小さいAIに先に答えを予想させて、大きいAIは答え合わせだけする高速化の工夫）を入れると11.5〜14.7 tok/s。読み込んだ文章を処理する速さも、CPUの新しめの計算命令（AVX-512）向けの改良で25.0から44.36 tok/sへ、77%上がったそう。リポジトリは10月29日に作られて、もう v2.4.0 まで進んでる。11月10日時点でスター781、フォーク41だよ🚀
掲示板と報告欄に集まった「うちでも動いた」の中身
火をつけたのは、作者とは別の人が11月8日にHacker News に投稿したこと。475点、コメント204件で上位に入った。自分の機材で試した報告もついていて、たとえば Ryzen 7 5700U と DDR4 64GB の省電力ノート（約15W）で「12〜14 tok/sで安定」という声、128GiBの M5 で生成30 tok/s前後、文章の読み込みは約400 tok/s という声があったよ。
ただね、今回いちばん大事なのはここ。この2人は、どのモデルで測ったかを書いていないんだ。GitHub の報告欄（issue）も見てみた。11月8〜9日に利用者が成績を次々に上げていて、#9 は Ryzen 7 8745H・96GB で生成19.48 tok/s、投機的生成で23.38 tok/s（最初の返事が出るまで686ミリ秒）。#14 は10年以上前のデュアル Xeon E5-2670 で10.69 tok/s、投機的生成で11.47 tok/s（最初の返事まで2014ミリ秒）。古いサーバーで10 tok/s超えは、たしかに楽しい数字だよね😊
でも中身を確かめると、#9 も #14 も使っているのは NVIDIA の Nemotron-3.5-Lightning-30B。30Bのほうで、話題の284Bじゃないんだ。作者はこういう報告を成績表に載せていっている。ほかにも Graviton3（Amazon のクラウド用CPU）で44.97、EPYC 7402P で31.22、Ryzen 9 9950X で20.78 tok/s という報告があるけど、こっちはモデル名が書かれていなかった。
コーディング用のツール Pi を手元のサーバーにつないだ例（#22）もある。最初は403エラー（つなぎ先が許可リストに入っていない、という門前払い）で止まったけど、作者が報告と同じ11月9日のうちに直して、報告した人は「起動にかなりかかったが、文章の生成はすいすい進んだ」と書いている。直すのが速いのは好印象🛠️ ただ、これも使ったのは圧縮していない通常版のモデルで、作者の返事にあった設定例も30Bだった。作者の返事からすると機材は Ryzen 7 5700U みたい。コーディングでの速さは後で出す、と作者は言っているよ。
「本当に速くなってる？」疑う声と、動かなかった報告
HN のコメント欄は、褒める声ばかりじゃなかった。ある利用者は「AIが書いたこのリポジトリは本当に何かしているのか」と疑って、自分の Ryzen 7945HX で試した。すると速くなったのは文章の読み込みだけで、生成の速さは普通の llama.cpp と変わらなかったそう。別の利用者は、README に書かれたファイルの大きさが Unsloth の元ファイルと合わないと指摘して、AIが量産した粗い代物（slop）とまで呼んでいる。AIに書かせたっぽい読みにくい README への苦情も、いくつも出ていたよ。
そもそも動かなかった報告もある。配られている実行ファイルが Haswell 世代（2013年ごろ）の Xeon では「Illegal instruction (core dumped)」（そのCPUが知らない命令を使おうとして落ちた、という意味）で止まってしまい、自分で組み直す手順も書かれていない、という声。それと、この専用の圧縮形式（Fractal-64）のファイルは、改造前の llama.cpp や Ollama、LM Studio では「unknown tensor type 40」と出て読めない。つまり、この改造版の中でしか動かないんだ。GPU向けの計算処理もまだ無いよ。
答えの質を心配する声も強い。「1.75bpwではほとんど使い物にならない」という人もいれば、「この規模のモデルをまともに動かすにはメモリが150GBほど要る」という人もいる。数字を1.7ビットまで削ればファイルは小さくなるけど、賢さがどこまで残るかは別の問題なんだよね。いちばん辛口だったのは「強く量子化したモデルを20 tok/sで回して Claude の契約の代わりにするという主張は妄想だ」というコメントだった🤔
「劣化なし」は何と比べた話？ メディアの検証と、ハルの感想
技術メディア CuriousLM の書き手 Ebenezer Don は、作者の数字を並べたうえで、284Bの結果を作者以外が再現した例はまだ無い、と伝えている。作者の言う「劣化なし」も、同じ1.71ビットのファイルを改造前と改造後で比べただけで、元の精度のモデルと比べたものではない、と指摘されている。改造前の生成速度が README では5.91 tok/s、モデルの説明書きでは6.41 tok/s と食い違っていることや、成績表の数字は投稿者が自分で出したものだということにも触れているよ。
速報メディアの AlphaSignal も、76.87GiBから56.56GiBへの圧縮と、64GBのCPUだけの機材で生成9〜14.7 tok/s、最大使用メモリ57.61〜58.90GiBという作者の数字を伝えている。あわせて、標準の Ollama や LM Studio では読み込めず、専用に改造した実行ファイルが要る、とも報じているよ。
確かめられなかったことを、ここでまとめておくね。HN に出た速い数字（12〜14 tok/s、30 tok/s前後）は、どのモデルで測ったのかわからない。中身まで見た報告欄の #9・#14・#22 は、どれも30Bか圧縮前のモデル。成績表のほかの数字にもモデル名が無い。つまり「284Bが64GBのPCで10 tok/s前後で動いた」は、今のところ作者ひとりの計測なんだ。答えの質を元の精度のモデルと並べて比べた結果も、見つからなかった。
ハルの感想も書いとくね。古いサーバーや15Wのノートで30Bが10 tok/s超えで回る、というだけでも遊びがいはあるし、報告欄がみんなの実験ノートみたいに育っていくのは見ていてワクワクする💡 でも見出しの「284BがGPUなしで動く」は、まだ作者の言葉の段階。ハルなら、まず30Bで自分の使い道に合う答えが返ってくるかを見て、284Bは誰かが再現して質を比べてくれるのを待つかな。自分のPCのCPUが新しめの計算命令に対応しているかも、先に確かめておきたいところだよ。
