NIMを採用するかの議論で必ず挙がるのが「カスタマイズ余地」だ。NVIDIAの公開ドキュメントとNIM CLIの仕様から読み取れる範囲で、実運用に効くカスタマイズパターンを4つ整理する。
LoRAアダプタのホットスワップ
NIMはマルチLoRA推論に対応しており、起動時に`NIM_PEFT_SOURCE`でローカルディレクトリまたはNGCレジストリを指定すると、複数のLoRAアダプタをロードできる。リクエスト時に`model`フィールドで`base-model:lora-adapter-id`の形で指定すれば、同一ベースモデル上で異なるアダプタを同時に推論できる。内部的にはTensorRT-LLMのmulti-LoRA kernelが、バッチ内で異なるアダプタ重みをswapしながらGEMMを実行する方式だ。この仕組みがあるので、顧客別・タスク別の微調整モデルを数百規模で運用しても、GPUインスタンスを分割する必要がない。
PEFTワークフロー統合
HuggingFace PEFT（`peft`ライブラリ）で生成した`adapter_model.safetensors`と`adapter_config.json`を、NIMが期待するディレクトリ配置に置くだけでロード可能なケースが多い。NeMo Frameworkでトレーニングした場合は`.nemo`形式からの変換スクリプトも提供されている。実運用では、MLflow等のモデルレジストリにadapterをアーティファクトとして登録し、CIで`NIM_PEFT_SOURCE`配下に同期するパイプラインを組むのが定石だ。
カスタムトークナイザとシステムプロンプト
NIMコンテナには`tokenizer.json`と`tokenizer_config.json`が同梱されるが、チャットテンプレート（`chat_template`）を組織固有のものに差し替えたい場合は、モデルディレクトリをマウントで上書きする。OpenAI互換APIの`messages`配列からrawプロンプトへの組立ロジックがここに依存するので、社内用の「常時システムプロンプト」を混ぜ込む実装ポイントとしても有効だ。
BYOMとengineの再ビルド
NGCにないモデル（社内で事前学習したLlamaアーキテクチャ派生など）をNIMフォーマットで動かすには、`trtllm-build`でTensorRT-LLM engine planをビルドし、NIMが期待するメタデータを添えてコンテナに同梱する必要がある。ビルド時にbatch size/sequence length/parallelism（TP・PP）を決め打ちするため、プロファイル設計が重要だ。典型的にはシングルGPU向けとTP=2・TP=4のプロファイルを用意し、起動時のGPU数に応じて選択させる。
注意点
LoRAのランク・ターゲットモジュールがベースモデルの対応範囲外だと、ロード時にエラーまたは性能劣化を起こす。対応モジュール一覧はベースごとに異なるので、事前確認が必須。また、量子化済みベースモデル（FP8/INT4）上でのLoRA適用は制約が多いため、重要な変更は再コンパイルも検討したほうが良い。