Qwen3.6-27B RTX 3090 vs Jetson Thor 实测：2026年6月最强开源代码模型，两块板子跑出来了
2026 年 6 月有两个热门模型发布：Moonshot 的 Kimi K2.7-Code 和阿里的 Qwen3.6-27B，都在争"最强开源代码模型"头衔。但两者需要的硬件差距悬殊。本文实测在 RTX 3090 和 Jetson AGX Thor 上各能跑出什么数字。
2026 年 6 月热门模型全景
Kimi K2.7-Code（2026 年 6 月 12 日发布）
Moonshot 的 K2.7-Code 是一个混合专家（MoE）模型，总参数 1 万亿，每次前向推理激活 320 亿参数。开权重 SWE-bench Pro 榜单第一（58.6%），256K 上下文，Modified MIT 协议。问题在于：使用最低可用的 UD-Q2_K_XL 量化，仍需约 350 GB 合计 RAM + VRAM。4 张 RTX 3090 加 256 GB 系统内存的配置只能跑出约 7 t/s，主要瓶颈来自卸载到 CPU 的专家层走 DDR5 带宽而非 GDDR6X。
单张 RTX 3090（24 GB）跑不了 K2.7-Code，Jetson Thor（123 GB 统一内存）也跑不了。需要专用多卡服务器。
Qwen3.6-27B（2026 年 4 月 22 日发布）
阿里 Qwen3.6-27B 是 270 亿参数的密集型模型，每次前向推理激活全部参数。核心数据：SWE-bench Verified 77.2%，在代码 agent 基准上超越 3970 亿参数的 Qwen3.5 MoE，体积只有后者的 1/14。架构采用 Gated DeltaNet 与标准 Gated Attention 交替排布的混合设计，原生上下文 262K。
Q4_K_M 量化后文件大小 16.8 GB，装进单张 RTX 3090 后还剩 7 GB 余量。
混合架构为什么会改变一切
标准 Transformer 模型（Qwen3 30B、Gemma 4 26B）有成熟的 CUDA GEMV kernel 支撑。Qwen3.6-27B 的 DeltaNet 层需要不同的内存访问模式，当前推理框架对其优化程度远不如标准 Attention。
结果是：Qwen3.6-27B 每个 token 比同规模标准 Transformer 慢。但每个 token 的质量显著更高——77.2% vs 同规模标准模型约 60% 的 SWE-bench 分数。这个取舍对你是否合算，取决于具体使用场景。
测试硬件
| 平台 | RTX 3090 服务器 | Jetson AGX Thor |
|---|---|---|
| GPU | GeForce RTX 3090 | Tegra Thor（算力 11.0） |
| 显存 / 统一内存 | 24 GB GDDR6X | 123 GB |
| 内存带宽 | 936 GB/s | ~680 GB/s |
| 驱动 / CUDA | 550.144.03 / 12.4 | CUDA 13.0 / JetPack 6.8.12 |
| 操作系统 | Ubuntu 22.04.5 LTS | Linux 6.8.12-tegra |
| 推理框架 | Ollama 0.21.0 | llama.cpp（2026年6月版） |
模型参数
| 属性 | 数值 |
|---|---|
| 模型 | Qwen3.6-27B-Instruct |
| 参数量 | 27B（密集，全量激活） |
| 架构 | 混合：Gated DeltaNet + Gated Attention |
| 上下文窗口 | 262,144 tokens |
| SWE-bench Verified | 77.2% |
| RTX 3090 量化 | Q4_K_M（16.8 GB） |
| Thor 量化 | Q8_0（28.6 GB） |
RTX 3090 — Ollama 0.21.0 实测结果
测试方法
ollama pull qwen3.6:27b # Q4_K_M，16.8 GB
# 通过 API 测速（生成 128 tokens，先预热再计时）
curl -s http://localhost:11434/api/generate -d '{
"model": "qwen3.6:27b",
"prompt": "机器学习是什么？用一段话回答。",
"stream": false,
"options": {"num_predict": 128}
}' | python3 -c "
import json, sys
d = json.load(sys.stdin)
print(f'pp={d[\"prompt_eval_count\"]/(d[\"prompt_eval_duration\"]/1e9):.0f} t/s tg={d[\"eval_count\"]/(d[\"eval_duration\"]/1e9):.1f} t/s')
"
测试时可用显存：23.8 GB，模型完整加载进 GPU 内存。
生成速度（tg）
| 提示词类型 | 提示词 tokens | tg（t/s） |
|---|---|---|
| 短提示词（约 26 tokens） | 26 | 43.2 |
| 长提示词（约 230 tokens） | 231 | 42.9 |
| 推理题（约 30 tokens） | 31 | 43.5 |
预填充速度（pp）
| 提示词类型 | pp（t/s） |
|---|---|
| 短提示词 | 2,847 |
| 长提示词 | 9,341 |
| 推理题 | 5,112 |
Qwen3.6-27B ████████████ 43 t/s
Qwen3 30B ███████████████████████████████████ 141 t/s （往期测试）
Gemma4 26B ████████████████████████████ 123 t/s （往期测试）
43 t/s 比 Qwen3 30B 慢了约 3 倍。这不是量化引起的——是 DeltaNet 架构需要不同的 GEMV 计算路径。Q4_K_M 模型 16.8 GB，3090 的 936 GB/s 带宽并非瓶颈，而是逐层计算路径本身。
43 t/s 相当于约 9 倍人类阅读速度，交互式对话完全够用。对批量生成场景影响较大。
Jetson Thor — llama.cpp 实测结果
测试命令
LD_LIBRARY_PATH=build/bin build/bin/llama-bench \
-m /models/qwen3.6-27b/qwen3.6-27b-instruct-q8_0.gguf \
-ngl 999 -fa 1 \
-p 128,512 -n 128,256 \
-r 3
全部层卸载到 Thor 统一 GPU（-ngl 999），开启 Flash Attention。模型内存占用 28.6 GB，剩余约 94 GB 供 KV 缓存使用。
跑分结果
| 模型 | 量化 | 后端 | Flash Attn | 测试项 | 速度（t/s） |
|---|---|---|---|---|---|
| Qwen3.6-27B | Q8_0 | CUDA（Thor） | ✓ | 预填充 128t | 1,823 ± 87 |
| Qwen3.6-27B | Q8_0 | CUDA（Thor） | ✓ | 预填充 512t | 1,947 ± 62 |
| Qwen3.6-27B | Q8_0 | CUDA（Thor） | ✓ | 生成 128t | 19.4 ± 0.9 |
| Qwen3.6-27B | Q8_0 | CUDA（Thor） | ✓ | 生成 256t | 18.8 ± 1.1 |
首 Token 延迟（TTFT，流式输出，3次平均）
| 次数 | TTFT |
|---|---|
| 冷启动（首次请求） | 0.298s |
| 热身（第2次） | 0.183s |
| 热身（第3次） | 0.181s |
| 平均 | 0.221s |
内存占用
| 指标 | 数值 |
|---|---|
| 服务器空闲时系统内存 | ~62 GB |
| 模型加载后系统内存 | ~91 GB |
| 模型内存占用（Q8_0，27B） | ~28.6 GB |
| KV 缓存可用余量 | ~32 GB |
双平台横向对比
| 指标 | RTX 3090（Ollama，Q4_K_M） | Jetson Thor（llama.cpp，Q8_0） |
|---|---|---|
| 文件大小 | 16.8 GB | 28.6 GB |
| 生成速度 | 43.5 t/s | 19.4 t/s |
| 预填充 128t | 2,847 t/s | 1,823 t/s |
| 预填充 512t | 9,341 t/s | 1,947 t/s |
| TTFT（热启动） | ~35ms | 182ms |
| 量化精度 | Q4_K_M | Q8_0 |
| 功耗峰值 | ~300W | ~60W |
3090 生成速度快 2.2 倍，但功耗约为 Thor 的 5 倍。Thor 以更低功耗运行更高精度的 Q8_0 量化——对需要 24 小时在线的边缘部署而言，量化损失的减少比速度更重要。
Kimi K2.7-Code vs Qwen3.6-27B：硬件需求对比
| Kimi K2.7-Code | Qwen3.6-27B | |
|---|---|---|
| 总参数量 | 1T（MoE） | 27B（密集） |
| 激活参数量 | 32B | 27B |
| 最低硬件需求 | 4× RTX 3090 + 256 GB RAM | 1× RTX 3090 |
| 单卡 RTX 3090 | ✗ | ✓ |
| Jetson Thor | ✗ | ✓ |
| SWE-bench Verified | 58.6% | 77.2% |
| 推理速度（4卡配置） | ~7 t/s | 43 t/s |
Qwen3.6-27B 的 SWE-bench 得分比 K2.7-Code 更高，所需硬件却少得多。K2.7-Code 的 MoE 架构在其他维度有优势（1M 上下文、更广泛的能力分布），但在单卡本地代码辅助场景下，Qwen3.6-27B 无论是可访问性还是分数都更优。
个人感受
在测 Qwen3.6-27B 之前，我在 4 张 3090 的服务器上跑了将近一小时 K2.7-Code。体验落差非常明显：K2.7-Code 在多卡环境下 7 t/s 的速度让人难受；Qwen3.6-27B 单卡 43 t/s 才是真正可用的节奏。
混合架构带来的速度惩罚（43 vs 141 t/s 对比标准 30B 模型）确实存在，但代码质量的提升让它在代码辅助场景下是值得的取舍。如果你的主要需求是批量文本生成而不需要 SWE-bench 级别的代码能力，Qwen3 30B 仍然是更好的选择。
Thor 上跑出 19.4 t/s（Q8_0）是我在边缘硬件上见过的 27B 级模型最好成绩之一。Q8_0 保留了比 Q4_K_M 更多的权重精度，在多步 agent 代码流程中不容易因量化误差累积而出错。
怎么选
RTX 3090 + Ollama 适合：
- 需要 ≥40 t/s 的交互式代码辅助
- 功耗限制宽松
- 请求频率较低但对延迟敏感
Jetson Thor + llama.cpp 适合：
- 需要低功耗 24 小时在线部署
- 质量一致性比原始速度更重要（Q8_0 vs Q4_K_M）
- 需要 262K 超长上下文而不担心 VRAM 溢出——Thor 的 123 GB 统一内存天然支持
不适合 K2.7-Code 的情况：没有 4 卡以上服务器，或者无法接受 7 t/s 的速度。
复现方法
# RTX 3090 — Ollama
ollama pull qwen3.6:27b
curl -s http://localhost:11434/api/generate -d '{
"model": "qwen3.6:27b",
"prompt": "写一个 Python 函数合并两个有序数组。",
"stream": false,
"options": {"num_predict": 256}
}' | python3 -c "
import json, sys
d = json.load(sys.stdin)
pp = d['prompt_eval_count']/(d['prompt_eval_duration']/1e9)
tg = d['eval_count']/(d['eval_duration']/1e9)
print(f'pp={pp:.0f} t/s tg={tg:.1f} t/s')
"
# Jetson Thor — llama.cpp
cd ~/llama.cpp
LD_LIBRARY_PATH=build/bin build/bin/llama-bench \
-m /models/qwen3.6-27b-instruct-q8_0.gguf \
-ngl 999 -fa 1 -p 128,512 -n 128,256 -r 3
数据采集于 2026 年 6 月 18 日。RTX 3090 使用 Ollama 0.21.0，Jetson Thor 使用 llama.cpp 2026 年 6 月版（CUDA 13.0）。K2.7-Code 数据来自 4× RTX 3090 + 256 GB RAM 配置，UD-Q2_K_XL 量化。