ollamaでdeepseekを動作させる

最近何かと話題になるDeepseekのモデルがollamaでも実行できると聞き、試してみました。

環境

　Windows 11 Home
　　LLMサーバ　Ollama　version 0.5.4
　　GPU　RTX4060　VRAM(8GB)
　　WebUI（dockerで実行）

準備

ダウンロード可能なDeepseek関係モデルはこちら
Ollama　Deepseek関連モデル検索結果

　本日時点で一番新しいモデルは
　　deepseek-v3　671b　
ですが、推奨VRAMを確認したところ640GB…　無理ですね。

　グラフィックボードの価格が高騰しているので、現時点では個人で１４ｂ以上のモデルを使うのは難しそうです。（私は無理です）

deepseekモデルのダウンロード　

WebUI上のモデル検索に
　　deepseek-r1
と入力したところ、ダウンロードが始まりました。
　ダウンロード時間は計測していませんが、体感では１０～１５分位といった感じでした。

ダウンロード後、一度ブラウザを立ち上げなおしたところ、deepseekモデルが使えるようになりました。

簡単な質問をしたところ、deepseekモデルが作動していることがわかります。
確認したところ、deepseek-r1 7.6b　モデルが作動していました。

実験

それぞれのモデルに同じ問題を行い、回答を比較しました。

１問目　雪はどうして白いの？

llama 3.2の回答

雪は白い色になる理由を知りたいですか？
snow は、氷晶の構造によって白い色になります。snow の水分子間には空間があって、光線が伝わるときにはその空間に放出されるものとして表現できます
この空間は、光線が反射するような形にあり、これが雪が白い色になる原因
また、光線を表す光学的量を「インドックス（n）」と呼びます。このインドックスは、物体の特性によって決まります。水分子のインドックスは約1.3です。したがって、光線はsnowに当たるとき、インドックスが小さいため光線が反射され、白い色になりsnow が白くなるのは、光線が反射することで、気温によって変化するインドックスの原因です
また、気象学者によると、snow の白さはもともとは気温によるものです。寒い気候では、水分子が凝縮し、空間はあまりなく、その結果、光線は反射されることになります
このため、寒い気候で雪がより白くなりますが、暑い気候の雪は、温度上昇によってインドックスの増加、光線の吸収により、色が変わります
これらの要因によってsnow の白さが変わることはありますが、基本的には snow が白くなるのは、光線を反射するためにあって、そのためです。

gemma2の回答

雪が白いのは、光の反射 때문

雪の氷晶は六角形の構造をしていて、その表面にはたくさんの小さな凹凸があります。これらの凹凸に光が入ると、いろんな方向に反射されてしまいます。そして、私たちが目にする色は、様々な方向から反射された光の組み合わせなんです。
白は色々な色を含んだ光を混ぜ合わせた色だから、雪がいろいろな角度に光を反射することで白く見えるのです！ 🌈
簡単に言うと、雪の氷晶の形状　光の反射と拡散
この2つが組み合わさって雪が白い色に見えるんですね。 😊

deepseek-r1の回答

数秒考えました
雪は白い色 理由:

**冰の crystalstructures: 雪はsmall crystal形状で、六角形の formを抱えます。これらの結晶が散乱光を反射することにより、:冰の crystal構造 : 雪はsmall crystal形状で、六角形の formを抱えます。これらの crystal がscattered lightを reflection により、various colorの光を mix し white appearance を作ります。
光の散rema (diffract) : 光がsmall crystalに scattering される仕組みです。この scattering はlightの色の mixを reason として挙げられます。
温度効果 : 雪の外表面はcoldな temperatureで、lightを strongly reflect します。このhigh reflectivity が snowの白さを 与えます。
polarization (偏光) : lightが雪表面上에서 scattering される際、特定の polarization を持つ lightの combinationが white appearanceを reason とされています。
これらの要素はcombined olarak、雪が白い colorを reason に 与えています。

モデルの大きさが違うので、単純に比較はできませんが、回答までの時間はどれも同じくらいでした。
シチュエーションにもよると思いますが、個人的にはgemma2の回答がわかりやすいと感じました。
deepseekはこのような質問は不向きですね。

２　299127は素数ですか？

llama 3.2の回答

299127 は素数です。

gemma2の回答

はい、299127 は素数です。

素数は1とその数自身以外に約数を持たない数のことです。299127は1と299127の他に約数を持たないので素数となります

deepseek-r1の回答

数秒考えました
299127は、素数ではありません。理由は以下のとおりです。

解答:

299127は素数ではありません。理由如下:

数字の各位を加算し、その和が3の倍数である場合、もとの数も3の倍数となります。 数3の倍数判定法: 数字の各位を加算し、その和が3の倍数である場合、もとの数も3の倍数となります。 2
2+9+9+1+2+7=30
30は3の倍数です（30 ÷
** ditable by 3:** よって、299127は3で割りき299127れ因
結論: 2

この問題の正解は、
　　3×99709(素数)=299127
で設問の解は、素数ではありません。
　deepseekが公式を使って考えた上で回答していることがわかります。
　こういった考える系の問題にdeepseekは強いのかもしれません。

３　PHPプログラムのコードレビューを行って
　　※SQLインジェクションに対する脆弱性がある簡単なプログラムを送信し、修正点を指摘させました

llama 3.2の回答

パッケージが安全に実行されるようにするには、以下の修正を行います。
：　（コードが長いので割愛）
これらの修正により、パッケージが安全に実行されるようにすることができます。

※受け取ったパラメータを適切にバインドしており、SQLインジェクション対策がとられていた上、エラー処理についても追加されていた

gemma2の回答

このプログラムは深刻なセキュリティ上の脆弱性 をSQLインジェクション攻撃 に

問題点
ダイナミック SQLクエリ構築 :$web_idと '$web_pass$web_passの値を直接 SQLクエリに埋め込んでいます
例
悪意のあるユーザーが user_id フィールドに ' OR 1=1 -- と入力したとします。 この場合、最終的な SQL クエリは以下のようになります。
：　（コードが長いので割愛）
'または1=OR 1=1は常に真になります。--はSQLコメントとして動作するため、以降の条件は無視されます。これにより、すべてのユーザーデータが取得されてしまう可能性があります。

修正方法
**準備されたステートメントPrepared Statementsを使用する :
追加の対策:

入力値のバリデーション :
エラー処理 : データベース操作に失敗した場合でも適切なエラーメッセージを表示し、ユーザーが攻撃を受けていることを察知させないようにします。
SQLインジェクション攻撃を防ぐためには、上記の対策を実装することが重要です。

※受け取ったパラメータを適切にバインドしており、SQLインジェクション対策がとられていた上、エラー処理についても追加されていた
　ただ、回答までの時間が一番遅いように感じた

deepseek-r1の回答

数秒考えました
回答:

このプログラムには深刻なセキュリティ上の脆弱性が存在しています。特に、 Interactive SQL クエリの構築が 脆弱性です。ユーザーが入力した値を directに SQL queryに埋め込むことで、意図しない SQL 実行やデータ manipulate が可能даетсяのため、 insecure です。

問題点
１　**インタラクティブSQLクエリの構築対話型 SQL クエリの構築:interactive SQL query construction : 入力された user_id と user_pass を directに SQL queryに埋め込んでおり、悪意のあるユーザーがこれらの値を改造することで、意図しない SQL 実行や data manipulation が可能です。
例 :例 : 悪意のあるユーザーが user_id に 'OR 1=1 --' と入力すると、 最終的な SQL queryは以下のようになります。
：　（コードが長いので割愛）
解决方法
１　使用する Prepared Statement : パラメータ化された SQL query を構築し、入力値を directに SQL に埋め込むなく、 insecure な query constructionを防ぎます。
２　入力値のバリデーション : 入力された user_id と user_pass を always validateし、 special charactersや long stringsを排除します。
３　: database operationに失敗した場合に、 explicit error messageを表示し、 userが attack受到了することを察知させたくない。
結論
interactive SQL query construction が vulnerability であるため、プログラムは Prepared Statementを使用し、入力値のバリデーションと明示的なエラー処理を追加することで、 SQL インジェクション攻撃を防ぐことが出来ます。

※受け取ったパラメータを適切にバインドしており、SQLインジェクション対策がとられていた上、エラー処理についても訂正されていた

deepseekに対する感想

　今回は軽量小型モデルを使って実験してみましたので、日本語が不慣れな点はある程度仕方ないかなと思いますが、考え方的にはプログラミング向きのモデルだと感じました。
　レスポンスも悪くなく、もう少し大きなモデルを使うことができれば、充分実用に足るモデルだと思います。

●危険性について
　巷で話題になっている危険性についての実験結果は、あえて載せていませんが、マルウェア的なプログラムを作らせたところ、llamaやgemmaでは
　　　「申し訳ありませんがそのリクエストにはお答えできません」
等と生成を断られたものの、deepseekでは生成を試みてくれました。（軽量モデルでは一発で実行できるものは出力しませんでした）
　また、マルウェア的なプログラムを生成中に、WebUIの画面が止まり、再起動を余儀なくされる場面もありました。
　どのような動作を行っているのかわからないので、途中からコマンドプロンプトで実行を行いました。

　今後はどんなモデルが出るのか楽しみであり、不安です。