モデル一覧に戻る
Deep Principle
hydrogen-1.0

Hydrogen 1.0

Deep Principle Hydrogen 1.0 - 100万トークンのコンテキスト、テキスト専用

1,000,000 トークン
入力: ¥155.232/M
出力: ¥421.344/M

仕様

モダリティ

入力
text
出力
text

最大出力トークン

131,072

データの取り扱い

プロンプトの保持
不明(確認できていません)
学習への利用
不明(提供元からの申告がありません)

「不明」は「問題なし」ではありません。確認できていない、という意味です。

学習の可否は提供元との条件に基づく申告値です。保持の可否は、このモデルが到達しうる実行先すべてについて上流が公表する一覧から判定しています。いずれも推測は含みません。

コード例

curl https://api.fastmetal.ai/v1/chat/completions \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer YOUR_API_KEY" \
  -d '{
    "model": "hydrogen-1.0",
    "messages": [{"role": "user", "content": "Hello!"}]
  }'

Hydrogen 1.0の実際の回答

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…

## 原因 `orders` テーブルから取得した `price`(または `quantity`)が **数値型ではなく文字列 (`str`)** として返ってきているためです。 DB から文字列で返る典型的なケース: | ケース | 例 | |---|---| | カラムの型がそもそも文字列型 | `price VARCHAR(20)` / `TEXT` に `"1000"` を格納している | | ドライバ/設定の問題 | MySQL Connector の `get_warnings`/変換設定、SQL Server の `decimal`→`str`、一部の ODBC 設定 | | 文字列として入ってしまったデータ | CSV や外部 API から `"1,000"` や `"¥100"` のままINSERTされた | その結果 `order["price"] * order["quantity"]` が「文字列 × 数値」として評価できず `TypeError` になっています。 > 補足: 厳密には Python では `str * int` は例外にならず文字列の反復(`"10" * 3` → `"101010"`)になるため、この traceback は実際には「両方が文字列」あるいは「数値にできない文字列」の可能性が高いです。**どちらにせよ、静かに間違った金額を返すより例外で止まった方がマシ**であり、根本原因は同じ「DB から数値が文字列で返っている」です。 ## 確認方法 まず実際の型と値を見ます: ```python row = db.…
応答時間 59.8秒

コードレビュー

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

# コードレビュー: `fetchAllUsers` 全体的な動作は正しそうですが、**型安全性・エラー処理・終了条件の堅牢性**の3点で重大な問題があります。以下、重要度順に指摘し、最後に改善版を示します。 --- ## 🔴 高重要度 ### 1. 戻り値・レスポンスが `any`(型安全性の欠如) `Promise<any[]>` や `await response.json()` の結果が `any` のため、以下のデメリットがあります。 - 呼び出し側でコンパイラの支援が得られない(タイポや存在しないプロパティアクセスが通る) - `data.users` が `undefined` や非配列だった場合、実行時に **`Cannot read properties of undefined`** でクラッシュ - リファクタリング安全性が著しく低下 **改善:** API レスポンスと返却オブジェクトの型を定義します。 ```ts interface ApiUser { id: number | string; first_name?: string; last_name?: string; email?: string; status?: "active" | "deleted" | "inactive" | string; } interface UsersApiResponse { users: ApiUser[]; total?: number; has_more?: boolean; } export in…
応答時間 62.8秒

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…

# クエリ診断と最適化 ## 結論(先に要点) このクエリの最大の問題は**性能以前に「結果が壊れている」**ことです。`order_details`(1対多)と `reviews`(1対多)を**同じ SELECT 内で横並びに結合**しているため、1商品あたり「注文明細数 × レビュー数」のデカルト積が発生し、 - `COUNT(o.order_id)` … レビュー数分**水増しされる** - `SUM(o.amount)` … レビュー数分**水増しされる** - `AVG(r.rating)` … たまただ正しい値になる(均等に重複するため)が、レビュー0件の商品では NULL という動作になります。この射影爆発の中間行数が、5百万行テーブル相手に30秒以上かかる主因です。 さらに `LEFT JOIN orders o ...` としているのに `WHERE o.created_at >= '...'` でフィルタしているため、**実質 INNER JOIN に戻っています**(`NULL >= 日付` は NULL になり WHERE で落ちる)。 --- ## 1. 問題点の一覧 | # | 問題 | 影響 | |---|---|---| | 1 | `order_details` と `reviews` の二重の 1対多結合によるファンアウト(射影爆発) | **集計値の誤り** + 中間行数の爆発(最大で 数千万〜数億行) | | 2 | `LEFT JOIN orders` に対する `WHERE o.created_at >= ...`…
応答時間 129.5秒

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

よくある質問

Hydrogen 1.0のAPI料金はいくらですか?
FastMetalでは100万トークンあたり入力¥155.23・出力¥421.34(税別)の円建て従量課金です。前払いクレジットから使った分だけ差し引かれ、月額料金やサブスクリプションはありません。
Hydrogen 1.0はOpenAI SDKからそのまま使えますか?
はい。base_url を https://api.fastmetal.ai/v1 に変更し、model に "hydrogen-1.0" を指定するだけで、既存のOpenAI向けコードから呼び出せます。ストリーミング、ツール呼び出し、構造化出力にも対応しています。
Hydrogen 1.0のコンテキスト長はどのくらいですか?
1,000,000トークンです。プロンプトと回答を合わせてこの範囲に収める必要があります。
Hydrogen 1.0を試すには何が必要ですか?
アカウントを作成してクレジットをチャージすると、ブラウザのチャット画面とAPIの両方から利用できます。契約や最低利用額はありません。

Hydrogen 1.0を今すぐ試す

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