JetBrainsが公開したMellum2という記事を読んで、少し考え込んでいます。
12Bパラメータ規模のMixture-of-Expertsモデルで、1トークンあたりに実際に動かすのは2.5Bだけという設計です。推論速度が同規模モデルの2倍以上出るという話で、しかもApache 2.0ライセンスで使い放題。コードと自然言語の両方を対象にしていて、RAGパイプライン、ルーティング、サブエージェントの中間処理といった用途を想定して作られています。
これを読んで最初に頭をよぎったのは、「これ、社内に置けるのでは」という一点でした。
うちの部門では、AI関連のツール導入が稟議に上がるたびに、情報セキュリティ部門からの指摘が入ります。「社外のAPIにどんなデータが送られているか」「ログは残るのか」「製品設計情報が学習データになるリスクは」。どれも正当な懸念で、否定できません。
昨年、ある生成AIツールを部下25名に展開しようとした際も、最終的にクラウドAPIへの通信要件で稟議が一時停止しました。結局、個人情報や図面データを含む業務には使用しないという条件付きで承認を得ましたが、現場の使い勝手は半分以下になった印象があります。部下からは「結局、コピペして確認してから貼り直す手間が増えた」という声が出て、それはそうだろうと。
Mellum2が面白いのは、「プライベートデプロイ」を正面から用途として掲げているところです。自社サーバーやオンプレミス環境に置けて、外部に一切データが出ない。これなら製品設計情報を含むドキュメントの要約処理や、社内ナレッジを使ったRAG構築にも使える可能性が出てきます。
投資対効果の観点でも、このモデルの構造は説明しやすいです。
フロンティアモデルと呼ばれる大規模な商用APIは、確かに性能が高い。ただし、全業務にその性能が必要かというと、そうでもない。Mellum2が想定しているのはまさにその「中間の処理」です。ルーティング、要約、文脈の整理、プランニングの補助。これらは処理頻度が高いわりに、大きなモデルを毎回呼ぶ必要はない。
自社インフラに軽量な特化モデルを置いて、必要なときだけ大きなモデルに渡す。そういうアーキテクチャを社内に作ることで、ランニングコストを抑えつつ、セキュリティ要件もクリアできる可能性があります。この話は、今期の経営会議でも説明できる形に整理できそうです。
ただ、課題もあります。オープンモデルを自社で運用するということは、インフラ側の設計・維持管理が必要になる。うちの部門には、そこを担えるエンジニアが現時点では一人しかいません。ベンダーに外出しするにしても、どの会社にどこまで任せるかの評価が別途必要になります。ベンダー選定の責任は自分が持つことになるので、ここは慎重に動かないといけない。
今週末、息子が帰省するので夕食を一緒にと思っていますが、その前に月曜の朝一で部下のひとり、技術寄りの担当に声をかけるつもりです。「Mellum2、動作検証できる環境を作れるか調べてほしい」というタスクです。
PoC(概念実証)としてどの程度のサーバースペックが必要か、社内のセキュリティポリシーと照らして何が論点になるか。そこまで出てくれば、情報セキュリティ部門との事前相談にも持ち込めます。稟議に上げる前に根回しをしておくのが、うちの会社では結局一番早い。
オープンモデルを活用した自社デプロイ構成が現実的かどうか、答えはまだ出ていません。ただ、「クラウドAPIに頼り切らない選択肢」を持つこと自体の意味は、以前よりずっと大きくなってきたと感じています。あとは、その選択肢を現場で動かせる体制をどう整えるかです。
12Bパラメータ規模のMixture-of-Expertsモデルで、1トークンあたりに実際に動かすのは2.5Bだけという設計です。推論速度が同規模モデルの2倍以上出るという話で、しかもApache 2.0ライセンスで使い放題。コードと自然言語の両方を対象にしていて、RAGパイプライン、ルーティング、サブエージェントの中間処理といった用途を想定して作られています。
これを読んで最初に頭をよぎったのは、「これ、社内に置けるのでは」という一点でした。
セキュリティ要件との戦い、いつも同じところで詰まる
うちの部門では、AI関連のツール導入が稟議に上がるたびに、情報セキュリティ部門からの指摘が入ります。「社外のAPIにどんなデータが送られているか」「ログは残るのか」「製品設計情報が学習データになるリスクは」。どれも正当な懸念で、否定できません。
昨年、ある生成AIツールを部下25名に展開しようとした際も、最終的にクラウドAPIへの通信要件で稟議が一時停止しました。結局、個人情報や図面データを含む業務には使用しないという条件付きで承認を得ましたが、現場の使い勝手は半分以下になった印象があります。部下からは「結局、コピペして確認してから貼り直す手間が増えた」という声が出て、それはそうだろうと。
Mellum2が面白いのは、「プライベートデプロイ」を正面から用途として掲げているところです。自社サーバーやオンプレミス環境に置けて、外部に一切データが出ない。これなら製品設計情報を含むドキュメントの要約処理や、社内ナレッジを使ったRAG構築にも使える可能性が出てきます。
経営陣への説明で使えるロジック
投資対効果の観点でも、このモデルの構造は説明しやすいです。
フロンティアモデルと呼ばれる大規模な商用APIは、確かに性能が高い。ただし、全業務にその性能が必要かというと、そうでもない。Mellum2が想定しているのはまさにその「中間の処理」です。ルーティング、要約、文脈の整理、プランニングの補助。これらは処理頻度が高いわりに、大きなモデルを毎回呼ぶ必要はない。
自社インフラに軽量な特化モデルを置いて、必要なときだけ大きなモデルに渡す。そういうアーキテクチャを社内に作ることで、ランニングコストを抑えつつ、セキュリティ要件もクリアできる可能性があります。この話は、今期の経営会議でも説明できる形に整理できそうです。
ただ、課題もあります。オープンモデルを自社で運用するということは、インフラ側の設計・維持管理が必要になる。うちの部門には、そこを担えるエンジニアが現時点では一人しかいません。ベンダーに外出しするにしても、どの会社にどこまで任せるかの評価が別途必要になります。ベンダー選定の責任は自分が持つことになるので、ここは慎重に動かないといけない。
まず部下に調べさせてみるところから
今週末、息子が帰省するので夕食を一緒にと思っていますが、その前に月曜の朝一で部下のひとり、技術寄りの担当に声をかけるつもりです。「Mellum2、動作検証できる環境を作れるか調べてほしい」というタスクです。
PoC(概念実証)としてどの程度のサーバースペックが必要か、社内のセキュリティポリシーと照らして何が論点になるか。そこまで出てくれば、情報セキュリティ部門との事前相談にも持ち込めます。稟議に上げる前に根回しをしておくのが、うちの会社では結局一番早い。
オープンモデルを活用した自社デプロイ構成が現実的かどうか、答えはまだ出ていません。ただ、「クラウドAPIに頼り切らない選択肢」を持つこと自体の意味は、以前よりずっと大きくなってきたと感じています。あとは、その選択肢を現場で動かせる体制をどう整えるかです。