はてなブックマーク

Preferred Networksの子会社のPreferred Elements(以下PFE)では7月から約1ヶ月の間、1兆 (1T) パラメータ規模のLLMの事前学習について検証を行っていました。今回の記事ではこの取り組みとその結果について紹介します。 この検証は経済産業省が主導する国内の生成AIの開発力を強化するためのプロジェクト「GENIAC（Generative AI Accelerator Challenge）」のもと、NEDO（国立研究開発法人新エネルギー・産業技術総合開発機構）の助成事業に採択され、計算資源の提供支援を受けて実施しました。 超巨大モデル学習の目的 今回の取り組みは、超巨大な (1Tクラスの) DNNモデルを学習できるかを確認することを目的としています。そもそもなぜこの検証をしたのかについての説明から始めようと思います。 LLMの事前学習では、学習に利用したデ

Preferred Networksの子会社のPreferred Elements（以下、PFE）では、2月から1,000億（100B）パラメータ規模のLLM「PLaMo-100B」の開発を行っていました。5月に事前学習部分を終え、以降は後段となる事後学習を行っていました。今回の記事では、後段の事後学習の取り組みを紹介します。 事後学習を終えたPLaMo-100B-Instructの性能は、Jasterという日本語性能評価ベンチマークでGPT-4を超え、日本固有の知識を問うRakuda BenchmarkでもGPT-4の性能を超えることが確認できました。以下のプレスリリースもご覧ください。 PFEが開発する大規模言語モデルPLaMo β版の無料トライアルの申込受付を開始 この「PLaMo-100B」の開発は、日本の生成AI基盤モデル開発力向上を目指す政策GENIACにおいて、国立研究開発法

この記事は、パートタイムエンジニアの川上航さんとLLM応用に取り組んでいるエンジニアの鈴木渓太とリサーチャーの岩澤諄一郎による寄稿です。 概要 既存の大規模言語モデル (LLM) に対して医療ドメインの独自コーパスを用いた finetuning を行い、医療特化の大規模言語モデル Llama3-Preferred-MedSwallow-70B を開発しました。 Llama3-Preferred-MedSwallow-70B は日本医師国家試験において、 GPT-4 を上回る成績を収め、Hugging Face Hub で公開されているモデルの中で最高性能を誇ります。 PFN では医療・ヘルスケアを含む様々な分野での LLM 活用を目指し、引き続き研究開発を進めていきます。 はじめに 大規模言語モデル (Large Language Model, LLM) は医療やヘルスケアの分野で診断補助

Preferred Networks(以下PFN)の子会社のPreferred Elements(以下PFE)では2月より1,000億（100B）パラメータ規模のLLM、「PLaMo-100B」の開発を行ってきました。このPLaMo-100Bの開発に関して、5月に事前学習部分はひと段落したので、今回の記事ではこのモデルの事前学習部分に関して紹介します。 この「PLaMo-100B」の開発は経済産業省が主導する国内の生成AIの開発力を強化するためのプロジェクト「GENIAC（Generative AI Accelerator Challenge）」のもと、NEDO（国立研究開発法人新エネルギー・産業技術総合開発機構）の助成事業に採択され、計算資源の提供支援を受けて実施しました。 PLaMo-100Bの事前学習の概要 学習済みモデルを元に日本語データなどで追加学習を行うLLMは多くの成功を収め

この記事は、金融チームエンジニアの今城(@imos)と金融チームリサーチャーの平野(@_mhirano)による寄稿です。 概要 本稿では、ドメインに特化したLLMの構築の一環として、金融ドメイン特化のLLMの構築の検証を行いました。継続事前学習によるドメイン知識の獲得を模索し、特定のドメイン向けに専用のパラメータ数が多い高性能なLLMを提供を可能にすることを目指します。 実験では、nekomata-14bとPFNで構築した金融に特化したデータセットを用いて、継続事前学習を実施しました。 継続事前学習の結果として、金融ベンチマーク性能が向上することが確認できました。 出力の差としては、Instruction Tuningを施していないため、大きな差は見られないものの、一定の差が見られるケースもありました。 継続事前学習後のモデルは、https://huggingface.co/pfnet/n

上記の結果で重要な点の1つは、Trial数を10倍にした際にRust版 Optuna実装の実行時間は約10倍で済んでいるのに対して、Optunaの実行時間は50-100倍にまで伸びてしまっている点です。この原因はOptunaが提供するいくつかの便利な機能に起因しています。Optunaでは利便性と速度低下のバランスを慎重に判断して開発を進めていますが、多くのユーザーにとっての利便性を追求した結果、一部のユーザーにとってこのような速度低下を招いてしまっているのも事実です。 Rust版 Optuna実装は高速化により重きを置いています。速度に大幅な改善がなければ存在意義がなくなってしまうからです。互換性を重視してOptunaの設計や機能に合わせすぎてしまうと高速化に限界が生じてしまうため、enqueue_trial()のような一部の機能については導入を慎重に判断しています。 “基本的に” 同じA

はじめに ブラックボックス最適化フレームワークOptunaの最新バージョンであるv3.6をリリースしました。今回のリリースには、様々な新機能やリファクタリング、バグ修正が含まれています。このブログではv3.6のハイライトと多くの機能改善についてお伝えします。 TL;DR Wilcoxon Pruner、軽量なガウス過程ベースのSampler、 PED-ANOVA重要度評価器等の様々な新しいアルゴリズムのサポート FrozenTrialの検証ロジックの厳密化、 Dashboardのリファクタリング、 Integrationの移行などOptunaの品質に関わる様々な改善を実施 Wilcoxon Pruner Optuna v3.5以前では、Prunerは典型的な機械学習のハイパーパラメータ最適化を想定して作られていました。そのような問題では、学習曲線を見て悪いパラメータを早期終了することができ

本記事は、2023年夏季インターンシッププログラムで勤務された菱沼秀和さんによる寄稿です。 Introduction 2023年度夏季インターンシップに参加した九州大学大学院 医学専攻 博士課程3年の菱沼 秀和と申します。今回のインターンシップでは、画像セグメンテーションの基盤モデルである Segment Anything Model (SAM) の医用画像に対する応用手法について研究しました。インターンシップ中の取り組みのうち、本記事では特に SAM とその派生モデルの比較や fine-tuning の手法についての結果を紹介します。 Background SAM [1] は2023年4月に Meta 社が発表した画像セグメンテーションのための基盤モデルです。約1100万枚の画像と10億以上のセグメンテーションマスクから学習されており、追加で学習を必要としない zero-shot により

GPT-4が67%という突出したスコアを出しています。Codegen[^3]やStarcoder[^4]などの重みが公開されているモデルは2割から4割程で大きく後れを取っていたのですが、2023年の8月にLlama2[^16]やStarcoder[^4]をチューニングして作成されたWizard[^17], Code Llama[^18]が50%,60%台のスコアを出し、CodeLLMにおいてはチューニングが注目されています。特に、WizardやCode Llamaによってチューニングの中でも指示チューニングがHumanEvalのスコアを伸ばす事が確認されており、指示チューニングとCode LLMの関係が気になるところです。 Code LLMの自然言語指示チューニング CodeLLMが指示チューニングによってなぜスコアを大きく伸ばせるかが気になりました。我々はCodeLLMモデル自体に自然言

本記事は、2023年夏季インターンシッププログラムで勤務された佐々木司温さんによる寄稿です。 目次 概要 背景 先行研究 再現実験 考察&改善案 まとめ おわりに 参考文献 概要 今回のインターンでは、LLM関連の技術領域であるRetrieval Augmented Generation(RAG)について、REPLUG(-LSR)[1]という手法の再現に取り組みました。 最終的にREPLUGについては論文と同様の結果を得ることができましたが、REPLUG-LSRに関しては論文通りの結果とはなりませんでした。実際に取り組んでいる中での難しさ、発見について共有したいと思います。 背景 現在(2023年)LLMが非常に注目されていますが、その活用には様々なハードルがあります。その内の1つとして、ハルシネーション（Hallucination：幻覚）があります。ハルシネーションとは、もっともらしい嘘

本記事は、2023年夏季インターンシッププログラムで勤務された上原祐輝さんによる寄稿です。 背景 商品の購入数予測は重要 近年、小売業界ではDXが進み、多くのビジネスプロセスが効率化されています。その中で、特に購入数予測は企業の競争力を左右する重要な要素となっています。購入数予測とは、過去のデータやトレンドを元に、将来の商品の購入数や需要を予測することを指します。正確な購入数予測は、在庫の無駄を削減し、商品の売り切れリスクを減少させるだけでなく、適切な価格設定を可能にし、利益の最大化に寄与します。 PFNにおいても購入数予測に取り組んでいますが、これまでのモデルでは商品間の需要の食い合いを捉えられていませんでした。そこで、本インターンシップでは需要の食い合いを考慮した商品の購入数予測モデルの開発に取り組みました。 既存モデルの問題点 購入数の予測において、最も基本的なアプローチの一つが各店

ハイパーパラメータ自動最適化フレームワークOptunaの新しいバージョンであるv3.4がリリースされました。今回のリリースには、ユーザーの相対的な評価結果をもとに最適化を行う新機能 “Preferential Optimization” や、ファイル管理機構、Jupyter Lab拡張、VS Code拡張が含まれています。 ✨ハイライト機能 選好に基づく最適化 (Preferential Optimization) 今回のリリースでは、選好に基づく最適化 (Preferential Optimization)が導入されました。この機能は、画像生成や音声合成、自然言語生成タスクのように、生成物の定量的な評価が難しく、人間が主観的な評価をつける必要があるタスクにおいて特に有用です。 Optuna 3.2においてサポートされたHuman-in-the-Loop最適化では、絶対評価のみが可能となっ

はじめに Optunaの新しいバージョン3.4では、新たにJupyter Lab拡張とVS Code拡張が公開・アナウンスされました。これらの拡張機能を利用することで、Optuna DashboardをJupyter LabやVS Code内で起動し、最適化履歴をより手軽に確認できます。 本記事ではこれらの拡張機能がどのように実装されているのか、その仕組みを解説します。Optuna Dashboardの開発に興味を持ってくださっている方に限らず、Jupyter Lab拡張やVS Code拡張を開発しようとしている方のお役に立てば幸いです。 Jupyter Lab拡張の仕組み Optuna Dashboardは次の図に示すように、PythonのBottleフレームワークで書かれたサーバープログラムと、Reactで書かれたシングルページアプリケーションからなります。 このプログラムをJupyt

本記事は、2023年夏季インターンシッププログラムで勤務された竹田悠哉さんによる寄稿です。 はじめに 2023年度のPFN夏季インターンに参加した、東京大学大学院工学系研究科の竹田悠哉と申します。学部では画像生成の研究をしていましたが、技術の社会実装をより俯瞰的に学びたいと思い、現在は技術経営戦略学専攻で教育工学の研究をしています。 インターンでは「機械学習技術の社会実装」をテーマに、LLM（Large Language Model）にドメイン知識を習得させることに取り組みました。様々な設定において、主に英語で学習されたモデルであるLLaMA2に対して日本語のデータでのFine-tuningを行い、LoRAやInstruction Tuning、ドメイン知識の習得に関する知見を得ることができたと思います。本記事では、そこで利用した技術の紹介と、日本語におけるドメイン知識の習得に関する実験、

大規模言語モデル (LLM) は日進月歩で進化しており、日本語の理解能力についても多くの言語モデルがしのぎを削っています。先日PFNからも、日英2言語を併せた能力で世界トップレベルの性能を示す言語モデルPLaMo-13Bを公開*しました。 一方で、LLMを実際のタスクに適用する場合には、事前学習モデルやファインチューニングによる改善もさることながら、プロンプトの違いが性能を大きく左右します。本稿ではプロンプトを自動的にチューニングすることによって、LLMの能力を最大限に引き出し、与えられた課題の精度をどこまで高められるのかを検証します。 * 本稿で解説するプロンプトチューニング技術は、PLaMo-13B公開時の性能評価には用いていません。 プロンプトエンジニアリングについて LLMを使ったチャットシステムでは、ユーザーからの問い合わせ内容を改変してLLMに入力することがあります。例えば、図

本記事は、2023年夏季インターンシッププログラムで勤務された石森大路さんによる寄稿です。 こんにちは。PFN2023 夏季国内インターンシップに参加していた大阪大学3年の石森大路です。私はPFNの機械学習基盤を開発、運用するCluster Servicesチームにおいて、「キャッシュを利⽤した機械学習・深層学習ワークロードの加速」というテーマで課題に取り組みました。 Cluster Servicesチームでは、機械学習データセットをはじめとする大容量データの読み込みを高速化する分散キャッシュシステムを開発しています。キャッシュシステムの細部については次の記事や発表において詳しく説明されていますが、この記事でも改めて簡単に説明します。 深層学習のための分散キャッシュシステム – Preferred Networks Research Development 分散キャッシュシステム on K

Preferred Networksでは、9月28日にPLaMo-13Bという大規模な言語モデル (LLM) を公開しました。公開されている他のモデルと比較して、日英２言語を合わせた能力で世界トップレベルの高い性能を示しています。実際に学習を回すまでの技術開発には自社スーパーコンピューターであるMN-2を利用し、学習はAI橋渡しクラウド（AI Bridging Cloud Infrastructure、ABCI)　の”第一回 大規模言語モデル構築支援プログラム”を利用して行いました。 今後、PLaMo-13Bを基にした事前学習モデルや、指示学習を行ったモデルについても公開を予定しています。 PLaMo-13Bの概要 PLaMo-13Bは約130億個のパラメータからなる言語モデルです。 PLaMo-13Bは日本語・英語の2つの言語のベンチマークタスクで高い性能を示しています。日本で使われるL

私がPFNに入ってから知った、もっとも好きな技術トピックの一つである、MN-Core™向け再計算のご紹介をします。再計算(recomputation、rematerializationやcheckpointingなどのキーワードで呼ばれることもあります)は、その名の通り同じ計算を複数回することで、GPUメモリを節約するために再計算を利用するテクニックは広く知られています。PFNでも、再計算を使ったメモリ節約アルゴリズムに取り組み、実際の事業でフル活用しています。 MN-Core向けの再計算は、消費メモリ削減でなく、高速化を主目的としています。再計算で計算する量が増えるにも関わらず、高速化が達成できるというのが、私がとても面白いと思う点です。カラクリを紹介していきます。 MN-Coreは、DRAMとSRAMの二種類のメモリを持ち、使えるリソースをとにかく演算器に費やしているのが特徴のアクセラ

Preferred Networks 計算基盤担当VPの土井です。 ちょっと最近ばたばたしていて、あまり何をやっているか紹介できていませんでした。その結果「PFNって何やってるの?」と聞かれてなかなかお答えできない。またPFNで計算機をやっているといってもピンとこない、というお話も増えてきました。先日のJANOGに行ったメンバーからも、PFNが何をしているのかイマイチ知られていないと聞いて、冷や汗を流しております。 なので、チーム的に露出に力を入れることにしました。今後blogを、あるいはネタによってはQiitaなども含めて、シリーズ的に書いていければと思います。まずは、土井が担当している計算基盤領域およびその周辺について概観する記事を書かせて頂こうと思います。 端的に言うと、PFNはあまりオンプレインフラのイメージがないかもしれませんが、上から下までかなりがっつりやっていますし、こんな場

エンジニアの上野です。Cluster Servicesチームという、PFNのKubernetesベースの機械学習基盤を開発・運用するチームに所属して、基盤の改善や新機能の開発に務めています。本記事では、深層学習における学習データセット読み込み速度の改善を目指して開発し、現在もKubernetes上で運用中の分散キャッシュシステムを紹介します。 PFNの機械学習基盤については、ブログ「2022年のPFNの機械学習基盤」もご参照ください。 深層学習における学習データセット読み込み 深層学習を高速化するため、深層学習に向いたアクセラレータの開発が日々続けられています。PFNで開発しているMN-Coreシリーズや、NVIDIA社製GPUもそのひとつです。これらのアクセラレータは高速に行列演算を行うことができ、深層学習の1イテレーションにかかる時間を高速化、ひいては深層学習を活用する研究開発全体を加

はじめに PFN では、計算クラスタ MN-2 と MN-3 の運用に Kubernetes を採用しており、3, 4 ヶ月に一度のペースで Kubernetes をアップグレードしています。直近のアップグレードは 2023 年 1 月で、Kubernetes 1.24 から 1.25 に更新しました。 Kubernetes 1.25 ではいくつかの API が削除されましたが、とりわけ影響が大きかったのは PodSecurityPolicy (PSP) の削除でした。PSP は、pod が満たすべきセキュリティポリシを定義し、Pod リソースの定義をそれに適合するよう変更したり、適合しない pod の作成を拒否したりする機能です。しかし、PSP はユーザビリティに大きな問題を抱えており、互換性を保ったままそれを解決するのも難しいという理由から、Kubernetes 1.21 から非推奨に

この記事は、電気情報通信学会会誌に寄稿した解説記事「Optunaで始めるハイパパラメータ最適化」の転載です。この記事のパワーアップ版ともいえる書籍「Optunaによるブラックボックス最適化」が2月21日に出版されます。Optuna開発チームのメンバーが、Optunaについてより詳しく、よりわかりやすく説明し、より豊富な事例を紹介していますので、ぜひ予約して発売日からお読みください！ 出典 柳瀬利彦, Optunaで始めるハイパパラメータ最適化, 電子情報通信学会誌　Vol.104 No.7 pp.728-733 2021年7月 ©電子情報通信学会2021 Abstract 機械学習アルゴリズムの性能を引き出すためには，ハイパパラメータをデータやタスクに応じて適切に調整する必要がある．本稿では，その自動的な調整のためのツールとして，オープンソースのハイパパラメータ最適化フレームワークであるO

PFN では HDFS から Apache Ozone への移行を進めています。Ozone クラスタは順調に社内のプロジェクトで採用が進んでデータが増加しており、これまでの 2 年間は数度にわたってクラスタを拡張しました。ところが、段階的にクラスタを拡張したことでデータノード間でのディスク使用量の不均衡が問題になってきました。例えば、全てのディスクが 8 割埋まっている Ozone クラスタにまったく空のデータノードを追加すると、データ使用量に大きな不均衡が生じます。新規追加した空のサーバにデータを移動することをリバランスといいますが、運用しやすいようにリバランスを実装する方法は自明ではありません。HDFS ではノード単位でディスク使用量を規定の範囲内に均すように移動する Balancer やデータノード内のディスクを同様に移動する Disk Balancer があります。一方で Ozon

本投稿はPFN2022 夏季国内インターンシップに参加された松岡航さんによる寄稿です。 はじめに PFN2022年度夏季インターンシップに参加した法政大学情報科学部ディジタルメディア学科3年の松岡航です。大学では学内のサーバ管理をしています。ネットワークやコンテナ技術に興味があり、今回Cluster ServicesチームというPFNの機械学習基盤を開発・運用するチームのインターンシップに参加しました。 背景 良い深層学習モデルを実現するには、モデルの構造や適切な学習率などを変更した多くの試行を行うことが重要です。1回の学習を高速に完了させることで、効率よくこの探索を行うことができます。高速化の方法の1つとして、複数のプロセスを使って学習することで学習を高速化する分散深層学習という手法があります。例えばデータ並列な分散深層学習では、複数のプロセスにデータを分散させて処理することで、一度に多

本記事は、2022年夏季インターンシッププログラムで勤務された早川知志さんによる寄稿です。 はじめまして。2022年度のPFN夏季インターンに参加した早川知志です。普段はオックスフォード大学で数学（確率論・数値解析）の博士学生をしており、確率測度の離散化やそれにまつわる理論や応用に興味があります。 今回は、大学でやっていることとは趣旨を変えて、深層学習のエンターテインメント応用として二次元キャラクターの学習・生成タスクに取り組みました。 学んだキャラクターのCLIP embeddingを用いた生成例 1. Motivation オリジナルのキャラクターを描くときに角度や表情を微調整するのには途轍もない労力が必要です。筆者はイギリスでのロックダウン以来趣味でイラストや漫画を描こうとすることが増えたのですが、その過程でこのことに気付きました。生成モデルの力を借りて今までに描いたことのない構図で

エンジニアの清水です。PFNでは、計算アクセラレータとしてGPUを採用するMN-2と自社開発のMN-Coreを採用するMN-3をKubernetesクラスタとして運用しており、その中でCNI Pluginを内製開発して使っています。このブログでは、内製CNI Pluginの話を中心にこれまでPFNのKubernetesクラスタのネットワーク部分、特に、CNI Pluginの構成とその変遷について紹介し、また最後に今後の展望についても触れます。 目次 なぜCNI Pluginを内製したのか？ 内製CNI Pluginの特徴 Kubernetesクラスタのネットワーク構成（第1世代） 運用中に見つかった課題 時間が経過すると割り当て可能なVFが無くなる Podの起動直後にCluster IPを使った通信ができない kube-proxyのリソース使用量が増加し続ける Kubernetesクラスタ