はじめに Turing では、日々たくさんの自動運転モデルを開発し、これを実車にデプロイして検証する開発サイクルを回しています。実世界でMLモデルによる自動運転システムを成立させるためには、モデル推論のレイテンシが非常にクリティカルな要素になってきます。モデルを高速に推論させるためには、低精度化や量子化、あるいはモデルの構造によってはKV Cacheなど、様々な手法が考えられます。 しかし、色々なアーキテクチャのモデルを大量に開発するTuring において、そのすべてにこうした技術を適用できるソフトウェアスタックを構築することは容易ではありません。今回の記事では、高速化技術を適用する

こんにちは、ソリューションアーキテクトの宇佐美です。 2026年7月15日(水) に開催された「Neuron Community – 2026 Vol.1」の様子をレポートします。このイベントは、2025年3月に立ち上げられた「Neuron Community」の協力のもと開催しました。 今回は、 AWS Summit Japan 2026 開催後ということもあり、AWS Summit Japan の振り返りや、AWS Neuron のアップデート情報が多めの内容となっています。 Neuron Community とは AWS では、機械学習のトレーニングと推論のための高性能で費用対効果の高い機械学習アクセラレータ（ AWS Trainium 、 AWS Inferentia ）、および深層学習と生成 AI ワークロードを実行するために使用される SDK の AWS Neuron を提供しています。「Neuron Community」は、ユーザー間で AWS Trainium / AWS Inferentia / AWS Neuron の知見共有を促進する場として発足しました。 「Neuron Community」は、主に Discord を使用して運営されています。興味を持っていただいた方は、下記の URL から参加してみてください。 AWS Neuron Community (Discord) : https://discord.gg/DUx4g3Z3pq オープニング：Neuron Community の成り立ちとカラクリ社での Trainium 取り組み紹介 中山 智文 氏（カラクリ株式会社 取締役 CPO) 資料：後日公開 オープニングセッションでは、カラクリ株式会社の中山氏より発表していただきました。カラクリ株式会社は、2023年より一貫して AWS Trainium を利用し続けており、Neuron Community の立ち上げにも大きな貢献をしていただいています。この発表では、Neuron Community の始まりについて紹介していただきました。また、カラクリ株式会社の AWS Trainium に関する2つの取り組みについても紹介していただきました。1つ目の取り組みは、Amazon EKS 上に構築された 「Neuron 分散学習プラットフォーム」 です。このプラットフォームを構築することで、インフラ関連の知識が十分ではないメンバーでも分散学習を実行できる環境の整備を進めているそうです。2つ目の取り組みは、AWS Trainium の NKI カーネル開発を促進するための 「カーネル開発エージェント」 です。この AI エージェントにより、NKI カーネル開発をエージェントが自律的に進められるようになるということです。最後に、今後の Neuron Community の活動について、よりオープンな場にしていきたいという発信をしていただきました。 AWS Summit Japan 振り返り① セッションダイジェスト「⼤規模学習から AI エージェントの推論まで ~ コスト効率と性能が両⽴する AWS Trainium の全貌 ~」 澤 亮太 (Amazon Web Services Japan G.K.) 資料： “AI エージェントの推論から⼤規模学習まで” コスト効率と性能が両⽴する AI インフラ ̶ AWS Trainium の全貌 Amazon Web Services Japan G.K. の澤からは、 AWS Summit Japan 2026 の振り返りとして、「”AI エージェントの推論から大規模学習まで” コスト効率と性能が両立する AI インフラ ー AWS Trainium の全貌」のセッションを、15 分のダイジェスト版で紹介しました。このダイジェストでは、AWS Trainium の典型的な使い方として、 “A. コードはそのままで学習コストを下げたい” 、 “B. 性能を最適化したい” 、 “C. 推論コストを固定化したい” の3点に注目して説明しました。 A. では、 Native PyTorch support（ベータ版） を使い、GPU向けPyTorchコードのデバイス指定を cuda から neuron に変更して、AWS Trainium 上で学習を実行する方法を紹介しました。デモでは、GPT-2 の学習スクリプトを実行しました。B. では、 NKI (Neuron Kernel Interface) により AWS Trainium のハードウェア命令セットに直接アクセスして AI カーネルの最適化が可能であることを紹介しました。また、性能最適化とデバッグのワークフローを支援する Neuron Explorer、NKI の開発を AI エージェントで加速するためのオープンソースツールキットの “Neuron Agentic Development” についても紹介し、Neuron Agentic Development のデモを見ていただきました。C. では vLLM on Trainium を使うことで、オープンウェイトモデルをAWS Trainium 上でサービングできます。ここでは、openai/gpt-oss-20b モデルを AWS Trainium 上でサービングするデモを見ていただきました。 AWS Summit Japan 振り返り② ブース展示紹介「⽣成 AI を⽀えるインフラ技術」 赤澤 Toshinobu (Amazon Web Services Japan G.K.) Amazon Web Services Japan G.K. の赤澤からは、 AWS Summit Japan 2026 の振り返りとして、ブース展示「生成AIを支えるインフラ技術」について紹介しました。この展示は、複数のマルチモーダルモデルを Amazon EC2 trn2.48xlarge でサービングする様子を見ていただくもので、マルチモーダルモデルで画像の編集を行います。音声で画像編集の指示をすると Whisper Large v3 で音声認識を行い、Qwen3-VL-8B-Instruct で元になる画像を編集するための指示を生成します。指示は Qwen-Image-Edit-2511 に渡され、画像が編集されます。編集された画像は、Qwen3-VL-8B-Instruct を使って指示通りに編集できているかを講評し、XTTSv2 で音声出力します。この発表では、３匹の子猫のイラストを、4匹に増やすという画像編集の様子を見ていただきました。 また、このデモを実現しているアーキテクチャについての説明も行いました。4つのモデルのtrn2.48xlarge の 64 論理コアへのアロケーションや、モデルのデプロイフローなども説明しています。 AWS Trainium / Inferentia / Neuron SDK 最新アップデート 常世 大史 (Amazon Web Services Japan G.K.) 資料： Neuron Communit 2026 Vol.1 AWS Trainium / Neuron 最新アップデート Amazon Web Services Japan G.K. の常世からは、ちょうどイベント前日にテレビ東京の WBS（ワールドビジネスサテライト）で AI 向けアマゾン独自の半導体開発が特集 されたことに触れ、自身が所属するアマゾン内のチップ開発部隊「アンナプルナラボ」について紹介しました。Anthropic との共同プロジェクト Project Rainier では、これまでに 140 万個超の Trainium 2 および Trainium 3 チップが稼働中であること（WBS 内の特集にて紹介）、 OpenAI が 2GW 規模での Trainium 採用を発表 したこと、また従来のチャットボット型 AI からエージェント型 AI へとシフトする中で、AI チップに加え AWS Graviton プロセッサの重要性が増している点を紹介しました。 Meta が数千万の Graviton コアで Agentic AI をスケールしている事例 にも触れました。 次に、澤のセッションでも紹介された AWS Trainium 向けの SDK「AWS Neuron」のアップデートとして、ライブラリのネイティブ化（Native PyTorch、Native vLLM）の最新状況を紹介しました。 また、7 月 7 日にリリースされた最新の Neuron 2.31 では、性能最適化の要である NKI（Neuron Kernel Interface）と NKI Library に大きなアップデートがあった点、さらに NKI カーネル開発用のエージェントコーディング機能 Neuron Agentic Development によるカーネル自動最適化ループへの注力を紹介し、セッションを締めくくりました。 ※ イベント開催後の 2026年7月20日(月) に vLLM Neuron Beta がパブリックリリースしました！ さいごに 通算3回目の Neuron Community は、カラクリ株式会社での AWS Trainium への取り組みの発表や、AWS Summit Japan 2026 の振り返り、AWS Neuron 関連の最新アップデート情報の紹介と、充実した内容となりました。AWS Summit Japan 2026 のセッション動画は、 AWS Summit Japan の Web ページ に登録いただくことでオンデマンド視聴が可能です。ご興味のある方は、ぜひ登録してみてください。 発表後には今後の Neuron Community についてのディスカッションも行われ、約 1 年ぶりの開催となったことを踏まえ、より高い頻度で開催していこうという声が挙がりました。AWS としても積極的に支援していきます。 今後の Neuron Community も、Discord を中心に募集や告知を行っていきます。興味を持っていただいた方は、ぜひ、下記の URL から参加してみてください。 AWS Neuron Community (Discord) : https://discord.gg/DUx4g3Z3pq 著者について 宇佐美 雅紀 (Usami Masanori) 製造業のお客様を担当するソリューションアーキテクトです。 製造業のお客様のクラウド活用を支援しています。 常世 大史 (Tokoyo Hiroshi) AWS Annapurna Labs のソリューションアーキテクトです。 Annapurna Labs が提供する AWS Trainium、Inferentia の技術支援に注力しています。  

こんにちは。イノベーションセンターの加藤です。先日私たちのLLMベースJSON生成についての論文がニューラルネットワーク分野の国際会議IJCNN2026 1 に採択され、ポスター発表を行いました。本稿ではその発表内容を紹介します。 プレプリントはこちら： https://arxiv.org/abs/2605.13076 IJCNNについて LLMベースJSON生成 既存手法の問題点 提案手法 今後の方向性 IJCNNについて IJCNN（International Joint Conference on Neural Networks）は、ニューラルネットワークをはじめとするAI分野を対象とした主要な国際会議のひとつです。ニューラルネットワークの理論から応用まで幅広いテーマを扱っており、近年は深層学習や大規模言語モデル（LLM: Large Language Model）に関する研究も多く発表されています。 今年のIJCNN2026は、進化計算を扱うIEEE CEC（Congress on Evolutionary Computation）およびファジィシステムを扱うFUZZ-IEEE（International Conference on Fuzzy Systems）と合同で、IEEE WCCI（World Congress on Computational Intelligence） 2 として6月21日から26日にオランダのマーストリヒトで開催されました。 この合同会議は2年に一度開催される計算知能分野の大規模な国際会議であり、分野を横断した活発な議論や交流が行われました。 LLMベースJSON生成 LLMはチャットボットのように人間向けの文章を生成するだけでなく、その出力を外部のプログラムに繋ぎ込むことで、より高度なシステムを構築できます。近年注目されているLLMエージェントは、下図のように複数のLLMやツールを連携させて複雑なタスクを遂行しますが、こうした連携ではLLM同士やLLMとツールの間でやり取りされるデータが機械的に解釈可能である必要があります。 このような用途では、決まったスキーマに従うJSONをLLMに生成させることが定番の方法となっています。JSONはキーと値の対応が明確で、多くのプログラミング言語で標準的に扱えるため、LLMの出力を後段のプログラムに渡す際のインターフェースとして広く使われています。実際、OpenAI 3 やGemini 4 など主要なLLMプロバイダはStructured Outputという名称で指定したスキーマに沿ったJSONを生成するAPIを提供しています。 一方でLLMは元々自然言語でのやり取りを前提にデザインされているので、プロンプトで「JSONのみを出力してください」と指示するだけでは、余計な説明文が混ざったり括弧の対応が崩れたりして、文法的に正しくない出力となることがあります。そこで、プロンプトのような確実性のない手段に頼るのではなく、生成の段階で選択できるトークンの候補を適切に制限することで、出力を必ず目的のフォーマットに従わせる文法制約付き生成（Structured Generation, Grammar Constrained Generation）が用いられています。 一般的な文法制約付き生成では対象とする文法のパーサーを利用します。 各生成ステップにおいて、パーサーはそれまでの途中出力を部分的にパースして次に来ることが許される終端記号を教えてくれます。終端記号とは、文法においてそれ以上分解されない最小の要素のことで、JSONでいえば { や } といった記号や、 true や false のようなキーワードが該当します。パーサーの仕様によっては文字列や数などの記述も終端記号として扱われます。対して、オブジェクト {"key": "value"} や配列 [0,1,2] のように複数の要素から構成される概念を表した記号を非終端記号と呼びます。このようにして提示された終端記号の候補をもとにして有効なLLMトークンを判定します。 より詳細な解説は こちらの記事 をご覧ください。 既存手法の問題点 文法制約付き生成のアルゴリズムはさまざまなものが提案されていますが、既存の手法はどれも停止性が保証されていないという問題があります。 LLMは無限生成を避けるため、あるいは推論コストや応答時間を抑えるために生成するトークン数の上限（ max_new_tokens 5 ）を指定することがほとんどですが、この最大トークン数の指定を文法制約付き生成と併用すると、JSONを閉じきる前に上限トークン数に達してしまったとき途中で切れたJSONが出力されてしまいます。 これは既存手法があくまで文法的に正しい続きのトークンを選択しているにすぎず、最大トークン数に達する前に出力が完成するかどうかは考慮されていないことが原因です。 私たちの論文ではこの問題に対して、文法的な正しさだけでなく将来必要になるトークン数を意識した制約を導入し、最大トークン数に達する前に必ず出力が止まる制約手法を提案しました。 提案手法 上記の問題を解決するために私たちの提案手法が必要とするのは、次に有効な終端記号だけではなく、そこから出力が完成するまでに続き得る終端記号の列です。将来的に必要となるトークン数を見積もるには、この先どのような単語がどれだけ続くのかを把握する必要があるためです。 このような「続きとして有効な記号列」の候補数や探索のための計算量は文法やそれに対応するパーサーの複雑さに依存して変化します。 私たちは有効記号列の計算を効率化するために、JSONの定義をLL(1)文法と呼ばれる形式で記述し、それに対応したパーサーを採用しました。LL(1)パーサーは1つ先の終端記号を参照するだけで内部状態を決定でき、続きうる記号列も一意に決定できます。そうして得られた「あり得る続きの候補」と、あらかじめ前計算しておいた「各記号を実現するのに必要なLLMのトークン数」をもとに、将来必要になるトークン数の最小値を求めることで、最大トークン数に達する前に必ずJSONが完成するように生成を制御します。 実験ではJSON Mode Eval 6 というJSON生成のベンチマークを使い、厳しい最大トークン数制約下では提案手法が常に文法的に正しいJSONを出力することを確認しました。それに加えて内容の正確性という観点では、Beam SearchやMonte Carlo Tree Searchのようなより良い出力を探索する生成手法と組み合わせた場合に、既存手法では効果がなかったのに対し提案手法では精度が向上することを確認しました。 今後の方向性 前述のとおり、提案手法では文法的な正しさは保証できましたが、内容の正確性についてはBeam SearchやMonte Carlo Tree Searchといったサーチ手法を併用する必要がありました。しかし、これらのサーチ手法は計算量の高さが課題です。 ポスター発表ではその課題を改善するための方向性についてのヒントをいくつか得られたので、より頑健な文法制約手法を模索しようと思います。 https://attend.ieee.org/wcci-2026/ijcnn-2026-topics/ ↩ https://attend.ieee.org/wcci-2026/ ↩ https://platform.openai.com/docs/guides/structured-outputs ↩ https://ai.google.dev/gemini-api/docs/structured-output ↩ https://huggingface.co/docs/transformers/ja/main_classes/text_generation#transformers.GenerationConfig.max_new_tokens ↩ https://huggingface.co/datasets/NousResearch/json-mode-eval ↩