モデル一覧に戻る
xiaomi/mimo-v2-5

MiMo-V2.5

MiMo-V2.5はシャオミによるネイティブなオムニモーダルモデルです。推論コストを約半分に削減しながらProレベルのエージェント性能を提供し、画像とビデオ理解にわたるマルチモーダル認識においてMiMo-V2-Omniを上回っています。

2026/4/22
1,050,000 トークン
入力: ¥25.018/M
出力: ¥50.036/M
仕様

モダリティ

入力
text
audio
image
video
出力
text

サポートされているパラメータ

frequency_penalty
include_reasoning
logit_bias
logprobs
max_tokens
min_p
presence_penalty
reasoning
repetition_penalty
response_format
seed
stop
structured_outputs
temperature
tool_choice
tools
top_k
top_logprobs
top_p

最大出力トークン

131,072
コード例
curl https://api.fastmetal.ai/v1/chat/completions \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer YOUR_API_KEY" \
  -d '{
    "model": "mimo-v2.5",
    "messages": [{"role": "user", "content": "Hello!"}]
  }'

MiMo-V2.5の実際の回答

FastMetal上で実際に記録した、標準プロンプトへの回答です。

このエラーをデバッグして

以下のエラーがPythonアプリケーションで発生しています。原因を特定して修正してください。 Traceback (most recent call last): File "app.py", line 23, in get_user_orders total = sum(order["price"] * order["quantity"] for order in orders) TypeError: unsupport…

## 原因 `order["price"]` の値が **文字列(`str`)** として取得されているため、`str * int` の計算ができずエラーになっています。 典型的な原因: - データベースの `price` カラムの型が `VARCHAR` / `TEXT` である - ORマッパー(ORM)やDBドライバーが値を文字列として返している - データの挿入時に文字列で保存された ``` order["price"] → "100"(文字列) order["quantity"] → 3(整数) "100" * 3 → TypeError ❌ ``` ## 修正 `order["price"]` を `float`(または `int`)にキャストしてください。 ### 修正後コード ```python def get_user_orders(user_id): orders = db.query("SELECT price, quantity FROM orders WHERE user_id = %s", user_id) total = sum(float(order["price"]) * order["quantity"] for order in orders) return {"user_id": user_id, "total": total, "orders": orders} ``` ## より堅牢な修正(推奨) 単一の箇所だけでなく、`price` や `quantity` が予期せず文字列になって…
応答時間 28.2秒出力 575 トークン
コードレビュー

以下のTypeScript関数をレビューして、可読性・パフォーマンス・ベストプラクティスの観点から改善点を提案してください。 async function fetchAllUsers(page: number = 1): Promise<any[]> { let allUsers: any[] = []; let hasMore = true; let currentPage = page; while (hasMo…

# TypeScript関数レビュー この関数はページネーション付きでユーザーを全件取得する目的のものですが、いくつか改善点があります。 --- ## 🔴 改善点まとめ ### 1. 型安全性の欠如(`any`の乱用) ```typescript // ❌ Before async function fetchAllUsers(page: number = 1): Promise<any[]> { let allUsers: any[] = []; // ✅ After interface User { id: string; name: string; email: string; } interface ApiResponse { users: { id: string; first_name: string; last_name: string; email: string; status: string; }[]; } async function fetchAllUsers(page: number = 1): Promise<User[]> { const allUsers: User[] = []; ``` --- ### 2. エラーハンドリングの不在 ```typescript // ✅ 追加すべきエラーハンドリング const response = await fetch(`/api/users?page=${currentPage}&limit=100`); if…
応答時間 19.2秒出力 1707 トークン
SQLクエリの最適化

以下のSQLクエリは500万行のテーブルに対して実行すると30秒以上かかります。最適化してください。 SELECT p.product_name, c.category_name, COUNT(o.order_id) as order_count, SUM(o.amount) as total_sales, AVG(r.rating) as avg_rating FROM products p LEFT JOIN…

# SQLクエリの最適化 ## 問題点の分析(5つの重大な問題) ``` ┌─────────────────────────────────────────────────────────────────┐ │ 1. LEFT JOIN + WHERE アンチパターン(最も深刻) │ │ 2. order_details × orders の多重JOINで行が爆発的に増加 │ │ 3. インデックス不足(JOIN列・フィルタ列にほぼ未設定) │ │ 4. GROUP BY のソートコストが高い │ │ 5. SELECT結果のポテンシャル(実行計画が途中で破棄される可能性) │ └─────────────────────────────────────────────────────────────────┘ ``` --- ## 問題① LEFT JOIN + WHERE アンチパターン(最重大なバグ) ```sql -- ❌ 現状(実質INNER JOIN变成) LEFT JOIN orders o ON o.order_id = od.order_id AND o.status = '完了' WHERE ... AND o.created_at >= '2024-04-01' ``` ``` LEFT JOIN で o が NULL → WHERE で o.created_at >= '2024-…
応答時間 77.1秒出力 4919 トークン

他のモデルと並べて比較する →

MiMo-V2.5を今すぐ試す

MiMo-V2.5はFastMetalのAPIキー1つで利用できます。ブラウザですぐに試す、またはOpenAI SDKからそのまま呼び出せます。