NTT大規模言語モデルバックエンド面接体験記：モデルサービング・APIゲートウェイ・高コンカレンシー推論の完全評価
3年のバックエンド経験からLLMバックエンドへの転換、NTT大規模言語モデルの3次面接体験記。Go/Javaマイクロサービス、vLLM/Tritonモデルサービング、APIゲートウェイ設計、高コンカレンシー推論最適化を網羅
背景紹介
まず私の背景から説明します。バックエンド開発として3年の経験があり、主にGoとJavaを使用しています。以前はクラウドコンピューティング企業でマイクロサービスアーキテクチャ関連の仕事をしており、APIゲートウェイやサービスガバナンスなどの領域に携わっていました。昨年、大規模言語モデルが話題になってから、社内でもLLM推論サービスの展開を模索し始め、私はモデルサービングの一部の作業に参加し、vLLMとTriton Inference Serverについて初步的な理解を得ました。その後、NTTの大規模言語モデルバックエンドチームが採用しているのを見て、この方向性には大きな展望があると感じ、履歴書を提出しました。
正直なところ、従来のバックエンドからLLMバックエンドへの転換には少し不安がありました。どちらもバックエンドですが、LLMバックエンドには推論最適化、GPUスケジューリング、モデルサービングなど多くの要素が含まれており、以前のビジネスバックエンドとはかなり異なります。しかし、面接を通じて、マイクロサービスと高コンカレンシーの経験が重視されていることが分かりました。LLMバックエンドの多くの課題は本質的に分散システムの問題なのです。以下、面接プロセスを詳しく説明します。
面接プロセスの振り返り
一次面接：Go/Java + マイクロサービス
一次面接の面接官はシニアバックエンドエンジニアでした。まずプロジェクト経験について話し、その後技術面接が始まりました。最初にGoとJavaの違いについて聞かれ、並行モデル、メモリ管理、パフォーマンス特性のいくつかの次元から比較するよう求められました。GoのgoroutineはJavaのスレッドより軽量で、GCの一時停止時間が短く、高コンカレンシーシナリオに適している一方、Javaはエコシステムがより成熟し、JIT最適化が深く、複雑なビジネスロジックに適していると説明しました。
次にGoのスケジューリングモデルについて深く掘り下げられ、GMPモデルを図で説明するよう求められました。G（goroutine）、M（スレッド）、P（プロセッサ）の関係を描き、work stealingメカニズムとhand offメカニズムについて説明しました。面接官はgoroutineリークのシナリオとトラブルシューティング方法について追及しました。チャネルのブロック、ロック競合、無限ループなどの一般的なシナリオを挙げ、runtime/pprofとtraceを使ったトラブルシューティングについて説明しました。
続いてマイクロサービスアーキテクチャについて聞かれ、高可用性のマイクロサービスシステムを設計するよう求められました。サービス登録・発見（Consul/Nacos）、設定センター、APIゲートウェイ、負荷分散、サーキットブレーカー、分散トレーシングのいくつかの側面から全体アーキテクチャを説明しました。面接官は特にサービス間通信に注目し、gRPCとHTTPの選択について聞きました。gRPCは内部サービス間の高性能通信に適し、HTTPは外部APIの公開に適していると答えました。
また分散トランザクションについても聞かれ、2PC、TCC、Sagaのいくつかのアプローチを比較するよう求められました。2PCは重すぎる、TCCはビジネス侵入性が強いが一貫性は最高、Sagaは長時間トランザクションに適しているが補償メカニズムが必要だと説明しました。面接官はSagaを使って注文決済フローを設計するよう求め、シーケンス図を描き、順方向操作と補償操作の対応関係を説明しました。
最後にシステム設計問題：複数のレート制限戦略（固定ウィンドウ、スライディングウィンドウ、トークンバケット）をサポートするレート制限システムを設計する。Redis + Luaを使ったスライディングウィンドウの分散レート制限実装について説明し、クラスターレベルとインスタンスレベルのレート制限の一貫性問題について議論しました。一次面接は約60分で、かなり包括的でした。
二次面接：モデルサービング + vLLM/Triton
二次面接はモデルサービングチームのリーダーで、この回は明らかにLLM方向に偏っていました。まずモデルサービングのアーキテクチャについて聞かれ、ユーザーリクエストからモデル推論までの完全なパイプラインを描くよう求められました。APIゲートウェイ→リクエストスケジューリング→モデル推論→結果返却のフローを描き、リクエストキューとバッチ処理の重要性を特に強調しました。
次にvLLMについて深く掘り下げられ、PagedAttentionの原理を説明するよう求められました。vLLMのコアイノベーションは、KV Cacheを仮想メモリとして扱い、ページテーブルを使って物理メモリをマッピングすることで、KV CacheのGPUメモリ断片化問題を解決し、より大きなバッチサイズを可能にすることだと説明しました。面接官はContinuous Batchingメカニズムについて追及しました。vLLMは生成プロセス中に新しいリクエストを動的に追加でき、バッチ全体の完了を待つ必要がないため、GPU利用率が大幅に向上すると説明しました。
続いてTriton Inference Serverのアーキテクチャについて聞かれました。マルチフレームワークサポート（TensorRT、PyTorch、ONNX）、動的バッチング、マルチモデルインスタンス管理について説明しました。面接官はvLLMとTritonの適用シナリオの比較を求めました。vLLMはLLM推論専用に最適化されておりPagedAttentionがコアの利点、Tritonはより汎用的で複数のモデルタイプをサポートし、混合デプロイメントシナリオに適していると答えました。
またモデル量子化についても聞かれ、INT8とINT4の量子化原理と精度損失を説明するよう求められました。PTQ（訓練後量子化）とQAT（量子化認識訓練）の違い、LLM量子化のGPTQとAWQアプローチについて説明しました。面接官は量子化が推論パフォーマンスに与える影響について追及しました。INT8推論速度はFP16の約2倍で、メモリ使用量は半分になるが、精度損失は具体的なタスクで評価する必要があると答えました。
最後に実践シナリオ問題：QPSが100から10,000に増加した場合、モデルサービングをどうスケールするか？垂直スケーリング（より大きなGPU、モデル並列性）と水平スケーリング（より多くの推論インスタンス、負荷分散）の2つの次元からソリューションを説明し、リクエストスケジューリング戦略とメモリ管理の重要性を特に強調しました。二次面接は約70分で、最も難しい回でした。
三次面接：APIゲートウェイ + 高コンカレンシー + プロジェクト深掘り
三次面接はテクニカルディレクターで、総合的な評価でした。まずAPIゲートウェイの設計について聞かれ、LLM推論をサポートするAPIゲートウェイを設計するよう求められました。いくつかの重要な設計ポイントを説明しました：リクエストルーティング（モデルタイプごとに異なる推論クラスタにルーティング）、レート制限（ユーザーとモデルの次元ごと）、リクエスト変換（HTTPリクエストをgRPC呼び出しに変換）、ストリーミングレスポンス（SSEでトークンストリームを返す）、監視・アラート（レイテンシ、エラー率、GPU利用率）。
面接官は特にストリーミングレスポンスの実装に注目し、SSEプロトコルとGo実装について詳しく説明するよう求めました。SSEはHTTP長接続に基づいており、サーバーはContent-Type: text/event-streamを使用し、dataフィールドを順次送信すると説明しました。Go実装ではflusherを使って継続的に書き込むことができるが、接続タイムアウトとバックプレッシャー制御に注意が必要です。
次にプロジェクト経験について深く掘り下げられ、履歴書に書いた高コンカレンシー最適化ケースについて聞かれました。以前のAPIサービスでQPSを500から5000に最適化したプロセスを説明しました：まずボトルネックを特定し（データベースのスロークエリとコネクションプール不足）、その後キャッシュの追加（Redis）、SQL最適化、コネクションプールサイズの調整、非同期処理の導入を行いました。面接官はキャッシュ一貫性のアプローチについて追及し、Cache Aside Patternと書き込み時の二重削除戦略について説明しました。
またLLM推論のレイテンシ最適化についても聞かれました。Speculative Decoding（小規模モデルが予測、大規模モデルが検証）、KV Cache最適化、Prefix Cachingなどのアプローチを説明しました。面接官はPrefix Cachingに非常に興味を持ち、共有プレフィックスのキャッシュ再利用メカニズムについて詳しく説明しました。
最後にキャリアプランとチームへの期待について話しました。三次面接は約60分でした。全体的に、面接官は皆非常に実務的で、曖昧な質問はなく、すべての技術ポイントが実装の詳細まで追及されました。
主要質問まとめ
1. GoとJavaの違いは？並行モデル、メモリ管理、パフォーマンス特性で比較
2. GoのGMPスケジューリングモデルを図で説明、work stealingとhand offメカニズム
3. goroutineリークのシナリオとトラブルシューティング方法
4. 高可用性のマイクロサービスシステムを設計する
5. gRPCとHTTPの選択の考慮事項
6. 2PC、TCC、Sagaの分散トランザクションアプローチを比較
7. Sagaを使って注文決済フローを設計する
8. 複数の戦略をサポートするレート制限システムを設計する
9. 完全なモデルサービングパイプラインアーキテクチャを描く
10. vLLMのPagedAttentionの原理を説明する
11. Continuous Batchingメカニズムとは？
12. vLLMとTriton Inference Serverの適用シナリオを比較
13. モデル量子化の原理？PTQとQATの違い？GPTQとAWQ？
14. QPSを100から10,000にスケールするには？
15. LLM推論をサポートするAPIゲートウェイを設計する
16. SSEストリーミングレスポンスのプロトコルとGo実装
17. LLM推論のレイテンシ最適化アプローチ
18. Prefix Cachingのキャッシュ再利用メカニズム
心得とアドバイス
1. マイクロサービスの基礎がベースライン。LLMバックエンドは本質的に分散システムです。マイクロサービス、高コンカレンシー、APIゲートウェイは必須要件です。これらがしっかりしていないと、一次面接を通過するのは困難です。
2. モデルサービングの知識が差別化要因。vLLM、Triton、モデル量子化は必須ではありませんが、明確に説明できれば大きなプラスになります。面接前にvLLMのソースコードとPagedAttention論文を体系的に学習することをお勧めします。
3. システム設計には階層を持たせる。面接のシステム設計問題では、すぐに詳細に入らないでください。全体アーキテクチャから始め、レイヤーごとに深掘りしてください。面接官はシステム思考とアーキテクチャ能力をより重視します。
4. プロジェクト経験を深掘りする。履歴書のすべてのプロジェクトについて、背景、課題、ソリューション、結果、反省を説明できるようにしてください。面接官は様々な角度から追及します。表面的な理解だけでは不利になります。
5. LLM推論の最新動向に注目する。この分野は非常に急速に進化しています。面接で最新の最適化技術（Speculative Decoding、Prefix Cachingなど）に言及すると、技術的感度を示すことができます。
FAQ
Q：従来のバックエンドからLLMバックエンドへの転換は難しいですか？
A：コアとなる分散システムスキルは転用可能ですが、モデルサービングの知識を補う必要があります。vLLM/Tritonの使用法と原理、GPUプログラミングの基礎とモデル推論パイプラインの理解をお勧めします。移行期間は約1-2ヶ月です。
Q：LLMバックエンド面接でアルゴリズム問題は聞かれますか？
A：はい、しかし重点ではありません。一次面接では中程度の難易度のLeetCode問題が1-2問出るかもしれませんが、システム設計とエンジニアリング能力がより重視されます。プロジェクト経験とシステム設計に重点を置いて準備してください。
Q：GPUプログラミングの知識は必要ですか？
A：CUDAを書く必要はありませんが、GPUのメモリ階層、計算モデル、CUDAの基本概念は理解している必要があります。面接ではGPUコードを書くことよりも、GPUを推論最適化にどう活用するかに焦点が当てられます。
Q：NTTのLLMバックエンドチームの技術スタックは何ですか？
A：主にGoとPython、推論フレームワークとしてvLLMと独自フレームワークを使用し、Kubernetesにデプロイし、gRPCでサービス間通信を行っています。GPUクラスタ管理の経験はプラスになります。
Q：面接で分からないことを聞かれたらどうすればいいですか？
A：深い知識がないことは正直に言い、知っていることに基づいて推論してみてください。面接官はすべての答えを知っていることよりも、思考プロセスと学習能力を重視します。