Show HN: Spinf-serve – 大量スコアリングと決定のための推論サーバー

spinf-serve

大量の分類と決定推論を1つのGPUで実行。

spinf-serveは、コンテンツを一度読み込み、同じパスでそれに関する多くの質問に回答します。各回答は生成されたテキストではなく、与えられた選択肢に対する確率です。24GBのNVIDIA GPU上で動作し、ホストされているspinfサービスと同じAPIであるOpenAI互換APIを提供します。ライセンスはApache 2.0です。

なぜ存在するのか

私たちは自分たちの仕事のためにこのエンジンを構築しました。それは、何百万ものニュース記事から日々の市場インデックスを読み取り、各記事に対して数十の狭く調整された質問を投げかけるというものです。チャット用に構築されたサービングエンジンは、質問ごとにコンテンツを再読し、一度に1トークンずつ生成するため、その作業は遅く高価でした。spinf-serveは、すべての質問をコンテンツの1回の読み込みのブランチとして配置し、多くのコンテンツを1回のフォワードパスに詰め込みます。大量分類は、それが始まった場所であり、最も得意とする分野です。

同じメカニズムが、現在決定モデルと呼ばれているものです。これは、段落を返すのではなく、固定された回答セット（はい/いいえ、ラベル、レベル）に対する確率を返すモデルです。spinf-serveでは、任意のオープンな指示モデルがこの方法で動作し、専用の決定モデルも同様に実行されます。ホストされているspinf APIはこのエンジンから派生しました。私たちは、人々が自身のハードウェアで実行したいと求めたため、これを公開しています。

これはチャットサーバーではありません。要求されない限り何も生成されず、単一リクエストのレイテンシよりもスループットのために構築されています。

インストールと実行

Linux、24GBのNVIDIA GPUとfp8テンソルコア（Ada、Hopper、Blackwell：RTX 4090 / 5090、L4、L40S、RTX 6000 Ada、H100）、CUDA 13をサポートするドライバー、Python 3.12が必要です。Ampereカードはint8ウェイトで動作します（設定）。

pip install "spinf-serve[server]"
spinf-serve serve spinf/gemma-4-12b-fp8          # 初回起動時にチェックポイントをダウンロードします。ポート8000でサーブします。

または、NVIDIA Container Toolkitがインストールされたイメージを使用します（ボリュームはモデルとコンパイルキャッシュを保持します。イメージ名の後の引数はspinf-serve serveの引数です）：

docker run --gpus all -p 8000:8000 -v spinf-cache:/root/.cache ghcr.io/spinfinc/spinf-serve

その後、クエリを実行します。コンテンツの1回の読み込みから2つの分類と1つの抽出を行います：

curl http://localhost:8000/v1/score \
  -H "Content-Type: application/json" \
  -d '{ 
    "model": "spinf/gemma-4-12b-fp8",
    "messages": [ 
      { "role": "user",
        "content": "Customer support message:\nI was charged twice for September, please refund one of the charges." }
    ],
    "scoring": { 
      "queries": [ 
        { "id": "topic",
          "template": "\n\nTopic (billing, technical, account, shipping, or cancellation):{?}",
          "options": [" billing", " technical", " account", " shipping", " cancellation"] },
        { "id": "refund",
          "template": "\n\nIs the customer asking for a refund?\nAnswer:{?}",
          "options": [" yes", " no"] },
        { "id": "month",
          "template": "\n\nQ: Which month was charged twice?\nA: \"{*}\"" } 
      ]
    }
  }'

スコアリングされた各質問に対して、応答は各オプションの確率と、空のコンテンツでの同じ確率（12Bモデルからの実数）を提供します：

{ "id": "refund", "combinations": [ { "values": {}, "options": [ 
    { "text": " yes", "logprob": -0.90, "p": 0.72, "floor_p": 0.60 },
    { "text": " no",  "logprob": -1.86, "p": 0.28, "floor_p": 0.40 } ],
    "residual": 0.44 } ] }

pはオプション間の確率です。floor_pはコンテンツがない場合の同じ質問の確率なので、p - floor_pはコンテンツが追加した値です（ここではtopicが「 billing」を0.47から0.91に動かしています）。residualはオプション外の単語に割り当てられた確率です。monthについては、応答は最も可能性の高い回答とその確率（「September」が最初）をリストします。APIキーを使用すると、同じボディがapi.spinf.comに対して実行されます。OpenAI SDKは、extra_bodyのscoringブロックを使用して/v1/chat/completions経由で機能します（クイックスタート）。

何が得られるか

• 1回の読み込み、多数の質問。 コンテンツは一度だけ読み込まれます。各質問は同じパスのブランチであり、独自のトークンのみを消費します。プレースホルダーは、1つのテンプレートを質問のグリッドに変換します。
• 閾値を設定できるスコア。 オプションごとの確率、そのフロア値と対数確率。決定は、独自のデータで選択する閾値です（キャリブレーション）。
• 同じ読み込みからの抽出：{*}テキスト、{n}数値、{$}金額を確率付きでデコードするか、生成された自由形式テキストをスロットに挿入します。
• バッチ内の他のものに関わらず同じスコア。 fp8チェックポイントでは、コンテンツのスコアは、単独でも、数千もの他のコンテンツとパックされていても、呼び出し間、日、サーバー間でビット単位で同一です。system_fingerprintは、2つの応答が比較可能でない場合に示します。
• モデルが読み取る画像、音声、ビデオフレームをコンテンツに含めることができます。
• プロンプトパック。 ジョブ（コンテンツモデレーション、トリアージ、商品リスト、レビュー、ブランド、エンターテイメント）用の準備済みで調整済みの質問セット。リクエストで事前ロードされ、名前が付けられます（以下）。
• ホスト型またはセルフホスト型。 クライアントは、ベースURLとキーを変更することで、このサーバーとapi.spinf.comを切り替えます。spinf-clientは両方と通信します。エージェントスキルは、コーディングエージェントにAPI、このサーバー、およびパック形式を教えます。

スピード

RTX 4090 1台でGemma 4 12Bをfp8で測定：約470トークンのWikinews記事24件、それぞれ56の2オプション質問、合計1,344の質問（fixtures/の公開ジョブセット）。HTTP経由でspinf-serveとvLLM 0.26（プレフィックスキャッシュ付き）に送信。スクリプトと完全な結果はbenchmarks/にあります。

vLLMは既にプレフィックスキャッシュを通じて各記事を56の質問間で再利用しています。しかし、1回のフォワードパスでそれらを回答することはできません。1,344のシングルトークンリクエストを実行しますが、spinf-serveは56の質問を1回の読み込みのブランチとして配置し、24の記事を2回の16kトークンパスにパックします。質問数がコンテンツあたりで増えると、その差は拡大します。

実際には、12Bモデルと4090 1台あたり：spinf/moderationパック（106の質問/メッセージ、22カテゴリ）は約1時間あたり20,000件のメッセージをスコアリングします。74の質問をされたニュース記事は、毎秒700件近くの質問で読み取られます。抽出スロットはデコード作業を追加しますが（検索されたスロットはスコアリングの200〜600トークン、生成されたスロットは最大約2,000トークンに相当）、読み込みは共有されます。

プロンプトパック

ジョブはめったに単一の質問ではありません。コンテンツモデレーションは106の質問からなり、それぞれが通常のトラフィックに対して調整され、カテゴリスコアと決定に結合されます。プロンプトパックは、質問、コンテンツがモデルに提示される方法、回答がスコアに変換される方法、スコアが決定に変換される方法を保持する1つのファイルです。サーバーはパックを事前ロードし、リクエストは1つを名前指定します（"packs": [{"id": "spinf/moderation"}]）。これにより、パックのカテゴリと決定が独自の質問と並んで、同じ読み込みから返されます。

公式パックはspinf-promptsにあり、デフォルトでロードされます。サーバーは、--packsで指定された任意のGitHubリポジトリまたはローカルフォルダからパックをロードします。PACKS.mdは、私たちが知っているすべてのパック（私たちのものと他者のもの）をリストしており、issueであなたのパックを追加できます。 フォーマット、リクエストフィールド、ソースについては、docs/prompt-packs.mdを参照してください。

モデル

それぞれが、私たちが量子化および調整したチェックポイントであり、Hugging Face Hubでそのレシピ（quantizations/）とともに公開されています。エンジンは、パリティテスト済みのリビジョンをピン留めします。サポートされているアーキテクチャファミリーの他のHubチェックポイントは、そのパスで実行でき、ロード時に量子化されます。

ドキュメント

docs/：クイックスタート、例、スコアリングAPI、設定、質問の書き方、キャリブレーション、プロンプトパック、FAQ；ガイド（決定モデル、操作可能な確率、少数ショット分類、感情分析、アンケートコーディング、モデレーション、意図ルーティング）；およびエンジンの仕組みに関する技術文書（アーキテクチャ、バッチ不変性、精度、Qwenスタック、抽出）。

ステータス

バージョン0.1。エンジン（スコアリング、抽出、生成、メディア、バッチ不変性、2つのモデルスタック）は完了しており、記録された参照に対してパリティテスト済みです。サーバーはホストサービスとの公開APIを話します。4つのチェックポイントは公開されています。まだ欠けているものはdocs/README.mdにリストされています。

質問、アイデア、バグは、このリポジトリのissuesに送ってください。フォーラムやチャットはなく、どんなに些細なことでも歓迎します。

レイアウト

spinf_serve/には、エンジン（protocol、compiler、packer、scorer、extract、service）、サーブされるモデルのマニフェスト、packsモジュール（純粋なPythonで、クライアントとホストAPIでも使用）、アーキテクチャファミリーごとのモデルスタック（models/）、量子化スキーム（quant/）、HTTPサーバー（server/）、およびspinf-serveコマンドが含まれています。quantizations/には公開されたチェックポイントごとのフォルダ（レシピ、量子化出力、モデルカード）があります。fixtures/には公開されたパリティフィクスチャと参照があります。benchmarks/にはスループット比較があります。コードマップはdocs/ARCHITECTURE.mdにあります。

開発

uv sync --extra server
uv run pytest                                   # CPUテスト（公式パックのゴールデンフィクスチャには ../spinf-prompts または SPINF_PROMPTS_DIR が必要です）
uv run ruff check . && uv run ruff format --check .
CUDA_VISIBLE_DEVICES=0 uv run spinf-serve parity --fixture fixtures/wikinews_20261024.json.gz \
    --reference fixtures/wikinews_20261024.spinf-gemma-4-12b-fp8.json.gz --passes 2

カーネル、コンパイル境界、または量子化スキームに触れるすべての変更は、GPUパリティ実行とともに提供されます。公開された各チェックポイントの記録された参照に対するビット単位で同一な対数確率（fixtures/）。依存関係は正確にピン留めされており、パリティ実行と同時にのみ変更されます。CONTRIBUTING.mdを参照してください。

ライセンスと謝辞

Apache 2.0（LICENSE、NOTICE）。私たちが実行および再量子化するモデル、私たちが構築するプロジェクト、私たちが実装する技術、および私たちがチェックしたデータは、ACKNOWLEDGEMENTS.mdでクレジットされています。

---

オープンウェブを破壊しても悪質なボットは止められない

［画像：クモが巣の中にいるクローズアップ。Valeriia Neganova/Unsplash］

先月下旬、主要メディアアウトレットの300人以上の代表者が連邦議会に集まり、Stealth Bot Prohibition Actを推進しました。彼らは正当な不満を持っていました。ニュースルームは、主にAI開発者からの自動トラフィックの急増に見舞われています。AI開発者は膨大な量のオンラインコンテンツを抽出し、そのコンテンツでトレーニングされた生成AI機能やチャットボットによって、ウェブサイト所有者から参照トラフィックや広告収入を奪う可能性があります。これは、実際の解決策を必要とする現実の問題です。しかし、この法案は悪用的なクロールによって引き起こされる害を直接対象としていません。代わりに、ウェブサイトに自動的にアクセスするすべての人に、その身元と公開情報を収集する目的を開示することを強制することになります。この法案はジャーナリストを保護するどころか、彼らや他の多くの人々がオンラインで情報を収集するために頼っている基本的なツールを脅かしています。

最先端の調査報道は、自動化されたデータ収集に依存しています。2022年、ピューリッツァー賞を受賞したウォール・ストリート・ジャーナルの調査は、12,000人の連邦政府高官の31,000件以上の財務開示を分析し、連邦政府職員のほぼ4分の1が、その機関が規制する産業の株式を取引していたことを明らかにしました。その規模の調査を実施するために、ジャーナルはウェブスクレイピングに依存しました。これは、クローラーとして知られるソフトウェアボットがインターネットを閲覧して情報を収集する自動化されたプロセスです。オープンウェブのこの基本的なツールは現在、「ステルスクローリング」を対象としていると主張する法案によって脅かされていますが、実際には、保存、ジャーナリズム、研究、およびセキュリティを含む正当な公益活動を妨げる可能性があります。

再び、特にAIトレーニングとコンテンツの需要が爆発的に増加するにつれて、攻撃的で大規模なスクレイピングは現実の問題です。それはウェブサイトを圧倒し、コストを増加させ、商業出版社、Wikipedia、図書館、そしてこの原稿の著者の1人が働くインターネットアーカイブを含む、知識を生成・保存する機関を脅かす可能性があります。

問題のあるスクレイピング行為を削減または排除しようとする試みとして、連邦のStealth Bot Prohibition Actやニューヨーク州のStealth Crawler Prohibition Actのような法案が提案されていますが、これらは実際の害に対処せずに、匿名でのスクレイピングに広範な禁止措置を課しています。

両法案は、「ボット」または「クローラー」を、「ウェブサイトまたはその他のインターネットソースを取得、スキャン、インデックス作成、スクレイピング、またはその他の方法でアクセスする」ソフトウェアと定義しています。ボットは、その身元と「ボットの特定の性質と目的」を開示しない場合に「ステルス」と見なされます。連邦法案の下では、FTCは、個人がウェブサイトの「技術的または商業的運用に損害、障害、または負担をかける可能性が合理的に高い」方法でステルスボットを使用したと判断された場合、最大53,000ドルの罰金を科すことができます。この法案は、「合理的にウェブサイトを損なう可能性が高い」とは何かについて、定義や基準を提供していません。カバーされたニュースサイトにのみ適用されるニューヨーク州法案では、発行者は、いかなる損害の証拠も必要とせずに、クローラーの身元を明らかにするための召喚状を取得できます。

クローラーの背後にある身元を知ることは、その行動が有害であるかどうかについて、比較的少ない情報しか提供しません。ニューヨーク州法案の下では、身元を開示してから毎分10,000回ウェブサイトにアクセスする企業は、依然としてサイトに多大な、そしておそらく不当なコストを課しているにもかかわらず、法律を遵守しています。しかし、匿名でクローラーを使用して、潜在的に反競争的な慣行を行うテクノロジー企業を調査するジャーナリストはそうではありません。クロールによる最も社会的に価値のある用途の多くは匿名性を必要とします。クローラーの身元と目的を明らかにすることは、収集される情報の性質そのものを変える可能性があります。研究対象が観察されていること、そして誰によって観察されているかを知っていれば、その行動は変わるでしょう。それが匿名で研究するポイントです。

さらに、すべての自動データ収集が悪用されているわけではなく、すべてがAIのトレーニングに使用されているわけでもありませんが、これらの提案された法案は、責任を恐れて、アーカイブ担当者、研究者、および市民技術者が自動データ収集ツールを使用することを思いとどまらせるリスクがあります。ジャーナリストは、WSJの記事のように、公開記録を分析するためにスクレイピングを使用します。研究者は、オンラインでの差別や偽情報を研究するためにそれを使用します。

インターネットアーカイブのWayback Machineは、1兆ページ以上のウェブページをアーカイブするためにクローラーを使用しており、そうでなければ絶えず変化したり消滅したりするインターネットの歴史的記録を作成しました。そのアーカイブ記録は、何千ものニュース記事の事実的背景、全国の何百もの訴訟の証拠、そして物事がうまくいかなくなったときのバックアップとして役立ってきました。

公共の利益を推進するためにスクレイピングに依存しているのは、アーカイブ担当者だけではありません。障害擁護者は、アクセシビリティの問題を検出するために100万以上のウェブサイトを自動的に評価するためにスクレイピングを使用しています。公衆衛生研究者は、オピオイド流行病や中毒および治療に関する偽情報を追跡するためにスクレイピングを使用しています。連邦政府は、脅威検出のためにスキャンするためにクローラーに依存しており、全国の組織に無料のサイバーセキュリティサービスを提供しています。そして、これらのユーザーの一部にとって、匿名性は彼らの仕事の整合性と安全性のために不可欠です。たとえば、公開されている企業情報や衛星画像ポータルから情報を収集している環境研究者は、調査対象の企業からの報復を恐れる可能性があります。

コンテンツをメールで受け取る。

テクノロジーと民主主義の交差点における問題とアイデアに関するニュースレターにご登録ください。

第一修正は歴史的に、情報を受け取ることに結びついた政府による身元確認要件から私たちを保護してきました。Lamont v. Postmaster General事件では、最高裁判所は、特定の政治出版物を受け取る前に受信者に積極的に身元を確認することを要求する法律を無効にしました。同じ原則がウェブクロールにも適用されます。公開されている情報にアクセスするための条件として人々に身元を確認させることは、情報を受け取る自由を妨げます。

法律が曖昧な言葉を使用する場合、その懸念は高まります。研究者が禁止された方法でクローラーを「展開」することの意味、または「ウェブサイトを合理的に損なう可能性のある」活動が何であるかを容易に理解できない場合、彼らは法律に違反するリスクを避けるためにスクレイピングを控えるかもしれません。

ニューヨーク州知事キャシー・ホークルへの書簡で述べたように、「匿名化は、AI関連のクロールによる技術的および潜在的な経済的損害に実際に対処することなく、オープンウェブの核心を脅かします。」クローラーを匿名解除しても、サーバーへのリクエスト数は減りません。AI製品の構築に使用されたコンテンツの発行者に補償するわけでもありません。そして、ユーザーが情報のためにAIチャットボットに頼る場合に発行者が失う可能性のある参照トラフィックを回復するわけでもありません。

実際、既存の法律は、スクレイピングされたデータの多くの有害な用途に対処するために使用できます。たとえば、プライバシー法は機密データの処理方法を制限できます。著作権法は、侵害的なAI生成出力に対応できます。消費者保護法は、欺瞞的なデータ収集または使用に対処できます。

攻撃的なAIクロールによって提起された特定の問題に対処するために、政策立案者は、ウェブサイトが自動化されたトラフィックをより良く管理するのに役立つ標準化された相互運用可能な技術ソリューションの開発を支援できます。標準化団体であるInternet Engineering Task Forceは、オンラインコンテンツへの機械アクセスを管理するための新しいプロトコルを検討しており、良好なクローラー動作の匿名認証メカニズムを開発しています。政策立案者は、この作業が開発されるのを許容すべきであり、時期尚早に「良い」ボットを損ない、「悪い」ボットがすぐに回避することを学ぶような法的および技術的措置を課すべきではありません。

そして、政策立案者が新しい法律が必要であると結論付ける場合、責任は、過剰なリクエストでサーバーを圧倒する、詐欺を行う、または禁止された目的でデータを収集するなどの識別可能な損害を引き起こす行為に転じるべきです。

AIクロールの広がりは、発行者やウェブサイト運営者にとって、慎重な政策対応を必要とする正当な課題を生み出しました。しかし、政策立案者は、匿名性をそれ自体が悪いものとして扱うことを避けるべきです。オープンウェブは、身元を明らかにしたり、すべてのウェブサイト所有者から事前に許可を求めたりすることなく、公開されている情報にアクセス、分析、および保存する能力に依存しています。

悪用的なクロールを抑制しつつ、健全な情報エコシステムを維持したい政策立案者には、より良い選択肢があり、私たちはそれらを支援することに熱心です。州および連邦レベルの立法者に対し、有害な行為を対象としながら、ジャーナリスト、研究者、アーカイブ担当者、および市民が長年デジタル世界をナビゲートするために使用してきたツールを保護する代替案について、私たちに連絡することを奨励します。