使用 Ollama 将 Qwen2.5 与 Qwen2.5-Coder 部署到本地环境运行，整个过程颇具探索价值。这两款模型来自通义千问系列的最新迭代成果，而本地化部署为我们提供了充分的自由调试空间。今天就来分享实际使用感受，重点对比这两款模型在文本创作与代码任务中的具体表现。

Qwen2.5：文本生成与语言理解能力实测

首先聚焦 Qwen2.5 的文本生成表现。让它创作一首藏头诗，再编写一个适合儿童的睡前故事——这类任务对模型的创意和叙事连贯性有不小的挑战。实际输出相当自然：藏头诗能精准对齐首字，故事结构具备基本的起承转合。作为一款本地可运行的小参数模型，这样的表现已经令人满意。

接着测试语言理解能力。给定一段新闻文本要求模型总结，结果能够准确抓取核心信息，逻辑条理清晰。再尝试中英互译，译文忠实度较高，没有出现明显的机器翻译痕迹。虽然这些任务看似基础，但恰恰是日常使用中最高频的场景，Qwen2.5 应对起来游刃有余。

Qwen2.5-Coder：代码专项深度测试

接下来进入重点环节——代码模型的专项评测。Qwen2.5-Coder 针对编程场景做了专门优化，我们准备了几个典型问题来检验它的实际水准。

迭代器删除元素问题

先看一道经典的 Java 陷阱题：使用 for 循环遍历 List 并执行 list.remove(i)。给定代码后，模型输出的执行结果并不正确——正确答案应为 [b, d]，但模型未能识别出因索引偏移引发的 bug。这说明在底层逻辑分析方面，当前小参数模型仍存在明显盲区。

浮点数精度问题

再测试一个隐蔽的 Bug：浮点数精度丢失。输入一串小数运算结果，模型未能指出系统中常见的 double 精度误差。正确输出应显示类似 0.06999999999999999、0.5800000000000001 这样的数值，说明模型对这类细节的敏感度还有提升空间。

代码改写能力

最后考察代码改写：给出一段求 100 以内素数的 Java 代码，要求将其转换为 Python 实现。模型生成的 Python 版逻辑正确，能够实现等价的埃拉托斯特尼筛法，输出结果也完全准确。这一点值得肯定，表明模型在跨语言迁移方面具备一定基础。

// 原始 Ja va 代码（埃拉托斯特尼筛法）
public class PrimeNumbers {
    public static void main(String[] args) {
        int n = 100;
        boolean[] isPrime = new boolean[n + 1];
        for (int i = 2; i <= n; i++) {
            isPrime[i] = true;
        }
        for (int factor = 2; factor * factor <= n; factor++) {
            if (isPrime[factor]) {
                for (int multiple = factor * factor; multiple <= n; multiple += factor) {
                    isPrime[multiple] = false;
                }
            }
        }
        System.out.println("Prime numbers up to " + n + ":");
        for (int i = 2; i <= n; i++) {
            if (isPrime[i]) {
                System.out.print(i + " ");
            }
        }
    }
}

从实际执行效果来看，改写后的 Python 版本能够正确输出素数列表，模型在该任务上的表现达到预期。

总结与使用建议

坦诚地说，本次测试使用的是参数规模较小的本地下载版本，并不能完全代表 Qwen2.5 系列的真实上限。有条件的朋友可以尝试参数更大的版本，效果会更为惊艳。

不过对于个人本地使用而言，这些小模型已经是相当不错的选择——在国内开源模型中，通义千问系列无疑是表现最出色的之一。配合本地 Web-UI 框架（如 ollama-webui），即使没有独立显卡也能流畅运行，响应速度也并不慢。如果你只是日常写写文案、调几段代码，这套方案完全够用了。