Kolibriは、単なる学術的なMoEの実験ではありません。Aleph Alphaは、総パラメータ数の大きさとトークンあたりのアクティブなパラメータ数の少なさを両立する、英語とドイツ語に対応したトランスフォーマーを開発しました。全384個のエキスパートの中から、各トークンを6つのルーティング対象エキスパートと1つの共有エキスパートに振り分けることで、トークンあたりの計算量を約3.46Bパラメータ相当に抑えています。この疎な構造に50ブロックのトランスフォーマー層とハイブリッドアテンション方式を組み合わせることで、最先端の能力を備えながら、従来ならクラウドでの運用を余儀なくされる高密度な計算構成を避けて実行できます。
運用面で重要な鍵となるのが、アテンション設計です。Aleph Alphaは40層のスライディングウィンドウアテンションと10層のフルアテンションを組み合わせ、KVキャッシュの増加を一部のブロックに限定しています。そのため、コンテキスト長に対するメモリ使用量の増加は線形より緩やかになります。その結果、最大1,048,576トークンをネイティブに受け付ける能力を備えると報告されています。法律案件、航空宇宙分野のログ、技術マニュアルなど、長文の推論が必要な企業にとって、検索に大きく依存する高コストな回避策を使わずに、文書一式全体を扱えるセルフホスト型モデルとなります。
導入の観点では、KolibriのFP8チェックポイント（約78GB）とApache-2.0ライセンスが、主権性を確保するためのコスト構造を変えます。Aleph Alphaのドキュメントによると、vLLMを使ってB200/B300/H200の単一カード構成や、H100 SXM5の2カード構成で実行できます。規制対象の企業の多くにとって、オープンウェイトを自社管理のインフラでホストできることは、ベンダーロックインの軽減やデータ所在地に関する規則への準拠の簡素化につながります。ただし、安定したレイテンシーとスループットを実現するには、特に本番環境のリクエスト分布を踏まえたルーティングやエキスパート間の負荷配分について、慎重な設計が必要です。
Kolibriでは、学習方法やトークナイザーの選択も運用上重要です。128kのUniBPE語彙により、一部の最先端トークナイザーと比べてドイツ語のトークン化に伴うオーバーヘッドを抑えられ、学習データもドイツ語コンテンツを重視しています。そのため、ドイツ語を主に扱う企業のワークロードでは、コストや性能の面で測定可能なメリットが得られます。また、極めて長いシーケンスでの事前学習や強化学習ベースの事後学習を含むとされるAleph Alphaの学習工程からは、長時間にわたる推論や、コンテキストが不十分な場合に回答を控える挙動を重視して調整されたモデルであることがうかがえます。