【基建】大模型初体验：本地部署or云端调用api

目标：vscode 代码补全+对话，轻度使用

针对 MacBook Air M1 + 24GB 统一内存配置，四个方案的核心差异整理如下：

📊 方案对比总览

维度	方案一：Ollama + Qwen2.5-Coder 7B	方案二：LM Studio + Qwen3.5-9B MLX	方案三：Claude Code 插件 + 云端	方案四：阿里百炼 API 调用
模型能力	Qwen2.5-Coder 7B，代码生成扎实	Qwen3.5-9B-Sushi-Coder-RL，社区微调增强版	Claude 云端模型，代码理解/Agent 能力顶级	千问 Coder 全系列，可选云端大模型
推理速度	~15-25 token/s（GGUF 格式，基准性能）	~30-40 token/s（MLX 格式，约 2 倍于 Ollama）	取决于网络，通常 80-150 token/s	取决于网络，云端算力充沛
内存占用	~5-6 GB	~6-7 GB（模型稍大）	极低（仅插件本身）	极低（仅 API 调用）
数据隐私	✅ 完全离线，数据不出电脑	✅ 完全离线，数据不出电脑	❌ 代码需上传 Anthropic 服务器	❌ 代码需上传阿里云服务器
费用	免费	免费	按量付费，深度思考消耗大量 credits	按量付费，约 0.004 元/千 tokens（输入）
联网依赖	仅下载模型时需要	仅下载模型时需要	全程需要	全程需要
配置复杂度	简单（3 条命令）	中等（GUI 操作，需切换 MLX 后端）	中等（需 Anthropic 账号和 CLI 配置）	简单（获取 API Key 后填配置）

🔬 各方案详细分析

方案一：Ollama + Qwen2.5-Coder 7B

• 优势：上手最简单，ollama run qwen2.5-coder:7b 一条命令即可；Continue 原生支持 provider: ollama，配置极简。
• 劣势：截至 2026 年 3 月，Ollama 对 Qwen 3.5 系列存在兼容问题（工具调用/视觉功能异常）；GGUF 格式在 M1 上性能不如 MLX，速度约为方案二的 一半。
• 适用：追求开箱即用、对极致速度不敏感的场景。

方案二：LM Studio + Qwen3.5-9B MLX

• 优势：MLX 是苹果原生框架，专为 M 芯片优化，统一内存架构下实现零拷贝张量操作，生成速度约为 Ollama 的 2 倍；图形界面友好，模型管理可视化；9B 参数 + 社区 RL 微调，代码质量优于 7B。
• 劣势：需手动切换后端为 MLX（默认为 llama.cpp）；模型需单独下载 MLX 格式（GGUF 不兼容 MLX 加速）。
• 适用：追求 M1 上最佳本地性能，愿意花 10 分钟配置。

方案三：Claude Code 插件 + 云端模型

• 优势：Claude 在代码理解和 Agent 任务规划方面能力顶级；插件可直接在 VSCode 中使用，支持 /ide 命令、plan 模式、深度思考等高级功能。
• 劣势：完全依赖网络，代码需上传；深度思考模式消耗大量 credits，成本不可控；国内访问 Anthropic 服务可能不稳定。
• 适用：需要顶级代码 Agent 能力、不在意数据出站的场景。

方案四：阿里百炼 API 云端调用

• 优势：可调用千问 Coder 全系列（包括 480B MoE 大模型），能力远超本地 7-9B；API 兼容 OpenAI 格式，Continue 配置简单；国内网络延迟低、稳定；新用户有 90 天 100 万 tokens 免费额度。
• 劣势：按量付费，高频使用需关注成本；数据需上传阿里云服务器。
• 适用：需要最强模型能力、可接受数据上云的场景。

💡 最终建议

在你的 M1 24GB 配置上：

你的偏好	推荐方案
追求本地最佳性能 + 免费	方案二（LM Studio + Qwen3.5-9B MLX）——MLX 速度优势明显，24GB 跑 9B 游刃有余
追求极简配置 + 够用就好	方案一（Ollama）——但需接受 Qwen3.5 兼容性风险和较慢的速度
追求最强能力 + 不在意隐私/费用	方案四（阿里百炼 API）——云端大模型能力远超本地，国内延迟低
需要 Agent 级编程体验	方案三（Claude Code）——但需评估网络和成本

混合策略推荐：日常代码补全用 方案二（本地 MLX），复杂重构/长文本理解时切 方案四（阿里百炼 API），兼顾隐私、速度与能力。Continue 插件支持同时配置多个模型，一键切换即可。