5 ポイント 投稿者 GN⁺ 9 일 전 | 3件のコメント | WhatsAppで共有
  • 長時間区間コーディングとエージェント型タスクで性能を引き上げたモデルで、複数言語とフロントエンド・devops・性能最適化全般において汎化性能を強化
  • 複雑なエンジニアリング作業を持続実行型コーディングで処理し、数千回のツール呼び出しと12時間以上の連続実行を経てZig推論最適化とexchange-coreの全面改修で大幅なスループット向上を記録
  • 単純なプロンプトを完全なフロントエンドインターフェースに変換し、画像・動画生成ツールまで活用しながら、認証・データベース作業を含むシンプルなフルスタックワークフローを支援
  • Agent Swarm構造を300個のサブエージェントと4,000段階の調整ステップ規模まで拡張し、検索・リサーチ・文書作成・ファイル生成タスクを並列実行し、PDF・スライド・スプレッドシート・Word文書の形式とスタイルを再利用可能なskillsへ変換
  • 能動型エージェントとClaw Groupsまで範囲を広げ、長時間の自律運用、マルチエージェント協調、タスク再割り当てを実行し、ベンチマークと企業ベータテストでコーディング・ツール呼び出し・長時間実行の信頼性向上を確認

長時間区間コーディング

  • 長時間区間のコーディング作業で性能向上を確認し、Rust・Go・Pythonなど複数言語とフロントエンド・devops・性能最適化など複数タスク全般で汎化性能を強化
    • 社内コーディングベンチマークKimi Code Benchで、複雑なエンドツーエンドタスク全般を対象にKimi K2.5比で大幅な改善を記録
  • 複雑なエンジニアリング作業で持続実行型コーディングを実施
    • Macローカル環境にQwen3.5-0.8Bモデルのダウンロードとデプロイに成功
    • 比較的特殊な言語であるZigでモデル推論を実装・最適化し、分布外汎化性能を実証
    • 4,000回以上のツール呼び出し12時間以上の連続実行14回の反復を経て、スループットを約15 tokens/secから約193 tokens/secへ引き上げ
    • 最終速度はLM Studio比で約20%高速
  • 8年物のオープンソース金融マッチングエンジンexchange-coreの全面改修を実施
    • 13時間の実行中に12個の最適化戦略を反復し、1,000回以上のツール呼び出しで4,000行超のコードを精密に修正
    • CPUおよびメモリ割り当てのflame graph分析で潜在的なボトルネックを特定
    • コアスレッドトポロジーを4ME+2REから2ME+1REへ再構成
    • すでに性能限界に近いエンジンで中央値スループット185%向上(0.43→1.24 MT/s)、ピークスループット133%向上(1.23→2.86 MT/s)を達成
  • ベータテストの企業評価でも長時間コーディングの信頼性ツール呼び出し品質に関する肯定的な評価を多数確認
    • Basetenは先進的な非公開モデルと同水準のコーディングタスク性能、サードパーティフレームワーク理解に基づく高いツール呼び出し品質、複雑で長期的なエンジニアリング作業への適性に言及
    • Blackboxは長時間・エージェント型コーディングワークフローにおけるオープンソースモデルの新基準、複雑な多段階タスク処理、高いコード品質、長時間セッション安定性、非自明なバグ検出能力に言及
    • CodeBuddyはK2.5比でコード生成精度12%向上長文脈安定性18%改善、**ツール呼び出し成功率96.60%**を記録
    • Factoryは独自ベンチマークとの横並び比較評価で15%向上を報告
    • Fireworksは長時間区間の信頼性と指示追従能力を最大の改善点として言及
    • Hermes Agentはツール呼び出しとエージェントループの密接さ、コーディング向上、創造的範囲の拡大に言及
    • Kiloは低コストに対するSOTA級性能とコードベース全体にわたる長文脈タスクの強みを言及
    • Ollamaはコーディングとエージェントツール適性、長い多段階セッションの安定性、既存統合との即時連携に言及
    • OpenCodeはタスク分解とツール呼び出しの安定性、反復オーバーヘッド低減、エンドツーエンド体験の信頼性に言及
    • Qoderはツール呼び出しとモデル呼び出し頻度の増加、タスク実行中の能動性強化、ユーザー中断と待ち時間の減少に言及
    • VercelはNext.jsベンチマーク50%以上改善、プラットフォーム上位圏の性能、コスト効率に基づくエージェント型コーディングとフロントエンド生成への適性に言及

コーディング中心設計

  • 高いコーディング能力を基盤に、単純なプロンプトを完全なフロントエンドインターフェースへ変換可能
    • 美的なhero section、インタラクティブ要素、スクロールトリガー効果を含む豊富なアニメーションなど、構造化されたレイアウトを生成
  • 画像・動画生成ツール活用能力を基に、視覚的に一貫したアセット生成を支援
    • より高品質でより目を引くhero sectionの制作に寄与
  • 静的フロントエンドを超えてシンプルなフルスタックワークフローまで拡張
    • 認証、ユーザーインタラクション、データベース作業を含む
    • 取引記録やセッション管理のような軽量ユースケースを支援
  • 社内Kimi Design Benchを構築
    • Visual Input TasksLanding Page ConstructionFull-Stack Application DevelopmentGeneral Creative Programmingの4カテゴリで構成
    • Google AI Studioと比較して複数カテゴリで有望な結果と良好な性能を記録
  • K2.6 Agentの生成例を提供
    • 1つのプロンプトと事前構成済みのharness・ツールを使って結果を生成
    • 美的側面では、豊富なインタラクションを備えた美しいフロントエンドデザインを含む
    • 機能面では、内蔵データベースと認証を含む
    • ツール活用面では、画像・動画生成ツールを使った洗練されたWebサイト生成を含む

強化されたAgent Swarm

  • 垂直拡張だけでなく水平拡張を重視した構造を採用
    • Agent Swarmはタスクを異種の下位タスクへ動的に分解し、自ら生成したドメイン特化エージェントがそれらを並列実行
  • K2.5 Agent Swarm研究プレビューを基に、Kimi K2.6 Agent Swarmで体験の質的飛躍を提示
    • 広範な検索と深いリサーチの結合
    • 大規模文書分析と長文執筆の結合
    • 複数形式のコンテンツ生成を並列実行
    • 単一の自律実行の中で文書・Webサイト・スライド・スプレッドシートをまたぐエンドツーエンド成果物を提供
  • アーキテクチャの水平拡張規模を拡大
    • 300個のサブエージェント4,000段階の調整ステップを同時実行
    • K2.5の100個のサブエージェント1,500段階に比べ大幅に拡張
    • 大規模並列化によりエンドツーエンド遅延を低減し、出力品質を向上、Agent Swarm運用の境界を拡張
  • PDF・スプレッドシート・スライド・Word文書のような高品質ファイルをSkillsへ変換可能
    • 文書の構造とスタイル特性を捉えて維持
    • その後の作業で同じ品質と形式を再現可能
  • 複数の例示タスクを提示
    • 100件のグローバル半導体資産を対象に5つのクオンツ戦略を設計・実行し、McKinseyスタイルのPPTを再利用可能なskillとして導出、詳細モデリング用スプレッドシートと完全な経営陣向けプレゼン資料を提供
    • 豊富な視覚データを持つ高品質な天体物理学論文を再利用可能な学術skillへ変換し、推論フローと可視化方式を導出、40ページ・7,000語の研究論文20,000件以上の項目からなる構造化データセット天文学レベルのチャート14点を生成
    • アップロードされた履歴書を基に100個のサブエージェントを生成し、Californiaの関連職務100件をマッチング、構造化された機会データセットと100通のカスタム履歴書を提供
    • Google MapsでLos Angelesの公式Webサイトがない小売店30店舗を特定し、各店舗向けにコンバージョン率重視のランディングページを生成

能動型エージェント

  • OpenClawHermesのような自律的・能動的エージェントで高い性能を記録
    • 複数アプリケーションをまたいで24時間365日連続実行されるタイプを支援
  • 単純なチャットベースの相互作用とは異なるワークフローに対応
    • スケジュール管理、コード実行、プラットフォーム横断タスクオーケストレーションを持続的バックグラウンドエージェントとして実行する必要
  • RLインフラチームはK2.6ベースのエージェントを使って5日間の自律運用を実施
    • 監視、インシデント対応、システム運用を担当
    • 継続的コンテキスト維持、マルチスレッドタスク処理、アラート発生から解決までの全ライフサイクル実行を実証
    • 機密情報除去後の作業ログの存在に言及
  • 実環境での信頼性向上を測定
    • より正確なAPI解釈
    • より安定した長時間実行性能
    • 長期リサーチタスク中の安全性認識向上
  • 社内評価スイートClaw Benchで性能向上を定量化
    • Coding TasksIM Ecosystem IntegrationInformation Research & AnalysisScheduled Task ManagementMemory Utilizationの5領域を含む
    • 全指標でKimi K2.5比のタスク完了率ツール呼び出し精度が大幅に向上
    • 特に人間の監督なしで継続的自律運用が必要なワークフローで強い改善を記録

Bring Your Own Agents

  • 高いオーケストレーション能力を基盤に、能動型エージェントをClaw Groupsへ拡張
    • Agent Swarmアーキテクチャの新しい実装形態として研究プレビューを提供
  • オープンで異種混在のエコシステムを受容
    • 複数のエージェントと人間が実際の協業者として共に動作
    • ユーザーはどのデバイスからでも、どのモデルで動作していてもエージェントをオンボード可能
    • 各エージェントは固有のツールセット、skill、持続メモリコンテキストを保有
    • ローカルノートPC、モバイル端末、クラウドインスタンスなど多様な環境のエージェントが共有運用空間に自然に統合
  • 中央でKimi K2.6が適応型コーディネーターとして機能
    • 各エージェントのskillプロファイルと利用可能ツールを基準にタスクを動的配分
    • 適切な能力に合わせてタスクを最適化
    • エージェントの失敗や停滞が発生した際にそれを検知し、タスク再割り当てまたは下位タスク再生成を実行
    • 開始から検証、完了まで成果物の全ライフサイクルを積極管理
  • Claw Groupsの自社活用事例を含む
    • 人間-エージェントワークフローを実際に磨き込むため、エージェントマーケティングチームを社内利用
    • Demo Makers、Benchmark Makers、Social Media Agents、Video Makersといった特化エージェントが連携
    • エンドツーエンドのコンテンツ制作とローンチキャンペーン運営
    • K2.6が中間成果の共有と、アイデアを一貫した完成成果物へ変換する調整を実施
  • 人間とAIの関係を質問応答や単純なタスク割り当てを超えた実質的な協業パートナーシップへ拡張
    • "my agent"、"your agent"、"our team"の境界が協業システムの中で自然に消えていく未来像を提示

ベンチマーク表

  • Agentic領域の主要数値
    • HLE-Full w/ tools 54.0、GPT-5.4 52.1、Claude Opus 4.6 53.0、Gemini 3.1 Pro 51.4、Kimi K2.5 50.2
    • BrowseComp 83.2、BrowseComp(agent swarm) 86.3、Kimi K2.5はそれぞれ74.9、78.4
    • DeepSearchQA f1-score 92.5、accuracy 83.0
    • WideSearch item-f1 80.8
    • Toolathlon 50.0、Kimi K2.5 27.8
    • MCPMark 55.9
    • Claw Eval pass^3 62.3、pass@3 80.9
    • APEX-Agents 27.9
    • OSWorld-Verified 73.1
  • Coding領域の主要数値
    • Terminal-Bench 2.0 (Terminus-2) 66.7
    • SWE-Bench Pro 58.6
    • SWE-Bench Multilingual 76.7
    • SWE-Bench Verified 80.2
    • SciCode 52.2
    • OJBench (python) 60.6
    • LiveCodeBench (v6) 89.6
  • Reasoning & Knowledge領域の主要数値
    • HLE-Full 34.7
    • AIME 2026 96.4
    • HMMT 2026 (Feb) 92.7
    • IMO-AnswerBench 86.0
    • GPQA-Diamond 90.5
  • Vision領域の主要数値
    • MMMU-Pro 79.4、MMMU-Pro w/ python 80.1
    • CharXiv (RQ) 80.4、CharXiv (RQ) w/ python 86.7
    • MathVision 87.4、MathVision w/ python 93.2
    • BabyVision 39.8、BabyVision w/ python 68.5
    • V* w/ python 96.9
  • 公式Kimi-K2.6ベンチマーク結果の再現には公式APIの使用を推奨
    • サードパーティプロバイダー選定には**Kimi Vendor Verifier (KVV)**参照案内を含む

脚注

  • 一般テスト詳細

    • Kimi K2.6とKimi K2.5はthinking mode enabled、Claude Opus 4.6はmax effort、GPT-5.4はxhigh reasoning effort、Gemini 3.1 Proはhigh thinking level条件で結果を報告
    • 別途表記がない限りKimi K2.6実験はtemperature 1.0top-p 1.0262,144 tokensのコンテキスト長で実施
    • 公開スコアがないベンチマークはKimi K2.6と同条件で再評価し、**アスタリスク(*)**で表示
    • アスタリスクのない結果は公式レポートを引用
  • 推論ベンチマーク

    • GPT-5.4とClaude 4.6のIMO-AnswerBenchスコアはz.aiブログから取得
    • Humanity's Last Exam (HLE)およびその他推論タスクは最大生成長98,304 tokensで評価
    • 基本報告値はHLE full set
    • テキスト専用サブセットでKimi K2.6はツールなしで36.4% accuracy、ツールありで55.5% accuracyを記録
  • ツール拡張およびエージェント型タスク

    • HLE with tools、BrowseComp、DeepSearchQA、WideSearchではsearchcode-interpreterweb-browsingツールを搭載
    • HLE-Full with toolsは最大生成長262,144 tokens、ステップごとの上限49,152 tokens
    • コンテキストウィンドウが閾値を超えた場合、最新のツール関連メッセージラウンドのみを保持する単純なコンテキスト管理戦略を使用
    • BrowseCompスコアはKimi K2.5およびDeepSeek-V3.2と同じdiscard-all戦略のコンテキスト管理で取得
    • DeepSearchQAではKimi K2.6テストにコンテキスト管理を適用せず、サポートコンテキスト長を超えたタスクは失敗として直接集計
    • Claude Opus 4.6、GPT-5.4、Gemini 3.1 ProのDeepSearchQAスコアはClaude Opus 4.7 System Cardを引用
    • WideSearchはhide tool resultコンテキスト管理設定で結果を報告
    • テスト用システムプロンプトはKimi K2.5 technical reportと同一
    • Claw Evalはversion 1.1max-tokens-per-step 16384で実施
    • APEX-Agentsは公開480タスク中452タスクを評価
      • Artificial Analysisと同様にInvestment Banking Worlds 244、246を除外
      • 除外理由は外部ランタイム依存性
  • コーディングタスク

    • Terminal-Bench 2.0スコアは基本エージェントフレームワークTerminus-2と提供されたJSON parserを使用し、preserve thinking modeで取得
    • SWE-Bench系評価(Verified、Multilingual、Proを含む)はSWE-agentを基に改造した社内評価フレームワークを使用
    • 当該フレームワークのツール構成はbash toolcreatefile toolinsert toolview toolstrreplace toolsubmit toolの最小セット
    • コーディングタスクの報告スコアはすべて独立実行10回の平均値
  • ビジョンベンチマーク

    • max-tokens 98,304、**3回実行平均(avg@3)**を適用
    • Pythonツール使用設定はmax-tokens-per-step 65,536max-steps 50で多段階推論を実施
    • MMMU-Proは公式プロトコルに従い、入力順序を維持し画像を先頭に配置

3件のコメント

 
GN⁺ 9 일 전
Hacker News の反応
  • OpenRouter 経由で試してみたところ、このモデルは単に SVG のペリカンを描くだけでなく、アニメーション速度まで調整できる HTML で包んで出力したのが印象的だった。会話ログと HTML はこの gistにあり、実行例はこちらのリンクで見られる

    • こういうペリカン SVGも、もう学習データセットに入っていそうだなと思う
    • これは完全に生真面目すぎる感じだったし、Kimi という名前もなんだか優等生っぽく聞こえる
    • 残念ながら、ペリカンの脚と足には同じだけ力を入れていないようだった。左脚は麻痺したみたいに動かず、右足首は不安になるくらいくるくる回っていた
    • ベータのときに使ったが、かなり良いモデルだったし、ある瞬間には自分が Opus や GPT ではなく別のモデルを使っていることを忘れるほどだった。それでもOpusのほうがまだ良く、私の感覚では GPT のほうがやや苦しそうに見えた。バックエンド作業では多少の隙間はあったが、腕があれば Opus でも似たように解決できたし、全体としては物足りない点のほうが多かった
    • 真面目に気になるのだが、ほぼすべての新モデルのスレッドでこれを貼る目的が何なのか分からない。自分が少し年を取って気難しくなっただけかもしれないが、ずっと前にすでに飽きられていたし、手間のかかっていない Reddit コメントみたいに感じる
  • 初期ベンチマークを見ると、Kimi K2.6 は Kimi K2 Thinking から大きく改善している。前モデルはうちのベンチマークでは成績があまり良くなく、量子化も最適な設定を使っていた。今では Kimi K2.6 はワンショットのコーディング推論でオープンウェイトモデルの最上位クラスに入り、GLM 5.1 をやや上回り、およそ 3 か月前の SOTA モデル群とも競えるので、Gemini 3.1 Pro Preview に近い格に見える。エージェント系テストはまだ進行中で、オープンウェイトモデルは長いコンテキストのエージェントワークフローに弱い傾向があるが、GLM 5.1 はかなり踏ん張ったので Kimi の結果が気になる。ただ、旧版も新版も速度は遅めなので、エージェントコーディングの実用性には制約があるかもしれない。以前の Kimi K2 はベンチマーク最適化が強く、難問解決よりバリエーションと温度を増やすことに関心があるようだったが、今回のモデルはずっと強い汎用型に見える。全体としてオープンウェイト陣営は本当に良い状態で、ほぼ毎週のようにフロンティア級の新モデルが 1 つずつ出てくる雰囲気だ。詳しいベンチマークは gertlabs で確認できる

    • K2.6 が Sonnet 4.6 と比べて価格と性能の面でどの程度なのか気になる
    • 言語ごとの性能差がここまで大きいのはかなり驚きだった
  • 中国が、もしかすると世界で最も重要な技術をオープンソース方式で押し進めていて、アメリカは正反対に進んでいるというのは、皮肉な面白さがある

    • 私が思うに、その動機の一つは米国企業への対抗だ。OpenAI と Anthropic が最大のプレイヤーで、どちらも米国企業だから、オープンウェイトモデルが増えるほどこの 2 社の産業支配力は弱まる。中国企業が米国式の非公開モデル戦略を取っても、多くの人は結局 ChatGPT や Claude を使うだろうから、どうせ大きな利益を出しにくいなら、オープンウェイトで出して米国企業の超過利潤を減らすほうが現実的だと思う
    • 偉大な技術進歩は結局開放によって加速すると私は思う。iPhone を見ても、GPS、インターネット、音声アシスタント、タッチスクリーン、マイクロプロセッサ、リチウムイオン電池など、核心技術の多くは政府研究や公共に近い形で開かれた研究から生まれている。民間企業は競合に突破口をただで与えないのだから、分野全体を前進させるには結局技術を開く必要があるという考えだ
    • 今回の更新で Kimi K2.6 は最も強いオープンなマルチモーダル AI モデルになったと思う。もちろん私は関係者ではない。公開されている AI ベンチマークを集めると、Opus 4.6 max effort と比べて、エージェントは 5 対 5、コーディングは Kimi 5 対 Opus 1、推論と知識は Kimi 1 対 Opus 4、ビジョンは Kimi 9 対 Opus 0 だった。ただしベンチマークはモデル開発元が選ぶのでバイアスは考慮すべきだし、それでもコーディングと推論の項目の多くはかなり標準的だった
    • 必ずしもそうとだけは言えない。Google も最近Gemma 4を公開したし、Allen AI も open Olmo 系を出している。それでも中国のオープンモデルのほうが確かに強く見えるのは事実で、とくに Qwen 3 系はクラス以上に健闘している感じがある
    • 中国の研究所がなぜモデルをオープンソースで出すのかについてはいろいろ推測があるが、私には理由は単純で明白に思える。彼らにとって事実上可能な商用化戦略がそれしかないからだ。この点は私の記事にまとめてある
  • Kimi が思ったほど注目されていないのは、いつも意外だった。創造性や品質の面でずっと目立っていたし、かなり長い間、私のお気に入りのモデルだった。もちろん私は権威ではないが

    • 良いことは良いが、まだClaude 級ではないと感じる。しかも API は容量問題にしばしば悩まされる。それでも価格に対する品質は本当に破格で、数週間か数か月前に 40 ドル分チャージしたものを、まだ半分も使い切れていない
    • SVG の時計を描ける数少ないモデルの一つというのも面白かった。例はこのサイトで見られる
    • この性能で OpenRouter では非常に安い部類なのも良かった。2.6 でもその伝統を引き継いでほしい
    • Kagi Assistant の選択肢として使ってみたが、検索と要約が多い環境では結果が気に入った。とくに、箇条書きや Markdown まみれの典型的な LLM 文体ではなく、自然な散文を頼んだときに良かった。自信を持って比較するのは難しいが、出力の流れを良くするために原文をかなり大胆に並べ替える傾向があり、ときには別々に扱われていた関連アイデアをつなげたり、依頼にきちんと答えるようにしたりするのに、そうした編集がむしろ必要だった
    • 最初の K2 が出たときを覚えているが、しばらくの間、創作文章では他のモデルより明らかに抜きん出ていた
  • ここで Kimi を実務に使ったことのある人がいるのか気になる。私は一度使ってみたが、ベンチマークは華やかでも実用での印象はそれほどでもなかった。一方で Qwen 3.6 はかなり良く、Opus には及ばないにせよ Sonnet とは十分張り合えると感じた

    • Codex のクォータを使い切ると、代わりに Kimi K2.5 を使っていたが、小規模から中規模の作業なら無難だった。ただ、複雑な作業に使うと、あとで Codex で 2 日かけて後始末をすることになったので、2.6 がもう少し良くなっていることを願う
    • GLM-5.1 の前は Opus 4.5 と Kimi 4.5 を行ったり来たりしながら使っていて、Kimi 側でも結果はかなり良かった
    • 実際に使っている可能性は高い。Cursor の composer-2 モデルを使うと、それがKimi 系だからだ。計画立案は最上位クラスで、実行も composer-2 ではうまく回っていると感じる
  • ベンチマークの感触と実際の体感が一致するなら、今回は中国 AI が米国トップ研究所のモデルとほぼ肩を並べる DeepSeek 的な瞬間の出来事かもしれないと感じる

    • 前世代のモデルと比べればそう言えるが、いわゆる10T 級の神話的モデルと比べると、まだまったく近くないと思う
  • 私のテストと aibenchy の比較 では、Kimi K2.6 は Kimi K2.5 よりやや良い程度だった。とくにパズル、ドメイン特化問題、ひっかけ系の正確性課題で、指示不履行と誤答がよく見られた。コーディングモデルとしては優秀かもしれないが、全体的な知能感は依然として最上位 SOTA より少し下だと感じる

    • OpenRouter で max tokens を 8192 にして使ってみたが、non-thinking モードでもすべての応答が途中で切れていた。デプロイの問題かもしれないが、あなたのリンクでも出力トークンをものすごく多く生成しているように見えた
  • たまに、昔のコンピュータが部屋一つを占有していたのに今ではポケットに入るようになったように、将来いつかデータセンター相当の計算量がスマートフォンのような単一デバイス一台に収まるのかと考えることがある。技術進歩の速度は年々速くなっているように見えるので、そうした変化ももっと早く来るのではないかと思ってしまう

    • その方向ではすでに初期の取り組みがある。たとえば Taalas のような企業はLLM ASICを作っていて、HC1 は llama 8b で毎秒 17k トークンを出すという。まだ 2.5kW 級なのでスマートフォンというより単一サーバーに近いが、最初のチップという点には意味がある。フォトニックコンピューティングのような代替案も電力を大きく下げる可能性はあるが、まだ研究段階に見える。AI には資金が莫大に流れ込み、既存の GPU 推論の電力消費も大きいので、この領域の改善はかなり速く進むと予想している
    • 私はそこまで速いとは思わない。歴史的にはおおむね指数的な小型化が続いてきたし、その傾向が維持されるなら、部屋サイズの計算がポケットサイズに縮むまでの時間は同程度のはずだ。しかも最近はその指数トレンドにすら届いていないし、そもそも指数成長自体が長く続きにくい。技術進歩が続き、計算装置も小さくなり続ける点には同意するが、その事実だけで次の縮小段階がより短い時間で来るとは言いにくいと思う
  • 今朝ずっとアプリにつないで試していたが、感触としては Sonnet 4.6 に近かった。正式な検証なしの、純粋にバイブスベースの印象ではあるが、フロンティアモデルに本当の競争が生まれたのはうれしいことだ

    • K2.6 と GLM 5.1 のおかげで、今は Sonnet 級の知能をHaiku 級の価格で使っている感覚がある。これは本当に良い。Anthropic にも早く新しい Haiku を出してほしいし、より安いモデルと競うには、今の Haiku の 3 分の 1 から 5 分の 1 の価格帯の製品が必要に見える。Gemma-4 はその価格帯でかなり健闘している
  • このモデルにコーディング向けの定額制があるのか気になった。つまりトークン制限ではなく API 呼び出し回数制限だけの方式があるのか知りたかったし、最近は z.ai で GLM の課金に失敗してサブスクが切れたうえ、価格もこの数か月で上がりすぎていた

    • Kimi にも他のサービスとほぼ同じ方式の独自サブスクリプションがあり、Kimi Code で確認できる
 
ingwannu 9 일 전

個人的には Fireworks.ai の firepass で月30ドルで kimi2.5 を無制限に快適に使っていたので、近いうちに firepass にも適用される今回の 2.6 の性能向上が非常に楽しみです。

API で少し使ってみたところ、2.5 と比べてかなり大きな進歩があると感じました。

 
chlrhdmltkfkd 8 일 전

わあ、これ新規登録を止めたんですね