1 ポイント 投稿者 haruneo 1 일 전 | まだコメントはありません。 | WhatsAppで共有

大きなモデルを安く動かす方法はないかと考えていて、CMP 100-210を見つけたので4枚買ってみました。
HBM2が1枚あたり16GBあるので、良さそうに見えました。

ところが、NVIDIAが本気で塞いでいました。

  • Tensor Coreが64倍遅いです(HMMA latency 8→512 cycle)
  • PCIe Gen1 x1で、P2Pもありません
  • CUPTIも塞がれていて、torch.profilerも使えません
  • ダイに焼かれたe-fuseなので、ファームウェアでも解除できません(全部試しました)

そのため、vLLM、llama.cppの標準経路、FA、bnbはどれも使えません。
cuBLAS Tensor Coreを触るものは全部、1/64の速度で動くか落ちます。

64万円分のGPUが机の上で転がっているのがもったいなくて、自分で推論エンジンを書きました。

スロットリングがかからない経路だけを選んで:

  • GEMMはDP4A(int8、17 TFLOP)の自作カーネル
  • attentionは自作FlashAttention + MInference風のblock-sparse
  • GPU間はpinned-hostでhidden state bridge(P2Pがないので)
  • 256K contextは3-bit KV cache(WHT + Lloyd-Max)で17GB → 3.5GB

現在はQwen3.5/3.6 hybrid(GDN + Attention)モデルであれば、27B / 9Bの両方に対応しています。
OpenAI互換API、streaming、tool calls、vision(mmproj)、/no_think も使えます。

ベンチマーク(vs llama.cpp build 8462、同じQ8_0 GGUF、同じハードウェア):

  • 9B 単一GPU prefill: 1.22 ~ 2.99x
  • 27B 3GPU prefill: 1.45 ~ 2.86x
  • genは +30 ~ 50%

率直な制約:

  • MoEは非対応です(dense hybridのみ)
  • A100 / H100があるならvLLMを使ってください。はるかに速いです。
  • DFlashのようなものはコードだけあり、動きません(drafter mismatch)
  • 正式対応はQ8_0のみ

同じ環境に閉じ込められている人たちの助けになればうれしいです。
高校1年生がClaudeを使って作ったエンジンなので、バグやスパゲッティコードが多いかもしれません。
IssueやPR歓迎です!

まだコメントはありません。

まだコメントはありません。