リコーが開発した国内トップクラスの性能を誇る大規模言語モデル(LLM)の技術的特異性と、それを支えるアーキテクチャを解剖する。同モデルは、既存の強力なグローバルベースモデル(Llamaシリーズ等)に対し、日本語に特化した「語彙拡張(Vocabulary Expansion)」と「継続事前学習(Continual Pre-training)」を施し、さらに「モデルマージ(Model Merging)」技術を駆使して120B(1200億パラメータ)規模へとスケールアップさせたものである。
![[リコー120Bモデル]継続事前学習とモデルマージ](https://s.wordpress.com/mshots/v1/https%3A%2F%2Fjp.ricoh.com%2Frelease%2F2026%2F0330_1?w=320&h=180)
![[リコー120Bモデル]継続事前学習とモデルマージ](https://mtoy.work/develop/wp-content/uploads/cocoon-resources/blog-card-cache/09b3bab46ee25157af417ddac1c60762.png)
トークナイザの再構成、マージアルゴリズムの数理的背景、およびHugging Face / vLLMを用いた高速な推論環境の構築手順までを、実践的なコードを交えて徹底的に解説する。
事象の背景と構造
現在のLLM開発において、ゼロから数千億パラメータのモデルを事前学習(Scratch Training)するには、巨額の計算資源(数億円〜数十億円規模のGPUインフラ)と数テラバイト規模の高品質なマルチリンガルコーパスが必要となる。このため、多くの国内プレイヤーはMetaのLlamaやMistral AIのオープンモデルをベースとした微調整(SFT)やRAG(検索拡張生成)を選択せざるを得なかった。
しかし、英語圏中心に設計されたベースモデルをそのまま日本語タスクに適用する場合、以下の構造的ボトルネックが発生する。
- トークナイズ効率の悪さ(Byte-Pair Encodingの限界)
英語に最適化されたトークナイザは、日本語の文字や単語を細切れ(バイト単位)に分割するため、同一テキストに対するトークン数が英語の2〜3倍に膨れ上がる。これは、コンテキストウィンドウ(文脈長)の実質的な縮小と、推論時における計算コスト(KVキャッシュ消費量)の急増を意味する。 - 言語転移(Language Transfer)の不完全性
アライメント調整(SFT/RLHF)のみで日本語に対応させようとすると、モデル内部の知識表現が英語に偏っているため、日本語独特のニュアンス、商習慣、法制度、文化的背景に適合できず、「不自然な直訳調」や「ハルシネーション」が高頻度で発生する。
リコーはこれらの課題を解決するため、ベースモデルの表現能力を維持しつつ、日本語の言語空間を効率的にマージ・拡張するアプローチを採用した。
![[リコー120Bモデル]継続事前学習とモデルマージ](https://mtoy.work/develop/wp-content/uploads/sites/3/2025/08/amazon-bedrock-160x90.jpg)
コアとなる技術的仕組みの解説
1. 語彙拡張(Vocabulary Expansion)とトークナイザの最適化
リコーのモデルは、ベースモデルのトークナイザ(例：Llama-3の128k語彙)に対して、日本語の頻出単語や文字を追加した「拡張トークナイザ」を定義している。
具体的には、元の埋め込み層(Embedding Layer)と出力射影層(LM Head)の次元数を拡張し、追加された日本語トークンに対してのみ、厳選された日本語コーパスを用いて初期学習を行う。これにより、日本語1文字あたりの平均トークン数を劇的に削減し、推論速度の向上とコンテキストウィンドウの有効活用を実現している。
2. 継続事前学習(Continual Pre-training)のデータパイプライン
単なる指示チューニング(SFT)とは異なり、モデル内部の「世界モデル」自体を日本語に適応させるため、大規模な日本語ウェブコーパス、書籍、ニュース、ビジネス文書を用いた継続事前学習を実施している。
この際、既存の英語知識(推論能力や数学的思考力)の喪失(破滅的忘却: Catastrophic Forgetting)を防ぐため、以下の制御が行われる。
- データのブレンド比率(Data Mixing Ratio)の最適化: 日本語コーパスの中に、一定割合の高品質な英語コーパスやコードデータを意図的に混在させて学習を進行する。
- コサイン・アニーリング・スケジューラ: 学習率(Learning Rate)を再設計し、追加学習時の勾配爆発を防ぎつつ、局所最適解からの脱出を図る。
3. モデルマージ(Model Merging)による120Bへのスケールアップ
リコーの120Bモデル群を支えるコア技術が、複数のファインチューニング済みモデルを数理的に融合する「モデルマージ」である。GPUによる再学習を伴わずにパラメータを融合するため、計算コストを極限まで抑えつつ、各モデルの強みを統合できる。
主に以下のアルゴリズムが採用されている。
| マージ手法 | 概要 | 技術的特徴 |
|---|---|---|
| SLERP (Spherical Linear Interpolation) | 球面線形補間を用いて、高次元空間上の重みベクトルを干渉させずに補間する。 | 2つのモデルの重みを、幾何学的歪みを最小限に抑えて統合する。 |
| TIES-Merging | 複数の微調整モデル間で発生するパラメータの干渉(正負の相殺)を解決する。 | 変化量の少ない微小な重みをトリミング(Pruning)し、競合する符号を解消した上でマージする。 |
| DARE (Drop And Rescale) | パラメータの大部分をランダムにドロップアウトさせ、残った重みをスケールアップしてマージする。 | 性能低下を防ぎつつ、複数のタスク特化型モデルを1つに統合可能。 |
これにより、日本語の言語理解能力(JGLUE等で測定)と、ベースモデルが持っていた高度な論理推論能力を極めて高い次元で両立させている。
![[リコー120Bモデル]継続事前学習とモデルマージ](https://mtoy.work/develop/wp-content/uploads/sites/3/2025/08/what_is_token-160x90.jpg)
環境構築と実装手順
ここでは、リコーが公開しているLLMアーキテクチャ(または同等の継続事前学習・マージモデル)をローカル環境またはクラウドインスタンス(A100 / H100推奨、最低でもVRAM 24GB以上のGPU環境)にデプロイし、高速推論エンジンである `vLLM` を用いてサービングする手順を示す。
1. 前提条件と環境構築
CUDA 12.1以上がインストールされたLinux環境を前提とする。
# 仮想環境の作成とアクティベート
python3 -m venv ricoh-llm-env
source ricoh-llm-env/bin/activate
# 必須パッケージのインストール（vLLMおよびHugging Face CLI）
pip install --upgrade pip
pip install vllm==0.4.3 huggingface_hub transformers accelerate2. 推論実行スクリプト(Python)
vLLMの「PagedAttention」を活用し、メモリ効率を最大化しながら高速にテキスト生成を行う最小構成コードである。ここでは、Hugging Faceにホストされているリコーの120Bモデル、または13Bモデル(例: `ricoh-co/Ricoh-Geisha-120b-v1.0` 等の任意の公開リポジトリ)を指定する。
import os
from vllm import LLM, SamplingParams
# Hugging Faceのトークンが必要な場合は環境変数に設定
# os.environ["HF_TOKEN"] = "your_huggingface_token_here"
# モデルIDの指定（環境に応じて13Bや120B、または量子化版AWQ/GPTQを選択）
# ※ここでは検証用に軽量なモデルIDを指定するか、適切なパスに置き換えてください
MODEL_ID = "ricoh-co/Ricoh-Geisha-120b-v1.0"
def main():
# サンプリングパラメータの設定
# 決定論的な出力を得るため、temperatureは低めに設定
sampling_params = SamplingParams(
temperature=0.3,
top_p=0.95,
max_tokens=512,
stop=["<|im_end|>", "<|endoftext|>"]
)
print(f"Loading model: {MODEL_ID}...")
# 120Bモデルをロードする場合、複数GPU（Tensor Parallelism）の指定が必要
# 例: A100 (80GB) × 2枚 or 4枚構成を想定
llm = LLM(
model=MODEL_ID,
tensor_parallel_size=2, # 使用するGPU数に合わせて調整
trust_remote_code=True,
gpu_memory_utilization=0.90, # VRAMの最大使用率
max_model_len=4096 # コンテキスト長の上限
)
# プロンプトテンプレートの定義（ChatMLフォーマットを想定）
prompt = """<|im_start|>system
あなたは誠実で優秀な日本人のアシスタントです。<|im_end|>
<|im_start|>user
リコーが開発したLLMの特徴と、モデルマージ技術のメリットについて簡潔に説明してください。<|im_end|>
<|im_start|>assistant
"""
print("Generating response...")
outputs = llm.generate([prompt], sampling_params)
# 結果の出力
for output in outputs:
prompt = output.prompt
generated_text = output.outputs[0].text
print(f"\n[Generated Text]:\n{generated_text}")
if __name__ == "__main__":
main()3. APIサーバーとしての起動(本番運用向け)
OpenAI互換のAPIサーバーとしてバックエンドに常駐させる場合は、以下のコマンドを実行する。
python3 -m venv.entrypoints.openai.api_server \
--model ricoh-co/Ricoh-Geisha-120b-v1.0 \
--tensor-parallel-size 4 \
--port 8000 \
--host 0.0.0.0これにより、既存のLangChainやLlamaIndex等を用いたRAGシステムへシームレスに組み込むことが可能となる。
今後の影響と論点
1. インフラ・設計への波及効果とコストのトレードオフ
120Bクラスの巨大なモデルを本番運用する場合、最大のボトルネックはVRAM(ビデオメモリ)容量と推論レイテンシである。
FP16(半精度浮動小数点数)で120Bモデルをロードする場合、単純計算で約240GBのVRAMが必要となり、A100 (80GB) が最低でも3〜4枚必要となる。
このため、実用フェーズにおいてはINT4/INT8量子化(AWQ, GPTQ, GGUF)の適用が必須となる。量子化による日本語のニュアンス喪失や、論理推論能力の劣化度合いを厳密に評価(Eval)するパイプラインの構築が、アーキテクトにとって重要なミッションとなる。
2. エンタープライズ領域におけるセキュリティとオンプレミス回帰
リコーが国産LLMに注力する背景には、製造業、金融、医療、官公庁といった「機密情報の外部送信(API経由の送信)が許容されない」エンタープライズ領域の需要がある。
自社専用のプライベートクラウド、あるいはオンプレミスのGPUサーバー上で、このクラスの高性能LLMを自社データでさらに「継続事前学習」または「LoRAファイントレーニング」を施して運用するスタイルが、今後のエンタープライズAIのデファクトスタンダードになる可能性が高い。
3. 今後の技術的論点：継続事前学習の限界
モデルマージは極めてコスト効率の高い手法であるが、ベースモデル間のパラメータ干渉を完全に防ぐことはできない。マージを繰り返すことで、特定のドメイン知識が破壊される「マージの飽和現象」も報告されている。
今後は、MoE(Mixture of Experts)アーキテクチャへの移行や、より動的なルーティング機構を取り入れたマージ手法の確立が、国産LLMのさらなる進化の鍵を握る。
コメント