在通常被称为“中等数据”项目的工作中，我已经能够在4到32个内核之间的任何一个系统上并行化我的代码（主要用于Python中的建模和预测）。现在，我正在考虑扩展到EC2上的群集（可能使用StarCluster / IPython，但也可以接受其他建议），并且对如何协调实例与群集上实例之间的内核之间的分配工作感到困惑。
跨实例以及跨每个实例的内核并行化甚至可行吗？如果是这样，那么谁能快速总结一下运行许多每个核心很少的实例与少数几个核心很多的实例的优缺点？是否有经验法则来选择每个实例的实例与核心的正确比例？
带宽和RAM在我的项目中不是无关紧要的问题，但是很容易发现何时出现瓶颈和重新调整。我想，要在没有重复测试的情况下将正确的内核混合基准用于实例要困难得多，而且我的项目相差太大，以至于任何一次测试都无法应用于所有情况。在此先感谢您，如果我只是未能正确搜索到此内容，请随时为我指出其他地方的正确答案！
Answers:
使用IPython时，您几乎不必担心它（以牺牲一些效率/更大的通信开销为代价）。默认情况下，StarCluster中的并行IPython插件将在每个节点上的每个物理核心启动一个引擎（我相信这是可配置的，但不确定在哪里）。您只需使用DirectView api（map_sync，apply_sync，...）或％px magic命令即可在所有引擎上运行所需的任何内容。如果您已经在一台机器上并行使用IPython，那么在群集上使用它也没有什么不同。
解决您的一些特定问题：
“如何协调实例上的核心与群集上的实例之间的分配工作” –每个核心（至少）有一个引擎；工作会自动分布在所有核心和所有实例之间。
“跨实例以及跨每个实例的内核并行化甚至可行吗？” -是：)如果您正在运行的代码令人尴尬地是并行的（在多个数据集上使用完全相同的算法），则您几乎可以忽略特定引擎在何处运行。如果核心需要引擎之间进行大量通信，那么您当然需要对其进行结构设计，以使引擎主要与同一台物理计算机上的其他引擎进行通信。但是我认为这种问题并不十分适合IPython。
“如果是这样，那么任何人都可以快速总结一下运行每个核心很少的实例与运行许多核心很多的实例的利弊吗？是否有一个经验法则来为每个实例选择正确的实例与核心的比率？ ” -将最大的c3实例用于计算限制，而最小的c3实例用于内存带宽限制的问题；对于消息传递受限的问题，请使用最大的实例，但请尝试对问题进行分区，以使每个分区都在一台物理计算机上运行，并且大多数消息传递都在同一分区内。在N个四重c3实例上运行的速度比在2N个double c3实例上运行的速度显着慢的问题很少见（人工示例可能是在大量图像上运行多个简单滤镜，其中您遍历了每个滤镜的所有图像，而不是遍历所有滤镜的所有滤镜。同一张图片）。
一般的经验法则是不要分发，除非您必须这样做。通常，拥有一定容量的N台服务器要比容量一半的2N台服务器效率更高。更多的数据访问将是本地的，因此内存访问速度快，而网络访问速度慢。
在某个时候，扩大一台机器变得不经济，因为额外资源的成本比线性增长更多。但是，这一点仍然很高。
但是，特别是在亚马逊上，如果您使用现货市场实例，则每种实例类型的经济状况可能会有很大不同。默认定价或多或少意味着，无论实例类型如何，相同数量的资源成本几乎相同，这可能相差很大。大型实例可以比小型实例便宜，或者N个小型实例可以比一台具有相同资源的大型机器便宜得多。
这里有一个重要的考虑因素是，当您从一台计算机迁移到多台计算机时，计算范例可能会发生很大变化。通信开销引起的折衷可能会迫使您例如采用数据并行范式进行扩展。这意味着工具和算法的不同选择。例如，SGD在内存和Python中看起来与MapReduce完全不同。因此，您必须在并行化之前考虑这一点。
为了提高可靠性，即使您选择单个节点和未分配的范式，也可以选择在整个群集中分配工作。如果单个节点发生故障，则会丢失所有计算；分布式计算可以潜在地恢复和完成丢失的部分计算。